Scribd
Upload
79 views

How To Write A Software Requirements Specification

The document provides guidance on writing an effective software requirements specification (SRS). It discusses that an SRS should define what the software needs to do, its external interfaces, performance requirements, and design constraints. An SRS benefits projects by establishing agreement between customers and developers on scope, reducing rework, providing a cost estimation baseline, and facilitating validation and future enhancements. The document recommends following the IEEE standards for SRS content and quality characteristics like being correct, unambiguous, complete, consistent, verifiable and modifiable.

Uploaded by

arvind_yadav_12
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
79 views

How To Write A Software Requirements Specification

The document provides guidance on writing an effective software requirements specification (SRS). It discusses that an SRS should define what the software needs to do, its external interfaces, performance requirements, and design constraints. An SRS benefits projects by establishing agreement between customers and developers on scope, reducing rework, providing a cost estimation baseline, and facilitating validation and future enhancements. The document recommends following the IEEE standards for SRS content and quality characteristics like being correct, unambiguous, complete, consistent, verifiable and modifiable.

Uploaded by

arvind_yadav_12
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

How to write a software requirements specification

by Robert Japenga

What Makes a Great Software Requirements Specification?


There are many good definitions of System and Software Requirements Specifications that will provide us a good basis upon which we can both define a great specification and help us identify deficiencies in our past efforts. There is also a lot of great stuff on the web about writing good specifications. The problem is not lack of knowledge about how to create a correctly formatted specification or even what should go into the specification. The problem is that we don't follow the definitions out there. We have to keep in mind that the goal is not to create great specifications but to create great products and great software. Can you create a great product without a great specification? Absolutely! You can also make your first million through the lottery but why take your chances? Systems and software these days are so complex that to embark on the design before knowing what you are going to build is foolish and risky. The IEEE (www.ieee.org) is an excellent source for definitions of System and Software Specifications. As designers of real-time, embedded system software, we use IEEE STD 830-1998 as the basis for all of our Software Specifications unless specifically requested by our clients. Essential to having a great Software Specification is having a great System Specification. The equivalent IEEE standard for that is IEEE STD 1233-1998. However, for most purposes in smaller systems, the same templates can be used for both.

What are the benefits of a Great SRS?


The IEEE 830 standard defines the benefits of a good SRS: Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if

the software specified meets their needs or how the software must be modified to meet their needs. [NOTE: We use it as the basis of our contract with our clients all the time]. Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customers organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. [NOTE: Again, we use the SRS as the basis for our fixed price estimates] Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. [NOTE: We use the SRS to create the Test Plan]. Facilitate transfer.The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers. Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation. [NOTE: This is often a major pitfall when the SRS is not continually updated with changes]

What should the SRS address?


Again from the IEEE standard: The basic issues that the SRS writer(s) shall address are the following: a) Functionality. What is the software supposed to do? b) External interfaces. How does the software interact with people, the systems hardware, other hardware, and other software? c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? d) Attributes. What are the portability, correctness,

maintainability, security, etc. considerations? e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

What are the characteristics of a great SRS?


Again from the IEEE standard: An SRS should be a) Correct b) Unambiguous c) Complete d) Consistent e) Ranked for importance and/or stability f) Verifiable g) Modifiable h) Traceable Correct - This is like motherhood and apple pie. Of course you want the specification to be correct. No one writes a specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping the specification up to date when you find things that are not correct. Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Again, easier said than done. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them. Complete - A simple judge of this is that is should be all that is needed by the software designers to create the software. Consistent - The SRS should be consistent within itself and consistent to its reference documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another. Ranked for Importance - Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS. Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable. Traceable - Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. Why do we need this requirement?

You might also like