Documenting the software requirements compliant with IEC 62304

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.

Software Requirement Specification (SRS): Typical errors and their consequences 

The typical mistakes of many Software Requirement Specifications (SRS) are the following:  

  • The software requirements are incomplete and therefore do not permit the developers to continue to develop the product, without further inquiry. 
  • The document is incorrect or even contradictory, because the authors weren’t writing a mental model like a software requirement should be documented. 
  • The software requirements are a crude mixture of purpose, customer requests, project requirements (i.e. not only the product), usage requirements, system requirements and specifications for concrete solutions (e.g. relating to the architecture). This problem applies especially in companies that work with the concept of specification sheets (read more about this drama here).

Faulty software requirements 

  • result in costly rework and project delays, 
  • make it difficult to test, because for verification no concrete specifications are available,
  • make it impossible to separate the validation and verification and
  • cause problems during the audit, because the regulatory requirements are not met. 

Some companies try to avoid these consequences, in which they "overly document" and produce a dangerous QM overhead.


Our tip: Specify the software requirements (SRS) from Blackbox point of view 

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:

  • User interface(s)
  • The GUI: positioning of elements, style guides, ... 
  • Behavior of the system to user actions in normal cases and cases of failure: From the system information displayed, calculations, graphics, messages, warnings, "ScreenFlow", ... 
  • The rate at which these reactions take place 
  • To which environments the software (black box) can be Installed (operating system presupposed databases and other server hardware, including RAM) and how this installation is supposed to happen. 
  • How the system should react to user error and overload. 
  • Technical interfaces (to other systems)
    • Structural, syntactic and semantic interoperability and thus technical protocols, data types, classification systems (more on this in the audit guarantor) 
    • Importing and exporting data is also included. 
    • Timing 
    • Expected volume, number of transactions 
    • Expected views and reactions

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?

  • Usage requirements
  • Requirements for the technologies to be used
  • Solution requirements such as "ideas" for the architecture, the database
  • etc.

Evaluate software requirements yourself 

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? 

  1. The software must be able to run on the Motorola processor A383B. 
  2. The software must control the electrode with 50 pulses per minute. 
  3. The software must display the data on the screen in a way that a normal sighted person can read it from 2 metres away. 
  4. The software must be maintainable. 
  5. The software must be available in a beta version within 4 month.
  6. 5000 devices should be sold within 24 months. 

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, 

  • how much you understand when it comes to writing the software requirements, 
  • what your team knows about the subject,
  • how likely your document is to be endured in the audit, 

then take about 8 minutes, and fill out the self-assessment test. Then you know. 

So try it! I look forward for your feedback! 

Software Requirements versus Software Specification

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.

Software Requirements: How we can support them 

Consultancy (partly free) 

 

With our team of consultants from lead auditors and software experts (yes, we also develop ourselves) you can get support anytime. Fast, highly professional and uncomplicated. And with minor problems, we even consult free. Simply use the free audit consultation hour or contact us.

Find out what Johner Institute can do for you
Starter-Kit_rot_dunkel

A quick overview: Our

Starter-Kit

Learn More Pfeil_weiß
blog_rot_dunkel

Always up to date: Our

Newsletter

Learn More Pfeil_grau
X

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.