The IEC 62304 demands that you specify the software requirements in section 5.2. This article shows you how you can not only conform to standards, but also completely document your software requirements with little effort, in a precise and condensed way. This helps you to develop better products faster, more cost-effectively and avoid trouble in the audit.
The typical mistakes of many Software Requirement Specifications (SRS) are the following:
Faulty software requirements
Some companies try to avoid these consequences, in which they "overly document" and produce a dangerous QM overhead.
These free(!) video training sessions show you the way to precise software requirements step by step
Because I come across these problems again and again, which are actually really easy to avoid, I have decided to publish a series of free video training sessions. If you follow my advice, you will get stable and complete software requirements. This will benefit you in several ways:
As I said, the video training sessions are free of charge. You only need to register once.
An SRS should describe the demands for the software as a black box.
How should the system behave outwardly? How does it react via the interfaces, whether for the user interface (GUI) or other systems?
Therefore, SRS should describe:
Why this concept helps to meet the requirements of IEC 62304 Section 5.2
Does this list sound familiar? Then check the ISO 9126 or its successor, the standard ISO 25010, here you will find a wonderful taxonomy. Here, the IEC 62304 has taken a lot of the software requirements for chapter 5.2. You can meet all requirements described in this chapter with the above procedure. We advise you against classifying the software requirements, the way the requirements are classified in the IEC 62304.
And what does not belong in a SRS?
Do you understand what a software requirements document must contain and what it must not contain? Would you know which part of the following phrases belongs in a software requirements specification?
Our self-assessment test gives the answers. And how well does your team know these?
But knowledge alone is not enough. During the audit your documented software requirements specification also counts.
If you want to find out,
then take about 8 minutes, and fill out the self-assessment test. Then you know.
So try it! I look forward for your feedback!
The English term is software requirements specification. This term contains the requirements and the specification. Strictly speaking, both are not identical. We recommend that you specify the software as a black box. That would actually be a software specification. Since the IEC 62304 only speaks of the software requirements, we also use this term, mostly even synonymously.
If you separate the two terms, the software requirements would formulate the requirements more generally than a software specification. Examples:
|Software Requirement||Software Specification|
|The system must show the patient name||The system displays the patient's name in font Arial, size 18, 20 pixels from the right edge of the screen (according to mockup screen X)|
|The system needs to send the data via HL7 connected neighboring systems||When a new patient is detected, the system sends a HL7 V2.6 ADT A01 message via the interface port X, whereby the system has been registered as "KIS" in the MSH segment as the sending system.|
|The system must store the 1024-bit encryption internally||-|
We recommend the black box-like specification, because only these can be tested in the corresponding software system test. In addition, almost all software requirements are more precisely, more completely, more clearly specifiable (and testable in a simpler way) as a black box property. The above table indicates the last line of a few counterexamples.
1. Auditgarant: The step-by-step video training sessions (not only) for standard-compliant software development
If you want to know more about the development of medical software, I suggest the auditgarant. In several video tutorials you'll learn how to document the software requirements quickly and IEC 62304 compliant.
2. Consultancy (partly free)