Software Requirement Specification

Document
6/15/2007

kranthi
 WRITING SOFTWARE REQUIREMENTS SPECIFICATIONS

Table of Contents

1. GENERAL DESCRIPTION ..................................................................................................................... 3

2. PORPOSE OF THE DOCUMENT .......................................................................................................... 3
3. INRODUCTION ................................................................................................................................... 3
4. GOALS OF SRS ................................................................................................................................... 4
5. BENEFITS OF SRS ............................................................................................................................... 4
6. WHAT KIND OF INFORMATION SHOULD AN SRS INCLUDE? ............................................................. 5
7. SRS OUTLINE ..................................................................................................................................... 5
8. WHY SHOULD A TECHNICAL WRITER BE INVOLVED WITH SRS? ....................................................... 6
9. CONCLUSION ..................................................................................................................................... 7
 WRITING SOFTWARE REQUIREMENTS SPECIFICATIONS

1. GENERAL DESCRIPTION

For technical writers who haven't had the experience of designing software requirements
specifications (SRS, also known as software functional specifications or system specifications)
templates or even writing SRS, they might assume that being given the opportunity to do so is either
a reward or punishment for something they did (or failed to do) on a previous project. Actually,
writing SRS is an ideal project for technical writers to be involved with because they lay out the
foundation for the development of a new product and for the types of user documentation and
media that will be required later in the project development life cycle. It also doesn't hurt that you'd
be playing a visible role in contributing to the success of the project.

2. PORPOSE OF THE DOCUMENT

This document is intended for Technical writers and associates who would like to work with SRS of a
project. This document will describe what an SRS is and why it is so important, shows how and why
technical writers should be involved with them, and discuss the critical elements for writing an SRS.
Although this document does not attempt to address all aspects of developing SRSs, it aims to help
you determine the scope for such a project, to provide some guidelines for writing SRSs, and to
provide additional resources. Hopefully with this information I will jump to the actual part of the
document. Yes “the SRS”!

3. REFERENCES
http://www.microtoolsinc.com/Howsrs.php
http://satc.gsfc.nasa.gov/support/STC_APR97/write/writert.html
https://www.cs.tcd.ie/~sweetmag/what.php

4. INRODUCTION

An SRS is basically an organization's understanding (in writing) of a customer or potential client's

system requirements and dependencies at a particular point in time (usually) prior to any actual
design or development work. It is a two-way policy that assures that both the client and the
organization understand the other's requirements from that perspective at a given point in time.
The SRS document itself states in precise and explicit language those functions and capabilities a
software system (i.e., a software application, an E-Commerce Web site, and so on) must provide, as
well as it states any required constraints by which the system must abide. The SRS also functions as
a blueprint for completing a project with as little cost growth as possible. The SRS is often referred
to as the "parent" document because all subsequent project management documents, such as
design specifications, statements of work, software architecture specifications, testing and
validation plans, and documentation plans, are related to it. It is important to note that an SRS
contains functional and non-functional requirements only; it doesn't offer design suggestions,
possible solutions to technology or business issues, or any other information other than what the
development team understands the customer's system requirements to be.
 WRITING SOFTWARE REQUIREMENTS SPECIFICATIONS

5. GOALS OF SRS

A well-designed, well-written SRS accomplishes four major goals:

 It provides feedback to the customer: An SRS is the customer's assurance that the
development organization understands the issues or problems to be solved and the
software behavior necessary to address those problems. Therefore, the SRS should be
written in natural language, in an unambiguous manner that may also include charts, tables,
data flow diagrams, decision tables, and so on.
 It decomposes the problem into component parts: The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the
problem, solidifies ideas, and helps break down the problem into its component parts in an
orderly fashion.
 It serves as an input to the design specification: As mentioned previously, the SRS serves as
the parent document to subsequent documents, such as the software design specification
and statement of work. Therefore, the SRS must contain sufficient detail in the functional
system requirements so that a design solution can be devised.
 It serves as a product validation check: The SRS also serves as the parent document for
testing and validation strategies that will be applied to the requirements for verification.
SRSs are typically developed during the first stages of "Requirements Development," which
is the initial product development phase in which information is gathered about what
requirements are needed and what are not. This information-gathering stage can include
onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI)
analysis or needs analysis of the customer or client's current business environment. The
actual specification, then, is written after the requirements have been gathered and
analyzed.

6. BENEFITS OF SRS

The IEEE 830 standard defines the benefits of a good SRS:

 Establishes 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.
 Reduces the development effort. The preparation of the SRS forces the various concerned
groups in the customer’s 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.
 Provides 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.
 WRITING SOFTWARE REQUIREMENTS SPECIFICATIONS

 Provides 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.
 Facilitates 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.
 Serves 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]

7. WHAT KIND OF INFORMATION SHOULD AN SRS INCLUDE?

You probably will be a member of the SRS team (if not, ask to be), which means SRS development
will be a collaborative effort for a particular project. In these cases, company will have developed
SRSs before, so you should have examples (and, likely, the company's SRS template) to use. But, let's
assume you'll be starting from scratch. Several standards organizations (including the IEEE) have
identified nine topics that must be addressed when designing and writing an SRS:
 Interfaces
 Functional Capabilities
 Performance Levels
 Data Structures/Elements
 Safety
 Reliability
 Security/Privacy
 Quality
 Constraints and Limitations

8. SRS OUTLINE

The above Table shows what a basic SRS outline might look like. This example is an adaptation and
extension of the IEEE Standard 830-1998:
A sample of a basic SRS outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
 WRITING SOFTWARE REQUIREMENTS SPECIFICATIONS

1.5 Contact information/SRS team members

1.6 References
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined

9. WHY SHOULD A TECHNICAL WRITER BE INVOLVED WITH SRS?

Unfortunately, much of the time, systems architects and programmers write SRSs with little (if any)
help from the technical communications organization. Having technical writers involved throughout
the entire SRS development process can offer several benefits:
 WRITING SOFTWARE REQUIREMENTS SPECIFICATIONS

Technical writers are skilled information gatherers, ideal for eliciting and articulating
customer requirements. The presence of a technical writer on the requirements-gathering
team helps balance the type and amount of information extracted from customers, which
can help to improve the SRS.
Technical writers can better assess and plan documentation projects and better meet
customer document needs. Working on SRSs provides technical writers with an opportunity
for learning about customer needs early in the product development process.
Technical writers know how to determine the questions that are of concern to the user or
customer regarding ease of use and usability. Technical writers can then take that
knowledge and apply it not only to the specification and documentation development, but
also to user interface development, to help ensure the UI (User Interface) models the
customer requirements.
Technical writers involved early and often in the process, can become an information
resource throughout the process, rather than an information gatherer at the end of the
process.
In short, a requirements-gathering team consisting solely of programmers, product marketers,
systems analysts/architects, and a project manager runs the risk of creating a specification that may
be too heavily loaded with technology-focused or marketing-focused issues. The presence of a
technical writer on the team helps place at the core of the project those user or customer
requirements that provide more of an overall balance to the design of the SRS, product, and
documentation.

10. CONCLUSION

There's so much more we could say about requirements and specifications. Hopefully, this
information will help you to get started when you are called upon or step up to help the
development team. Writing top-quality requirements specifications begins with a complete
definition of customer requirements. I conclude my document by saying technical writing
professionals well-trained in requirements gathering, template design, and natural language use are
in the best position to create and add value to such critical project documentation.