Software Requirements: How we can support them

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.