Writing Software Requirements Specifications
What is a Software Requirements Specification (SRS), what is it for and how important is it? The short answer is an SRS is document that outlines what software developer needs to create software and a software tester needs to define requirement scope
The complicated answer is an SRS is a complete and comprehensive document that outlines the purpose, capabilities, specifications and behavior of software to be created. It describes all the interactions potential users will have, list all the software’s functional requirements, and nonfunctional requirements, and even sometimes, down to the hardware it should run in.
Now, it is really pointless at this time to tell you how to write an SRS. You can just as easily go and search online for SRS templates and modify them to suit your needs. What we are aiming for in this article is to remind you what should go into a good SRS and what you should focus on when writing one in order for you to create the most appropriate SRS document for your company or for your client.
What Makes a Great SRS?
When writing an SRS, and staring at the template you have on your screen, remind yourself that you are NOT designing the software but telling the software designer and developer what the software SHOULD do so that it can be built for you. It is the job of the designer to design and build the software including the looks and the GUI, not you. Spare yourself any effort in trying to “design” the software for the programmer to build, and rather focus your energies on getting the functions of the software right for your needs. A great SRS focuses less on the frills and more on the essential features or sometimes called the mission critical features.
A properly written SRS reduce the effort of the development team. If all the various requirements are already properly outlined before the software design and coding begins, less time and effort is lost when additional specs and functions are suddenly added because they were not thought of before. If you have a comprehensive and complete SRS, there will be no more need for – or at least a minimal need for – redesigning, recoding, and retesting software.
A properly written SRS helps the company in estimating the related manpower, costs, man-hours, equipment, and other resources needed to complete the product. If the SRS is off even by a bit, it could impact the whole viability of the project because that omission or mistake in the SRS could mean tens of thousands if not millions of dollars.
A great SRS is also unambiguous – make sure that the designers understand what you write down explicitly. Avoid any misleading words and conflicting statements. When listing features, make such to provide a hierarchy in terms of importance so that designers will not be confused about your priorities when it comes to function.
Additional things to consider:
- Description of Functionality – What do you want the software to do, what is it for and what is its use.
- User Interface – How will people use the software? How will they operate it or what instruments should the software recognize when people need to interact with it?
- Performance – Indicate your expected performance levels in terms of daily operation, tolerances, resource requirements etc.
How would you judge if you’ve made a good SRS? Well, there’s no way to check really as software differs from the other as much as any one person differs from the next. Even the same software separated by a generation would basically be unique from each other. The only way to assure that we did a good job with the SRS is that if upon reviewing your SRS, you feel that at the end of the day, the person reading it will be able to create a great product for you.
Source: http://www.clevertester.com/articles/writing_software_requirements_specifications.html
StumbleIt! 
Comments
No comments yet.
Leave a comment