Challenges for Traceability
Many industry standards like ISO 26262, DO-178C/ED-12C, or ISO 13485/IEC 62304 ask for traceability between requirements and other development artifacts.
However, they often use top-down development processes as an underlying mental model: Assuming the requirements are stable, traceability data must be collected during the subsequent steps in the development process. But projects in complex domains often do not follow a strictly linear process. In fact, their requirements keep changing during later stages. But requirements tracing is still obligatory or at least encouraged.
The most crucial factor is proving that critical requirements have been sufficiently verified. To this end, it is necessary to know which software tests verify which requirements or where a specific requirement has been implemented in the code.
But with artifacts subject to change at any point in the process, maintaining traceability is a major challenge.
How Teamscale Helps
1. Keeping requirements, design, code, and tests in sync
Teamscale complements Polarion by providing software engineers with all they need to know to maintain traceability at all times.
Whenever they make a change to source code or tests, Teamscale automatically surfaces a list of all requirements affected by that change directly in the software pull request (PR). That way, the developer and reviewer can easily make sure all relevant requirements are still in sync with code and tests once their change is merged. Prior knowledge of the affected requirements or reading hundreds of pages of specifications is not necessary.
Conformity between code, tests, and requirements also surfaced in the familiar form of a badge in the software PR. This enables teams to easily include conformity in their definition of done.
2. Automatically creating a verification matrix
Even today, many teams still manually maintain spreadsheets to record whether their tests successfully covered all requirements.
Requirements tracing in Teamscale saves you from this unnecessary manual work. Test cases are detected automatically in the codebase or extracted from test management tools. Tests are linked to requirements via a simple, customizable annotation in test code or alternatively stored in a testing tool.
Teamscale uses this information to automatically create views that facilitate verification such as a classic verification matrix or similar, more modern alternatives.
The calculation is done automatically whenever any change occurs, which means all data is always up to date.
Which requirements are displayed can be freely chosen, e.g. to focus on a single component.
This makes all typical verification questions easy to answer:
- “Are there any requirements without associated tests?”
- “Which tests verify too many requirements?”
- “Which tests of a given requirement fail?”