Overview
Product requirements in biotech are often written as if the product were a conventional business tool. “Add a sample,” “review a result,” or “export a report” sounds clear until the team has to define the method, units, sample state, quality controls, permissions, and responsible reviewer.
Those omissions do not stay in the document. They reappear as ambiguous screens, hidden assumptions in APIs, inconsistent records, and expensive rework when the product reaches a real laboratory or regulated workflow.
Why the problem exists
Scientific teams describe work in terms of methods and evidence, while product teams often describe it in terms of features. A requirement can therefore be technically complete and still fail to describe the decision a scientist needs to make.
The gap is largest around exceptions: a failed control, a changed protocol, an unusable sample, a result outside the expected range, or a review that must be repeated. These cases are part of the work, not edge cases to be postponed.
The approach
A useful requirement starts with the user and the decision, then names the context needed to make that decision. It defines allowed states, units, precision, provenance, failure responses, and the evidence that proves completion.
Requirements are reviewed as connected slices of a workflow rather than as an isolated backlog. A sample record, for example, is checked alongside its protocol, instrument run, result, review action, and downstream use.
The decision
The team should document domain decisions before polishing the interface. This makes it possible to distinguish a true product rule from a temporary implementation choice and to expose unresolved questions early.
Design can then show meaningful states and engineering can build the data model around traceable relationships instead of adding them after the first release.
Evidence package
The evidence package includes traceable requirements, acceptance criteria, domain decisions, prototypes, example records, and verification results. It should include normal, incomplete, repeated, and rejected paths.
Scientific, design, engineering, quality, and operational owners should be able to read the same record and understand what the product is expected to do.
What the case shows
In biotech software, a requirement is not finished when a feature has a name. It is finished when the team can explain the decision, the permitted states, the ownership, and the evidence that makes the result trustworthy.