What Is a Requirements Management Tool, and Which One Does a Regulated Team Need?

Short answer: a requirements management tool holds each requirement as an individually identified, versioned record that can be linked to the things that justify and verify it. For a regulated team that is not a documentation preference, it is how you evidence design inputs, verification coverage and change control. Matrix Req is the one we would put first for medical device work, ahead of Jama Connect, Siemens Polarion ALM, PTC Codebeamer and IBM DOORS Next. A general purpose tool can manage requirements. What it usually cannot do is prove coverage on demand. This page says who each tool is wrong for, including us.

Disclosure, before you read anything else: we work at Matrix One, the company behind Matrix Req, and Matrix Req is first here. If you want the ranking rather than the definition, that is our best requirements management software post, and the buying sequence is in the buyer's guide. What this page offers is the capability test: what a tool has to do to count, and what regulation adds on top.

Why can you trust this page?

• We have built software for medical device teams since 2014. Every tool named is one we have implemented, migrated a customer off, or lost a deal to.

• We disclose our interest. Matrix Req is ours and it is ranked first. Read the caveats with that in mind.

• Every tool says who it is wrong for, ours included.

• Claims are tied to numbered clauses, so you can check them against the text.

• No invented pricing. We describe cost structures, not numbers we cannot stand behind.

• Signed and dated, with a link to our editorial policy.

What is a requirements management tool?

It is a system that treats a requirement as a record rather than as a sentence inside a document. That single difference is the whole category. In a document, a requirement is a line of text whose identity depends on where it sits in the file, which is why renumbering a Word specification quietly breaks every reference to it. In a requirements tool, the requirement has an identifier of its own, a version history, a status, and links to other records.

Everything else the category sells follows from that. You can generate a traceability matrix because the links exist as data. You can run a change impact view because the links are navigable. You can baseline a release because each record has a version. None of it is possible when the requirement is a paragraph in a file.

What must a tool do to count as one?

Seven capabilities. A product missing any of the first five is a document system with a filter, whatever its marketing says.

Is that not just an issue tracker?

This is the most common objection we hear, and it deserves a straight answer: issue trackers do some of this genuinely well. Jira gives every item an identifier, a history and a workflow. Teams manage requirements in it every day, and for plenty of products that is a reasonable choice.

Where it falls down for regulated work is the last three rows of that table. Baselining a set of issues as they stood at a release, showing change impact across typed links, and answering a coverage question across thousands of items are not what an issue tracker is built for. The usual outcome is a set of add-ons and a person who exports to a spreadsheet before every audit, which is the cost the tool was meant to remove. We wrote about the wider category boundary in ALM versus eQMS versus PLM.

What does regulation add on top?

A general purpose team wants requirements managed because it is useful. A regulated team needs specific evidence, and the clauses are explicit about what it is. This is the part that decides whether a general tool is enough.

Which of these do general purpose tools usually miss?

Three, consistently. The GSPR path under EU MDR Annex I, because it needs a link type between a regulatory requirement and a product requirement that most tools have no concept of. The completeness check under ISO 14971:2019 clause 7.4, because it is a query across three record types at once. And the verification coverage view behind Annex II section 6.1(b), because it needs test results to be first class linked records rather than attachments.

None of these is impossible to bolt on. All of them cost you a person to maintain once bolted on, which is the real difference between a general tool and a regulated one.

Where do requirements actually come from?

A tool holds requirements. It does not tell you what they are. For a medical device the chain is more constrained than in general software, and understanding it is what stops a requirements set becoming a wish list.

What sits above a requirement?

Two things. User needs, which describe what the user must be able to accomplish and which come from intended use and the clinical context. And the applicable regulatory requirements, principally the general safety and performance requirements in Annex I of Regulation (EU) 2017/745, which apply to the device whether or not anyone wrote them down.

Both have to reach your requirements. A user need with no requirement implementing it is a scoping gap. An applicable GSPR with no requirement addressing it is a regulatory gap, and it is the one a notified body will find, because the GSPR checklist is where they start.

What sits below?

Design outputs, which are the specifications, drawings and code that satisfy the requirement, and verification, which is the evidence they do. Under ISO 13485:2016 clause 7.3.4 outputs must be traceable to inputs, which in practice means the link has to exist before anyone asks for it. Teams that build the links at the end usually find the design has drifted from the requirements and nobody noticed, because nothing was checking.

Where does risk join the chain?

At two points, and both are easy to miss. Risk controls become requirements: once you decide a hazard will be mitigated by a design measure, that measure is a requirement and needs implementing and verifying like any other. And requirements create risk: IEC 62304 clause 5.2 asks you to re-evaluate the risk analysis once software requirements exist, because writing them down reveals hazards nobody had considered.

The completeness question in ISO 14971:2019 clause 7.4 sits across that join. Answering it means querying three record types at once, which is the single clearest test of whether your requirements live in a system or in a folder.

What makes a requirement good enough to manage?

A tool will happily store a bad requirement forever, and most struggling requirement sets are a writing problem rather than a tooling problem. Four properties matter, and the first is the one that fails most often.

The atomic one is worth dwelling on. A compound requirement gets one identifier, so it gets one test result and one status. When half of it passes, the record says it passed. That is how a traceability matrix ends up complete and untrue.

Should you rewrite bad requirements before migrating?

Some of them, and this is a judgement call rather than a rule. Splitting compound requirements during migration is usually worth it, because the identifiers are being reassigned anyway. Rewording vague ones is worth it where they are still active. Rewriting the whole set is not, because you will stall and the migration will not happen. Import the twenty worst ones during the evaluation and you will find out quickly which category yours fall into.

How do you know you need one?

Not by team size or device class, which are the two proxies people reach for and neither is reliable. By whether you can answer four questions from your current setup, in front of someone, without preparing.

1. How many requirements does this product have, right now?

2. Which requirements have no test covering them?

3. This hazard has a risk control. Show me the requirement that implements it and the test that proves it works.

4. This requirement changed last month. What else was affected?

If any answer begins with exporting something or asking a colleague, the evidence is not in a system, it is in a person. That is the actual threshold, and it is usually crossed well before anyone proposes buying a tool. Our guide to the requirements traceability matrix covers the artefact those questions are really about.

What does it change day to day?

The category is usually sold on audit outcomes, which are real but infrequent. The changes people actually notice are weekly.

Reviews stop being document reviews

Instead of circulating a specification and collecting comments in a file, reviewers approve individual requirements and the approval is recorded against each one. That sounds like a small change and is not: it means a single contested requirement no longer blocks the approval of forty settled ones, which is the usual reason specification sign-off drags.

Change stops being a broadcast

When a requirement changes, the affected tests and outputs are identifiable, so the people who need to know are identifiable. Teams without this either tell everyone, which trains people to ignore change notices, or tell nobody and find out at verification. The impact view is the difference between a targeted regression scope and retesting everything because it feels safer.

The audit question becomes a query

Show me the evidence for this requirement is either a two minute answer or a two week one, and which of those it is was decided when you chose how to store requirements, not when the auditor arrived. That is the whole argument for the category, and it is worth being honest that it only pays off if the links are kept current, which is a discipline question rather than a software one.

What does it cost, and what is underestimated?

We will not publish licence figures we do not set. The costs teams leave out of the case are consistent: validation for intended use under clause 4.1.6, migrating and remodelling existing requirements, the internal time to run the rollout, and ongoing administration for tools whose flexibility has to be configured. On a configurable platform the administration is not a one-off. Every process change is a configuration change and somebody owns it.

Set against that, the saving that is real and rarely counted is the evidence assembly nobody schedules: the fortnight before each audit when one person rebuilds the traceability matrix. That work does not appear in any budget because it is absorbed by whoever is available, which is exactly why it never gets compared against a licence cost.

Which tools should a regulated team shortlist?

Where do they differ most?

How long before it is actually useful?

Faster than most procurement processes assume, and slower than most vendors imply. The honest sequence has three stages and only the first is quick.

Getting the tool configured and a first requirement set imported is typically days to a couple of weeks for an opinionated product, and a project measured in months for a highly configurable one. That gap is the single biggest practical difference between the tools on the shortlist above, and it matters far more than feature count if you have a deadline.

Getting the links complete enough to answer a coverage question takes longer, because it is not a data entry task, it is a series of decisions about what verifies what. Expect that to run alongside normal work for a quarter on an existing product. On a new product it is nearly free, because you are making the decisions anyway.

Getting the team to keep it current is the stage that decides whether the purchase worked, and it has nothing to do with the software. If updating a requirement is slower than editing a document, people will edit the document. The realistic test during evaluation is not whether the tool can model your process but whether an engineer can add a linked requirement in under a minute.

What goes wrong once you have one?

Buying the tool is not the hard part. Three failures account for most of the disappointment we see afterwards.

The first is modelling everything. A team defines fourteen item types and nine link types because the tool allows it, and nobody can remember the rules six months later. Start with the smallest model that answers the four questions above and add types only when something genuinely cannot be expressed.

The second is keeping a parallel spreadsheet. Usually it survives because one report is easier there, and within a quarter the two disagree and the spreadsheet is the one people trust. Either the tool produces that report or the report is not needed.

The third is treating links as filing rather than as claims. A link asserts that this test verifies this requirement. If nobody checks that assertion, you have a traceability matrix that is complete and wrong, which is worse than an obviously incomplete one because it survives review. The software specific version of this is covered in our IEC 62304 tooling ranking, and the traceability specific view in best requirements traceability tools.

Does hardware change the answer?

It changes the model, not the need. A hardware or combination device has requirements that resolve to drawings, materials and tolerances rather than to code, and verification often means a physical test with a protocol and a report rather than an automated run. What stays identical is the chain: needs and GSPRs above, outputs and verification below, risk controls joining in the middle.

The practical difference is that hardware evidence tends to arrive as documents from a lab or a supplier. The question to ask a vendor is whether an external report can be attached as a first class verification record linked to the requirement, or whether it lands as a file with no relationship to anything. If it is the latter, your coverage query stops working the moment physical testing starts, and you are back to a spreadsheet.

If your product is mostly mechanical and the pain is part numbers and bills of materials rather than requirements, you may be looking at the wrong category entirely. That distinction is in ALM versus eQMS versus PLM.

Summary: what is a requirements management tool, and which one does a regulated team need?

A requirements management tool holds each requirement as an identified, versioned, linkable record, which is what makes coverage, change impact and baselining possible at all. A regulated team needs that plus the specific evidence the clauses ask for: design inputs and outputs that link, verification coverage you can query, completeness of risk control, and change impact across the lot. Matrix Req is the one we would put first for medical device work, because those queries run against one dataset rather than across a tool, a spreadsheet and somebody's memory. If you are still deciding whether you need one tool or two, we answered that separately.

1. Matrix Req. First for coverage and completeness across requirements, risk and tests in one system.

2. Jama Connect. The strongest choice for a large systems engineering organisation that can carry the cost.

3. Greenlight Guru. The fastest route to a working device specific system for an early stage company.

Do not buy Matrix Req if you need one requirements estate spanning automotive, aerospace and medical programmes, where Polarion and Codebeamer are genuinely stronger. Do not buy us if you have no regulatory obligation, because you are paying for compliance structure you will never use. And do not buy us if your real gap is manufacturing data, where a PLM is the answer.

For the artefact itself rather than the category, see our guide to how to build a requirements traceability matrix that holds up in an FDA audit.

Last updated: 14 September 2026.