Jump to content

Requirements traceability

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Datlasr (talk | contribs) at 23:04, 14 April 2017 (violation of your rules). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. 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)".[1][2] In the requirements engineering field, traceability is about understanding how high-level requirements – objectives, goals, aims, aspirations, expectations, needs – are transformed into low-level requirements. It is therefore primarily concerned with satisfaction relationships between layers of information (aka artefacts).[3] However, traceability may document relationships between many kinds of development artefacts, such as requirements, specification statements, designs, tests, models and developed components.[4] For example, it is common practice to capture verification relationships to demonstrate that a requirement is verified by a certain test artefact.

Traceability is especially relevant when developing safety-critical systems and therefore prescribed by safety guidelines, such as DO178C, ISO 26262, and IEC61508. A common requirement of these guidelines is that critical requirements must be verified and that this verification must be demonstrated through traceability.

It has been argued that the use of the requirement after the implemented features have been deployed and used should be traceable.[5]

Overview

Traceability as a general term is the "ability to chronologically interrelate the uniquely identifiable entities in a way that matters." The word chronology here reflects the use of the term in the context of tracking food from farm to shop, or drugs from factory to mouth. What matters in requirements management is not a temporal evolution so much as a structural evolution: a trace of where requirements are derived from, how they are satisfied, how they are tested, and what impact will result if they are changed.

Requirements come from different sources, like 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 when user studies show that a feature is not used, to see why it was required in the first place.

Requirements Traceability is concerned with documenting the relationships between requirements and other development artefacts. Its purpose is to facilitate:

  • the overall quality of the product(s) under development;
  • the understanding of product under development and its artefact; and
  • the ability to manage change.

Not only the requirements themselves should be traced but also the requirements relationship with all the artefacts 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.

Tracing beyond the requirements

Requirements are realized into design artefacts, implementation, and finally, verified. Artefacts tied to the latter stages should be traced back to the requirements as well. This is typically done via a Requirements Traceability matrix.

Establishing traceability beyond requirements into design, implementation, and verification artefacts can become difficult.[6] When implementing software requirements for instance, the requirements may be in a requirements management tool, while the design artefacts may be in a tool such as MagicDraw, MATLAB/Simulink, Rhapsody, or Microsoft Visio.

Furthermore, implementation artefacts will likely be in the form of source files, links to which can be established in various ways at various scopes. Verification artefacts such as those generated by internal tests or formal verification tools (i.e. The LDRA tool suite, Parasoft Concerto, SCADE)

Repository or tool stack integration can present a significant challenge to maintaining traceability in a dynamic system.

Usage of traceability information

The usage of traceability, especially when tracing beyond requirements to all artefacts located in the tool chain, can bring several benefits:[7][8]

  • Change Impact analysis – if a requirement is changing, trace links inform about related and dependent artefacts. These artefacts can easily be verified and if required be adjusted. The probability to overlook related artefacts 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 to see 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 artefacts are missing and need to be realized.
  • Reuse of product components – it is possible to structure requirements and their linked artefacts 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 use of traceability this knowledge is saved by visualizing the relation between the different artefacts. This knowledge remains even 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.

A more complete overview of development activities supported by traceability and their relevance is given in.[9]

Visualization of traceability information

One goal of traceability is to visualize the relationship between artefacts. As the number and complexity of trace links increases, techniques for traceability visualization are necessary. A visualization can include information about the artefacts (e.g. artefact type, metadata, attributes) and links (e.g. link typ, metadata, link strength).[10]

Common visualizations for traceability information are matrices, graphs, lists, and hyperlinks.

  • Traceability matrix – A traceability matrix is a table-like representation that maps artefacts of one type (e.g., requirements) depicted in columns to artefacts of another type (e.g., source code) depicted in rows. Cells visualize a trace between two artefacts if filled or a non-trace if left empty.[10] The advantage of traceability matrices is that all links between artefacts are visible at a glance. Filters help to reduce the amount of displayed information. Traceability matrices are suitable for management tasks.[10] However, in industry projects often consist of thousands of artefacts: the tables could become very large and confusing.
  • Traceability graph – In a traceability graph artefacts are represented as nodes. Nodes are connected by edges, if a trace link between the artefacts exists. Graphs are especially suitable for development tasks. They allow getting an overview on the links exploratively and are characterized by a high information comprehension ratio.[10] By navigating through the graph it is easy to identify missing links as a hint to create required artefacts.
  • List – Lists represent traceability links in one entry. This entry could include information concerning the source and target artefact and attributes. They are especially suitable when bulk operations for several different artefacts should be executed. Filters and sorting mechanisms allow to handle the displayed information. However, compared to the visualizations described above lists are less suitable to execute project management, development and testing tasks.[10]
  • Hyperlink – Hyperlinks connect linked artefacts and allow to “jump” from a source artefact to a linked artefact. This visualization is suitable if detailed information about an artefact is needed as it allows to navigate to artefacts in their native environment.[10] Using hyperlinks solely has the disadvantage that a lot of navigation effort is necessary to get an overview on the link status as linked artefacts are not visualized compactly.

Visualizations can be combined to overcome their specific limitations.

Technical realization

Manual traceability

Traceability is realized by capturing traces either entirely manual or tool supported, e.g. as spreadsheet in Microsoft Excel. 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 artefacts to be traced.[11]

Tool-supported traceability

Tool-supported traceability requires that development information that is distributed across a whole chain of development tools to be homogenized and aggregated. The following approaches exist for reaching this state:

Homogenization of the tool environment through ALM tool – ALM tool chains cover the whole life-cycle of a system and manage all artefacts of the development process in a holistic approach. Issue trackers implementing the Volere requirements template have been used successfully in distributed environments. The advantage of this approach is that the homogenization of artefacts allows to manage and analyze them easily with dedicated tools of the ALM tool. The disadvantage is that it is necessary to implement the whole ALM tool chain. If introduced, it is difficult to replace specific tools in the tool chain.

Homogenization of data through surrogate requirements – Requirements management (RM) tools allow storing, organizing, and managing all requirements of a system's specifications and typically arrange them in a specification tree that links each requirement to its parent requirement in the higher specification. Commercial RM tools with traceability support are, e.g., 3SL Cradle, IRise, Gatherspace, Rational RequisitePro, IBM DOORS, CaliberRM, and QFDCapture. Freely available tools are, e.g., FreeMind and Concordion.[12] Typical analysis functions based on recorded traceability information are, e.g., completeness checks i.e. do all system level requirements go down to equipment level (with or without modification), assessment of requirements deviations over all levels, and qualification status presentation. In order to ensure traceability to artefact types beyond requirements, RM tools often allow to import other artefacts as surrogate requirements that can then be traced with the tool's requirements tracing methods. For example, elements of a Simulink model can be imported into an IBM DOORS surrogate module and then be related to requirements. The disadvantage of this approach is that different adapters or converters for the different artefact types are necessary that need to have a consistent version and data format. In contrast to ALM tools this consistency must be carried out oneself.

See also

References

  1. ^ Gotel, O.C.Z.; Finkelstein, C.W. "An analysis of the requirements traceability problem". Proceedings of IEEE International Conference on Requirements Engineering. doi:10.1109/icre.1994.292398.
  2. ^ 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.
  3. ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick (2005). Requirements Engineering (Second Edition). Springer. pp. 9–13, 131–151. ISBN 1-85233-879-2.
  4. ^ Pinheiro F.A.C. and Goguen J.A., "An object-oriented tool for tracing requirements", IEEE Software 1996, 13(2), pp. 52-64
  5. ^ Gotel O.C.Z; Finklestein A.C.W. "An analysis of the requirements traceability problem" (PDF). Proceedings of ICRE94, 1st International Conference on Requirements Engineering, Colorado Springs. IEEE CS Press, 1994.
  6. ^ 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.
  7. ^ Wiegers, Karl (2013). "Requirements Traceability: Links in the Requirements Chain, Part 1". jama. Retrieved 2016-12-14.
  8. ^ Wiegers, K.; Beatty, J. (2013). Software Requirements. Microsoft Press.
  9. ^ 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. doi:10.1007/978-3-642-37422-7_12. ISBN 9783642374210.
  10. ^ a b c d e f Li, Y.; Maalej, W. (2012). Which Traceability Visualization Is Suitable in This Context? A Comparative Study. Springer. pp. 194–210.
  11. ^ Kannenberg, Andrew; Saiedian, Hossein (2009). "Why Software Requirements Traceability Remains a Challenge" (PDF). CrossTalk Magazine - The Journal of Defense Software Engineering.
  12. ^ Laplante, Phillip A. (2009). "Requirements Engineering for Software and Systems". CRC Press. {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Requirements_traceability&oldid=775448227"