Medical Device Software Development—An Example

We’ve kicked off a project, reviewed the SOPs that will guide the project, and created work instructions to apply those SOPs to our project. We’ve set up our repository with Subversion, our ticketing system with Redmine, and our CI environment in Hudson and linked them all together. We’ve completed and captured our use cases, business requirements, software requirements, software design document, and initial hazard analysis. Now what?

Let’s start with an example use case. This use case, along with all project use cases, resides in our repository (of course).

From this use case we derived a number of requirements (and perhaps a few hazards were identified). Here’s a single requirement (pulled from our requirements document) that may have come from this use case. (Note: If we name our requirements in an intelligent way, such that the requirement ID includes the use case number from which it came, the tracing from requirement to use case is obvious.)

Now that’s a fairly bad requirement alone, in that it really doesn’t say much about how authentication is handled, but we’re just dealing with examples here. Next, a project may (or rather, it should) have a software design document. This document offers more details specific to the software design. It is written by technical people for technical people. It explains design patterns, database considerations, libraries, and other specific technical requirements. This software design document may have specific line items regarding authentication implementation (realms, LDAP, etc.). To capture the requirement in our ticketing system, we create a new ticket. This ticket will serve as the parent to all other implementation details related to it.

This ticket alone doesn’t have much meaning. But when we look at its dependencies, we see that there is work to be done. Perhaps ticket #505 is some user documentation need, and #506 has to do with LDAP. Using the ability of our ticketing system to create dependencies we can capture all of our requirements, track their relationship to implementation (including design, development and documentation), organize the flow of work, and trace the entire process. Ticket # 405, our requirement, cannot be closed until all the dependencies are addressed. 

Of course there isn’t anything magical about using an issue tracking system in this way. We’ve all been doing this for years. What is unique to this approach is the fact that we are taking the issue tracing a step further by including user requirements, using a single repository, and tracing through out continuous integration. No longer must we treat the documentation, development, design and testing needs as a part of separate systems. By using our ticketing system to handle all project design and development outputs, we maintain a history record of the entire process and of the relationships throughout. Because of this, we have simplified what was previously a mess of project documentation maintenance. Our traceability matrix is no longer some separate element that must be created and validated after the fact—It is an integral part of our process.

Another great benefit of capture requirements as tickets comes in the form of continuous testing. If you are fortunate enough to have a dedicated tester or testers, this approach provides the QA team the resources needed to test the product not just at the end of a development phase, but throughout. I recall one project I worked on very early in my career in which I became quite annoyed by the QA team. Every day it seemed they would write new tickets in our system, flagging them as “defects,” indicating that some feature of our system was not working. That feature was not working because it was not yet developed! Had the requirements been included in our ticketing system from the highest to lowest level of functional need, such time wasters would have never been introduced.

Finally, and this may be the greatest benefit, by organizing our tickets in this way we achieve something slightly less obvious but at least as important: A more rewarding work environment. Taking on a single very large task can seem daunting, if not impossible. It is difficult to know where or how to start, and, as a developer, it can be difficult to get motivated to work on something that doesn’t seem to have an end in sight. By breaking a project down into many smaller tasks we give ourselves a real way to organize and assign tickets and use sprints within larger iterations to reach end goals. As a contributor to any team, it certainly feels rewarding to close a ticket and say “I completed something today!”

Return to Best Practices for Design and Development of Software Medical Devices