Enhancement of Requirements Traceability with UML Class Diagram
Mina Zahid 01-241181-012Sana Wajid 01-241181-022
Department of Software Engineering
Bahria University Islamabad
Requirements Traceability is an important phase that assists in requirements validation and change management. Requirement traceability is most important part of requirement management phase in requirement engineering process. It is not addressed properly then it results failing the software product. In agile as we all know requirements change rapidly and we have very short time to map them and finalize them for future development. UML is mostly use for recording user requirements in document so here we find id most compatible tool for solving our problem by making a frame work based on its 3 diagrams. We are proposing an approach to enhance our traceability by using class diagram. We make class diagram with the help of simple use case and activity diagram. In the end we have a class diagram which present an effortless framework to trace requirements in backward in agile development.
Keywords: Requirement traceability, UML diagrams, use case diagram, Activity diagram, class diagram, agile development.
Software requirements keep on evolving not only during the analysis and development of product phase but also after the product is launched. The requirements management process has a vital role in managing and keeping records of these requirements changes. Requirements management can be well achieved if the relationships, the root and type of requirements is correctly identified. Requirements traceability serves the purpose. Requirements traceability is defined as “the ability to describe and follow the life of a requirement in both directions towards its origin or towards its implementation, passing through all the related specifications state”. CITATION Pat l 1033 2 In this research a model is proposed based on the UML Use Case diagram for implementing the backward requirements traceability. Use Case diagram is a graphic depiction of the interactions among the elements of a system. A use case is a methodology used in system analysis to identify, clarify, and organize system requirements.
Requirements traceability analysis is used to verify that the software design implements the specified software requirements as well as that all the code is linked to established specifications. CITATION Gui05 l 1033 3 Software traceability is an essential element of the software development process CITATION Jan l 1033 4.
The requirements traceability is an important domain in software development process and a lot work is being done in it in recent decade but during the literature review its been observed that most of the practitioners in industry do not pay much attention to it.
This section briefly explains the research work done in traceability field. Research on requirements traceability has been done and many methods and techniques have been proposed for Requirements traceability. There is, however, no single technique that can be said to as the best suitable traceability strategy. One of them is the Requirements traceability matrix, which is a tool that is used to determine the relationship between the requirements and the source of those requirements. A study proposed the use of state diagrams to improve the requirements traceability matrix. But in the longer run, many complexities arise when using traceability matrices.
Another research improvised a goal oriented road map for requirement traceability whose focus was to provide cost effective, portable, trusted, scalable and valued traceability. Need for traceability serves helpful in conducting the traceability according to the research.
A process oriented approach was also presented which the researchers proposed the traceability as a strategical process which is first planned and strategized and then implemented.
Here we are proposing a model of requirement traceability by using different uml diagrams first we start with a simple use case diagram then we add different more activities and made an activity diagram which is a little more complex and after this we develop a class diagram by using previous diagrams and enhance traceability of requirements. This model is mostly used in agile development where we have very short time to map our requirement and I a change is occur by user this mode presents a backward traceability method which directly take us to requirement origin.
Figure STYLEREF 1 s 3. SEQ Figure * ARABIC s 1 1Case diagram of proposed model
This use case show that traceability is triggered by the stakeholder and or stakeholder specifies the prediction of traceability by wanting change in state of previous requirements. When we are predicating traceability, we make sure that there is change that needs backward traceability in our requirements. After this we create a proper traceability requirement and we try to plan and manage all the traces. From the traces found in planning state we head back to the roots of requirement under observation. This model also allows us to preserve all the traces of requirement for -5715006748145Figure STYLEREF 1 s 3.2 ACTIVITY DIAGRAM
Figure STYLEREF 1 s 3.2 ACTIVITY DIAGRAM
-5715001252855further release of product.
Our second step in methodology is to convert figure 3.1 in to activity diagram by improving its functionality. We easily watch the flow of our proposed method it will also make this method easy for others to understand.
Figure 3.2 is activity diagram and it shows us that a stakeholder is responsible for change in requirement, so he is one who is basically predict traceability in requirement. If our prediction is true or right the we will proceed further else if our prediction is wrong, then we will move back to our prediction try to make it right and proceed. After this our work will flow in two directions. In these directions we must plan and manage strategy which we are going to use. While planning we decide what type of traceability we are following forward backward or bidirectional. And manage the chosen strategy by taking it backward or forward through all the requirements. We manage our strategy in such a way that it will not disturb our other requirements. Then we merge these two processes and use this planned traceability further backward because we proposed method for backward traceability here. After using this traceability, we found the original roots of requirement, type of requirement and all the components of requirement from which stakeholder have extracted this requirement. After finding traces of requirement we maintain all traces for future release. And if requirement whose traces we are maintain got changed again then we must plan and manage traceability again from creation phase. If requirement is not changes whose who traces, we were maintaining we can keep its trace in documentation and retire this trace and proceed further for next traceable requirement and repeat all this process. The third step we make a class diagram.
4381504474210Figure STYLEREF 1 s 3.3 class diagram
0Figure STYLEREF 1 s 3.3 class diagram
In figure 3.2 is class diagram is make out of our activity diagram and include some more features to make our task easy. As previous stated stakeholder is one who is responsible for traceability and he is only one wo can modify this traceability. Now in prediction of traceability is specified by three main things like what stakeholder want to trace, why he want to trace this and in what way he wants to trace this. When all this is finalizing we create traceability and plan further to manage it. Here in this stage we trace our requirement that whether is due to of conflict in requirement or because of some suspects. These two states maps trace to in planning and manage traceability phase. Now this
planning and managing phase aggregate all the previous stages and further drop our traceability in to using stage. Here our traceability meets its end when we use our planned strategy and find out origin type and components of our requirements. And this phase is also aggregates all the previous stages and the 2nd last stage is maintaining traceability for future use is depending on all the previous requirements. In last we are winding up our traceability by retiring the traces of this requirement and start with the next one before retiring traces in maintaining phase we document all the finding about roots of our requirement for future release of product.
Conclusion and future work
In this paper we disagree with all the previous techniques of requirement traceability and proposed our own framework with the help of uml diagrams. As we all know in agile requirement are frequently changing that why traceability is very difficult to achieve but it is so important we can’t ignore it because of these aspects we propose a model in which we can easily track our requirement CITATION WTL l 1033 5back in agile we can find there roots with the conformance of other requirements.
In future we plan to use this framework to develop an algorithm and apply that algorithm in real world industries.
1 Y. L. S. Soonsongtanee, ” “Enhancement of Requirements Traceability with State Diagrams”.”.
2 P. Letelier, “A Framework for Requirements Traceability in UML-based Projects”.
3 “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices,,” 2005.
4 O. C. Z. G. J. H. H. Jane Cleland-Huang, “Software Traceability: Trends and Future Directions”.
5 “W.-T. Lee, “DependencyLinkDerivationProcessandTheoremsofRequirementsTraceability Matrix”.”.
6 “B. Ramesh, ” “Factors in?uencing requirements traceability practice,” Communications of the ACM, vol. 41, no. 12, pp.”.
7 “”https://hubtechinsider.wordpress.com/2011/07/12/what-is-software-traceability-what-is-a-software-requirements-traceability-m,” Online.