.png)
Over the years, I have helped a lot of clients rewrite their software requirements. Big and small alike, they often have problems writing good, clear, testable requirements. Like software itself, there are rules, standards, and best practices, and it takes both study and practice to get good at it. In this post, I will give some guidance from lessons I have learned over the years.
Let's start with the categories of requirements your SRS should have.
Functional Requirements: These define the features being provided by the software - what the software needs to accomplish. These should be traceable to system requirements and market requirements. They are generally discussed between the stake-holders and the engineers. These should include "happy path" and error handling.
User Interface Requirements: These describe what the user interface must include. I do not like to put UI design elements in the requirements, as those tend to change often and are not "requirements." But having the elements, such as describing the menu of options for a user, is good. The alarms, warnings, and operator messages should be included, as well as how erroneous input will be handled.
Capability Requirements: These describe the performance requirements, timing requirements, computing environment limitations (memory size, etc.)?
Software Inputs and Outputs and Data Requirements: These represent what data being input is acceptable, including the type of data (numerical, alpha-numeric, etc.), ranges, limits and defaults used, and associated data output. These also describe the data storage requirements and event logging requirements.
Software System Interface Requirements: These describe what external interfaces and connections must be supported by the software, and provide detail of what will be supported. Protocols should be referenced in the SRS but should not be part of the SRS. For example: Software shall support the the serial protocol per specification XYZ.
Security Requirements: These explain what is required of authentication, authorization, audit trails, and data protection.
Risk Control Requirements: These are the mitigations that were assigned to the software in the hazard analysis.
Installation and Maintenance Requirements: These include requirements to allow for installation and acceptance of the software for the production device. These also include upgrade requirements, service requirements, self test requirements.
So what makes a good SRS?
Every requirement must be unambiguous and correct. Nothing should be left to interpretation. I’ve had clients tell me that they purposely left requirements vague so that they would have flexibility to decide later. You can temporarily use TBDs, but don’t introduce ambiguities in the document. They cause misunderstandings between stake holders and developers.
The document should be consistent and complete. Avoid duplication so that you don’t end up with inconsistencies as requirements change. Like the software itself, the document needs to be maintainable.
And lastly, each requirement should be verifiable and traceable. Your test activities need to trace to the requirements, so make sure they have identifiers that do not change when you add requirements or rearrange the document. I like to use tags with unique numbers (ex: SW_REQ0023) that have no order assumed. Using the section headers as your numbers will cause havoc when you want to add requirements and move things around.
Here are examples of good requirements:
Note that the language of the requirement says what the software shall do, not what the user can do or what the hardware will support.
And here are examples of requirements with problems:
A great reference is the IEEE std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications. This is my favorite guidance on the topic.
For even more information on this topic, check out our blog on User Stories Versus Software Requirements.
Working on a project utilizing software requirements? Our experts at Promenade can provide independent testing and regulatory submissions services, enabling your robust, successful market entry.
