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 try to give some guidance -things I have learned over the years.
Let's start with the categories of requirements your SRS should have.
Functional Requirements: These should 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. Include how erroneous input will be handled as well.
Capability Requirements: What are the performance requirements, timing requirements, computing environment limitations (memory size..)?
Software Inputs and Outputs and Data Requirements: These should define what data being input acceptable, including the type of data (numerical, alpha-numeric..) 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 proved detail of what will be supported. Protocols should be referenced in the SRS but not part of the SRS. For example: Software shall support the the serial protocol per specification XYZ.
Security Requirements: What is required of authentication, authorization, audit trails, 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. Also 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 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 a couple good requirements:
Note that the language of the requirement says what the software shall do, not what the user can do, or the hardware will support.
And here are a couple 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.
Our experts at Promenade can provide independent testing and regulatory submissions services, enabling your robust, successful market entry.