Jump to content

User:Noahritfeld/Requirements traceability

From Wikipedia, the free encyclopedia

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary[1] as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another;[2] (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy.[3]

In the domain of requirements engineering, traceability is concerned with understanding the relationship between the higher overview of information compared to the more detailed levels. More specifically, it outlines how high-level requirements, such a goals, objectives and expectations can be translated into the low-level requirements, such as calculations, technical details, data manipulation and processing. In these relationships, one lower level requirements can be associated with one or multiple high-level requirements and vice versa. [4] The concept of requirements traceability is defined as "the ability to describe and follow the life of a requirement in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)."[5][6]

Progression of Requirements traceability

[edit]

Pre-requirements traceability.[5] Requirements come from different sources, such as the business person ordering the product, the marketing manager and the actual user. These people all have different requirements of the product. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation. This can be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment to see why certain unused features found during user studies were required in the first place.

Post-requirements traceability.[5] Not only the requirements themselves should be traced but also the requirements relationship with all the artifacts associated with it, such as models, analysis results, test cases, test procedures, test results and documentation of all kinds. Even people and user groups associated with requirements should be traceable. Requirements are realized into design artifacts, implementation, and finally, verified. Artifacts tied to the latter stages should be traced back to the requirements as well. This is typically done via a requirements traceability matrix.

Types of traceability

[edit]
The types of traceability visualized including forward, backward and bi-directional.

Forward traceability - The ability to trace requirements sources to their resulting product requirement(s) and tracing each unique requirement forward to the various artifacts that are created during the analyze, design, development, and testing phase of a software development project. [7] Examples of artifacts by phase are as follows:

  • Analyze:  meeting notes, presentations, overall vision, risk assessments, software requirements specification.
  • Design: object/data models, sequence diagrams, user interface designs, system architecture.
  • Development: source code, diagrams, and software documents.
  • Testing: test cases, prototypes, benchmarks, test results, and test summary reports.  

The advantages of forward traceability is that you can see if all requirements are allocated and ensure that a project goes in the desired direction.

Backward/reverse traceability - This refers to tracing back each artifact to its associated requirement and tracing each requirement back to its source(s). Examples of sources are stakeholders, developers, project managers and clients.[7] The advantage of backwards traceability is that if questions arise by the customer or stakeholder regarding why certain features were included, there is a comprehensive audit trail. Another advantage is that if there are different stakeholders involved, they will have different views of the requirements, so that’s why it is convenient to trace each developed artifact to the person, group or entity that requested it during the requirements gathering.

End-to-end/bi-directional traceability - The combination of tracing both forward (trace each requirement to a various artifact) and backwards (trace lineage and source of all the requirements) into one document or overview. The advantage of bi-directional traceability is that it answers the question what design decisions affect the implementation of a requirement. Besides that, it also answers the question where a requirement is implemented and if a requirement was necessary.

Visualization of traceability information

[edit]

Visualizations are used to represent an idea or data in "pictorial form for better perception, interpretation and insight of information." They help bring forth a single interpretation of artifacts and their relationships, by [stimulating] the sensory inputs of humans. [8] As the number and complexity of trace links increases, techniques for traceability visualization are necessary. A visualization can include information about the artifacts (e.g. artifact type, metadata, attributes) and links (e.g. link type, metadata, link strength).[9]

Common Visualizations

[edit]

Common visualizations for traceability information are matrices, graphs, lists, and hyperlinks. The choice of which visualization and information should be presented is highly dependent on the context or requirements of the task.

  • Traceability matrix – A traceability matrix is a table-like representation that maps artifacts of one type (e.g. requirements) depicted in columns to artifacts of another type (e.g. source code) depicted in rows. Cells visualize whether a trace exists between two artifacts and how strong it is.[9] The advantage of traceability matrices is that they are easy to understand, even by people with limited to no technical knowledge. As the number of relationships grows exponentially, this visual can become difficult to understand, especially if multiple layers are interpreted simultaneously. [10]
  • Traceability graph – In a traceability graph artifacts are represented as nodes, whereas the relationships where there is a trace are depicted by an edge. Graphs allow for a more informal, exploratory representation with relationships being easily identifiable. [9] They provide an intuitive representation of such relationships. [11]
  • List – Lists represent each trace link, with source information, target artifacts and attributes in a single entry. Usually, they are displayed sequentially in order of similarity with the most relevant appearing at the top. Lists are plain however they have a concrete focus on a small subset of relationships through filtering or ordering the results. [9] A challenge which is present with this type of visualization in the limitation of one dimension for presenting information.[10]
  • Hyperlink – Hyperlinks connect related artifacts (even in different tools) in a more organic way. This is the most explicit way of visualizing relationships as it has the most granularity. [9]

As each type of visualization has its purpose and applications, it is important to consider the situation, the audience and the domain knowledge. Depending on the requirements, approaches can be combined to overcome limitations.

Advanced Visualizations

[edit]

The more advanced visualizations which can be used to display relationships between artifacts are data models, sunburst visualizations and Netmaps. For all graphical representations, the traceability links are color coded.

  • Data model – This visualization shows the requirement artifacts and the links that connect them. Each artifact has common attributes. The traceability links can indicate a direction, thus showing a parent/child relationship. [10]
  • Sunburst Visualization – A graph in which the nodes are shown in a radial layout. The nodes are drawn next to each other to mimic a tree. "Each child of a node with depth n is represented in the ring n + 1 on the same radian space as its parent(s)." The advantage is the neat and compact global overview for users. However, as the graph grows vertically it is difficult to identify the nodes on the same level and the writing on the outer rings become illegible. [10]
  • Netmap – In contrast to the sunburst visualization, in this visual the nodes are all placed on a single ring. This helps avoid misinterpretations of the nodes but having a single ring limits the space for each node. [10]

Usage of traceability information

[edit]

Requirements traceability can contribute in many ways like impact analysis, maintenance, project tracking, risk reduction and testing.[11] Tracing requirements, when done properly can save time, money and effort. The usage of traceability, especially when tracing beyond requirements to all artifacts located in the tool chain, can bring several benefits: [12][13]

Benefits

[edit]
  • Change impact analysis – if a requirement is changing, trace links inform stakeholders about related and dependent artifacts. These artifacts can easily be verified and if required, be adjusted. The probability to overlook related artifacts is reduced.
  • Coverage analysis – traceability ensures that no requirements are overlooked. Especially when certifying safety-critical products it is necessary to demonstrate that all requirements are realized.
  • Project status analysis – tracking of the project status is possible: analyzing the traceability data allows seeing the completion status of the requirements. Requirements without links or with incomplete trace chain (e.g. requirements with implementation but without tests) indicate that further work is necessary. The missing links show which concrete artifacts are missing and need to be realized.
  • Reuse of product components – it is possible to structure requirements and their linked artifacts in packages. These packages can be used for different products.
  • Persisting relationships – often knowledge of a project or product is in the head of specific persons. By the use of traceability this knowledge is saved by visualizing the relation between the different artifacts. It even remains if a person leaves the project.
  • Test optimization – by linking requirements, source code, test cases and test results it is easy to identify affected parts of the source code if tests fail. Furthermore, redundant test cases can be identified and eliminated.

Besides of the benefits offered by traceability, its implementation still faces many challenges.

Challenges

[edit]
  • Cost - One major challenge facing the implementation of traceability is simply the costs involved. As a system grows in size and complexity, capturing the requirement traces quickly becomes complex and expensive. [14]
  • Managing chance - Requirements can change during the life cycle of a software project. [13] [15] [16]
  • Products at different life stages - A product can be in a different life stage than another product and therefore require different policies. [17]
  • Stakeholder viewpoints - There can be a different understanding of the many viewpoints regarding traceability between stakeholders. These viewpoints exist primarily because current software engineering standards typically require traceability to be implemented but provide little guidance as to why and how it should be performed. [18]
  • Complexity of the organization - Complexity of the organization can aggravate the traceability problem. Complexity is determined by the number of people involved in the project, how many teams are involved, where they are located and the experience level of the staff. [17]
  • Poor tool support - Traceability tool penetration throughout the software engineering industry is surprisingly low.[16]
  • Problems with manual traceability methods - A study performed found that the number of traceability links that need to be captured grows exponentially with the size and complexity of the software system. This means that manually capturing traceability data for large software projects requires an extreme amount of time and effort. [16][19]

A more complete overview of development activities supported by traceability and their relevance is given in Requirements Engineering: Foundation for Software Quality [19].

Practical use

[edit]

Extensive studies document the effectiveness, but also the difficulties of capturing traceability information:

  • Traceability accelerates and improves development activities - A study with 71 subjects who performed source code changes with and without traceability support showed benefits of traceability. Developers completed tasks with traceability support 24% faster and 50% more correct.[20]
  • More complete traceability helps avoid software defects - In an analysis of development data from 24 medium-sized and large open-source projects, a statistically significant relationship between the completeness of the captured traceability information and the defect rate of the developed source code was found. Components with more complete traceability showed a lower number of defects (otherwise known as bugs).[21]
  • Achieving compliant traceability is difficult - An analysis of the pre-market testing of software in medical devices at the US Food and Drug Administration (FDA) in 2013 identified significant gaps between prescribed and filed traceability information.[22] The quest towards a standard-conformable traceability often results in a "Big Freeze", since companies aim to avoid further development because re-certification is associated with enormous effort.[23]

Technical realization

[edit]

Traceability is realized by capturing traces either entirely manual or tool supported.

Manual traceability

[edit]

Though widely applied, this process is cumbersome, error-prone, and often leads to traceability information that is of insufficient quality due to the various involved development tools and the typically very high number of artifacts to be traced.[16]

Tool-supported traceability

[edit]

Establishing traceability beyond requirements into design, implementation, and verification artifacts can become difficult. [24] Therefore, people use office tools like spreadsheets for managing traceability. These tools are error-prone when there are hundreds of requirements and multiple users working on a project, it can be even more effective to control the projects.

Furthermore, implementation artifacts will likely be in the form of source files, links to which can be established in various ways at various scopes. Many companies have chosen a best-of-breed approach with the success and popularity of tools such as Jira, Azure DevOps, Git, Jenkins and numerous test automation tools. Companies that choose a best-of-breed approach solve the traceability challenge with requirements management (RM) tools that provide a complete traceability model and integrations for the best of breed tools.

See also

[edit]

References

[edit]
  1. ^ "ISO/IEC/IEEE International Standard - Systems and software engineering--Vocabulary". doi:10.1109/ieeestd.2017.8016712. {{cite journal}}: Cite journal requires |journal= (help)
  2. ^ IEEE Guide for Developing System Requirements Specifications. 1998-12-01. pp. 1–36. doi:10.1109/IEEESTD.1998.88826. ISBN 978-0-7381-1723-2. {{cite book}}: |journal= ignored (help)
  3. ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. 1998-12-01. pp. 1–24. doi:10.1109/IEEESTD.1998.89424. ISBN 978-0-7381-1407-1. {{cite book}}: |journal= ignored (help)
  4. ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick (2005). Requirements Engineering (Second ed.). Springer. pp. 9–13, 131–151. ISBN 978-1-85233-879-4.
  5. ^ a b c Gotel, O.C.Z.; Finkelstein, C.W. (April 1994). An analysis of the requirements traceability problem. pp. 94–101. CiteSeerX 10.1.1.201.7137. doi:10.1109/icre.1994.292398. ISBN 978-0-8186-5480-0. S2CID 5870868. {{cite book}}: |journal= ignored (help)
  6. ^ Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (2012-01-01). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Software and Systems Traceability. Springer London. pp. 3–22. doi:10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  7. ^ a b Lind, Mats; Johansson, Jimmy; Cooper, Matthew (2009). "Many-to-Many Relational Parallel Coordinates Displays". 2009 13th International Conference Information Visualisation. IEEE. doi:10.1109/iv.2009.43.
  8. ^ Altaf, Sohaib; Shah, Asadullah; Imtiaz, Najma; Shah, Abdul Salaam; Ahmed, Syed Faiz (2018). "Visualization representing benefits of pre-requirement specification traceability" (PDF). International Journal of Engineering & Technology. 7 (2.5): 44–52.
  9. ^ a b c d e Li, Y.; Maalej, W. (2012). Which Traceability Visualization Is Suitable in This Context? A Comparative Study. Springer. pp. 194–210.
  10. ^ a b c d e Merten, Thorsten; Juppner, Daniela; Delater, Alexander (2011). "Improved representation of traceability links in requirements engineering knowledge using Sunburst and Netmap visualizations". 2011 4th International Workshop on Managing Requirements Knowledge. IEEE. doi:10.1109/mark.2011.6046557.
  11. ^ a b "Requirements Traceability: Links in the Chain". Jama Software. Retrieved 2023-01-13.
  12. ^ Wiegers, Karl (2013). "Requirements Traceability: Links in the Requirements Chain, Part 1". jama. Retrieved 2016-12-14.
  13. ^ a b Wiegers, K.; Beatty, J. (2013). Software Requirements. Microsoft Press.
  14. ^ Heindl, Matthias; Biffl, Stefan (2005-09-05). "A case study on value-based requirements tracing". Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering. ESEC/FSE-13. New York, NY, USA: Association for Computing Machinery: 60–69. doi:10.1145/1081706.1081717. ISBN 978-1-59593-014-9.
  15. ^ Boehm, Barry (2003-03-01). "Value-based software engineering: reinventing". ACM SIGSOFT Software Engineering Notes. 28 (2): 3. doi:10.1145/638750.638775. ISSN 0163-5948.
  16. ^ a b c d Kannenberg, Andrew; Saiedian, Hossein (2009). "Why Software Requirements Traceability Remains a Challenge" (PDF). CrossTalk Magazine - the Journal of Defense Software Engineering.
  17. ^ a b Kirova, Vassilka; Kirby, Neil; Kothari, Darshak; Childress, Glenda (2008). "Effective requirements traceability: Models, tools, and practices". Bell Labs Technical Journal. 12 (4): 143–157. doi:10.1002/bltj.20272. ISSN 1538-7305.
  18. ^ Ramesh, B.; Jarke, M. (2001). "Toward reference models for requirements traceability". IEEE Transactions on Software Engineering. 27 (1): 58–93. doi:10.1109/32.895989.
  19. ^ a b Bouillon, Elke; Mäder, Patrick; Philippow, Ilka (2013-04-08). Doerr, Joerg; Opdahl, Andreas L. (eds.). Requirements Engineering: Foundation for Software Quality. Lecture Notes in Computer Science. Springer Berlin Heidelberg. pp. 158–173. CiteSeerX 10.1.1.659.3972. doi:10.1007/978-3-642-37422-7_12. ISBN 9783642374210.
  20. ^ Mäder, Patrick; Egyed, Alexander (2015-04-01). "Do developers benefit from requirements traceability when evolving and maintaining a software system?". Empirical Software Engineering. 20 (2): 413–441. doi:10.1007/s10664-014-9314-z. ISSN 1382-3256. S2CID 2514618.
  21. ^ Rempel, Patrick; Mäder, Patrick (2016-01-01). "Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality". IEEE Transactions on Software Engineering. PP (99): 777–797. doi:10.1109/TSE.2016.2622264. ISSN 0098-5589. S2CID 1959772.
  22. ^ Mäder, P.; Jones, P. L.; Zhang, Y.; Cleland-Huang, J. (2013-05-01). "Strategic Traceability for Safety-Critical Projects". IEEE Software. 30 (3): 58–66. doi:10.1109/MS.2013.60. ISSN 0740-7459. S2CID 16905456.
  23. ^ "open-DO | Toward a cooperative and open framework for the development of certifiable software". www.open-do.org. Retrieved 2017-04-15.
  24. ^ Li, Yin; Juan Li; Ye Yang; Mingshu Li (2008). Requirement-Centric Traceability for Change Impact Analysis:A Case Study. Springer Berlin/Heidelberg. pp. 100–111. ISBN 978-3-540-79587-2.


Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Noahritfeld/Requirements_traceability&oldid=1135427276"