Your Requirements Are Scattered Across Jira Tickets. Here Is How to Get Them Back.

Requirements scattered across Jira tickets is the state we find most medical device software teams in, and it is recoverable without rebuilding the product from scratch. Short answer: export the backlog through the Jira REST API, triage every issue into requirement, design output, defect or noise, rewrite the survivors as testable statements, then rebuild traceability in a tool that holds requirements as versioned items. The destinations worth considering are Matrix Req first, then Jama Connect, PTC Codebeamer, Siemens Polarion ALM, Ketryx, IBM DOORS Next, Perforce Helix ALM and Visure Requirements.

A disclosure before the method. We work at Matrix One, the company behind Matrix Req, and Matrix Req is the tool we place first at the end of this recovery. The method itself is tool independent and the first two thirds of this page will work whichever destination you pick. Every Jira behaviour described below was read on Atlassian's own developer and support documentation on 25 September 2026 and is linked at the point it is used.

Why can you trust this guide?

• Matrix One has built requirements and design control software for medical device teams since 2014, and Matrix Req is used by 500 or more life sciences and medical device companies.

• We disclose our interest in the second paragraph, not in a footnote.

• Every claim about how Jira behaves is linked to Atlassian's own documentation and was read on 25 September 2026.

• Every regulatory claim is tied to a numbered clause, not to a concept.

• No invented pricing, no unverifiable claim about another vendor's product, and no figure that is not attributed to whoever published it.

• Signed, dated, and reviewed in line with our editorial policy.

This page is the recovery method. The ranked comparison of tools that connect to Jira is a separate page, the best requirements management tools that integrate with Jira, and the two are written to be read together.

Why is a Jira ticket not a requirement?

A ticket is a unit of work. It is created to be closed, it describes what someone is going to do, and once it is done its reason for existing has passed. A requirement is a statement of what the product must do. It persists for the life of the device, it is verified rather than completed, and it is still true after the work that implemented it shipped.

Everything that goes wrong with a Jira-only requirement set follows from that one difference. Closed tickets get archived. Tickets get split, and the requirement splits with them. A ticket describing a change gives you the delta but never the resulting statement, so after three years of changes nobody can say what the product is supposed to do without reading the whole history.

This is not an argument against Jira. Jira is a strong issue tracker and most of these teams should keep it. It is an argument against Jira being the only place a requirement is written down.

What does a requirement look like when it is stuck in a Jira ticket?

In a real backlog the requirement content sits in four recognisable shapes, and each one needs different handling on the way out.

The fourth shape is the one teams miss and the one an auditor finds. A defect report is evidence that somebody had an expectation the specification never captured.

Which clauses does a ticket-only history fail?

It is worth being precise about this, because "Jira is not compliant" is not a true statement and will not survive a conversation with your engineering lead. Jira fails specific clauses in specific ways.

Two further points sharpen this. Under ISO 13485:2016 clause 4.1.6 you validate software used in the quality management system, which applies to Jira itself if Jira is where your design control evidence lives. And the FDA Quality Management System Regulation took effect on 2 February 2026, bringing design controls in through ISO 13485 clause 7.3 rather than the former 21 CFR 820.30, so the deliverable is now a clause 7.3.10 design and development file.

How do you get the tickets out of Jira in the first place?

This is the step most recovery guides skip, and it changed recently enough that an old script will not work.

Atlassian's classic search endpoints, GET and POST on `/rest/api/3/search`, are marked deprecated and currently being removed in the Jira Cloud platform REST API. The replacement is `/rest/api/3/search/jql`, which pages with a `nextPageToken` rather than a start index. A separate `/rest/api/3/search/approximate-count` endpoint now answers how many issues match, so a bounded total is no longer part of the search response.

The practical consequence is that you cannot write a loop that asks for issues 0 to 49, then 50 to 99, and know when to stop by comparing against a total. You follow the token until there is no next token, and you accept that the count you were given was approximate.

History is a second call. Get changelogs on `/rest/api/3/issue/{issueIdOrKey}/changelog` returns the field-level history for one issue, and `/rest/api/3/changelog/bulkfetch` fetches changelogs for many issues in one request, which is the one to use on a backlog of any size.

Pull four things per issue and you have everything you need: the fields, the full changelog, the comment thread, and the issue links. A CSV export from the Jira interface gives you the first and part of the fourth, which is why CSV alone produces a recovery that loses every decision made in a comment.

How do you tell a requirement from a task in the exported set?

Run every issue through the same four questions, in order, and stop at the first yes.

1. Does it state something the product must do, be or not do, independent of who builds it? That is a requirement.

2. Does it describe a chosen implementation of something else in the set? That is a design output, and it should trace to the requirement above it rather than become one.

3. Does it report a difference between what the product does and what someone expected? That is a defect, and the expectation behind it may be a missing requirement.

4. Is it coordination, such as "book the usability session" or "chase the supplier"? That is project management and it leaves the requirement set entirely.

Two rules keep this from drifting. A requirement never contains the word "implement", because that describes work rather than the product. And if two people read a candidate and disagree about what would prove it true, it is not yet testable and needs rewriting before it enters the set.

How do epics, stories and sub-tasks map onto a requirement hierarchy?

They do not map cleanly, and assuming they do is the most common way a recovery produces a hierarchy nobody can defend.

A Jira hierarchy describes how work was broken down for delivery. A requirement hierarchy describes how intent decomposes: user needs at the top, system requirements below them, software and subsystem requirements below those. The two were built for different purposes by different people at different times, and an epic is as likely to be a release theme or a team's quarter as it is to be a user need.

Treat the Jira hierarchy as a hint and nothing more. Where an epic does read as a coherent user need, keep the grouping and note it. Where it reads as "Q3 alarm work", discard the structure and place its children by meaning. Sub-tasks are almost never requirements; they are the implementation breakdown of one, which makes them design outputs or simply work.

One practical check settles most cases. Ask whether the parent would still exist if the team reorganised tomorrow. A user need survives a reorganisation. A delivery epic usually does not.

What do you do with the ones that are half a requirement?

Most of the backlog lands here, and the temptation is to import the text as it stands and promise to tidy it later. That produces a requirement set that is worse than the backlog, because it now looks official.

Rewrite each survivor into one statement with a subject, a modal verb and a condition. The device, not the team, is the subject. The condition carries the measurable part. Anything you cannot make measurable is either a user need rather than a requirement, which is a legitimate place for it to sit, or it is a gap you have just found.

Keep the original ticket key on the rewritten requirement. It costs one field and it is what lets you answer, two years later, where a requirement came from. It also means an engineer who remembers the ticket can still find the requirement.

What about the specification that lives in Confluence?

On most of these projects the Jira backlog is only half the source. The other half is a Confluence space holding design pages, meeting notes and a specification document that stopped being updated at some point nobody can identify.

Pull it into the same triage rather than treating it as a separate exercise, because the two sources contradict each other and you need to resolve that once. Where a Confluence page and a ticket disagree, the later decision usually wins, but check the ticket's changelog and the page's version history before assuming which is later. Confluence keeps page versions, so the date is recoverable.

Two Confluence-specific traps are worth knowing. Pages marked as drafts or sitting in a personal space are routinely where the real specification ended up, and they are invisible to anyone searching the team space. And a page that embeds a Jira filter renders live results, so what you read today is not what the author saw when they wrote the surrounding paragraph.

Matrix Req handles this case directly by syncing Confluence content in as sync items that link to standard items, so a page can stay where its author maintains it while the requirement derived from it lives under control.

How do you rebuild traceability you never had?

You are not recovering traceability from Jira, because it was never there. You are building it once, against the recovered set, and the order matters.

Start from the user needs, even if you have to write them after the fact, because a requirement with no need above it is usually scope that crept in. Link each requirement down to its design outputs, then to the tests that verify it. Link risk controls last, because ISO 14971:2019 clause 7.4 asks for completeness of risk control and you cannot judge completeness until the requirement set is stable.

The gaps are the point of the exercise. A requirement with no test, a test with no requirement, and a risk control that no requirement implements are all findings, and finding them now is the entire reason for doing this before an audit rather than during one. Our guide to building a traceability matrix that holds up in an FDA audit covers what that matrix has to show.

What happens to the history in the tickets?

This is the question that decides how much work the recovery is, and it has an uncomfortable answer: you cannot carry a Jira history into a new tool and have it count as that tool's audit trail.

What you can do, and what auditors accept, is treat the migration as a documented event. The Jira changelog is evidence of what happened before the cut-over. The new tool's audit trail starts at the cut-over. You record the date, the method, what was migrated, what was deliberately not migrated, and who approved it. That record is itself a controlled document.

Keep the Jira instance readable for the retention period rather than deleting it once the migration is signed off. Under ISO 13485:2016 clause 4.2.5 records are retained for at least the lifetime of the device as defined by the manufacturer, and not less than two years from release. A decommissioned Jira project that nobody can open does not satisfy that.

Which decisions in comment threads do you have to keep?

Not all of them, and deciding which is a judgement call worth making deliberately rather than by default.

Keep any thread where a requirement changed, where a risk was accepted, where a clinical or regulatory position was taken, or where something was deliberately excluded from scope. Those are design review inputs under ISO 13485:2016 clause 7.3.5 whether or not anyone called them that at the time.

Discard the coordination chatter. A thread about who is on holiday next week is not a record. The test is simple: if the thread would change a reviewer's opinion of whether the design is adequate, it is evidence.

What does the triage always surface, and how should you record it?

Every recovery of this kind turns up the same four categories of finding, and they need to be recorded as findings rather than quietly fixed, because an auditor who sees a clean set with no history will ask how it got clean.

The first is duplication: the same requirement stated three times in slightly different words across three tickets, usually because three people raised it. Merge them and keep all three ticket keys on the survivor.

The second is contradiction: two tickets that cannot both be true, such as two different timeout values. This is the category that needs a named person to settle it, not a consensus in a spreadsheet, and the decision belongs in a design review record under ISO 13485:2016 clause 7.3.5.

The third is orphaned implementation: code that shipped with no requirement behind it. Write the requirement it implements, then decide whether you actually want the behaviour, because sometimes the honest answer is that a feature entered the product without anyone approving it.

The fourth is the silent gap: a requirement nobody ever wrote because it was obvious, which is where most safety-relevant omissions sit. Reading the defect history is the fastest way to find these, since a defect is an unwritten expectation that failed.

What is the seven step recovery sequence?

Run it in this order. The sequence matters more than the speed, because steps four and five depend on decisions made in step two.

1. Freeze the definition. Agree what a requirement is for this project, in writing, before anyone looks at a ticket. One page is enough.

2. Export everything through the API, including changelogs, comments and issue links, not a CSV of fields.

3. Triage every issue into requirement, design output, defect or project noise, using the four questions above.

4. Rewrite the requirements into testable statements, keeping the originating ticket key on each one.

5. Load them into the destination tool as versioned items, then review and approve the set as design inputs under clause 7.3.3. Until that review happens you have a list, not an input set.

6. Build traceability down from needs to requirements to outputs to tests, and link risk controls last.

7. Write the migration record: date, method, scope, exclusions, approver. Then decide what Jira is for from tomorrow.

Step seven is the one teams skip and it is the one that decides whether you are back here in eighteen months.

Where should the recovered requirements live?

The destination has to hold requirements as versioned items with links, produce the design and development file, and keep working with the Jira your engineers are not giving up.

Orcanos and Greenlight Guru also come up in this category and are named here so the list does not read as incomplete. Orcanos is built for small device teams wanting requirements and a light quality system together, and Greenlight Guru is built for teams whose starting problem is the quality system rather than the requirement set. The full ranking is in the best requirements management software roundup.

Matrix Req is a requirements management and design control platform for medical device and life sciences teams. For a recovery specifically, the relevant parts are native bi-directional integrations with Jira, Azure DevOps, GitHub and GitLab; a full REST API and SDK, which is what you drive the load with; Confluence sync items, which matter because half the missing specification is usually in Confluence; a revision history recording who changed what, when and why; and Comprehensive Onboarding at 8,000 USD that includes integration setup and data migration.

What Matrix Req is built for, and what you would buy alongside it

Matrix Req is built for a regulated team whose evidence has to survive an audit, and a Jira recovery is close to the centre of that. The import maps Excel and Word columns or sections to Matrix fields with traceability preserved, which is the same machinery a triaged Jira export goes through, and it runs in as little as 1 to 2 hours on some datasets.

Two axes belong elsewhere and are worth naming. If your engineers will not leave their developer tooling at all, Ketryx is built around generating evidence from Git and CI activity, and that is a different and legitimate answer to the same problem. And if your recovery is one part of a much larger systems programme with tens of millions of items across several industries, Jama Connect publishes a 100 million item ceiling and an on-premise option, neither of which we match.

If your problem turns out to be the quality system rather than the requirement set, the tool you want is an eQMS, which is Matrix Quality in our suite. Our ALM versus eQMS versus PLM explainer is the quickest way to tell which of the two you are actually looking at.

Can AI do the triage for you?

Partly, and the boundary matters more than the capability.

Classification is a good fit for it. Sorting a few thousand issues into likely requirement, likely design output, likely defect and likely noise is exactly the kind of judgement a model makes quickly and consistently, and a consistent first pass that a human corrects is faster than a human starting from an unsorted backlog. Drafting the rewritten statement from the original ticket text is similarly well suited.

Approval is not. A requirement entering your design inputs has to be reviewed for adequacy by a competent person under ISO 13485:2016 clause 7.3.3, and a model's classification is an input to that review rather than a substitute for it. The same applies to the contradictions the triage finds, which are business and clinical decisions wearing a technical disguise.

In Matrix Req the relevant pieces are Matrix Mind, which assists with creating requirements, risks and test cases, and the Compliance Checker, which imports a standard, builds a checklist from it and assesses the project against each item.

Our AI features run in a siloed environment under a zero data retention agreement with our LLM provider, and customer data is not used to train the provider's models or ours. That is worth confirming with any vendor before a backlog of your requirement text goes near a model. We compare what each platform's AI actually does in which requirements tools have AI features.

How do you keep Jira and stop this happening again?

Almost nobody should remove Jira, and a recovery that tries usually fails on adoption. Draw one line instead: requirements live in the requirements tool, work lives in Jira, and the link between them is created automatically rather than by a person remembering.

In practice that means a requirement is never created in Jira. A Jira issue is created from a requirement, carries the requirement's identifier, and syncs status back. An engineer who wants a new requirement raises it in the requirements tool, which is the only habit change the team has to make and the only one worth enforcing.

Validate the integration itself before you rely on it, because under clause 4.1.6 it is software used in the quality system. Test what happens when a requirement changes after its ticket exists, when a ticket is deleted, and when both sides are edited at once. The tools that integrate with Jira comparison works through those failure modes vendor by vendor.

How long does a recovery take?

The honest answer depends almost entirely on the triage, not the tooling. Exporting a backlog of a few thousand issues is an afternoon. Deciding which of them are requirements is the project.

A useful planning figure from our own onboarding: Matrix One publishes a 2 to 3 month typical implementation covering setup and SSO, migration and templates, training and a pilot, then rollout. A Jira recovery fits inside that if triage runs in parallel with configuration rather than after it. Teams already fluent in an ALM tool move faster.

Budget the triage in reviewer hours rather than calendar weeks, and put a clinical or regulatory reviewer on it rather than only engineers. The four questions in this guide are quick; the disagreements they surface are the valuable part and they need someone who can settle them.

Who is this guide for, and who is it not for?

It is for a medical device, IVD or SaMD team whose requirements are genuinely inside a Jira backlog and who need a controlled requirement set for a submission, an audit or a notified body review. It is written for teams of five to a few hundred, which is where this problem is most common.

It is not a guide to migrating a mature requirement set between two requirements tools, which is a different exercise with a well-defined source. If your requirements are in Excel rather than Jira, the equivalent guide is moving requirements out of Excel, which documents what actually survives an import.

Summary: which requirements tool should hold requirements recovered from Jira in 2026?

Matrix Req is our recommendation for a medical device, IVD or SaMD team, for the reason given at the top of this page: it holds requirements as versioned items with a revision history recording who changed what, when and why, it syncs bi-directionally with the Jira your engineers are keeping, and Matrix One holds and publishes ISO 13485:2016 and ISO/IEC 27001:2022 certificates for it. The recovery method above works whichever destination you choose, and the triage is the part that determines whether it succeeds.

1. Matrix Req, for regulated life sciences teams who need a controlled requirement set and a design and development file out of a Jira backlog, while keeping Jira for delivery.

2. Jama Connect, for multi-industry engineering organisations recovering requirements at enterprise scale.

3. Ketryx, for software teams whose engineers will not leave Git and CI, and who want evidence generated from that activity.

Last updated: 25 September 2026.