Software Requirements Specification Document

Example (International Standard)

Aug 08, 2016

Failure projects are those ones that do not meet the original time,
cost and quality requirements criteria. The common cause of
software project failure: absence of well-defined requirements. This
document defines the normative content of the software
requirements specification (SRS). Organization of the information
items in the document such as the order and section structure may
be selected in accordance with the project's documentation policies.
1. PURPOSE
Delineate the purpose of the software to be specified.

Partial example: The goal of this project is to provide a mobile application for
Restaurant Clients and a web-portal for Restaurant Owners and Companys
administrators.

2. SCOPE
Describe the scope of the software under consideration by:

1. Identifying the software product(s) to be produced by name;

2. Explaining what the software product(s) will do;
3. Describing the application of the software being specified, including
relevant benefits, objectives, and goals;
4. Being consistent with similar statements in higher-level specifications
(e.g., the system requirements specification), if they exist.
Partial example: The Amazing Restaurant Finder is a GPS-based mobile
application, which helps people to find the closest restaurants based on the
users current position, price, restaurant type and dish. Users view desired
restaurants on a map and get navigation to them.
Restaurant owners provide their restaurant information using the web-portal.
An administrator of the web-portal verifies restaurant owners and manages
user information.

3. PRODUCT PERSPECTIVE
 Define the system's relationship to other related products. If the product is
an element of a larger system, then relate the requirements of that larger
system to the functionality of the product covered by the SRS. If the product
is an element of a larger system, then identify the interfaces between the
product covered by the SRS and the larger system of which the product is an
element.

A block diagram showing the major elements of the larger system,

interconnections, and external interfaces can be helpful.

Describe how the software operates within the following constraints:

1. System interfaces;
2. User interfaces;
3. Hardware interfaces;
4. Software interfaces;
5. Communications interfaces;
6. Site adaptation requirements.
Partial example: The mobile application requires both Internet and GPS
connection to fetch and display results. All system information is maintained
in a database, which is located on a web-server. The mobile application
interacts with the GPS-Navigator software, which is required to be already
installed on the users mobile phone.
 Figure 1. Block diagram. Source: cse.chalmers.se

3.1. SYSTEM INTERFACES

List each system interface and identify the functionality of the software to
accomplish the system requirement and the interface description to match
the system.

3.2. USER INTERFACES

Specify the following:

1. The logical characteristics of each interface between the

software product and its users. This includes those configuration
characteristics (e.g., required screen formats, page or window layouts,
content of any reports or menus, or availability of programmable function
keys) necessary to accomplish the software requirements.
2. All the aspects of optimizing the interface with the person who
uses, maintains, or provides other support to the system. This may
simply comprise a list of do's and don'ts on how the system will appear to
the user. One example may be a requirement for the option of long or short
error messages.
A style guide for the user interface can provide consistent rules for
organization, coding, and interaction of the user with the system.

Partial example: A first-time user of the mobile application should see the
log-in page when he/she opens the application, see Figure 2. If the user has
not registered, he/she should be able to do that on the log-in page. If the
user is not a first-time user, he/she should be able to see the search page
directly when the application is opened, see Figure 3. Here, the user chooses
the type of search he/she wants to conduct.

Every user should have a profile page where they can edit their e-mail
address, phone number and password, see Figure 4. Also, the user can set
the mobile application to his/her preferred language.

3.3. HARDWARE INTERFACES

Specify the logical characteristics of each interface between the software
product and the hardware elements of the system. This includes
configuration characteristics (number of ports, instruction sets, etc.). It also
 covers such matters as what devices are to be supported, how they are to be
supported, and protocols. For example, terminal support may specify full-
screen support as opposed to line-by-line support.

3.4. SOFTWARE INTERFACES

Specify the use of other required software products (e.g., a data
management system, an operating system, or a mathematical package), and
interfaces with other application systems (e.g., the linkage between an
accounts receivable system and a general ledger system).

For each required software product, specify:

1. Specification number;
2. Version number;
For each interface specify:

1. Discussion of the purpose of the interfacing software as related to this

software product;
2. Definition of the interface in terms of message content and format. It is
not necessary to detail any well-documented interface, but a reference to the
document defining the interface is required.

3.5. COMMUNICATIONS INTERFACES

Specify the various interfaces to communications such as local network
protocols.

3.6. MEMORY CONSTRAINTS

Specify any applicable characteristics and limits on primary and secondary
memory.

3.7. OPERATIONS
Specify the normal and special operations required by the user such as:

1. The various modes of operations in the user organization (e.g., user-

initiated operations);
2. Periods of interactive operations and periods of unattended operations;
3. Data processing support functions;
4. Backup and recovery operations.
 This is sometimes specified as part of the User Interfaces section.

3.8. SITE ADAPTATION REQUIREMENTS

The site adaptation requirements include:

1. Definition of the requirements for any data or initialization sequences

that are specific to a given site, mission, or operational mode (e.g., grid
values, safety limits, etc.);
2. Specification of the site or mission-related features that should be
modified to adapt the software to a particular installation.

4. PRODUCT FUNCTIONS
Provide a summary of the major functions that the software will perform. For
example, an SRS for an accounting program may use this part to address
customer account maintenance, customer statement, and invoice
preparation without mentioning the vast amount of detail that each of those
functions requires.

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.

Note that for the sake of clarity:

1. The product functions should be organized in a way that makes the list
of functions understandable to the acquirer or to anyone else reading the
document for the first time;
2. Textual or graphical 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.

5. USER CHARACTERISTICS
Describe those general characteristics of the intended groups of users of the
product including characteristics that may influence usability, such as
educational level, experience, disabilities, and technical expertise. This
description should not state specific requirements, but rather should state
the reasons why certain specific requirements are later specified in specific
requirements. Where appropriate, the user characteristics of the SyRS and
SRS should be consistent.
 6. LIMITATIONS
Provide a general description of any other items that will limit the supplier's
options, including:

1. Regulatory policies;
2. Hardware limitations (e.g., signal timing requirements);
3. Interfaces to other applications;
4. Parallel operation;
5. Audit functions;
6. Control functions;
7. Higher-order language requirements;
8. Signal handshake protocols (e.g., XON-XOFF, ACK-NACK);
9. Quality requirements (e.g., reliability);
10. Criticality of the application;
11. Safety and security considerations;
12. Physical/mental considerations

7. 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 any changes to these
factors can affect the requirements in the SRS. For example, an assumption
may be that a specific operating system will be available on the hardware
designated for the software product. If, in fact, the operating system is not
available, the SRS would then have to change accordingly.

8. APPORTIONING OF REQUIREMENTS
Apportion the software requirements to software elements. For requirements
that will require implementation over multiple software elements, or when
allocation to a software element is initially undefined, this should be so
stated. A cross reference table by function and software element should be
used to summarize the apportionments.

Identify requirements that may be delayed until future versions of the

system (e.g., blocks and/or increments).

9. SPECIFIC REQUIREMENTS
 Specify all of the software requirements to a level of detail sufficient to
enable designers to design a software system to satisfy those requirements.

Specify all of the software requirements to a level of detail sufficient to

enable testers to test that the software system satisfies those requirements.

At a minimum, describe every input (stimulus) into the software system,

every output (response) from the software system, and all functions
performed by the software system in response to an input or in support of an
output.

The specific requirements should:

1. Be stated in conformance with all the characteristics described in 5.2

of this International Standard;
2. Be cross-referenced to earlier documents that relate;
3. Be uniquely identifiable.

10. EXTERNAL INTERFACES

Define all inputs into and outputs from the software system. The description
should complement the interface descriptions in 3.1 through 3.5, and should
not repeat information there.

Each interface defined should include the following content:

1. Name of item;
2. Description of purpose;
3. Source of input or destination of output;
4. Valid range, accuracy, and/or tolerance;
5. Units of measure;
6. Relationships to other inputs/outputs;
7. Screen formats/organization;
8. Window formats/organization;
9. Data formats;
10. Command formats;
11. End messages.

11. FUNCTIONS
 Define the fundamental actions that have to take place in the software in
accepting and processing the inputs and in processing and generating the
outputs, including:

1. Validity checks on the inputs;

2. Exact sequence of operations;
3. Responses to abnormal situations, including Communication facilities
and Error handling and recovery;
4. Effect of parameters;
5. Relationship of outputs to inputs, including Input/output sequences and
Formulas for input to output conversion.
It may be appropriate to partition the functional requirements into
subfunctions or subprocesses. This does not imply that the software design
will also be partitioned that way.

Partial example:

There are three types of users that interact with the system: users of the
mobile application (User Class 1- User), restaurant owners (User Class 2 -
Restaurant Owner) and administrators (User Class 3 - Administrator). Each of
these three types of users has different use of the system so each of them
has their own requirements.

User Class 1 - User

Functional requirement 1.3
ID: FR3
TITLE: User registration - Mobile application
DESC: After user has downloaded the mobile application, then he/she is able
to register through the mobile application. The user must provide user-name,
password and e-mail address. The user can choose to provide a regularly
used phone number.
Functional requirement 1.4
ID: FR4
TITLE: User log-in - Mobile application
DESC: After user has registered, then he/she should be able to log in to the
mobile application. The log-in information is stored on the phone and in
future the user will be logged in automatically.
 Functional requirement 1.5
ID: FR5
TITLE: Retrieve password
DESC: After user has registered, then he/she is able to retrieve his/her
password by e-mail.
User Class 3 - Administrator
Functional requirement 3.7
ID: FR7
Feature: Manage restaurant owners
In order to keep track of the restaurant owners an administrator is able to
manage the restaurant owners.
Scenario: Add a new restaurant owner
When the administrator creates a new restaurant owner
Then the new restaurant owner should be added
Scenario: Edit an existing restaurant owner
When the administrator edits an existing restaurant owner
Then the restaurant owner information should be updated
Scenario: Delete an existing restaurant owner
When the administrator deletes an existing restaurant owner
Then the restaurant owner is deleted
And the restaurant information is deleted

12. USABILITY REQUIREMENTS

Define usability (quality in use) requirements. Usability requirements and
objectives for the software system include measurable effectiveness,
efficiency, and satisfaction criteria in specific contexts of use.

13. PERFORMANCE REQUIREMENTS

Specify 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 the following:

1. The number of terminals to be supported;

2. The number of simultaneous users to be supported;
3. 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.

The performance 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.
Numerical limits applied to one specific function are normally specified as
part of the processing subparagraph description of that function.

Partial example:
Quality requirement 6
ID: QR6
TITLE: The response time of a search.
DESCRIPTION: The response time of a search is the overall time beginning
with the initial user action (click on the search button) on the mobile device,
the request going to server, the response received from the server, and
finally the response processing by the mobile application.
METER: Measurements obtained from 1000 searches during testing (iOS 9,
Android 5.0).
MUST: No more than 2 seconds during 100% of the searches during testing.
WISH: No more than 1 second during 100% of the searches during testing.

18. VERIFICATION
Provide the verification approaches and methods planned to qualify the
software. The information items for verification are recommended to be
given in a parallel manner with the information items in subclause 10 to 17.

19. SUPPORTING INFORMATION

The SRS should contain additional supporting information including:

1. Sample input/output formats, descriptions of cost analysis studies, or

results of user surveys;
2. Supporting or background information that can help the readers of the
SRS;
3. A description of the problems to be solved by the software;
4. Special packaging instructions for the code and the media to meet
security, export, initial loading, or other requirements.
The SRS should explicitly state whether or not these information items are to
be considered part of the requirements.

Partial example: Appendix

Releas Dependenci Descriptio Motivation Releas Duratio

e Plan: es n e# n
(hours)

FR1 - Download This requirement 1 80

mobile makes the
application application
available to users
and is therefore an
important
requirement to
include in the first
release.

FR2 FR1 Download The download of 1 2

and notify new versions is
users of important for users
new to be able to
releases receive the future
release of the
application and will
therefore be
included in the first
release.

FR3 - User For the user to be 1 4

registratio able to use the
 n application, the
user has to be a
registrant.
Consequently, this
requirement needs
to be met in the
first release.

FR4 FR1, FR3 User Log-in For the user to be 1 2

able to use the
application, the
user has to log in.
Consequently, this
requirement needs
to be met in the
first release.

FR5 FR1 Retrieve For the user to be 2 1

Password able to receive a
forgotten
password, they will
have to wait for
the second release.
This is not vital for
the application and
was therefore not
included in the first
release.

FR6 FR4 Search The search feature 1 2

is one of the most
important and vital
part of the system.
It's part of the
basic goal of the
 program and
should therefore
be included in the
first release.

FR7 FR6, QR22, Search The ability to show 1 1

QR23 result in a the search result in
map view a map view is part
of the basic goal of
the program and
should therefore
be included in the
first release.

FR8 FR6, QR22 Search The ability to show 2 2

result in a the search result in
list view a list view is part of
the basic goal.
Figure. Briefly explaining what is usually meant by 'Software Requirements Specification'.