Agile Compliance - Bridging the Requirements Gap between Agile and Regulation in Medical Devices
The main challenge of applying agile software development processes for medical devices is that they result in lacking documentation needed for certifications and to pass audits, e.g.:
A requirement specification which lists all the requirements for the software release.
Verification and validation plans which show how it can be ensured that the delivered product is completed and correctly verified and validated.
Verification and validations reports which are signed, reviewed documents with objective evidence that the verification and validation was completed successfully
Evidence that the processes were followed, the plan was executed, updated and reviewed and approved - not just changed on the fly.
Talking about software requirements
What are software requirements according to ISO 62304?
SW requirements are documented, they do not contradict each other, they are unambiguous, they are expressed so that they can be tested, uniquely identified.
They are traced to verification tests and test results and to their source, e.g. product requirements.
Examples: functional, performance, user interface, inputs and outputs defaults and limits, database / data structures, interfaces with other (software) systems, security, network, risk controls, etc.
A standard way to write software requirements uses the word SHALL. Depending on what kind of requirement, it is there can be different methods:
The system SHALL do something (functional requirement), e.g. “the registration screen shall allow the user to enter his name”
Something SHALL be done a certain way (non-functional requirement), e.g “data shall be stored in a database”
WHILE something is the case, something SHALL be the case (state driven requirement), e.g. “while the user is logged on, notifications shall appear”
WHEN something happens, something else SHALL happen (event driven requirement), e.g. “when a new message arrives, a notification shall be displayed”
What are the "requirements" in the agile process?
Agile developers talk about epics and user stories. An Epic can be seen as a big not too concrete idea. A user story is a more concrete definition of a part of an Epic.
Epics can be formulated using this template <As a [role], I want [objective], So I [benefit]>, e.g. “as a new user, I want to register my email, so that I can be informed about news”.
What’s the gap in requirements?
Besides the different ways of formulating the requirements, user stories in an agile process:
will focus more on functional requirements (they describe what the system needs to do);
will be likely to contradict eachother, repeat or extend user previous user stories (as the stories are created when needed and validation feedback comes in early and frequently);
Normally during an agile process, you have a design phase where you convert the user stories into user interface requirements, non functional requirements, etc. For a regulated medical device documentation, these design decisions need to be documented and maintained.
It’s important to understand that the terms “requirements”, “specifications”, “tests” they use in the standards cannot be mapped one to one to terms used in agile processes: epics, user stories, etc. For example, the standards list what you need to do with “requirement” of any level.
How to bridge the gap?
The most efficient way to do this is to add an extra phase after a story has been developed. At the end of a development cycle you know which user stories are done (from a coding perspective) and it will be quickly easy enough to update the requirements, tests in the technical documentation.
Alternatively you could update requirements and tests after each phase of the cycle. For example after the planning the user and functional requirements, after the design, the test description and after the review, the risks, project plans
The downside of this method is that if you figure out during implementation or the review that the design was crap, you need to revisit the documentation.
The key to success
The key to success marrying agile development and regulatory documentation is to not work with documents but with a database of design items and traceability. The QA/RA department will make sure that it is complete and correct and added to the right documents in the right format.
