What is a good software requirement

Keyword: Documenting software requirements in accordance with IEC 62304

The IEC 62304 requires in chapter 5.2 to specify the software requirements (in English Software Requirements Specification).

This article shows you how you can document your software requirements not only in compliance with standards, but also with little effort, precisely, leanly and completely. This helps you to develop your products faster and more cost-effectively and to avoid annoyance in the audit.

1. What are software requirements?

Neither IEC 62304 nor the FDA define the term software requirements (in English Software Requirements Specification SRS). The definition of the term requirement in ISO 9000: 2015 is also not very helpful:

"Requirement or expectation that defines, is usually presupposed or mandatory"

Source: ISO 9000: 2015 (3.6.4)

The term is therefore simply approached using examples: The software requirements should describe

  • which data must be read in / received / processed,
  • how the data must be processed,
  • what the graphical user interface should look like and how it should behave when interacting with users,
  • the hardware on which the software must run.

Occasionally companies differentiate between software requirements and software specifications. Read more about this below.

2. How to describe software requirements

a) Tip from the Johner Institute

The Johner Institute recommends that a Software Requirements Specification SRS must describe the software requirements as a black box. That means it should define how the system behaves externally and how the software should react via the interfaces, be it to the user (GUI) or to other systems.

Therefore, an SRS should describe:

  • User interface (s)
  • The GUI: positioning of elements, style guides, ...
  • Behavior of the system on user actions in normal and error cases: information displayed by the system, calculations, graphics, messages, warnings, “screen flow”, ...
  • The speed with which these reactions happen
  • In which environments the software (black box) should be installed (operating system, required databases and other servers, hardware including RAM) and how this installation should be carried out.
  • How the system should react to user errors and overload.
  • Technical interfaces (to other systems)

b) Why they meet the requirements of IEC 62304 Chapter 5.2

Does this list sound familiar to you? Then take a look at ISO 9126 or the successor standard ISO 25010, here you will find a wonderful taxonomy. IEC 62304 has also eagerly made use of Chapter 5.2 on the software requirements. You can meet all of the requirements mentioned in this chapter with the above procedure. However, we advise against structuring the software requirements like the requirements in IEC 62304.

And what belongsNot into an SRS?

  • Usage requirements
  • Requirements for the technologies to be used
  • Solution specifications such as “ideas” for the architecture, the database
  • Etc.

c) software requirements Document quickly, leanly and in compliance with IEC 62304

These free (!) Video trainings show you step by step the way to precise software requirements

Because we keep encountering these problems that are actually so easy to avoid, we decided to publish a free series of video training sessions. If you follow these tips, you will get stable and complete software requirements. You benefit from this in several ways:

  • You get peace of mind in the project and avoid constant rework
  • With a clear understanding of responsibilities, you avoid the constant friction between product management and development
  • You save yourself the audit stress and can shine with exemplary documents

As I said, the video training is free. You only have to register once.

Watch the first video right now!

3. Typical mistakes when specifying software requirements

The typical errors of many Software Requirement Specifications (SRS) are as follows:

  • The software requirements are incomplete and therefore do not allow the developers to develop the product without further inquiries.
  • The document is incorrect or even contradictory because the authors do not have a mental model on how to write a software requirements document.
  • The software requirements are a crude mixture of intended purpose, customer wishes, project specifications (i.e. not just the product), user requirements, system requirements and specifications for the specific solution (e.g. relating to the architecture). This problem particularly affects companies that work with the concept of requirement specifications (more on this drama here).

Incorrect software requirements

  • lead to costly rework and project delays,
  • make testing more difficult because there are no concrete specifications for verification,
  • do not allow the validation and verification to be separated and
  • become a problem during the audit because the regulatory requirements are not met.

Some companies try to avoid these consequences by "overdocumenting" and producing dangerous QM overheads.

4. The software requirements checklist

a) Who should use the checklist

Such a checklist for software requirements is used in a document review. The IEC 62304 calls this in chapter 5.2 the verification of the software requirements. You should always take part in it

  • the author
  • the person responsible for the input of the document (here: the person responsible for the stakeholder requirements)
  • the one who has to continue working with the document (here: the software architect) and
  • the person who is responsible for the associated tests (here: software system tester).

Incidentally, this review fulfills the requirements of IEC 62304 (Chapter 5.2) for a verification of the software requirements.

Try it out now and download the checklist.

Download the software requirements checklist

b) Why IEC 62304 Chapter 5.2 is not suitable as a checklist

Couldn't one also use IEC 62304 Chapter 5.2 as a checklist for software requirements in order to check the completeness and standard conformity of one's own document?

Of course you could, but the IEC 62304 in Chapter 5.2 is at least misleading in some places. For example, if you were to test according to the standard, you would have to examine whether the “regulatory requirements” are mentioned. But that would be exactly wrong, because the regulatory requirements are stakeholder requirements and belong in the corresponding document and especially NOT in the software requirements. The software requirements would rather describe how the regulatory requirements have been implemented from a black box perspective.

The points mentioned are also far too general to be able to quickly and clearly check in a review whether the software requirements are precisely formulated. For example, requires that you describe the “interfaces between the SOFTWARE SYSTEM and other SYSTEMS”. That is too imprecise and therefore not clearly verifiable. It would have been better to ask whether the response time is specified for each interface, whether it describes how the product behaves if too much, no, late or invalid data is transferred via the interface.

The software requirements checklist tells you exactly these specific questions.

Download the software requirements checklist

5. IEEE 830 on software requirements

The IEEE 830 is a standard that describes how software requirements or software specifications should be described. The IEEE 830 suggests at least three chapters:

  1. Introduction with documents, meta information (purpose, references, structure) and with an overview of the software
  2. General description of the software: Here you should describe the delimitation to / from other systems as well as the most important product functions and limitations of the solution space. The IEEE 830 also provides for a characterization of the users as part of this chapter.
  3. According to IEEE 830, the specific requirements include functional and non-functional requirements, performance requirements, quality requirements, external interfaces and other requirements.

Wikipedia provides a more detailed overview of IEEE 830 chapters.

Be careful with the IEEE 830 for medical devices

I would like to warn you to blindly follow the recommendations of this standard for medical software. For many reasons:

  1. Mixing of aspects: The standard combines elements of the purpose, stakeholder requirements and system requirements in one document. Laws and standards (e.g. FDA, ISO 13485) differentiate this information and even require that you trace them among each other. You won't be able to do that if you put everything together in one document.
  2. Missing structure for checking: The IEEE 830 does not offer you a systematic structure that helps you to fully document your requirements and simply to check for completeness.
  3. Division into functional and non-functional requirements: IEEE 830 has adopted this division from ISO 9126. This division is no longer up to date. Rather, a breakdown according to interfaces is recommended. More on this in the video training (see below).
  4. Lack of conformity to standards: Even if you follow the suggestions of IEEE 830, you have not given conformity with IEC 62304. Aspects mentioned in IEC 62304 in Chapter 5.2 are missing.
  5. Inner logic: The division is partly misleading. What is the difference between “Restrictions for Developers” (IEEE 830 Chapter 2.4) and “Design Constraints (IEEE 830 Chapter 3.4)? Such a thing easily leads to redundancies.

6. How we support you

a) Auditgarant: The step-by-step video training

If you want to learn more about the development (not only) of medical software, I recommend the Auditgarant. In several video training courses, you will learn how to document the software requirements quickly and in compliance with IEC 62304.

b) Audit Guide: Your auditors' software checklist

If you already have an SRS that you would like to check for usefulness and conformity with standards, then I recommend the audit guide with the complete checklist for all development phases, including for creating the software requirements specification. We have developed the audit guide for notified bodies that use it to carry out medical software audits.

c) Advice (sometimes even free of charge)

Our team of consultants made up of lead auditors and software experts (yes, we also develop ourselves) will provide you with support at any time. Fast, highly professional and uncomplicated. And even free of charge for small problems. Use our free micro-consulting or contact us.

d) Brief checklist for software requirements

The easiest way to quickly check your software requirements for IEC 62304 conformity and to identify possible problems in the audit at an early stage.

Writing software requirements is one thing. Another thing is to check existing software requirements. How do you want to be sure that you have fully assessed the software requirements? Whether there is IEC 62304 conformity?

A Software requirements checklist is a great way to be certain of this quickly.

We have created such a free software requirements checklist for you. This not only gives you the certainty of how likely your software requirements will pass during the audit. In this way, you can also identify and correct errors at an early stage. This avoids time-consuming and costly rework and iterations during development.

Download the software requirements checklist

e) Self-test: Finding out whether you have understood it yourself

Did you understand what a software requirements document must and what not? Would you know which of the following sentences should be used in a Software Requirements Specification?

  1. The software must run on the Motorola Processor A383B.
  2. The software must control the electrode with 50 pulses per minute.
  3. The software must show the data on the display in such a way that a person with normal vision can read it from a distance of 2 meters.
  4. The software must be easy to maintain.
  5. The software must be available in a beta version in 4 months.
  6. 5000 pieces of the device are to be sold within 24 months.

Our self-assessment test will give you the answers. And how well does your team know?

But knowledge alone is not enough. Your documented software requirements specification also counts in the audit.

If you want to find out

  • how much you know about writing software requirements,
  • what your team knows about the topic,
  • how likely your document will survive the audit,

then take about 8 minutes to complete the self-assessment test. Then you know.

So give it a try! I look forward to your feedback!

Here is the self-assessment test

7. For professionals only

a) Software requirements versus software specification

The English term is Software Requirements Specification. This contains the requirements and the specification. Strictly speaking, the two are not identical. We recommend specifying the software as a black box. That would actually be a software specification. Since IEC 62304 only speaks of software requirements, we also use this term, mostly synonymously.

If you separate the two terms, the software requirements would formulate the requirements in a more general way than a software specification would. Examples:

Software requirementSoftware specification
The system must display the patient's nameThe system displays the patient's name in 18 point Arial 20 pixels from the right edge of the screen (according to mockup screen X)
The system must be able to send the data to connected neighboring systems via HL7As soon as a new patient is recorded, the system sends an HL7 V2.6 ADT-A01 message via data interface X, whereby the system is entered as "HIS" in the MSH segment as the sending system.
The system must store the data internally with 1024-bit encryption

We recommend the black box-like specification because only these can be checked in the associated software system test. In addition, almost all software requirements can be specified more precisely, more completely, more clearly (and more easily testable) as a black box property. The table above gives one of the few counterexamples in the last line.

b) Specify software requirements as a state machine

Specifying a medical device as a state machine, which is why I don't think so when I read in a system specification: "If you send the command 'MPS_0320' via the CAN bus, the machine [the medical device] goes into the 'Prepare' state ". But then I notice the catch.

Specify the medical device as a state machine

As an auditor, you are happy about any reasonably precise specification. And if it is even graphically modeled as a state machine with a UML state diagram, then everything should actually be fine.

Indeed, many systems can be modeled as state machines. For example, a machine knows states such as

  • In preparation
  • In stand-by
  • When treating
  • In cleaning
  • etc.

It is also clear that one cannot reach every state from every state. For example, it must not be the case that the machine goes directly from one treatment to the next without first going through the "in cleaning" state. It is precisely these possible and forbidden state transitions that can be modeled as a state machine - for example with a state diagram.

Problems specifying as a state machine

Specifying the system as a state machine also has pitfalls: “How do you want to test that?” I ask my customer. After some thought, the answer comes that you want to query the status via another command in the future.

Be careful when describing your medical device as a state machine. The system requirement or software requirement is a description of the system from the black box point of view. This means that the system requirements (PEMS requirements / PEMS specification) should describe how the black box at its interfaces reacts to actions via its interfaces. However, a state is an internal behavior of a system or a component.

Do without state machines / diagrams?

With this I am in no way arguing against specifying the system as a state machine. But specify the individual states as a combination of behavior visible via the interfaces. So a state is more like a kind of macro (as the C programmers would call it).

A state that is not visible to the outside world has no place in a system or software requirement.

By the way, all of the above applies to programmable electrical medical systems PEMS as well as standalone software and components.

Are you unsure whether you have created a specification that is compliant with the law and will "go through" for approval? Will the specification also help speed up development? Professor Johner and his team are happy to help! Get in contact!