You can have hundreds of work items in Jira and still have a traceability problem. Traceability isn't about how much data exists. It's about whether the relationships between requirements, risk controls, implementations, and tests are complete and understandable.
The IDA project we've been using across this series is small enough to walk through by hand, which makes it a useful stand-in for five gaps that show up in almost every IEC 62304 Jira project, no matter how well-structured it looks on the surface.
Gap 1: Requirements not linked to verification
Both work items exist. The Software Requirement is in Jira, the Test Case is in Jira, but nothing connects them, so the question "which test verifies this requirement?" has no answer you can point to. IDA-2 (Patient-configurable insulin sensitivity factor) is exactly this case in the IDA project: no Is Verified By link, and no issue links at all.
Prevention: require an explicit verification link before a Software Requirement is considered done, and periodically review the project for requirements with an empty Is Verified By column.
IDA-2 isn't the only one. Links Explorer's Tree View has a dedicated Show Orphan Issues toggle that sweeps the whole project for exactly this, and in the IDA project it also turns up IDA-9, a second unlinked Software Requirement, and IDA-8, a Test Case with nothing linked to it either: the same gap, from the other side.
Gap 2: Risk controls not connected to software requirements
Your risk analysis exists. Your Jira requirements exist. But there's no visible relationship connecting the two, so nothing in Jira shows that a given requirement exists because of a specific risk control.
IDA-5 (Low glucose alarm threshold configurable per patient) shows a partial version of this gap in the IDA project. It has an Is Verified By link to IDA-6, so verification looks complete. But it has no Is Driven By link to any risk control, unlike IDA-1, which we connected to its risk control, IDA-7, in the last article. A requirement can look fully verified and still be missing its most important upstream relationship.
Prevention: represent relevant risk controls as their own Jira work items, and require the link before treating a safety-related requirement as complete.
Gap 3: Your RTM is outdated
You generate an RTM, keep developing, add a test, remove a link, and forget to update the spreadsheet. Within a sprint or two the document no longer represents the current Jira relationships, but it still looks authoritative because it has a title and a date on it.
Prevention: generate traceability evidence from the current Jira data instead of maintaining a manually synchronized copy. A view generated from IDA-1 through IDA-7's live links this morning reflects this morning's relationships, not whatever the project looked like when someone last exported a spreadsheet.
Gap 4: New requirements don't have verification evidence
A requirement gets added mid-sprint. Everyone assumes a test will show up for it eventually. The sprint closes, the feature ships, and the verification relationship is still missing. It ends up looking exactly like IDA-2 from Gap 1, except this version of the gap is a timing problem more than a structural one: the requirement was never intentionally left unverified, it just never got picked back up.
Prevention: make the verification link part of your Definition of Done or design-review gate, not something checked only right before an audit.
Gap 5: You can trace forward but not backward
Your team can answer "which test verifies IDA-1?" (forward, requirement to test). Try answering "which requirement does IDA-3 verify?" (backward, test to requirement) and the answer often lives only in someone's memory.
Both directions come from the same underlying link, just read from opposite ends. IDA-1's Is Verified By column points to IDA-3, and IDA-3's own Verifies column points right back to IDA-1. The screenshot in Gap 2 above already shows both columns side by side.
Prevention: review traceability in both directions during design and verification reviews, not only requirement-to-test.
Audit-readiness checklist
- Every software requirement has a unique identifier.
- Requirements have upstream sources (risk controls or system requirements) where applicable.
- Requirements have implementation relationships.
- Requirements have verification relationships.
- Risk controls are connected to the requirements they drive.
- Tests have requirement relationships.
- Orphan requirements can be identified, not just assumed not to exist.
- Traceability works in both directions: requirement to test, and test back to requirement.
- Cross-project relationships are visible where the project boundary doesn't match the traceability boundary.
- The generated RTM reflects the Jira relationships as they exist right now.
Turn gap detection into a recurring activity
Don't limit traceability review to the week before an audit. It fits naturally into sprint reviews, design reviews, verification reviews, or whatever quality gate your process already has.
Instead of asking only "can we build the RTM?", ask throughout development: what is currently unlinked? Links Explorer supports that question directly, by making the relationship structure visible and letting the team focus attention on orphaned or incomplete chains like IDA-2 and IDA-5, rather than discovering them for the first time during an audit.
What's next?
The final article in this series puts the whole workflow together: turning the IDA project's Jira work item relationships into a live, exportable IEC 62304 Traceability Matrix.