Background: In this series of posts, I’ve been using medical device development (as Regulated by U.S. FDA via CFR 820.30 and international standard IEC62304) as an exemplar for suggesting ways to develop high quality software in regulated (and other high assurance, high economic cost of failure) environments in an agile manner. This series is sponsored, in part, by Rally Software Development, with a special thanks to Craig Langenfeld for his ongoing contribution.
As we described earlier, verification occurs continuously during the course of each iteration. Validation occurs primarily in the course of special iterations dedicated to this purpose. This is the second in a series of verification posts, covering the Product Requirements Document (PRD), product features, and relationships to the Software Requirements Specification (SRS). (Note: this post may appear out of sequence as I initially wrote it as a validation post, but on reflection, these activities are really part of continuous verification.)
In an earlier post, we described the SRS as a mandatory document, the center of much of our development activity, that consists primarily of a set (a data base, really) of user stories that described the behavior of the system in specific detail. Though we didn’t mention it there, in agile we use the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) model to help us keep our user stories, small and independent. Applying this agile construct helps us build more resilient systems incrementally, which is indeed the core construct in agility. However, since our iterations are short, our stories must be small. And even when we express them in user voice form (As an operator, rotating the energy knob past the point where the system is delivering 5 bar will have no further effect), we are likely to end up with a LARGE number of user stories, potentially numbering in the thousands. That’s ok, because these systems are complex and it takes a lot of little correct behaviors to build a system that works in aggregate to deliver the overall system value we need.
We also noted that there was another governing document, the Product Requirements Document, that provided the overall definition for the subject system.
Product Requirements Document
From the standpoint of the overall product (as opposed to the software that runs much of the product), the PRD is the document that defines the external behavior of the system in clear and unambiguous terms. As such it is a precedent document (a design input in FDA terms) to the SRS and is under the purview of those marketing and clinical personnel who have the relevant authority to decide what the system is intended to do. These are often described as the “labeling claims” for a device, i.e. the set of things the device does to deliver its therapy.
From the perspective of the market, management and the FDA, the PRD is probably the most critical document because it describes exactly what the system is intended to do for the users, and it does so at a level of abstraction intended to make sure that it is understandable by all these key stakeholders. Keeping the level of abstraction sufficiently high enough to make sure the document is understandable, and yet specific enough to drive development is the art of good product definition. The PRD typically contains at least these major elements:
– statement of device purpose
– system context diagram
– descriptions of users and operators
– features of the device
– nonfunctional requirements
– operation and maintenance requirements
– safety features and hazard mitigation
Note: While some of these items are specific to medical devices, guidance for the content of the PRD closely mimics the generic “Vision” document from RUP and other methods. I’ve provided a template/outline for a Vision document in most of my books, starting with (a more classical representation) in Managing Software Requirements: First Edition, A Unified Approach (1999) towards a more Use Case- driven view in Managing Software Requirements: Second Edition, A Use-Case Approach (2003) and a slightly repurposed, more current version in Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. (2011). (If there is interest, I’ll likely post one or more of these on this blog at some point).
Fortunately, making the document understandable by managing the level of detail, and simultaneously not over constraining the software development with over-specificity are sympatric goals, so keeping the descriptions high level in the PRD serves both purposes.
In any case, from the standpoint of system behavior, the primary content of this document is the set of features that the system provides to deliver its efficacy and safety. Features are high-level descriptions of some system behavior that addresses a user need. They can be expressed in user voice form (as a <role>…..) or, more typically, they are expressed in a short keyword phrase or sentence. For example, some claims for our exemplary EPAT (Extracorporeal Pulse Activation Therapy) device might include:
- Adjustable pulse wave frequency from 1-21 hertz
- Pressure amplitudes from 1-5 bar
- Acoustic energy may be concentrated to a focal area of 2- 8 mm in diameter
Tracing from PRD to SRS
While the PRD makes the “labeling claims” for the device via these features, the actual work of implementation is left to the software (and hardware, of course) so part of our verification effort is to assure that every feature traces to one or more user stories (or other forms of software requirements expression) as is illustrated below.
In this way we can be assured that every feature of the system traces to (is implemented by) one or more user stories. In addition, if through analysis we discover stories that do not trace to a feature, we’ll need to at least understand their purpose (some stories needn’t have a parent feature to justify their existence) to make sure that the system behaves only as intended. This particular traceability path gives us a way to reason about the impact of potential feature level changes, and to trace approved changes to features into implementation by the children stories.
That’s it for this second post on Verification, describing the PRD, features and PRD to SRS traceability. Coming next in the series: testing features.
Note: Some readers might (have!) noted the ambiguous description of “agile project management/document management” label in the above graphic. Managing the details of features, nonfunctional requirements, user stories, traceability etc. in agile project management tools, PRD and SRS documents, spreadsheets and the like is a significant challenge in a regulated environment where these documents take on the role of prima facia evidence of efficacy and safety. We’ll return to this topic in future posts as well, but first we must continue to lay out the overall method.