What are Software Requirement Specifications? Why should I write them up before developing software?
In one of my first entrepreneurial ventures I needed some software written. It was a pretty basic application. It needed to take an HTTP call from a cell phone provider text messaging system and translate it over to text we could display on a screen. We were one of the first to develop the idea… we called it TAGG. It later adopted the name “text to screen” which is now industry standard. While it might seem pretty straightforward how I have described the software, at the time of commissioning the project it wasn’t. We weren’t sure what exactly we wanted/needed and how to get it.
Thankfully the programmer I brought on as a partner was very experienced and was able to lead me and the other partners into the process without too much trouble. One HUGE mistake we made, however, was that we didn’t put our general ideas down into a software requirements specification (SRS) document. If we had done so we would have saved a lot of time, money and testing hassle. The SRS would have described exactly what we needed and laid forth a plan to obtain such.
An article to introduce you to Software Requirements Specifications
The MicroTools Inc. article “How to write a software requirements specification” provides an excellent introduction to developing software requirement specs that will increase end user satisfaction and decrease development costs. While it is a little of a snoozer, the content contained therein is excellent and a must read for anyone involved in software production or individuals looking to have software written for their organization. The article continually refers back to IEEE standards, showing how their recommendations uphold the IEEE 830 standards. IEEE is a society of engineers (from all realms of engineering… computer, mechanical, product, etc.) that has created standard guidelines that should be used in production environments to guarantee highest quality and best development value. Thus, the recommendations in this article seem to be exceptionally sound.
As I have only dabbled in software development I am, by no means, an expert in writing software requirement specifications. From my own experience I can say, however, that increased planning ahead of time can greatly decrease development costs and hassles. This is the theoretical framework for developing a sound set of SRS.
The article explains how a well written SRS will:
- Establish a set of goals equal to the customer/end user and the team developing the software
- Reduce development effort and therefore cost
- Provide a base for estimating costs and project completion schedules
- Facilitate transfer of software from development team to the customer/end user
- Serve as a blueprint for further software enhancements and revisions
One thing the article does a poor job of, however, is explaining the differences between SRS and System Specifications. This is where you can help me out… What is the difference between the two? The article outlines some requirements that should be covered in a systems spec but doesn’t clearly illustrate the difference.
How do I get started writing a Software Requirements Specification document?
First, make sure you set aside enough time to dive in. It will take several hours just to get your feet wet. Look through the SRS templates linked here and decide which one you want to use. The “Software Design Specification Template” by Brad Appleton will open as an HTML page in your web browser so you will have to copy it over to a document program. It is an excellent template and covers all the details you will need to include in your SRS in great depth. Because you do need to copy/paste it over to a document program the formatting is a hassle. There is another “Software Requirements Specifications” template available for free from ProcessImpact.com which already comes in a document format complete with an attractive table of contents and layout already provided. This template is a little more sparse than the previously mentioned one.
So, you decide which one will be your best bet and then sit down with all the key stakeholders in the software and write it out. It will need a lot of revisions and collaboration as you meet with the customer/end user and other stakeholders so it might be easiest if you put it into a web based document program like Google Docs.
If you found this blog post helpful please be sure to leave a comment below. Particularly, answer the questions: What is the difference between SRS and Systems Specifications? Which of the SRS templates did you use/plan to use and why?