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.
Lets start with the categories of requirements your SRS should have.
· Functional and capability requirements – what is the software supposed to do? These should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. Don’t forget to consider handling of abnormal or error situations.
· Interfaces - How does the software interact with people (User Interface), the system’s hardware, external connections, and other software?
· Performance- what is the speed, availability, response time, recovery time of various software functions, etc.? These should be stated in measurable terms.
· Data definition and database requirements - This includes the types of information used, frequency of use, accessing capabilities, entities and their relationships, integrity constraints and data retention requirements.
· Safety considerations and risk control measures - These are the mitigations that were captured in your hazard analysis.
· Security – security of sensitive information, authentication, authorization, audit trail, and communications integrity requirements should be captured.
· Design constraints – constraints imposed by other standards, hardware limitations, etc..
And what it should not have:
· User Interface Design– Include what the user needs to be able to do, but not how the screens are laid out. Leave that to a User Interface Specification.
· Software Design – Internal Design decisions. Don’t include how something will be done, just what needs to be done,
So what makes a good SRS?
First of all, 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 tend to stay there forever.
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 that have no order assumed. For example “SWReq-101”. If you use the section headers as your numbers you may run into problems when you want to add a section. You want your document to read well, so don’t force everything new to the bottom.
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. These are software requirements, so say what the software needs to do.
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.