Agile Methods with MedDev Software Requirements Gathering Lots of people have written about using Agile in medical device software development. There’s no one-size-fits-all when it comes to implementing Agile, or iterative, development processes in a medical device organization. Each organization, each project group, has differing needs and the process needs to be tailored, measured, analyzed, and adjusted to meet those needs.
| If you are unfamiliar with the Agile Manifesto, you can read it here. You can read about different process frameworks that implement Agile here. Note that TIR45:2021(2018) is a guidance document about implementing Agile in medical device software development. |
Dr. Christian Johner brings up several pitfalls when implementing Agile within a medical device development process.
One of Dr. Johner’s points that I have been thinking about a lot is, “User requirements never change in a given context of use. Rather, there is a deficit of identifying these usage requirements in a systematic, complete and correct way. And companies try to compensate for this deficit by creating a development process that can deal with these changes.”
In my experience the customer (or marketer) either does not know what they want until they see it, or they do not know how to describe what they want until they see an implementation.
So how do we fix this? Is there a way to apply an iterative or Agile process to a requirements gathering process? The answer, of course, is that there are lots of ways to implement Agile for requirements gathering. In this blog post I will describe one such approach.
Please note that your organization may be able to adopt this process as-is. But more likely you will need to analyze your own needs and determine how, or if, to adopt this process to your requirements gathering.
Using Agile in Requirements Gathering
The iterative steps for requirements gathering are:
- Requirements Elicitation
- Requirements Analysis
- Requirements Documentation
- Requirements Validation through Prototypes
The iterative steps do not need to be done in that order. Evaluating the prototypes with the process actors may elicit new requirements.
Requirements Elicitation
The purpose of the elicitation phase is to gather as many requirements as possible. Talk with subject matter experts, marketers, customers, etc. to gather information and knowledge about the proposed software product. Determine the problem the software product will solve and identify its key features.
Requirements Analysis
During the analysis phase start sorting, prioritizing, and structuring the requirements with the aim to understand the software system as a whole. Identify missing requirements. Determine emergent requirements. And resolve conflicts between requirements.
Requirements Documentation
The documentation phase further distills the prioritized requirements into unambiguous language. This includes all features, security and safety requirements, maintainability requirements, etc.
Requirements Validation through Prototypes
From the analysis, you know which requirements are highest-priority. They could be mission-critical or identified as having the largest safety risk. Build prototypes for these requirements first. The purpose is to get something in front of the customers quickly to elicit feedback and to validate the development team’s understanding of the requirements.
Prototypes could be static like drawings or storyboards. They could also be dynamic applications that implement subsets of requirements. Here you can decide whether you want to build an evolutionary prototype where new features are added to it through every iteration. Or you can build several throw-away prototypes to validate each requirement or subset of the requirements. For both evolutionary prototypes and throw-away prototypes, be sure to have a configuration management plan in place where each iteration or throw-away prototype is tagged with traceability back to the requirements they are validating.
Keep in mind that the purpose of these prototypes is to validate the requirements, not to build the final product. Use the time to test out critical features, new technology, or new architectures. The prototypes may be evolved into the final product as your project team moves through the design and construction phases, but do not succumb to the temptation to build a polished, final version while creating prototypes for requirements validation.
Prototyping helps stimulate and sustain communication with the customers and across the cross-functional team. Prototypes and experimentation encourage participation from all process actors. Prototypes also assist in analyzing the software – they help uncover the details of the software system. Prototypes allow for rework and correction of misunderstandings.
Mapping to SCRUM
The requirements elicitation phase creates the product backlog. The analysis phase would be sprint planning and where the development team and other process actors choose the sprint backlog. After each prototype is created the team will evaluate the prototype against the requirements that were implemented during this sprint which is the sprint review and sprint retrospective. Then the prototype would be evaluated against all the requirements during product backlog grooming to validate the requirements, correct ambiguities or mistakes, and help elicit new and emergent requirements.
Final Thoughts
- You will need a planned configuration management tool (i.e. GitHub branches) to keep track of each prototype.
- Keep prototypes simple to answer the question, “Are the requirements correct?”
- Never underestimate the power of a wireframe, clickable PDF to test out a GUI.
- The prototype may be evolved into the product or thrown away. If it’s evolved into the product, the code will need to be reworked to incorporate changes from the software architecture design and detailed design activities.
- Some requirements won’t need to be built into the prototype. They can be validated through documentation reviews. It’s up to the project team to determine which prototypes to create and in what order.
Iterative and Agile development techniques can be used to create prototypes during the requirements gathering process in order to increase confidence that the requirements are complete, correct, and unambiguous.
How has your organization implemented Agile? Or do you feel that Agile is not an effective approach to medical device software development?
Further Reading
Another good read about implementing Agile for the entire development process is “An agile approach to medical design” by Carl Warren at Team Consulting.
If you have any questions feel free to reach out to me Contact Us Now – Luova Solutions (luova-solutions.com)
