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

Lead Consultant and owner, Alastair Walker

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.

Erfahre mehr

Does the aviation industry do things better?

The aviation industry and specifically DO-178C, takes a different approach to the 3 previously listed documents. The concept of a requirements hierarchy that then traces to different implementation levels.

  • In software, high-level requirements trace to system requirements;
  • Low-level requirements satisfy the high-level requirements;
  • The software architecture does not conflict with the high-level requirements e.g. partitioning;
  • The source code is accurate and complete with respect to the low-level requirements (no source code is undocumented).

Also as indicated in figure 4, the topic of derived requirements is introduced, in DO-178C this is then defined as:

  • Derived requirements are requirements that are not directly traceable to higher level requirements e.g. interrupt for a chosen target computer.

Often in project IEC 62304 and ISO 26262 projects the traceability is attempted to higher levels without a logical linkage. Derived requirements define a pragmatic approach to capturing additional requirements spawned at a given level on the left-side of the V. ISO 26262-6 section 6.4.1 does though in a note introduce the topic of derived requirements in software ‘requirements for software functions and properties that if not fulfilled could lead to a violation of the technical safety requirements’. However, there is no dedicated clause on the subject.

Figure 4: DO-178C V-Model

Given generally the aviation sector is dealing with higher criticality products than the other two industries. However the DO-178C concept is both simple and pragmatic. In IEC 62304 with more relaxed approach to class A software the documentation unit source code would be deemed over the top, but the approach would work for class B and C and not to mention the FDA document levels.

Conclusion

Ultimately, each industry has it’s strategy to traceability, however the aviation sector approach gives good guidance on the end outcome. The implementation of a product is based on a hierarchy of requirements and the traceability from the requirements to the code at each hierarchal level needs to be established (exception IEC 62304 class A code).

Derived requirements also help understand the requirements that may not be traceable the level above.

This blog is the prelude to our forthcoming training course Requirements Management, which we have already held a couple of times this year and will be added to the Lorit website for the start of 2024. In the second blog in this series, we will look at methods to clearly define requirements and the differences between functional and non-functional requirements

By Alastair Walker, Consultant & Owner

If you would like to join one of our training courses covering a variety of safety related topics, take a look at our offerings . For these and  our new Requirements Management course, please do not hesitate to contact us info@lorit-consultancy.com.

KONTAKT

Formular

Wir freuen uns auf Ihre Kontaktaufnahme.

    Datenschutz­bestimmungen anzeigen