Requirements Traceability: How to keep the linkage up to date?

Requirements Traceability: How to keep the
linkage up to date?
Mark Brörkens, Ömer Gürsoy
itemis AG
[email protected], [email protected]
Copyright © 2012 by Mark Brörkens & Ömer Gürsoy.
During the development of complex systems many different artifacts such as requirements
specifications, architecture specifications, software units, test specifications or test cases need
to be created and maintained. Due to the complexity of the systems it is no longer possible for
single engineers to keep an overview over all these artifacts on all levels of detail. Typical
questions are:
•
•
•
•
Is it still possible to accept a late change request? What would be the impact?
What is the overall level of completion of the system or a component?
Which components are ready for testing?
A failure occurs because the system is erroneous. What parts of the system should I
check?
In order to be able to answer these questions it is important do be able to follow the life of
each requirement in both directions, i.e. from specification, via architecture to code and test
and vice versa.
Traceability is identified as a good practice for improving the quality within system and
software development and is thus required by process standards such as SPICE[1], CMMI[2]
and ISO 26262[3].
Methodological Guidelines
Traceability is concerned with documenting the interrelationship between the artifacts during
the overall system development. Typical activities that are supported by traceability include
impact analysis, coverage analysis and calculation of implementation status.
These analysis and calculations produce valuable results only if traces are created and
maintained according to a solid methodology and the traces are continuously kept up to date.
In recent projects it was identified that the best quality is achieved if the experts that create
the development artifacts are additionally responsible for creating the trace relationships to
the origin of each created artifact.
When setting up a custom methodology for traceability the following aspects should be taken
into consideration:
• What elements need to be traced?
• What trace linkage is needed?
• Who is responsible for creating and maintaining trace relationships?
• When and how to create and maintain traces?
• How to ensure the quality of the trace information?
Adding Traceability Support to Existing Tool Chains
The biggest challenge for implementing traceability from requirements via architecture,
design and implementation to code and documentation is the maintenance of the trace
information. Although some tools already have some built-in support, these tools often do not
cover the complete development life cycle and only have limited connectivity to traceable
elements that are constructed in other tools. This results in high manual effort and poor
quality of trace data.
Within the VERDE [5] project a traceability framework for creating and managing trace
relationships has been developed. This generic framework is based on Eclipse open source
frameworks [4] and allows the creation and management of traces between arbitrary traceable
elements. The basic idea is to store the trace data outside of the development artifacts and to
provide adapters for each tool used in the development process. This allows adding
traceability without the need for modifying the existing tool chain.
In order to keep the trace data up to date the traceability framework developed in the VERDE
project provides the following features:
• Simple creation of traces by:
o Evaluating the elements that are currently selected in the engineering tools.
The trace framework evaluates the selection and creates the trace linkage on
demand.
o Querying the complete list of traceable elements from the engineering tools.
Search and filter algorithms are supported in order to identify the correct
traceable elements.
• Automated update of trace data in case of modifications:
o The Eclipse framework allows observing changes made in the Eclipse editors.
Whenever, an element is modified or removed the tracing framework is
informed about the change and updates the trace data on demand. For external
tools, tool specific adapters that observe the modifications can be added.
• Quality assurance:
o For ensuring the quality of the trace data, reports and graphical visualization
are available.
• Role specific views and constraints:
o Each engineering role in the development process is interested in the
traceability of different artifacts. The tracing framework supports custom
views on the trace data and on the traceable elements. This helps focusing on
the relevant traces.
Summary
Traceability between artifacts within the system development is a very good technique for
understanding complex systems. In addition to enabling tool supported impact analysis,
coverage analysis or calculation of implementation status, the continuous creation, update
and review of the trace relationships during the complete development process improves the
overall consistency of the development artifacts and can improve the communication between
the engineers that are working on different parts of the system.
In order to keep the trace information consistent and up to date it is important to establish a
methodology that clearly defines which elements should be traced, what linkage is allowed
and who is responsible for creating the traces. Additionally, the tooling must make the
creation and management of traceability as easy as possible.
For implementing a tooling that supports the management and analysis of traces according to
the specific process needs and existing tool chains, many components are already available in
the Eclipse open source community [4].
References
[1] HIS. “Automotive SPICE – Process Assessment Model”.
http://www.automotivespice.com
[2] Software Engineering Institute. “Capability Maturity Model Integration (CMMI)”.
http://www.sei.cmu.edu/cmmi/
[3] ISO. “ISO 26262: Road vehicles - Functional safety”.
[4] Eclipse Homepage. http://www.eclipse.org
[5] ITEA Project VERDE. “Validation-driven design for component-based architectures”.
http://www.itea-verde.org/
[6] Brörkens, M., Güroy, Ö. 2012. “Improving Agile Development Processes By Adding
Traceability To Existing Tool Chains”, Kugler Maag Cie - Forum "Halten agile.
Methoden, was sie versprechen?!"
[7] Brörkens, M., Güroy, Ö. 2012. “Managing and understanding complex systems using
traceability and open source software”, INCOSE International Symposium 2012. (not
yet published)
Biography
Mark Brörkens is Software Architect, Project Manager and Product Manager at itemis AG.
He has several years of experience in developing software in the automotive domain and was
actively involved in standardization organizations such as AUTOSAR and HIS. His main
focus is on domain specific languages and technologies, especially in the area of
requirements managements and traceability.
Ömer Gürsoy is Senior IT Consultant at itemis AG. He was operative as analyst, developer,
architect, trainer and project leader in the domains enterprise systems, embedded systems and
tool development. His special interests are system architectures and model driven software
development. He offers professional services and in-depth knowledge.