Medical and regulated software

Agile speed, and a requirements document that is always current.

A medical software startup has to know exactly what its product does, and be able to show it to a regulator or an auditor. Writing requirements by hand, turning them into tickets and tracing them through sprints takes more time than building. SpecTrail closes that loop.

5 November 2026 · 6 minute read

Two reasons the document has to be right

The first reason is regulation. Standards for medical device software expect a requirements document that says what the software does, and evidence that each requirement was built and verified. An auditor will ask to see it, and expects it to match the product that was released.

The second reason is the team’s own need. A product cannot be tested until it is defined. To test it you have to know what it does, and you have to know that what it does is what you intended. For a startup that second reason matters as much as the first, because it is how you find a problem before the audit or the customer does.

The long way round

The usual cycle looks like this:

Product writes a requirement.
Someone translates it into a Jira ticket.
The ticket is planned into a sprint.
A developer builds it.
The ticket is closed.
Later, someone works out which version and which sprint each requirement went through.

Every step is manual and takes time, and every step is a place where the document and the code can drift apart. Teams that build with AI agents feel it most, because the code now moves faster than the cycle can follow. The cost usually appears before an audit, as weeks of reconstruction.

Closing the loop

SpecTrail starts from the one thing that is always true, which is the code. It does not ask the team to change how it builds.

Read the code, write the document
SpecTrail turns the repository into user stories with acceptance criteria, grouped by epic and feature, in plain language.
Build however you like
Agents or humans write the code. Tickets are opened before the work, during it or after it. None of that has to change.
Decide when the product changes
Each merged change is compared with the document. When it alters what the product does, a person accepts it, rewords it, or denies it and opens a ticket to fix the code.
The document stays current
An accepted change updates the requirement, and its history records the pull request, who decided and when.

The question “which version and which sprint did this requirement go through?” is answered by the requirement’s own history. Nobody reconstructs it afterwards.

A document people can read, edit and reference

The specification is a natural document, not a table of tickets. It reads as one continuous page in plain language, and the team can edit it directly. Every epic and every feature has a number, so a test, a risk analysis, a ticket or a conversation with an auditor can point at exactly one thing.

Beside each statement, small marks show the code that implements it and the tests that cover it. The document can be exported and given to a regulator or shown to an auditor, together with the history behind it.

Tested automatically, with manual testing next

SpecTrail links each requirement to the automated tests that cover it, so coverage is visible per requirement and gaps are easy to see. Manual testing is coming next: the checks that need a person will attach to the same requirements, with their results kept in the same place.

What the team and the auditor each see

The team

Builds with agents, humans, tickets or none
Sees only the changes that alter the product
Edits the document in plain language

Fast, in agile cycles

The auditor and the regulator

A numbered requirements document that matches the code
The tests linked to each requirement
Every change with who decided it, and when

Tight, and current

Speed and rigour together

On one side, the team works agile and fast, with agents and humans writing code and tickets opened whenever they are useful. On the other side, there is a tight, current document with all the requirements, kept up to date as the code changes. SpecTrail connects the two, so the speed does not cost the rigour and the rigour does not slow the speed.