Automotive Requirements Management with Matrix Req
Functional safety, cybersecurity and software work products in one traceable system. Matrix Req connects hazard analysis to safety goals, safety requirements, design and test results, so the safety argument holds together when it is assessed.
ISO 26262 asks you to prove a chain, not file a document
One traceable chain from hazard to test result
Traceability is the deliverable. ISO 26262 expects bidirectional traceability from hazard analysis and risk assessment through safety goals, functional and technical safety requirements, down to design and verification results. A spreadsheet breaks that chain the first time a requirement changes.
ASIL decomposition has to be visible. When a safety goal is decomposed across redundant elements, the rationale and the resulting ASIL of each derived requirement have to be recorded and defensible, not held in one engineer's head.
Automotive SPICE adds its own work products. The engineering and support process areas expect consistent bidirectional traceability and change control across system and software levels, assessed independently of your safety case.
Cybersecurity is now in scope. ISO/SAE 21434 brings threat analysis, cybersecurity goals and claims that need the same evidence discipline as functional safety, usually owned by a different team in a different tool.
Programmes run across suppliers. Requirements arrive from an OEM and leave to a tier two, and the trace has to survive every handover rather than restarting at each boundary.
Configure the item types you need. There is no fixed schema. Define hazards, safety goals, functional and technical safety requirements, design elements and test cases as their own types, with the fields and workflows your process calls for.
Bidirectional traceability with live coverage. Every link works in both directions, and coverage views show which safety requirements have no verification behind them before an assessor points it out.
Impact analysis before the change. See exactly what a requirement change touches downstream, including which test cases have to be re executed and which risk controls are affected.
Baselines and complete audit history. Every version, review, approval and electronic signature is retained, so a release baseline can be reconstructed exactly as it stood on the day.
Engineering stays in Jira or Azure DevOps. Two way sync keeps developers in the tracker they already use while requirements, risks and results stay governed in Matrix Req.
ISO 26262 asks you to prove a chain, not file a document
Traceability is the deliverable. ISO 26262 expects bidirectional traceability from hazard analysis and risk assessment through safety goals, functional and technical safety requirements, down to design and verification results. A spreadsheet breaks that chain the first time a requirement changes.
ASIL decomposition has to be visible. When a safety goal is decomposed across redundant elements, the rationale and the resulting ASIL of each derived requirement have to be recorded and defensible, not held in one engineer's head.
Automotive SPICE adds its own work products. The engineering and support process areas expect consistent bidirectional traceability and change control across system and software levels, assessed independently of your safety case.
Cybersecurity is now in scope. ISO/SAE 21434 brings threat analysis, cybersecurity goals and claims that need the same evidence discipline as functional safety, usually owned by a different team in a different tool.
Programmes run across suppliers. Requirements arrive from an OEM and leave to a tier two, and the trace has to survive every handover rather than restarting at each boundary.
One traceable chain from hazard to test result
Configure the item types you need. There is no fixed schema. Define hazards, safety goals, functional and technical safety requirements, design elements and test cases as their own types, with the fields and workflows your process calls for.
Bidirectional traceability with live coverage. Every link works in both directions, and coverage views show which safety requirements have no verification behind them before an assessor points it out.
Impact analysis before the change. See exactly what a requirement change touches downstream, including which test cases have to be re executed and which risk controls are affected.
Baselines and complete audit history. Every version, review, approval and electronic signature is retained, so a release baseline can be reconstructed exactly as it stood on the day.
Engineering stays in Jira or Azure DevOps. Two way sync keeps developers in the tracker they already use while requirements, risks and results stay governed in Matrix Req.
Core Features
What Matrix Req does for automotive engineering programmes.
FAQ
No, and it is worth being clear about that up front. Matrix Req is a configurable platform rather than a preloaded compliance package. You define the item types, fields, workflows and traceability rules that match your safety process, usually with our team during onboarding.
If you need a tool that arrives with an ISO 26262 process already modelled out of the box, Polarion and codebeamer are further down that road than we are.
No. Tool confidence level evaluation, and any qualification that follows from it, are programme level activities that depend on how you use the tool and what you rely on its output for.
Matrix Req holds and evidences your requirements, traceability and verification records. It does not remove your obligation to perform a tool confidence level assessment.
Yes. Requirement levels are item types you define, so a vehicle level safety requirement, a hardware requirement and a software unit requirement can live in one project with links between them.
That is the point of a single chain. The trace from a vehicle level hazard down to a software test result stays intact instead of crossing three tools and two exports.
Those three have longer automotive track records and arrive with automotive process content. That is a real advantage for a large OEM programme with an established estate.
Matrix Req is lighter to configure, faster to stand up and priced for smaller engineering teams, and it carries risk management inside the same item structure rather than beside it. If your team finds those platforms heavy to administer, we are worth measuring against them.
Yes. Matrix Req syncs two way with Jira and Azure DevOps, so developers keep working where they already are while requirements, safety requirements, risks and test evidence stay governed and traceable in Matrix Req.