As we continue our discussion of the top mistakes folks make in their DO-254 and DO-178C programs, the # 4 mistake is…Not Understanding the Purpose of Traceability.

DO-254 and DO-178C are requirements-based processes. As part of the process, requirements must be captured and validated, and then traced (via a traceability matrix) into both the corresponding design implementation (architecture/code/device) and verification (test cases, test procedures and results). Verification is a supporting/integral process of these standards and traceability is a key activity of this verification.

What traceability provides, if done properly, is assurance that all requirements have been implemented, that all portions of the design tie to requirements, and that the design as implemented behaves as the requirements say it should.  Traceability done throughout the development activity will flag derived requirements (i.e., those that may not trace upwards) that need validation and safety assessment.  Traceability can be a key ally to you in your program in another way – helping you monitor your development progress (in terms of how many requirements have been designed and tested, and how many are left to go). But all of this entails integrating traceability into the process as you go. By integrating traceability, it offers insights into design completion and verification coverage, and can even help find design bugs!

Instead of using this powerful tool and following the compliance requirements as mandated, what I often see is project teams who think of the Traceability Matrix is an artifact to be generated after the fact. They give it little or no thought until it needs to be reviewed during SOI audits.

If you wait until the last minute to create a traceability matrix, as opposed to incorporating traceability into each phase of design (using it as an analysis tool as part of requirements, design, code and test reviews), you miss the point and the benefits that this activity provides. So in your program, try to remember that Requirements Traceability isn’t an output of the program as much as it is a tool to be used throughout the program to help you understand your progress and provide an added measure of verification and visibility for change impact for each phase of the process.

If you need more help understanding traceability, check out our templates, which include instruction and advice about managing traceability throughout the project/documentation, as well as a Requirements Traceability Matrix document template. Click here to see what we offer in terms of templates.