Requirements are a lifelong commitment
The RTM must be represented explicitly in any lifecycle model to emphasize its importance as illustrated in Figure 3. With this elevated focus, it becomes the center of the development process, impacting on all stages of design from high-level requirements through to target-based deployment.
click for larger image
Figure 3 -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. (Source: LDRA)
At the highest level, requirements management and traceability tools can initially provide the ability to capture the requirements specified by standards such as the DO-178C standard. These requirements (or objectives) can then be traced to Tier 1 – the application-specific software and system requirements.
These Tier 1 high-level requirements might consist of a definitive statement of the system to be developed (perhaps an aircraft flap control module, for instance) and the functional criteria it must meet (e.g., extending the flap to raise the lift coefficient). 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. With our flap example, the low-level requirements might discuss how the flap extension is varied, building on the need to do so established in Tier 1.
Tier 3’s implementation refers to the source/assembly code developed in accordance with Tier 2. In our example, it is clear that the management of the flap extension 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 simulation techniques help create an 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 flap position is functioning as intended within its development environment, even though there is no guarantee it will work when in its target environment. DO-178C acknowledges this and calls for the testing “to verify correct operation of the software in the target computer environment.”
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 in the target environment. In our example, we ensure in the host environment that function calls to the software associated with the flap control system return the values required of them in accordance with the requirements they are fulfilling. That information is then updated in the RTM.
Our flap-control system is now retested in the target environment, ensuring that the tests results are consistent with those performed on the host. A further RTM layer shows that the tests have been confirmed.
Maintaining the Requirements Traceability Matrix
The RTM is a best practice whether a standard insists on it or not. However, maintaining an RTM in spreadsheets is a logistical nightmare, fraught with the risk of error and permanently lagging the actual project status.
Constructing the RTM in a suitable tool not only maintains it automatically, but also opens up possibilities for filtering, quality checks, progress monitoring and metrics generation (Figure 4). The RTM is no longer a tedious, time-consuming task reluctantly carried out at the end of a project; instead it is a powerful utility that can contribute to efficiently running the project. The requirements become usable artifacts to drive implementation and testing. Furthermore, many of the trace links may be captured simply by doing the day-to-day work of development, accelerating RTM construction and improving the quality of its contents.
Modern requirements traceability solutions extend the requirements mapping down to the verification tasks associated with the source code. The screenshot in Figure 4 shows an example. Using this type of requirements traceability tool, the 100% requirements coverage metric objective can be clearly measured, no matter how many layers of requirements, design and implementation decomposition are used. This makes monitoring system completion progress an extremely straightforward activity.
click for larger image
Figure 4 - Traceability from high level requirements down to source code and verification tasks. (Source: LDRA)
Connectivity and the Infinite Development Lifecycle
During the development of a traditional, isolated system, that is clearly useful enough. But connectivity demands the ability to respond to vulnerabilities identified in the field, essentially for as long as the product lives. Each newly discovered vulnerability implies a changed or new requirement, and one to which an immediate response is needed—even though the system itself may not have been touched by development engineers for quite some time. In such circumstances, being able to isolate what is needed and automatically test only the functions impacted becomes much more significant.
Connectivity changes the notion of the development process ending when a product is launched, or even when its production is ended. Whenever a new vulnerability is discovered in the field, there is a resulting change of requirement to cater for it, coupled with the additional pressure of knowing that in such circumstances, a speedy response to requirements change has the potential to both save lives and enhance reputations. This lifelong obligation shines a new light on automated requirements traceability.
The delivery of a requirements traceability matrix (RTM) can be contractually imposed or recognized as a best practice for successful projects. However, the creation of a useful and error-free RTM can only happen when the requirements are of sufficient quality and the process is managed to:
Ensure that requirements embrace functional, safety and security-related issues
Accept that requirements will change over the life of the project
Employ a development process that embraces and responds to change
Manage the quality of requirements
Let the requirements drive development
Build an RTM from the start of the project
Use the RTM to manage progress and improve project quality
Use the RTM to respond quickly and effectively to security vulnerabilities after product deployment
The end result will be a project that finishes on time and on budget, that avoids gaps between the stakeholder’s vision and what is delivered, and that results in an effective support vehicle for deployed connected systems.
Mark Pitchford has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0. Mark earned his Bachelor of Science degree at Nottingham Trent University, and he has been a Chartered Engineer for over 20 years. He now works as Technical Specialist with LDRA Software Technology.