Design Article
Gap analysis forges the links from requirements to verification
Mark Pitchford and Bill St. Clair, LDRA Technology
11/4/2010 4:02 PM EDT
Such an alternative view of the development landscape illustrates 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 investing in tooling for RTM construction, as they do purchase of requirements management, version control, change management, modeling, and testing tools. As well, the RTM must be represented explicitly in any lifecycle model to emphasize its importance, as Figure 2 below illustrates. With this elevated focus, the RTM is constructed and maintained efficiently and accurately as an integral part of the development process.
Figure 2: The requirements traceability matrix (RTM) plays a central role in a development lifecycle model. Artifacts at all stages of development are linked directly to requirements matrix and changes within each phase automatically update the RTM so that overall development progress is evident from design through coding and test.
As can be seen from the diagram, when the RTM becomes the center of the development process, it impacts on all stages of design from high-level requirements through to target-based deployment.
The Tier 1 high-level requirements might consist of a definitive statement of the system to be developed (perhaps an ABS control module, for instance) and the functional criteria it must meet (i.e., applying no more braking pressure to a wheel that is about to lock). This tier may be subdivided depending on the scale and complexity of the system.
Tier 2 describes the design of the system level defined by Tier 1. Above all, this level must establish links or traceability with Level 1 and begin the process of constructing the RTM. It involves the capture of low-level requirements which are specific to the design and implementation and have no impact on the functional criteria of the system. With our braking example, the low-level requirements might discuss how the applied braking force varies, building on the need to do so established in Tier 1.
Tier 3 implementation refers to the source/assembly code developed in accordance with Tier 2. Verification activities include code rule checking and quality analysis. Maintenance of the RTM presents many challenges at this level because tracing requirements to source code files may not be specific enough and developers may need to link to individual functions.
In our example, it is clear that the management of the braking force is likely to involve several functions. Traceability of those functions back to Tier 2 requirements includes many-to-few relationships. It is very easy to overlook one or more of these relationships in a manually managed matrix.
In Tier 4 host-based verification, formal verification begins. Using a test strategy that may be top-down, bottom up, or a combination of both, software stimulation techniques help create automated test harnesses and test case generators as necessary. Test cases should be repeatable at Tier 5 if required.
At this stage, we confirm that the example software managing the braking force is functioning as intended within its development environment, even though there is no guarantee it will work when in its target environment. ISO/DIS 26262 acknowledges this and calls for the testing environment to "correspond as closely as possible to the target environment" for all ASIL levels. However, testing in the host environment first allows the target test (which is often more time consuming) to merely confirm that the tests remain sound (valid) in the target environment.
|
|
|
|
|
Navigate to related information