Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 6 minutesA cornerstone of a rigorous software development process is requirements management and the traceability of those requirements to implementation—and subsequently, proof of correct implementation.
Requirements traceability is defined by authors, Gotel and Finkelstein, as “the ability to describe and follow the life of a requirement, in both a forward and backward direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of on-going refinement and iteration in any of these phases).”
Tracing requirements isn’t simply linking a paragraph from a document to a section of code or a test. Traceability must be maintained throughout the phases of development as requirements manifest into design, architecture, and implementation. Consider the typical “V” diagram of software.
Figure 1: The classic V diagram shows how traceability goes forward and backward through each phase of development.
Each phase drives the subsequent phase. In turn, the work items in these phases must satisfy the requirements from the previous phase. System design is driven from requirements. System design satisfies the requirements, and so on.
Requirements traceability management (RTM) proves that each phase is satisfying the requirements of each subsequent phase. However, this is only half of the picture. None of this traceability demonstrates that requirements are being met. That requires testing.
Figure 2: The other important part of requirements traceability is verification and validation testing to prove the implementation of the specification from the corresponding design phase. Validation typically occurs at the end of the development cycle during final acceptance testing with the customer.
In the V diagram shown in Figure 2, each testing phase verifies the satisfaction of the specifications associated with the corresponding design/implementation phase. In the example, acceptance testing validates requirements, integration testing verifies architecture design, unit testing verifies module design, and so on. Validation typically occurs at the end of the development lifecycle during acceptance testing with the customer.
Requirements traceability needs both the link to implementation and verification, plus all the associated artifacts from the development process. Software development on any realistic scale will have many requirements, complex design and architecture, and possibly thousands of units and unit tests. Automation of RTM in testing is necessary, especially for safety-critical software that requires documentation of traceability for certifications and audits.
A requirement traceability matrix is a document that illustrates the satisfaction of requirements with a corresponding work item, like a unit test, module source code, architecture design element, and so on. The matrix is often displayed as a table, which shows how each requirement is “checked off” by a corresponding part of the product. Creation and maintenance of these matrices are often automated with requirements management tools with the ability to display them visually in many forms and even hard copy, if required.
Below is a requirements traceability matrix example from Intland codeBeamer. It shows system level requirements decomposed to high-level and low-level requirements, and the test cases that verify each.
Figure 3: Requirements traceability matrix example in Intland codeBeamer.
In the simplest sense, requirements traceability is needed to keep track of exactly what you’re building when writing software. This means making sure the software does what it’s supposed to and that you’re only building what is needed.
Traceability works both to prove you satisfied the requirements and to identify what doesn’t. If there are architectural elements or source code that can’t be traced to a requirement, then it’s a risk and shouldn’t be there. The benefits go beyond providing proof of the implementation. Disciplined traceability is an important visibility into development progress.
Traceability isn’t necessarily strict in enterprise software application, although that’s certainly improving. However, it is a required activity in safety and mission-critical software.
Requirements in safety-critical software are the key driver for product design and development. These requirements include functional safety, application requirements, and non-functional requirements that fully define the product. This reliance on documented requirements is a mixed blessing since poor requirements are one of critical causes of safety incidents in software. In other words, the implementation wasn’t at fault, but poor or missing requirements were.
It’s important to realize that many requirements in safety-critical software are derived from safety analysis and risk management. The system must perform it’s intended functions, of course, but it must also mitigate risks to greatly reduce the possibility of injury. Moreover, in order to document and prove that these safety functions are implemented and tested fully and correctly, traceability is critical.
Maintaining traceability records on any sort of scale requires automation. Application lifecycle management tools include requirements management capabilities that are mature and tend to be the hub for traceability. Integrated software testing tools like Parasoft complete the verification and validation of requirements by providing an automated bidirectional traceability to the executable test case, which includes the pass or fail result and traces down to the source code that implements the requirement.
Parasoft integrates with market-leading requirements management and agile planning systems such as Intland codeBeamer, Polarion from Siemens, Atlassian Jira, CollabNet VersionOne and TeamForge.
As shown in the image below, each of Parasoft’s test automation tools (C/C++test, Jtest, dotTEST, SOAtest, and Selenic) support the association of tests with work items defined in these systems (such as requirements, stories, defects, test case definitions). Traceability is managed through Parasoft’s central reporting and analytics dashboard (Parasoft DTP).
Figure 4: Parasoft provides bidirectional traceability from work items to test cases and test results – both displaying traceability reports with Parasoft DTP as well as reporting results back to the requirements management system.
Parasoft DTP correlates the unique identifiers from the management system with static analysis findings, code coverage, and test results from unit, integration, and functional tests. Results are displayed within Parasoft DTP’s traceability reports and sent back to the requirements management system. They provide full bidirectional traceability and reporting as part of the system’s traceability matrix.
The traceability reporting in Parasoft DTP is highly customizable. The following image shows a requirements traceability matrix template for stories authored in Jira that trace to the test cases, static analysis findings, the source code files, and the manual code reviews.
Figure 5: Requirements traceability matrix template from Parasoft DTP integrated with Altassian Jira.
The bidirectional correlation between test results and work items provides the basis of requirements traceability. Parasoft DTP adds test and code coverage analysis to evaluate test completeness. Maintaining this bidirectional correlation between requirements, tests, and the artifacts that implement them is an essential component of traceability.
Parasoft DTP also helps triage the creation of defects and issues into new work items. Test automation and static analysis produce a lot of data to consume. Tools that help manage this data are important to prioritize the work items and prevent the tools from overwhelming the team.
Using the violation and test explorers in Parasoft DTP, shown below, the team can efficiently create new work items following triage of test failures and static analysis violations. The combination of traceability and triaged issue/defect creation provides a complete feedback loop for a workflow.
Figure 6: Creating a new Defect in VersionOne while triaging test failures in Parasoft DTP.
Requirements traceability is a key part of requirements management in software development. The level of formality in traceability varies by application type but the practice is absolutely necessary in safety-critical software.
Bidirectional traceability is important so that requirement management tools and other lifecycle tools can correlate results and align them with requirements and associated work items.
The complexity of modern software projects require automation to scale requirements traceability. Parasoft tools are built to integrate with best-of-breed requirement management tools to aid traceability into test automation results, and complete the software test verification and validation of requirements.
Sr. Technical Product Marketing Manager for Parasoft’s embedded testing solutions. He has expertise in the SDLC and test automation of embedded real-time, safety and security critical applications, and software compliance to industry standards.