A Semi-Automated Approach for Deriving UML Use Case Elements from Functional Requirements

In systems engineering, the requirements analysis phase constitutes the most critical stage of the development process. The primary objective of this phase is to define requirements documents with precision and clarity. Such requirements are typically expressed in natural language; however, natural language descriptions are often ambiguous, unstructured, and prone to misinterpretation. It is therefore necessary to analyze natural-language requirements and translate them into a formal specification, such as Unified Modeling Language (UML). Object-Oriented Analysis and Design (OOAD), which represents system domains using UML diagrams, plays an essential role in modern software development by bridging the gap between informal requirements and rigorous, implementable system models [1, 2].

The task of converting user requirements into UML diagrams falls to human analysts. Money, time, and effort are all heavily invested in this process. Furthermore, inconsistency and ambiguity are examples of natural language problems that can lead to errors. Because of all of this, semi-automated or automated support is required [3, 4].

Among the methods for describing the functional requirements is the UML use case diagram. The information is extracted using Natural Language Processing (NLP) since the requirements have been written in natural language. Text information extraction was accomplished using NLP [5, 6].

NLP is typically utilized for transforming extracted data to a machine-understandable format. However, ambiguous situations and different NLP approaches result from the grammar rules and various natural language structures [7, 8]. These days, NLP is widely employed in a variety of applications that take human-computer interaction (HCI) into account. One of the most important tasks in the software lifecycle phases is creating UML use case diagrams as part of the software analysis. Understanding system requirements is aided by the creation of use case diagrams. Yet, because system requirements need investigation, it takes time to create use case diagrams [9]. The UML's use case diagrams show how the system communicates with outside parties (actors) to accomplish a task. The external entity interacting with the system is known as the actor. It could be a system, user, device, company, and so on [10, 11]. Apart from the actor, the use case diagram illustrates the capabilities of the system through the use cases and their relations. Despite efforts, making a use case diagram with NLP remains a difficult task.

The Random Forest (RF) algorithm, a machine learning (ML) approach, and NLP are used in the presented study to suggest a novel method for creating a UML use case diagram. While NLP examines the functional requirements, the designed solution expedites the process by performing early spelling checks. The system recognizes parts of speech (POS) and assigns particular grammatical patterns to English sentences through segmenting them. After that, it first determines the use case and the actor. The RF algorithm is used for eliminating unwanted actors, duplicates, and use cases. The use case diagram is then drawn. Our study's primary contributions are:

1. We have developed an algorithm for extracting actors, relationships, and use cases from the functional requirements. Both external and primary actors are extracted by our method.

2. Our suggested method is validated by using literature-based case investigations, which demonstrate its importance in contrast to the novel method.

3. It employs NLP and the RF algorithm for element extraction as well as graph visualization.

4. For evaluating outcomes from literature-based case studies, we utilized recall and precision. Our method produces significant outcomes.

The remainder of the present study is structured as follows: Section 2 presents the literature that is reviewed in related work. Section 3 describes the software requirements, NLP, and the RF algorithm. Section 4 explains how the suggested method is used. Section 5 presents the case study's specifics, findings, and a comparison with an existing method. Finally, the study's conclusion comes last in Section 6.

Before beginning the research methodology, there is a need to understand the technical background necessary to implement the proposed approach. These techniques include:

3.1 Create software requirements

The descriptions of what a system must accomplish, the services it offers, and limitations on how it can operate are called requirements. Customers' needs for a system that fulfills a specific function, such as placing an order, controlling a device, or locating information, are reflected in such criteria. The procedure for analyzing, finding out, checking, and documenting such limitations and services. In the software industry, the term "requirement" isn't always utilized consistently [20, 21].

Sometimes a requirement is just a limitation on a system or a high-level, abstract specification of a service that must be offered by a system. It is a thorough, formal definition regarding a system function at the other extreme. Since various readers use requirements differently, they must be read by managers who are not interested in the system's specific features and aren't worried about how the system will be implemented. Since they're involved in system implementation or are interested in the way that the system will support business activities, system requirement readers need to know more specific information about what will be performed by the system [22].

Non-functional and functional requirements are two common categories for software system requirements:

1- Functional requirements, which represent statements of the services that a system should provide [23].

2- Non-functional requirements, which include constraints on functions or services that are offered by the system, including constraints on timing and constraints on the process of development, in addition to the constraints that are imposed by the standards. Non-functional requirements [24, 25].

The use case diagrams in these papers were built based on functional needs. They were extracted from the systems' Software Requirements Specifications (SRS) documents in order to meet functional requirements.

3.2 Natural Language Processing

A field in AI and ML called NLP enables devices to comprehend and work with natural human language. Additionally, to eliminate the need for human processing, natural language requirement texts are analyzed and processed using NLP methods [26]. After receiving the functional requirement text, the suggested study applies various NLP methods to the input text, which include multiple processes:

1. Spelling and grammar correction: It may be that the given functional requirement contains grammatical errors; it will result in predictions that are not accurate. So, one of the vital tasks is grammatical error correction in the area [27]. This suggested method will be applied. The Gingerit library will perform the detection as well as the correction of typing errors in text. This step involves taking the functional requirement as input, fixing any grammar errors, and then passing the grammatically accurate functional requirement to the NLP model.

2. Tokenization: With the use of sentence segmentation, separate into sentences (functional requirement). The sentences will next be divided into individual words with the use of word tokenization. For instance, following tokenization, "I love to cook food" will become [love], [I], [cook], [to], [food]. These techniques aid in carefully going over every word [28].

3. POS tagging is carried out. POS offers useful data regarding tokens or words [14]. To determine if a word is a verb, numeral, noun, preposition, pronoun, adjective, article, interjection, or conjunction, POS tagging is employed [29, 30].

4. Dependency parsing: Every word in the sentence will be subjected to dependency parsing, a method for examining the grammatical relationships between words. The sentence's tokens, or words, might be broken down according to the grammatical relation to produce a tree or graph data structure. The use of dependency parsing results in a precise NLP model. When a sentence does not have a "PRON" (pronoun) in POS tagging, the algorithms could use the "nsub" dependency parser to determine the sentence's subject. After that, it might determine the sentence's verb and object. The dependency parser regarding "dobj" will be used for identifying the object, and POS tagging of "VERB" will be used for identifying the verb [31].

5. Lemmatization: Lemmatization will be done to the subject, verb, and object after they have been identified. As indicated in Table 2, lemmatization can be defined as the procedure of converting a word or token to its root word [32, 33].

6. Identify actors and use cases: the verb-object combination will be recognized as the use case, and distinct subjects will be recognized as actors.

7. Determine the relationship of association between the use cases and actors. This relationship will be determined as follows: following the identification of a new actor, all subsequent use cases are regarded as those of that actor until the emergence of a different and new actor. A dictionary data structure will hold the use case diagram's extracted data.

Table 2. Word and its lemmatization

3.3 Random Forest algorithm

One ML model employed for classification and forecasting is the RF. A considerable amount of high-quality data is highly important for the efficient collection of data to train AI models and ML algorithms. System performance data is necessary for improving hardware and software efficiency, assessing user behavior, optimizing algorithms, and facilitating pattern recognition, predictive modeling, decision-making, and problem-solving [34, 35].

Several decision trees are generated to build RFs. This is accomplished by selecting input features at random and collecting random data samples with the use of bootstrap samples. Every decision tree is regarded as being simple [36]. Instead of using the original sample, bootstrap samples are used to build each tree. This lessens overfitting and is referred to as bootstrap aggregating, or just bagging [37].

Individual decision trees are simply interpretable, yet such interpretability is lost in RFs due to the accumulation of multiple decision trees (DTs). RFs, on the other hand, frequently outperform other prediction methods. In comparison with DTs, the error rate is more precisely calculated using the RF algorithm. More specifically, it has been mathematically proven that the error rate always converges as the number of trees increases [38].

The high accuracy of RFs in comparison to other methods like boosting and bagging is one of their advantages. Additionally, they work well with large databases and have a large variable capacity, which enables us to examine thousands of input variables without removing any of them. An unbiased estimation of the configuration error is required for balancing the category error in unbalanced data sets and evaluating the significance of variables; these benefits show the effectiveness and power of RFs. Because randomization works well in several real-world applications, it is an often-utilized method in ML and DM [39, 40].

The process starts with a dataset that contains rows and the class labels (columns) that correlate to those rows (Figure 1).

Figure 1. The Random Forest (RF) algorithm in machine learning

• After that, the training data is used to generate several DTs. A random subset of features and a random subset of data (with replacement) are used for training each tree. This method is referred to as bootstrap aggregating or bagging.

• The ensemble's DTs each develop their own prediction skills.

• Every DT in the ensemble produces a prediction in response to an unseen, new instance.

All of the DTs' predictions are combined to get the final prediction. Usually, a majority vote is used for classification, while averaging is used for regression.

The natural work of RF is that whenever the input space is partitioned into subsets represented in B, draw a bootstrap sample, randomly select a subset, and predict optimally, as shown in Algorithm 1.

A dictionary data structure containing use cases, actors, and association relationships is obtained from the NLP model using the RF, which is the technique suggested in these papers. To improve the filtering, selection, and elimination of unnecessary actors, use cases, and relationships from the data structure in the NLP model, the RF algorithm will be employed. The developed methodology was applied to a set of databases containing 1300 functional requirements (statements in the English language) taken from several systems [41] (such as THEMAS, The Energy Management System, E-GOVERNANCE MISSION MODE PROJECT, and Clarus Weather System). The RF algorithm was trained on 80% of this data and tested on 20% of it. RF is a supervised classification technique that performs classification through a straightforward yet efficient probabilistic approach. The modified data structure will be sent to the model of diagram generation once the actor, use cases, and relationships that are no longer needed have been filtered out.

Figure 4. Use case diagram for library management system

To evaluate the current technique (NLP and RF), the proposed algorithm was applied to databases supervised by the Italian National Research Council (ISTI-CNR) [41] that contain:

1. The E-Store Project

The project contains 62 functional requirements, distributed across 20 logical groups (e.g., account management, shopping cart operations, payment processing). The requirements were extracted from the original project documentation, focusing on identifying "actors" and "use cases." Consistency was maintained through rule-based validation, where each requirement follows a fixed format: [subject + verb + object]. This set represents a multi-class classification, providing a ratio of 3.1 requirements per class, thus testing the model's ability to differentiate between closely related classes.

2. The Inventory System

The Total Functional Requirements are 25 and categorized into 11 groupings (e.g., Stock Tracking, Low-stock Alerts, Supplier Management). With only 2.2 requirements per group, this system represents a challenging "few-shot learning" scenario. A model trained on this must generalize from extremely limited examples per class.

Annotation focused on entity-relationship extraction. Labels were applied to identify the "Object" (the inventory item) and the "Action" (update, delete, add), as the system follows a strict CRUD (Create, Read, Update, Delete) logic, making the labels highly predictable and discrete.

3. Philips System (Medical/Health Electronics)

Total Functional Requirements are 24 distributed across 19 groupings. This is the most granular system in the set. Almost every requirement represents its own unique functional group. This is used in ML to test uniqueness detection and outlier detection, as there is almost no overlap between categories. Consistency is verified against the ISO/IEC 29148 standard for requirements engineering, ensuring that the terminology (e.g., "shall," "must") is labeled uniformly across the 19 groups.

4. Total Functional Requirements are 23

Unlike the others, these are often treated as a singular functional block or analyzed for Non-Functional Requirement (NFR) cross-cutting concerns (like privacy and security). Used primarily for binary classification (Functional vs. Non-Functional) rather than multi-group categorization. Annotations were derived from the classic Sommerville Software Engineering case study. The labels focus on "Patient Privacy" and "Clinical Safety" tags.

Because this is a well-known pedagogical system, labels have been vetted by multiple researchers in the NLP4RE community, leading to high inter-annotator agreement, as shown in Table 4.

The outcomes, using several measures including recall and precision, were contrasted with the findings of the study [9].

According to Table 5 and Figures 5 and 6, recall shows the percentage of all actual positives that have been correctly identified, whereas precision shows how well the positive predictions performed.

Table 4. Description of the data set

Table 5. Experimental evaluation results

Figure 5. Chart of precision for the proposed method and the Natural Language Processing (NLP) method

The introduced framework was evaluated with the approach followed in applying a machine learning framework based on NLP [18] on users' stories. The result of the accuracy metric is equal to 75.52% for research [18], while the accuracy metric of the proposed method is equal to 77.8%.

Figure 6. Chart of recall for the proposed method and the Natural Language Processing (NLP) method

Based on the analysis of the output and depending on the analysis of the difficulties that complex sentences may encounter [42], the errors encountered in the proposed study can be divided into three main categories:

1. Linguistic and grammatical errors resulting from the complexity of sentence structure, such as the problem of conjunctions and pronouns (anaphora).

2. Semantic errors: resulting from the use of synonyms or multiple names for the same entity (e.g., User vs. Staff vs. Student).

3. Filtering and merging errors: resulting from the difficulty of merging similar requirements that differ in their wording