Four Tips for Writing Highly Effective Medical Software Requirements
All software requirements are not created equal. I’m not referring to the form or content of the requirements, but to their quality. If you are reading this blog for the key take-away, I recommend you read the following closely: the effect of requirement quality on a software development project can be profound, especially when it comes to medical software development. A set of low-quality requirements, apart from putting patients at risk in the worst of scenarios, can result in a project that plods along incessantly to its conclusion. Good quality requirements result in build after build that make explicit, predictable progress from developers well-engaged in both their strategy and tactics.
The Challenge of Medical Software Requirements
Effective medical software requirements are those that ultimately result in the creation of the product that was envisioned, and that do not present roadblocks and impediments to developing that product in a timely, cost-effective manner. Good quality requirements will guide you to the outcome you originally desired, and will continually instill in the development team a sense of converging on success. Requirements of lesser quality will make your course difficult and frustrating, and your footing will be unsure. So the challenge of the requirements effort is to produce something that is both pilot and navigator for the software project
So, what defines good quality requirements? Limiting this discussion to four shared characteristics, here are my tips to producing quality requirements:
Tip #1: The Requirement is ‘Necessary and Sufficient’
A requirement should state what it needs to and no more. Use explicit “shall” language, do not use undefined or vague terms, and do not hammer home points or include other superfluous or redundant text. Additionally, be careful not to repeat requirements – this can cause problems when the requirement changes and all instances are not duly updated. Requirements have to be consistent with other requirements!
NOT THIS: The table entry will result in additional functionality upon being clicked.
BUT THIS: Upon right-clicking anywhere on the table entry, a modal, acknowledge-only dialog shall appear indicating the entry’s date and time of creation, including time zone.
Tip #2 The Requirement is Focused
Akin to Tip #1, don’t pack too much into an individual requirement. Rather, address a single, or at least cohesive, region of interest (ROI) in a concise manner, without intrusions from other essentially extraneous requirements. In the example below, a single, complex requirement statement is broken into several components. These small requirements are easily rearranged, reprioritized, modified, expanded, deleted, and so on, and will give the ROI a flexibility to accommodate outside forces that are bound to occur. They also keep the ROI organized, a plus to developer-understanding when they crack into it for implementation.
Fields (3) and (4) can be edited by this dialog.
The dialog can discard all changes made via the ‘cancel’ button, without confirmation.
The dialog shall save all changes made via the ‘save’ button.
The save procedure includes a modal confirmation dialog that indicates the customer identifier.
Tip #3: The Requirement is Feasible
Implementation of the requirement must be doable! Requiring millisecond response times in a realm when only minutes are possible will only result in more heat than light in the ensuing discussions. Performance specifications are limited to the actual capabilities of the system design. If a given set of requirements is critical, this needs to be considered in the very early stages and may influence, among others, hardware selection or communication protocol attributes. Stating requirements that are unattainable is an invitation for major conflict at some future point. This is even more critical for medical software development and can negatively impact regulatory approval.
NOT THIS: Upon a precipitous loss of power, all state information since the previous start-up for the application shall be preserved for use by the subsequent power-up-restore-data operation.
BUT THIS: Upon a precipitous loss of power, all but the last 5 seconds (maximum) of state information for the application shall be preserved for use by the subsequent power-up-restore-data operation.
Tip #4: The Requirement is Testable
A requirement that cannot be proven to be implemented correctly or incorrectly, either by manual or automated testing methods (such as the classic “The application shall run indefinitely without crashing”), is not a true requirement. Remember, it is imperative that all your requirements are testable.
NOT THIS: Under no conditions shall the encrypted data exchanged between the server and the remote system be decrypt-able by eavesdroppers.
BUT THIS: Data transmitted between the server and the remote system shall be encrypted using a symmetric-key mechanism.
And So Grasshopper…
Work and rework your requirements as needed now– it’s a lot more efficient to get the requirements in shape up-front, before the developers gleefully go off and build it as stated. Otherwise you risk coming back frazzled months later with something that does not work as intended.
Comments are closed.