Any project of any significance has requirements. Whether these are vague ideas in someone’s head, a series of notes on the back of an envelope, or a series of detailed, rigorously defined requirements, there will be some end goals and some means of evaluating whether they have been achieved.
Properly maintained requirements traceability is a prerequisite for both change-based testing and change impact analysis
Requirements traceability is quite simply the ability to trace each of the requirements to demonstrate its evolution into code throughout the development process.
For any safety-critical or security-critical application, chances are good that the development process will need to be audited to meet certification or qualification requirements.
Even if the process and resulting code don’t need to meet stringent certification demands, requirements traceability and management increases code quality and the overall safety, security, and effectiveness of the application.
In theory, requirements traceability is easy to achieve. If the exact sequence of the chosen development model is adhered to, then the requirements will never change, and tests will never throw up a problem. But the fact is that requirements do change, and tests do fail – and in an environment that is both demanding and dynamic in nature, that can be a project management headache. Automating that traceability and highlighting inconsistencies helps to alleviate that pain.
Confusingly, and depending on context, definitions differ on whether there are three or four types of requirements traceability.
Where four types are cited, the context generally includes the derivation or requirements from customer needs – and, incidentally, excludes bidirectional traceability as a “type”.
The LDRA tool suite interfaces to many ALM and PLM tools provided by our technology partners. These help with deriving formal requirements from customer needs.
Depending on context and somewhat confusingly, definitions differ on whether there are three or four types of requirements traceability. Where three types are cited, they refer to forward traceability, backward traceability, and bidirectional traceability between requirements and development artefacts.
These type definitions are aligned with those usually cited in process, functional safety, and cybersecurity standards.
All requirements must be implemented. Equally, the reverse is also true – all source code (and all tests) should be traceable back to the design and ultimately to a requirement (either functional or non-functional). This Bidirectional traceability gives teams visibility from requirements specifications through design, coding, testing and back again. The challenge to maintain bidirectional traceability comes when requirements start changing, or failed tests mean that that code needs to change. It is important to manage the impacts of such changes quickly and effectively, if the project schedule is to be protected .
Change impact analysis is important to understand which parts of the code are impacted by the requirements change. Change Based testing fulfils a related role in ensuring that the effects of code changes on, the wider code base are adequately tested.
The challenges associated with change have always been present in traditional V-model and waterfall SDLC ( Software Development Life Cycle) But they are especially pertinent with iterative envelopment approaches as reflected in agile and DevSecOps. That’s because each iteration represents both modifications to requirements and changes in an established code base.
Many process, functional safety, and cybersecurity standards require bidirectional requirements traceability. Some specify it explicitly – ISO 26262 and DO-178, for example – whereas others imply it by specifying that each transition between development phases should include it, such as IEC 62304 and ISO/SAE 21434. The railway standard series EN 5012X is another example of the latter style with its repeated requirement for evidence of traceability (EN 50128 §5.3.2.7, §6.5.4.14, §7.5.4.10, §D.58 etc.)
Development lifecycle models (Waterfall, V-model, Agile…) invariably show each phase flowing into the next, perhaps with feedback to earlier phases. Traceability is assumed to be part of the relationships between phases; however, the mechanism by which trace links are recorded is seldom stated. The reality is that, while each individual phase may be conducted efficiently thanks to investment in up-to-date tool technology, these tools seldom contribute automatically to any traceability between the development tiers. As a result, the links between them become increasingly poorly maintained over the duration of projects.
The Requirements Traceability Matrix (RTM) provides the solution to this problem and represents the logical extension of the required traceability between different phases. The links between phases can be ignored, or they can be acknowledged and properly managed. Either way, they are critical.
The diagram below presents this alternative view of the development landscape, reflecting the importance that should be attached to the RTM. Due to this fundamental centrality, it is vital that project managers place the same priority on RTM construction and maintenance as they do on requirements management, version control, change management, modelling, and testing.
Here is a representation of a Requirements Traceability Matrix (RTM) as shown in by TBmanager, a component of the LDRA tool suite:
Yes – and it must be if these models are to be used in the development of applications in accordance with functional safety, cybersecurity, or process standards.
For example, the TBmanager component of the LDRA tool suite can be used as an integral component in a DevSecOps environment.
Integration with Continuous Integration (CI) platforms simplifies iterative and incremental development. Testing can be added to pipelines as needed, to test an operation, a file, or groups of operations/files. Adding LDRA tools to pipelines with existing testing tools results in improved software robustness.
Regression testing is a type of software testing. Test cases are re-executed to check if the previous functionality of the application is working fine, and the new changes have not produced any bugs.
Automated requirements traceability can identify which code needs retesting, but of course that testing must then be initiated. Doing so from first principles even with an automated tool suite could represent significant overhead.
Regression testing allows validation and verification exercises (primarily unit tests, but also adherence to coding standards, complexity metrics etc.) to be re-run on updated code to ensure that all relevant quality criteria are still met after the changes.
The LDRA tool suite supports development teams who are working in a formal development process to improve code quality and maintainability, including static and dynamic analysis, coding standards compliance, and unit, integration, and system testing.
TBmanager is a component of the LDRA tool suite. It is a role-based requirements management tool that supports team members in their work on allocated activities and links the resulting code and verification artefacts back to higher level objectives.
TBmanager highlights the effects of changed requirements and changed code. So, if a stakeholder specifies a new or changed requirement then the impact can be assessed – and conversely, if a failed test results in changed code, then the implications of that change on other tests can also be shown.
TBrun is another component of the LDRA tool suite. It is a unit/integration test tool, providing a complete verification environment for the automated generation and management of test harnesses and unit/integration tests. The regression test facilities it provides are a significant element of the tool suite’s support for requirements traceability.
TBevolve is an optional plug-in for use with the LDRA tool suite. It enables project teams to monitor the impact of code changes on their testing process. By comparing the current code base with a baseline copy, it highlights changes and reports on any untested source code impacting code coverage statistics.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707