To V or not to V
The challenges of requirement traceability
Not a blog covering the well-trodden path of agile against phase-gate development, but a look at requirement traceability and how it is handled in different sectors. Having just finished a week filled with both requirements and ISO 26262 training, the topic of requirements traceability is fresh in the mind.
Ultimately, requirements need to have originated from source at the start of a project, stakeholder requirements will be based on requirements such as those from customers (user needs). As we begin to define and scope out the project then we work down the hierarchy of requirements, adding detail at each subsequent level.
Requirements confusion
Often the traceability of code to requirements leads to confusion as it is often seen as a need to trace architectural and detailed design to code. Ultimately, the code needs to originate from requirements.
Both industry standards in medical device (IEC 62304) and automotive industries (ISO 26262) tend to be a bit vague in the area of traceability, both v-models (figure 1 and figure 2) that indicate a linkage from system requirements to software requirements, and then software requirements to software architecture, and finally from software architecture to detailed design.
As you read through ISO 26262 part 6 on software or through IEC 62304, there are notes and comments in appendices, that the architecture needs to satisfy the software requirements, but not really much on the software units satisfying the software requirements. IEC 62304 tending to focus more on traceability to risk control and documentation, the v-model also tends to leave software requirements so what floating. Although there is guidance on the quality of requirements.
Figure 1: ISO 26262 V-Model linking to Systems Design
Figure 2: IEC 62304 V-Model linking to IEC 60601 (systems/product level)
Automotive SPICE and Bidirectional Traceability
Where the topic of traceability in the automotive sector is better addressed is in Automotive SPICE, not only defining the traceability across the v-model to each verification level, but on the left-side of the V (see figure 3) the traceability from software requirements to the software architecture and importantly from the software requirements to software units. Bi-directional traceability at all levels being a key aspect of Automotive SPICE.
However, there is still a key aspect in all three documents listed, that is not well addressed and this leads to the approach in a different industry.
Figure 3: Left-side of the v-model Automotive ASPICE
To find out more about requirement traceability and ISO 26262 or IEC 62304, please join one of our training courses.
Send us your inquiry to info@lorit-consultancy.com.
Learn more
