Summary
A discussion of why the FDA requires 3 documents for software components in medical devices?
Why 3 documents?
The FDA requires 3 documents for a software component:
- SRS - Software Requirements Specification
- SDD - Software Design Description
- TP - Verification Test Protocol
When I first heard this, my question was why? Why all three? It seemed like there was a lot of cross-over between the docs and, in fact, no need to have all three, right? One or maybe two were sufficient, so why do we have to do all three?
To figure this out, I used a thought experiment https://en.wikipedia.org/wiki/Thought_experiment. In short, take each of the three documents, assume that it is written perfectly and see what it brings to the table, that the other two don't have.
The assumption has to be that it's written perfectly. It was quite possible that the FDA intent is to use the imperfectly written documents as cross-checks against each other i.e. writing one document gives us content from one perspective, writing another document from a new perspective gives us a way to ensure those contents are correct. TLDR yes this is a side benefit to having all three docs.
Why
The reason I wrote this page is to show the intent of these documents. I found that having these in mind while writing the documents made it much easier to determine what I should and should not include in a particular document.
It also made it easier to determine how to write those documents. What verbiage, what wording, how compact or verbose to make a particular statement, etc.
The SRS is perfect
Imagine an SRS for your project appears by magic. It's perfect.
- all necessary behaviors are covered by a requirement
- all requirements are clear and understandable (assume the Reasonable Person theory https://dictionary.justia.com/reasonable-person#:~:text=A%20phrase%20used%20to%20denote,and%20the%20interests%20of%20others
- all requirements are testable
- all requirements cover some behavior that occurs
- hazard mitigations are covered
- all stakeholder's needs are met:
- other components and subcomponents in the project
- clinical needs
- users, patients, nurses, doctors and other users of the device/software
- service technicians e.g. maintenance, calibrations, updates, etc.
- manufacturing e.g. device assembly assistance, installation self-tests, etc.
- marketing
So why would you need a design doc (SDD)?
The SRS declares component behaviors and should be independent of implementation details.
On the other hand, the SDD approaches the project from the software architecture perspective. It contains information that is useful for implementation purposes. The internal structure shows how acceptable behavior is allowed to happen while unacceptable behaviors (e.g. failures) are automatically disallowed or detected It shows constraints based on implementation architecture e.g. max processing speed.
The SDD must still have some independence from implementation details, but it should show more information from a software development point of view.
So why would you need a Test Protocol (TP)?
The behavior specified in the SRS is clear, but how to test that behavior is not laid out. An experienced tester could directly use the SRS document to test it, but a second tester may use a different approach. There may be gaps in their test approaches as well. Having a document explicitly specifying the actual and specific steps to use and what information to gather, confirm and verify ensures consistency in the testing of the SRS behaviors.
The SDD is perfect
Imagine an SDD for your project appears by magic. It's perfect.
- all pertinent descriptions of the design's architecture are clear, comprehensive and understandable (again, assume the Reasonable Person theory)
- all relevant architectural designs support any behaviors required by stakeholders
- as many possible failures modes are automatically prevented or detected by the architecture
- the architecture makes it easy for software to be extended, changed, or deleted i.e. isolation and encapsulation are key concepts
- the architecture makes it difficult for software implementation to cause failures
So why would you need a requirements doc (SRS)?
The SDD concentrates more on the high-level implementation factors and less on specific behaviors needed.
On the other hand, the SRS makes it very clear each and every specific behavior required by all stakeholders. From the SRS perspective, how that behavior is implemented or architected is irrelevant. The users and other stakeholders don't care if the code is architected one way or another, they only care how it behaves.
So why would you need a Test Protocol (TP)?
The architecture specified in the SDD is clear, but what should be tested is not laid out by the SDD doc. Based solely on the content of the SDD multiple testers could test very different sets of behaviors. Consistency of the testing of multiple versions of the software should remain very similar.
They may also test what the software component architecture does, rather than what the software component should do. For example, given one architecture, the behaviors expected by the stakeholders is some set of tests. If the architecture is changed, the behaviors expected by the stakeholders remains the same and therefore the test protocol used should stay the same as well.
The TP is perfect
Imagine a TP for your project appears by magic. It's perfect.
- all necessary behaviors are covered by a set of test steps
- all necessary conditions for a specific behavior are covered by one or more test steps
- all required behavior is checked by an assert or confirm in one or more test steps
- each step is easy to read and understand (the Reasonable Person theory again)
- the test sequences are consistently reproducible by multiple, different testers
'''So why would you need a requirements doc (SRS)?'''
This is a bit of a trick question. To create a perfect TP requires a pretty darn good SRS laid out to be testable.
More subtly, a test sequence can imply a behavior, but it isn't necessarily explicit enough for post fact agreement about what the actual behavior is. If the TP was perfect, then it's easier to guess that behavior. But in reality the TP may not be crystal clear what behavior it is trying to test. One workaround could be to specify that behavior in the TP itself, but that's just merging the SRS and the TP into one document (having them as separate documents eases maintenance issues).
'''So why would you need a design doc (SDD)?'''
The TP declares test procedures and should be independent of implementation details (as much as possible). The SDD specifies the design and architecture used to accomplish those behaviors. It can change towards a new architecture while the TP would remain the same.
Conclusion
All three documents specify and clarify different aspects of the system. There is some connection amongst all three but generally their perspectives are different.