Are you challenged with trying to map Agile Software Requirements to a traditional requirements model for the documentation required during internal or external audits?
If you answered “yes”, you are not unlike many of Rally’s highly regulated customers who want to reap the benefits of Agile but struggle to find good tools for creating and managing system documentation. For the next two posts in our Agile Tooling for High Assurance Software series, I will provide an overview of the material that I presented to a small sampling of customers in early May at our inaugural RallyON conference in Boulder. This work is a continuation of the project that Dean Leffingwell and I have been working on over the past year.
Let’s start by reviewing Dean’s post, Agile Software Requirements in High Assurance Development, which provides us with a traceability model as well as a medical device example to follow. From there I’ll demonstrate how Rally can be used to support traceability from what we traditionally think of as a PRD, a document detailing the system’s intent, to user stories that are commonly used to implement the features of the system.
An important part of the 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. But first we need to begin with a PRD that defines the overall behavior and intent of the system. This will serve as design input in FDA terms. The PRD is going to be decomposed into individual features that will be implemented by many Software Systems Requirements, which we’ll also refer to as User Stories. Take a moment to review the illustration.
With regard to managing these requirements, many of us have encountered or even created spreadsheets with thousands of rows of requirements and tens of columns of attributes that described the system we intend on building.
As part of the introduction to Agile practices we will trade-in the spreadsheet for an Agile Lifecycle Management (ALM) tool that will provide us with better traceability to the real system being implemented. An ALM tool, like Rally, allows us to create a high level user story that will represent system intent and maintain those items that we said were important to document such as a PRD. In Rally the system, intent, features, and user stories will all be tightly coupled by creating a family of user stories through parent/child relationships.
The screenshot below shows the EPAT example that Dean Leffingwell described in his post, extrapolated in Rally. Notice that our EPAT Device Enhancement has been broken down in a way that will allow us to trace each child user story back to the PRD (represented by a parent user story). Another convention being used in this example is that of tagging. Rally users often tag stories to represent requirement types like PRD, SRS, functional, or non-functional stories for better reporting on specific story groups.
Being prescriptive and consistent when structuring our Agile Software Requirements (User Stories) in Rally provides us with the unique capability to create our own custom document exports, such as the Product Requirement Document that I will highlight in a post next week.
In summary, Rally helps us to transform individual user stories that each implement a small increment of value into a aggregation of stories that represents the intended product.
To learn more about Rally’s User Story Hierarchy watch this informational video.
And, as always, I encourage your comments on this post or email email@example.com.
Craig Langenfeld is a Technical Account Manager with Rally Software Development who has been working closely with many Agile practitioners in the healthcare industry to define best practices.
Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Between consulting engagements and keeping up with his Blog Dean managed to publish his latest book, Agile Software Requirements.