Software Requirements Specifications

Software Requirements Specification (SRS)

The document in this file is an annotated outline for specifying software

requirements, adapted from the IEEE Guide to Software Requirements
Specifications (Std 830-1993).

Tailor this to your needs, removing explanatory comments as you go along.

Where you decide to omit a section, you might keep the header, but insert a
comment saying why you omit the data.

Page 1 of 14 f
 Software Requirements Specifications

SOFTWARE REQUIREMENTS SPECIFICATION

Project Title

Subject : Software Engineering

Subject Code : 2160701

Sr Enrollment Name
No Number
1
2
3
4

Faculty Name :
Signature : Date: (mm/dd/yyyy)

Page 2 of 14 f
 Software Requirements Specifications

Table of Contents

1. Introduction 4

1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview 5

2. General Description 6

2.1 Product Perspective 6

2.2 Product Functions 6
2.3 User Characteristics 7
2.4 General Constraints 7
2.5 Assumptions and Dependencies 7

3. Specific Requirements 8

3.1 Functional Requirements 9

3.1.1 Functional Requirement 1 9
3.1.2 Functional Requirement 2 9
3.2 External Interface Design 10
3.3 Performance Requirements 10
3.4 Design Constraints 11
3.4.1 Standards Compliance 11
3.4.2 Hardware Limitation 11
3.5 Software System Attributes 11
3.5.1 Reliability 11
3.5.2 Availability 12
3.5.3 Security 12
3.5.4 Maintainability 12
3.5.5 Portability 12
3.6 Other Requirements 13
3.6.1 Logical Database Requirements 13

4. Appendices 15

Page 3 of 14 f
 Software Requirements Specifications

1. Introduction

The following subsections of the Software Requirements Specifications (SRS) document

should provide an overview of the entire SRS. The thing to keep in mind as you write this
document is that you are telling what the system must do – so that designers can ultimately
build it. Do not use this document for design!!!

1.1 Purpose

Identify the purpose of this SRS and its intended audience. In this subsection, describe the
purpose of the particular SRS and specify the intended audience for the SRS.

1.2 Scope

In this subsection:
(1) Identify the software product(s) to be produced by name
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified, including relevant benefits,
objectives, and goals
(4) Be consistent with similar statements in higher-level specifications if they exist

This should be an executive-level summary. Do not enumerate the whole requirements list
here.

1.3 Definitions, Acronyms, and Abbreviations

Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the SRS. This information may be provided by reference to one or more appendices
in the SRS or by reference to documents. This information may be provided by reference to
an Appendix.

1.4 References

In this subsection:
(1) Provide a complete list of all documents referenced elsewhere in the SRS
(2) Identify each document by title, report number (if applicable), date, and publishing
organization
(3) Specify the sources from which the references can be obtained.

This information can be provided by reference to an appendix or to another document. If

your application uses specific protocols or RFC’s, then reference them here so designers
know where to find them.

Page 4 of 14 f
 Software Requirements Specifications

1.5 Overview

In this subsection:
(1) Describe what the rest of the SRS contains
(2) Explain how the SRS is organized

Don’t rehash the table of contents here. Point people to the parts of the document they are
most concerned with. Customers/potential users care about section 2, developers care about
section 3.

Page 5 of 14 f
 Software Requirements Specifications

2. General Description

Describe the general factors that affect the product and its requirements. This section does
not state specific requirements. Instead, it provides a background for those requirements,
which are defined in section 3, and makes them easier to understand. In a sense, this section
tells the requirements in plain English for the consumption of the customer. Section3 will
contain a specification written for the developers.

2.1 Product Perspective

Put the product into perspective with other related products. If the product is independent
and totally self-contained, it should be so stated here. If the SRS defines a product that is a
component of a larger system, as frequently occurs, then this subsection relates the
requirements of the larger system to functionality of the software and identifies interfaces
between that system and the software. If you are building a real system,compare its
similarity and differences to other systems in the marketplace. If you are doing a research-
oriented project, what related research compares to the system you are planning to build.

A block diagram showing the major components of the larger system, interconnections, and
external interfaces can be helpful. This is not a design or architecture picture. It is more to
provide context, especially if your system will interact with external actors. The system you
are building should be shown as a black box. Let the design document present the internals.

2.2 Product Functions

Provide a summary of the major functions that the software will perform. Sometimes the
function summary that is necessary for this part can be taken directly from the section of the
higher-level specification (if one exists) that allocates particular functions to the software
product.

For clarity:
(1) The functions should be organized in a way that makes the list of functions understandable to the
customer or to anyone else reading the document for the first time.
(2) Textual or graphic methods can be used to show the different functions and their relationships.
Such a diagram is not intended to show a design of a product but simply shows the logical
relationships among variables.

Finally the real meat of section 2. This describes the functionality of the system in the
language of the customer. What specifically does the system that will be designed have to
do? Drawings are good, but remember this is a description of what the system needs to do,
not how you are going to build it. (That comes in the design document).

2.3 User Characteristics

Describe those general characteristics of the intended users of the product including
educational level, experience, and technical expertise. Do not state specific requirements but
rather provide the reasons why certain specific requirements are later specified in section 3.

Page 6 of 14 f
 Software Requirements Specifications
What is it about your potential user base that will impact the design? Their experience and
comfort with technology will drive UI design. Other characteristics might actually influence
internal design of the system.

2.4 General Constraints

Provide a general description of any other items that will limit the developer's options.
These can include:

(1) Regulatory policies

(2) Hardware limitations (for example, signal timing requirements)
(3) Interface to other applications
(4) Parallel operation
(5) Audit functions
(6) Control functions
(7) Higher-order language requirements
(8) Signal handshake protocols (for example, XON-XOFF, ACK-NACK)
(9) Reliability requirements
(10) Criticality of the application
(11) Safety and security considerations

This section captures non-functional requirements in the customers language. A more formal
presentation of these will occur in section 3.
2.5 Assumptions and Dependencies

List each of the factors that affect the requirements stated in the SRS. These factors are not
design constraints on the software but are, rather, any changes to them that can affect the
requirements in the SRS. For example, an assumption might be that a specific operating
system would be available on the hardware designated for the software product. If, in fact,
the operating system were not available, the SRS would then have to change accordingly.

This section is catch-all for everything else that might influence the design of the system and
that did not fit in any of the categories above.

Page 7 of 14 f
 Software Requirements Specifications

3. Specific Requirements

This section contains all the software requirements at a level of detail sufficient to enable
designers to design a system to satisfy those requirements, and testers to test that the system
satisfies those requirements. Throughout this section, every stated requirement should be
externally perceivable by users, operators, or other external systems. These requirements
should include at a minimum a description of every input (stimulus) into the system, every
output (response) from the system and all functions performed by the system in response to
an input or in support of an output. The following principles apply:

(1) Specific requirements should be stated with all the characteristics of a good SRS
 correct
 unambiguous
 complete
 consistent
 ranked for importance and/or stability
 verifiable
 modifiable
 traceable
(2) Specific requirements should be cross-referenced to earlier documents that relate
(3) All requirements should be uniquely identifiable (usually via numbering like 3.1.2.3)
(4) Careful attention should be given to organizing the requirements to maximize readability
(Several alternative organizations are given at end of document)

Before examining specific ways of organizing the requirements it is helpful to understand the
various items that comprise requirements as described in the following subclasses. This
section reiterates section 2, but is for developers not the customer. The customer buys in
with section 2, the designers use section 3 to design and build the actual application.

Remember this is not design. Do not require specific software packages, etc unless the
customer specifically requires them. Avoid over-constraining your design. Use proper
terminology:
The system shall… A required, must have feature
The system should… A desired feature, but may be deferred til later
The system may… An optional, nice-to-have feature that may never make it to
implementation.

Each requirement should be uniquely identified for traceability. Usually, they are numbered
3.1, 3.1.1, 3.1.2.1 etc. Each requirement should also be testable. Avoid imprecise statements
like, “The system shall be easy to use” Well no kidding, what does that mean? Avoid
“motherhood and apple pie” type statements, “The system shall be developed using good
software engineering practice”

Avoid examples, This is a specification, a designer should be able to read this spec and build
the system without bothering the customer again. Don’t say things like, “The system shall
accept configuration information such as name and address.” The designer doesn’t know if
that is the only two data elements or if there are 200. List every piece of information that is
required so the designers can build the right UI and data tables.

3.1 Functional Requirements

Page 8 of 14 f
 Software Requirements Specifications

Functional requirements define the fundamental actions that must take place in the software
in accepting and processing the inputs and in processing and generating the outputs. These
are generally listed as “shall” statements starting with "The system shall…

These include:

Validity checks on the inputs

Exact sequence of operations
Responses to abnormal situation, including
*0 Overflow
*1 Communication facilities
*2 Error handling and recovery
Effect of parameters
Relationship of outputs to inputs, including
*3 Input/Output sequences
*4 Formulas for input to output conversion

It may be appropriate to partition the functional requirements into sub-functions or sub-

processes. This does not imply that the software design will also be partitioned that way.

3.1.1 Functional Requirement 1

3.1.1.1 Introduction
3.1.1.1 Input
3.1.1.1 Processing
3.1.1.1 Output

3.1.2 Functional Requirement 2

3.1.2.1 Introduction
3.1.2.1 Input
3.1.2.1 Processing
3.1.2.1 Output

3.2 External Interface Design

This contains a detailed description of all inputs into and outputs from the software system.
It complements the interface descriptions in section 2 but does not repeat information there.
Remember section 2 presents information oriented to the customer/user while section 3 is
oriented to the developer.

It contains both content and format as follows:

*0 Name of item
*1 Description of purpose
*2 Source of input or destination of output
*3 Valid range, accuracy and/or tolerance
*4 Units of measure
*5 Timing
*6 Relationships to other inputs/outputs
Page 9 of 14 f
 Software Requirements Specifications
*7 Screen formats/organization
*8 Window formats/organization
*9 Data formats
*10 Command formats
End messages

3.3 Performance Requirements

This subsection specifies both the static and the dynamic numerical requirements placed on
the software or on human interaction with the software, as a whole. Static numerical
requirements may include:
(a) The number of terminals to be supported
(b) The number of simultaneous users to be supported
(c) Amount and type of information to be handled
Static numerical requirements are sometimes identified under a separate section entitled
capacity.

Dynamic numerical requirements may include, for example, the numbers of transactions and
tasks and the amount of data to be processed within certain time periods for both normal and
peak workload conditions.

All of these requirements should be stated in measurable terms.

For example,

95% of the transactions shall be processed in less than 1 second

rather than,

An operator shall not have to wait for the transaction to complete.

(Note: Numerical limits applied to one specific function are normally specified as part of the
processing subparagraph description of that function.)

3.4 Design Constraints

Specify design constraints that can be imposed by other standards, hardware limitations, etc.

3.4.1 Standards Compliance

Specify the requirements derived from existing standards or regulations. They might include:
(1) Report format
(2) Data naming
(3) Accounting procedures
(4) Audit Tracing

For example, this could specify the requirement for software to trace processing activity.
Such traces are needed for some applications to meet minimum regulatory or financial
standards. An audit trace requirement may, for example, state that all changes to a payroll
database must be recorded in a trace file with before and after values.
Page 10 of 14 f
 Software Requirements Specifications

3.4.2 Hardware Limitation

Specify the requirements imposed on the hardware used by system

3.5 Software System Attributes

There are a number of attributes of software that can serve as requirements. It is important
that required attributes by specified so that their achievement can be objectively verified.
The following items provide a partial list of examples. These are also known as non-
functional requirements or quality attributes.

These are characteristics the system must possess, but that pervade (or cross-cut) the design.
These requirements have to be testable just like the functional requirements. Its easy to start
philosophizing here, but keep it specific.

3.5.1 Reliability

Specify the factors required to establish the required reliability of the software system at time
of delivery. If you have MTBF requirements, express them here. This doesn’t refer to just
having a program that does not crash. This has a specific engineering meaning.

3.5.2 Availability

Specify the factors required to guarantee a defined availability level for the entire system
such as checkpoint, recovery, and restart. This is somewhat related to reliability. Some
systems run only infrequently on-demand (like MS Word). Some systems have to run 24/7
(like an e-commerce web site). The required availability will greatly impact the design.
What are the requirements for system recovery from a failure? “The system shall allow users
to restart the application after failure with the loss of at most 12 characters of input”.

3.5.3 Security

Specify the factors that would protect the software from accidental or malicious access, use,
modification, destruction, or disclosure. Specific requirements in this area could include the
need to:
 Utilize certain cryptographic techniques
 Keep specific log or history data sets
 Assign certain functions to different modules
 Restrict communications between some areas of the program
 Check data integrity for critical variables

3.5.4 Maintainability

Specify attributes of software that relate to the ease of maintenance of the software itself.
There may be some requirement for certain modularity, interfaces, complexity, etc.
Requirements should not be placed here just because they are thought to be good design
practices. If someone else will maintain the system
Page 11 of 14 f
 Software Requirements Specifications

3.5.5 Portability

Specify attributes of software that relate to the ease of porting the software to other host
machines and/or operating systems. This may include:
*11 Percentage of components with host-dependent code
*12 Percentage of code that is host dependent
*13 Use of a proven portable language
*14 Use of a particular compiler or language subset
*15 Use of a particular operating system

Once the relevant characteristics are selected, a subsection should be written for each,
explaining the rationale for including this characteristic and how it will be tested and
measured. A chart like this might be used to identify the key characteristics (rating them
High or Medium), then identifying which are preferred when trading off design or
implementation decisions (with the ID of the preferred one indicated in the chart to the
right). The chart below is optional (it can be confusing) and is for demonstrating tradeoff
analysis between different non-functional requirements. H/M/L is the relative priority of
that non-functional requirement.

Definitions of the quality characteristics not defined in the paragraphs above follow.

• Correctness - extent to which program satisfies specifications, fulfills user’s mission

objectives
• Efficiency - amount of computing resources and code required to perform function
• Flexibility - effort needed to modify operational program
• Interoperability - effort needed to couple one system with another
• Reliability - extent to which program performs with required precision
• Reusability - extent to which it can be reused in another application
• Testability - effort needed to test to ensure performs as intended
• Usability - effort required to learn, operate, prepare input, and interpret output

THE FOLLOWING (3.7) is not really a section, it is talking about how to organize
requirements you write in section 3.2. At the end of this template there are a bunch of
alternative organizations for section 3.2. Choose the ONE best for the system you are writing
the requirements for.

3.6 Other Requirements

3.6.1 Logical Database Requirements

This section specifies the logical requirements for any information that is to be placed into a
database. This may include:

 Types of information used by various functions

 Frequency of use
 Accessing capabilities
 Data entities and their relationships
 Integrity constraints
 Data retention requirements

Page 12 of 14 f
 Software Requirements Specifications
If the customer provided you with data models, those can be presented here. ER diagrams
(or static class diagrams) can be useful here to show complex data relationships. Remember
a diagram is worth a thousand words of confusing text.

Page 13 of 14 f
 Software Requirements Specifications

4. Appendices

The Appendices are not always considered part of the actual requirements specification and
are not always necessary. They may include:

(a) Sample I/O formats, descriptions of cost analysis studies, results of user surveys
(b) Supporting or background information that can help the readers of the SRS
(c) A description of the problems to be solved by the software
(d) Special packaging instructions for the code and the media to meet security, export,
initial loading, or other requirements

When Appendices are included, the SRS should explicitly state whether or not the Appendices
are to be considered part of the requirements.

Tables on the following pages provide alternate ways to structure section 3 on the specific requirements.
You should pick the best one of these to organize section 3 requirements.

Page 14 of 14 f