How to Write a System Requirement Specification
Ever heard the expression “If you don’t know where you’re going, that’s probably where you’ll end up”? Planning is critical for the success of any type of project but, when it comes to software development, the planning needs to be supported by a sound System Requirements Specification (SRS). Without one, your project will be haunted by the risk of a collapse in communication and collaboration.
What is a System Requirement Specification (SRS)?
An SRS is a document that helps establish the foundation for an agreement between parties such as clients, contractors and suppliers. It outlines what the overall expectations are and what the software is going to do – and not do. As this document requires a thorough evaluation of requirements before the design phase, it helps to drastically reduce the need to redesign later.
Everyone involved in the development process relies on the SRS to be the focal point for planning, design, coding and testing. The document should be a realistic basis for estimating product costs, risks and schedules – which helps to prevent failures or delays.
Creating an SRS
There is a range of standard templates and examples easily found online, which will provide you with an SRS outline to expand upon and develop. You should then assign the initial authoring to someone with advanced writing skills, such as a technical author, who will be able to write with precision and clarity.
Example of a basic SRS outline
- Purpose
- Scope
- System Overview
- References
- Definitions
- Use Cases
- Functional requirements
- Non-functional requirements.
Pro Tip: Remember to include visual elements where appropriate, such as illustrations or photographs of equipment or screenshots of data or forms. A picture is worth a thousand words!
Using the IEEE Standard
There are many sources of advice and guidance on how to help develop a good SRS, and one very important source is the IEEE Standards Association. As well as various guidelines for aspects like Quality Assurance and Test Documentation, there is the standard IEEE 830 which specifically handles SRS.
These are the 5 key SRS considerations from the IEEE Standard:
- System functionality. What is the end solution intended to achieve for you?
- Outside interfaces. How will the software mesh with users and with various other hardware and software systems?
- What should the general operating speed look like, as well as response times and overall availability?
- Are there known design constraints in terms of system limitations, such as language, resource limits, database integrity and operating environments?
- Required attributes. There may be several other considerations that are important to the business, such as portability, maintenance and security.
The ideal characteristics of an SRS
The following characteristics form the ideal basis for a good SRS, which will help you ensure that you are getting the best possible use of the document.
- Correct
Naturally, the aim should be to make the document as accurate and correct as possible from the start, but there should be efforts made throughout the project to keep the specification updated when any discrepancies are found. - Unambiguous
There should only be one way to interpret every requirement. If needed, define specific terminology that some people using the SRS may not be familiar with. - Complete
The SRS should provide everything that the software developers actually need to design the solution. - Consistency
Ensure that the entire document follows the same clear standard when it comes to structure, formatting and terminology. (If, for example, if you refer to the end point of a programme as “Halt” or “Stop” or “End” or “Terminate” – then this should be agreed and adhered to throughout the entire work.) - Ranked for importance
It is very important to determine at the outset which features are essential to business operations and which ones are simply “nice-to-haves”, and assign priorities to these accordingly. - Measurable
Try to avoid vague terms like “usable” or “quick response” when describing deliverables. Instead, aim to do it quantitatively, such as “Response should be no longer than 100 milliseconds”. - Modifiable
When outlining the document, bear in mind the concept of change management. Avoid repeating the same requirements in different places in the document, as one may be missed if it is separate from the other when changes are made. - Traceable
Depending on the size of the organisation, you may need to link the SRS to other documents at different levels in the business. Always ensure that everyone who needs access to the SRS can find the current version of it easily and quickly.
One Beyond is a professional software development company and can help you with your software requirements specification as well as build a complete solution for you. Please get in contact if you require any assistance.
