“Bring Me the Right Rock” – Solving the Medical Software Requirements Challenge

Reading Time: 4 minutes

Someone once told me that most software projects begin like someone asking, “Bring me a rock”.  Subsequent requests about what kind of rock, or how big, or what it’s for, are met with “Just bring me a rock, and I’ll let you know if it’s what I want”.

While that may be an exaggeration, we’ve all had that feeling.  A shared understanding of what software should do and how the user should interact with it is one of the most important contributors to software development success.  The dilemma, of course, is that it’s seldom possible to know all of the needs in advance.

At Syncro Medical we’ve been refining the medical software requirements process for over 30 years, and I have three recommendations to improve this phase of the development effort.  Whether you use these suggestions on your own, or engage a firm like Syncro Medical to help, I think you’ll find that they’ll improve and accelerate your requirements process.

1. Use a combination of approaches to determine and document requirements

The following techniques are used to quickly surface product requirements.  Depending on the characteristics of a product (primarily it’s complexity), use one or more of these methods.

User Interaction Rapid Prototyping

This a very effective and relatively inexpensive technique for defining the user experience.  Many of our clients ask Syncro Medical to help with this process – to take advantage of our expertise and objectivity.  We help evolve the User Interface by creating wire frames and a graphical design.  We create a prototype application that simulates how the user will interact with the product – whether it’s an instrument, a web interface, or a mobile application.  While there are some situations in which we can re-use the prototype code for the final product, typically in the interest of speed and economy, the code is often ‘throw-away” at this stage.  Through a series of rapid iterations, our clients and their key stakeholders get a good understanding of the product’s workflow early in the project when changes can be made quickly, easily, and at the least cost.

Another benefit of UI rapid prototyping is that it inevitably uncovers “hidden requirements”:  desired features that are only discovered by simulating product interaction.  It’s common that this process will uncover hardware or instrument-based features as well, and by capturing them early we can greatly reduce the risk of unexpected delay and cost later in the project.

Use Cases and User Stories

These are two very effective mechanisms for defining how a product should work.  Use Cases define a sequence of operations to accomplish a task, as well as alternate scenarios that define various unusual or error conditions.  User Stories are declarative statements that define functions as a set of goals from the user’s perspective.  For example: “As an instrument user, I want to generate a daily usage report“.

Regardless of the complexity of the product itself, Use Cases and User Stories are easily readable forms of defining product functionality.  Therefore, they can and should be shared with a wide range of participants (both technical and non-technical) in the development effort to be sure that the full team has a common understanding.  Once completed, Use Cases become the basis for more detailed requirements, and User Stories function as the building blocks for Agile sprint planning at the development phase of the project.

For clients that don’t have the time or experience to do Use Cases or User Stories themselves, Syncro Medical can help.  The requirements experts on my staff can guide the process, and depending on client needs, assist your team in completing the effort.

2. Use the Right Tool for Requirements Management and Traceability

I have seen situations in which the tool used for requirements management is out of scale relative to the project needs and scope.  For example, Excel is probably not the right choice to track requirements for a FDA 510(k) Class III product requiring very rigorous, detailed, and traceable requirements.  Conversely, a fully-featured requirements management system may be overkill for a simple product.  In each case, the wrong tool would either impede the effort or worse, provide insufficient detail or flexibility to allow for detailed traceability.

Here at Syncro Medical, our in-house default for products of medium complexity is CaseComplete® by Serlio.  It supports Use Cases and User Stories, as well as tags and manages requirements and associated test cases.  CaseComplete® exports reports and traceability maps as Word documents and Excel spreadsheets.  There are other excellent systems, and for clients who have already selected one, chances are we know it and we’ll gladly use it.  For example, DOORS® and Requisite Pro® are used for more highly complex products that need thorough requirements management.  For less complex products, a spreadsheet may be sufficient.

3. Accept that it’s not necessary to have a fully developed Software Requirements Specification before beginning a software development effort

It’s not necessary to specify every detailed requirement before actually starting to develop the software itself.  In fact, in our experience, chasing the unattainable goal of perfect up-front requirements is often inefficient and can result in delayed product introductions.

Most of us have been trained to fully document requirements prior to starting design and development.  However, in actual practice we have found that development projects benefit from a phased approach to requirements documentation.  Most of the time, creating high-level use cases and associated general requirements can be enough to get underway with the software architecture and design.  More detailed requirements can then be defined and documented as part of each sprint in an Agile process, as the User Stories are being addressed in that sprint.  During the sprint, when the team is most focused on a given module or function, definition of detailed requirements tends to be more complete, and is accomplished more quickly.

In the end, particularly for FDA 510(k) and similar projects, you’ll need to create a formal requirements specification and demonstrate that the requirements have been formally verified.

The approach I’ve discussed above for defining and managing medical software requirements effectively balances efficient and adaptable software engineering with the regulatory needs of medical software development.

Next time you are tasked with providing a “rock”, consider employing this mix of options to optimize the place where regulatory needs and development efficiency intersect.  If you need help with this challenging part of the development process, I’d be happy to talk with you about how Syncro Medical’s requirements experts could be of assistance.


As VP of Engineering at Syncro, Bill leads a team of 30 talented software engineers to help client companies bring their software-enabled products to market faster. Syncro specializes in creating software for medical instruments and systems, conforming to FDA-regulated development processes.Bill has been in the software engineering field for 30 years in a number of other positions, including Software Engineer, Engineering Manager, Software Product Manager, Director of Software Engineering. Bill joined Syncro in 1996.Bill has used many process management approaches and methodologies. His experience has convinced him that good software engineering requires both flexibility and effective, systematic development procedures. When done right, Agile development provides the best of both worlds.Bill applies his deep experience over many years to understand the challenges facing fellow software engineering managers. His engineering team at Syncro accomplishes two key goals for Syncro clients: accelerating the development process and delivering top quality results.

Comments are closed.