Requirements traceability

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Requirements traceability is concerned with documenting the life of a requirement and providing bi-directional traceability between various associated requirements. It enables users to find the origin of each requirement and track every change that was made to this requirement. For this purpose, it may be necessary to document every change made to the requirement.

Traceability is especially relevant when developing safety-critical systems to comply with legal requirements such as ISO 26262, Automotive SPICE or EN 50128: it must be verified that critical requirements are realized with high quality.

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

Overview[edit]

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 artifacts. Its purpose is to facilitate:

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

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.

Definitions[edit]

A much cited [2] [3] [4] [5] definition of requirements traceability is the following:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases).[1]

While this definition emphasizes tracking the life of a requirement through all phases of development, it is not explicit in mentioning that traceability may document relationships between many kinds of development artifacts, such as requirements, specification statements, designs, tests, models and developed components. The next definition addresses this issue:

Requirements traceability refers to the ability to define, capture and follow the traces left by requirements on other elements of the software development environment and the trace left by those elements on requirements.[6]

The following definition emphasizes the use of traceability to document the transformation of a requirement into successively concrete design and development artifacts:

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 the relationships between layers of information.[7]

The principal relationship referred to here may be characterized as "satisfaction": how is a requirement satisfied by other artifacts? Other relationships that can be traced are, for example, "verification": how is a requirement verified by test artifacts?

Tracing beyond the requirements[edit]

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.

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

Furthermore, implementation artifacts will likely be in the form of source files, links to which can be established in various ways at various scopes. Verification artifacts 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.

Benefits[edit]

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

  • Impact analysis is facilitated: if a requirement changes, the trace links visualise the related artifacts. Thus, these artifacts can be located fastly, checked and adjusted if required. The probability to overlook related artifacts becomes low.
  • Traceability ensures that no requirements are overlooked. Especially when certifying safety-critical products it is necessary to demonstrate that all requirements are realized.
  • Tracking of the project status is possible: analysing 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 artifacts are missing and need to be realized.
  • It is easier possible to reuse product components: it is possible to structure requirements and their linked artifacts in packages. These packages can be used for different products.
  • Relations remain permanently visible: Often knowledge of a project or product is in the head of specific persons. By use of traceability this knowledge is saved by visualising the relation between the different artifacts. This knowledge remains even if a person leaves the project.
  • Optimisation of quality and tests: By linking requirements, source code, test cases and test results it is easier to identify the affected parts in the source code if the tests show bugs. Also redundant tests can be eliminated fastly.

Visualization of traceability information[edit]

One goal of traceability is to visualize the relationship between artifacts. 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 typ, metadata, link strength).[11]

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

Traceability matrix[edit]

A traceability matrix maps requirements to other artifacts in a table representation. Requirements are mostly located in columns, artifacts in rows. A marked cell represents that a requirement is linked with an artifact.[11]

The advantage of traceability matrices is that all links between artifacts are visible at a glance. Filters help to reduce the amount of displayed information. Traceability matrices are suitable for management tasks.[11] However, in industry projects often consist of thousands of artifacts: the tables could become very large and confusing.

Traceability graph[edit]

In a traceability graph artifacts are represented as nodes. Nodes are connected by edges, if a trace link between the artifacts 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.[11] By navigating through the graph it is easy to identify missing links as a hint to create required artifacts.

Lists[edit]

Lists represent traceability links in one entry. This entry could include information concerning the source and target artifact and attributes.

They are especially suitable when bulk operations for several different artifacts 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.[11]

Hyperlinks[edit]

Hyperlinks connect linked artifacts and allow to “jump” from a source artifact to a linked artifact.

This visualization is suitable if detailed information about an artifact is needed as it allows to navigate to artifacts in their native environment.[11] Using hyperlinks solely has the disadvantage that a lot of navigation effort is necessary to get an overview on the link status as linked artifacts are not visualized compactly. However, hyperlinks can be combined with the other kinds of visualization to overcome this limitation.

Realisation and tool support[edit]

Manually or semiautomatic[edit]

Often traceability is realised manually or semiautomatic by either analysing trace data with tool support or by doing it manually e.g. in MS Excel or in-house tools. However, as traceability beyond requirements involves several different tools and the number of related artifacts is extremely high in industry this process can be challenging and time consuming.[12]

Tool-supported[edit]

The goal of tool-supported traceability is to homogenize and aggregate all components in the toolchain. The following approaches exist:

Homogenisation of the tool environment - Application lifecycle management (ALM) tools[edit]

ALM tool chains cover the whole lifecycle of a system and manage all artifacts of the development process in a holistic approach.

The advantage of this approach is that the homogenisation of artifacts allows to manage and analyse 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.

Homogenisation of data - Surrogate requirements[edit]

There are several requirements management computer programs on the market for storing all requirements of all specifications of a technical system under development, which are arranged in a specification tree and linking each one to the "parent" requirement in the higher specification. Specialized commercial tools for requirements engineering are 3SL Cradle, IRise, Gatherspace, Rational RequisitePro, Doors, CaliberRM or QFDCapture, but also free tools like FreeMind, Reqchecker together with MS Office, Concordion can be used.[13] Issue trackers implementing the Volere requirements template have been used successfully in distributed environments.

Evaluation functions allow for

  • 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
  • qualification status presentation

In order to ensure an entire traceability beyond requirements to different artifact types some of these requirements management tools allow to import these artifacts as surrogate requirements. Here it is explained how elements of a Matlab model can be imported to IBM Doors as surrogate module.

The advantage is that several of these requirement management tools allow additionally traceing to different other tools.

The disadvantage is that different adapters or converters for the different artifact 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.

Homogenisation of data - dedicated traceability tools[edit]

Dedicated traceability tools extract the relevant data of the artifacts of the development process and present it in a consistent traceability model. This is realised by the use of adapters. In addition, these tools provide interfaces to integrate any - also propretary - tools.

There are some dedicated traceability tools on the market:

  • Capra: Capra allows to create, manage, visualise and analyse trace links in Eclipse. Capra is part of the open source tool platform AMALTHEA 4public that followed the EUREKA research project AMALTHEA.
  • Reqtify: Reqtify is an interactive tool to manage requirements. It allows traceability and impact analysis across the whole life cycle of hardware and software development. It is a commercial product from the Claytex company.
  • YAKINDU Traceability: YAKINDU Traceability allows easy and adjustable traceability management - e.g. to comply with legal standards such as ISO 26262. It is a commercial product from the itemis company and followed (as Capra) the EUREKA research project AMALTHEA.

The use of dedicated traceability tools combines the advantages of the approaches mentioned above: the tool supplier ensures the consistency of the adapters and converters. In addition, customizable interfaces ensure the flexible integration of different tools in the tool chain.

A disadvantage of this approach is that this flexibility necessitates to configure the technical connection to the tools.

See also[edit]

References[edit]

  1. ^ a b 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. 
  2. ^ Sampaio do Prado Leite, Julio Cesar; Jorge Horacio Doorn (2004). Perspectives on Software Requirements. Kluwer Academic Publishers. pp. 91–113. ISBN 1-4020-7625-8. 
  3. ^ "Requirements Tracing -- An overview". 
  4. ^ Turbit, Neville. "Requirements Traceability". Retrieved 2007-05-11. 
  5. ^ "Requirements Traceability". Retrieved 2007-05-11. 
  6. ^ Pinheiro F.A.C. and Goguen J.A., "An object-oriented tool for tracing requirements", IEEE Software 1996, 13(2), pp. 52-64
  7. ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick (2005). Requirements Engineering (Second Edition). Springer. pp. 9–13, 131–151. ISBN 1-85233-879-2. 
  8. ^ 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. 
  9. ^ Wiegers, Karl (2013). "Requirements Traceability: Links in the Requirements Chain, Part 1". jama. Retrieved 2016-12-14. 
  10. ^ Wiegers, K.; Beatty, J. (2013). Software Requirements. Microsoft Press. 
  11. ^ 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. 
  12. ^ Kannenberg, Andrew; Saiedian, Hossein (2009). "Why Software Requirements Traceability Remains a Challenge" (PDF). CrossTalk Magazine - The Journal of Defense Software Engineering. 
  13. ^ Laplante, Phillip A. (2009). "Requirements Engineering for Software and Systems". CRC Press. 

External links[edit]