Models Derived from Automatically Analyzed Textual User Requirements

Ilieva, Magda; Ormandjieva, Olga

doi:10.1109/sera.2006.51

Cited by 26 publications

(21 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…After eliminating duplicates, 361 papers remained to be further investigated. After filtering the results (361 papers) of the electronic search by applying the inclusion/exclusion criteria, we identified 11 papers [6,14,19,21,24,25,36,40,48,51,54] to include. The manual search of journals and conference proceedings yielded an additional six primary studies (i.e., [10,17,18,20,47,49]), and two of them (i.e., [18,49]) are more recent discussions and therefore replaced two of the 11 papers identified from the electronic search (i.e., [19,48]).…”

Section: Statistics From Included Primary Studiesmentioning

confidence: 99%

“…Nine approaches can generate behavioral features of a system (e.g., sequence diagrams, state machines, and/or activity diagrams). Three approaches ( [24], [18,35,44] and [10]) (highlighted) conforming to configuration 1 are capable of generating analysis models including both structural and behavioral aspects of a system, which are characterized as complete according to our evaluation criteria (Sect. 4.2); two approaches ( [6] and [25]) (highlighted) conforming to configuration 2 and 4, respectively, can also generate complete analysis models.…”

Section: Analysis Modelsmentioning

confidence: 99%

“…4.2); two approaches ( [6] and [25]) (highlighted) conforming to configuration 2 and 4, respectively, can also generate complete analysis models. The generated domain models of the approach proposed in [24], conforming to configuration 1, contain only objects and links, rather than commonly used class diagram representations; the generated hybrid activity diagrams (i.e., UML activity diagrams also including the concepts of actors, business rules, and messages) are at a very high level of abstraction, and are independently generated from the generated domain models (i.e., there might be inconsistencies between the two diagrams). The NIBA project [18,35,44], also conforming to configuration 1, can derive class, activity, and state machine diagrams from requirements.…”

Section: Analysis Modelsmentioning

confidence: 99%

“…Eight approaches use intermediate models (containing Step 2), when direct transformation from requirements to an analysis model cannot be achieved. Two intermediate models (three transformations, and therefore Step 3 is required) are contained in [6], [24], and [34,52] According to our evaluation criterion on efficiency of approaches, the approach proposed in [45,49] shows highest efficiency because it does not need any requirements pre-processing technique and requirements are directly transformed into analysis models. Note that it does not make sense to evaluate the efficiency of manual approaches so their efficiency is marked as ''N/A''.…”

Section: Transformation-efficiencymentioning

confidence: 99%

“…Nine ( [36], [21], [34,52], [24], [18,35,44], [10], [17], [54], and [4]) out of 16 approaches describe their transformation rules in their primary studies but none of them evaluate the completeness of the transformation rules. Five ( [6], [14], [20], [45,49] and [40]) out of 16 approaches do not describe their transformation rules at all.…”

Section: Completeness and Structuredness Of Transformation Rulesmentioning

confidence: 99%

See 4 more Smart Citations

A systematic review of transformation approaches between user requirements and analysis models

2010

View full text Add to dashboard Cite

Model transformation is one of the basic principles of Model Driven Architecture. To build a software system, a sequence of transformations is performed, starting from requirements and ending with implementation. However, requirements are mostly in the form of text, but not a model that can be easily understood by computers; therefore, automated transformations from requirements to analysis models are not easy to achieve. The overall objective of this systematic review is to examine existing literature works that transform textual requirements into analysis models, highlight open issues, and provide suggestions on potential directions of future research. The systematic review led to the analysis of 20 primary studies (16 approaches) obtained after a carefully designed procedure for selecting papers published in journals and conferences from 1996 to 2008 and Software Engineering textbooks. A conceptual framework is designed to provide common concepts and terminology and to define a unified transformation process. This facilitates the comparison and evaluation of the reviewed papers.One of the basic principles of Model Driven Architecture (MDA) [29] is model transformation. To build a software system, a series of transformations is performed: transformation from requirements to Platform Independent Model (PIM) (the analysis model), transformation from PIM to Platform Specific Model (PSM) (the design model), and transformation from PSM to code. However, the transformation from requirements to an analysis model is not part of the MDA lifecycle, which starts from an analysis model and ends with deployed code [29]. The reason of this exclusion is perhaps that requirements are mostly in a textual form, which is not a model formal enough to be understood by computers. As a result, requirements are not suitable for automated transformations, and only manual heuristics, such as Abbott's heuristics [4], are in general followed [9,32]. However, if a (semi-) automated transformation technology from requirements to an analysis model were devised, it would help fill an important gap in the MDA software development lifecycle.If these transformations can be automated, full traceability from requirements (through PIM and PSM) to the ultimate software code can be obtained at the same time. Traceability is the ability to link requirements to corresponding analysis and design models, code, test cases, and other software artifacts. Traceability is important during software development because it enables engineers to understand the connections between various artifacts of a software system, and it is also used to determine whether

show abstract