Aerospace and Defence Requirements Management with Matrix Req
Objective by objective evidence, from system safety assessment down to software verification results. Matrix Req keeps the trace intact so a certification package is assembled from live data rather than rebuilt by hand before an audit.
Certification is an evidence exercise, and the evidence is the trace
One chain from system requirement to verification result
DO-178C is written as objectives with evidence. Each design assurance level from A to E changes which objectives apply and which require independence. Satisfying them means producing artefacts and showing how they connect, not writing a narrative.
Bidirectional traceability is explicit. The standard expects trace data between system requirements, high level requirements, low level requirements, source code, and the test cases and results that verify them. Broken links become findings.
Hardware follows a parallel path. DO-254 runs its own lifecycle for airborne electronic hardware and ARP4754A sits above both, so a system safety requirement has to reach into two separate development chains.
Defence programmes add another frame. MIL-STD-882 system safety and customer specific data item requirements mean the same engineering evidence has to be presented in more than one shape.
Programmes outlive tools. A certification basis has to be reconstructable years later, which makes baselining and audit history a requirement rather than a convenience.
Define the requirement levels the standard uses. System, high level and low level requirements are item types you configure and link in both directions, so DO-178C trace data comes out of the project itself.
Coverage and gap analysis as you go. See which requirements have no verification behind them, and which tests trace to nothing, before a stage of involvement audit finds it for you.
Hardware and software in one project. Keep DO-254 hardware requirements and DO-178C software requirements traceable to the same system safety requirements instead of in separate estates.
Baselines that reconstruct exactly. Every approval, electronic signature and version is retained, so the configuration at any release can be shown as it stood.
Reviews with independence recorded. Structured review and approval workflows capture who reviewed and approved what, which is the evidence behind the independence objectives.
Certification is an evidence exercise, and the evidence is the trace
DO-178C is written as objectives with evidence. Each design assurance level from A to E changes which objectives apply and which require independence. Satisfying them means producing artefacts and showing how they connect, not writing a narrative.
Bidirectional traceability is explicit. The standard expects trace data between system requirements, high level requirements, low level requirements, source code, and the test cases and results that verify them. Broken links become findings.
Hardware follows a parallel path. DO-254 runs its own lifecycle for airborne electronic hardware and ARP4754A sits above both, so a system safety requirement has to reach into two separate development chains.
Defence programmes add another frame. MIL-STD-882 system safety and customer specific data item requirements mean the same engineering evidence has to be presented in more than one shape.
Programmes outlive tools. A certification basis has to be reconstructable years later, which makes baselining and audit history a requirement rather than a convenience.
One chain from system requirement to verification result
Define the requirement levels the standard uses. System, high level and low level requirements are item types you configure and link in both directions, so DO-178C trace data comes out of the project itself.
Coverage and gap analysis as you go. See which requirements have no verification behind them, and which tests trace to nothing, before a stage of involvement audit finds it for you.
Hardware and software in one project. Keep DO-254 hardware requirements and DO-178C software requirements traceable to the same system safety requirements instead of in separate estates.
Baselines that reconstruct exactly. Every approval, electronic signature and version is retained, so the configuration at any release can be shown as it stood.
Reviews with independence recorded. Structured review and approval workflows capture who reviewed and approved what, which is the evidence behind the independence objectives.
Core Features
What Matrix Req does for aerospace and defence programmes.
FAQ
No, and we will not imply otherwise. Matrix Req is not a qualified tool under DO-330.
Tool qualification depends on the tool qualification level, how your programme uses the tool and what certification credit you take for its output. Matrix Req holds and evidences your requirements, trace data and verification records. Any qualification argument remains your programme's responsibility.
No. It is a configurable platform rather than a preloaded certification package. You define system, high level and low level requirement types, the trace rules between them and the review workflows.
Teams that want a starting structure configure it with our team during onboarding rather than receiving it in the box.
Yes, in the sense that both are item types you define and link. Hardware requirements, software requirements and the system safety requirements above them can live in one project with bidirectional traceability between them.
The lifecycle processes themselves remain yours to run. Matrix Req holds the evidence and the trace, it does not perform the assurance activities.
Not today, and we would rather say so plainly than imply otherwise. Matrix Req's customer base is concentrated in regulated product development in life sciences.
The platform's mechanics, configurable requirement types, bidirectional traceability, coverage analysis, baselining and electronic signatures, are not sector specific, and they are the same mechanics an airborne programme needs. If you are evaluating us as an early aerospace customer, we will be direct with you about what is proven and what is not.
IBM DOORS and DOORS Next have the deepest aerospace and defence footprint and the longest certification track record, and both Polarion and Jama Connect have established programmes in the sector.
Matrix Req is lighter to configure and quicker to stand up, and it carries risk management inside the same item structure rather than as a separate module. For a large certification programme with an entrenched DOORS estate the switching cost is real. For a smaller supplier or a new programme, the setup time difference is worth measuring.