Software Requirements Specification Template

<Project Name>
Specification
Software Requirements (SRS)
Version <1.1.0>

[ Note : This Template is intended to serve as a Base for the preparation of

the Software Requirements Specification document. The text in square
parentheses and displayed in blue italic (style = InfoBlue) is intended to guide
the author and must be deleted before publication of the document. The Body
Text style is automatically activated when paragraphs of final text are
entered. The text format must have a “verdana” font. ]
[NOTE: For small projects, lasting less than a month and a team of
less than 3 people, this document can be replaced with a reference to
the Preliminary Analysis document. In this case the project manager
needs to maintain the Preliminary Analysis document during the
project life cycle as a baseline of requirements.]

Revision History
 Date Version Description Author

<yyyy-mm-dd> 1.1.0 Initial document <Name>

 Index

2. General Description..................................................................................................4
2.1. Functional Specification..............................................................................4
2.2. Assumptions and Dependencies..................................................................4
2.3. Agreements with the Client for the Administration of Requirements.........5
3. Requirements Specification......................................................................................5
3.1. Use Case Reports.........................................................................................5
3.2. Functional Requirements.............................................................................5
3.3. Additional requirements..............................................................................7
3.4. Non-Functional Requirements.....................................................................7
3.5. Technical requirements...............................................................................8
3.6. Process Requirements..................................................................................8
4. Requirements Administration...................................................................................8
4.1. Set of Requirements...........................................................................................9
4.2. Individual Requirements....................................................................................9
4.3. Requirements Review Criteria.........................................................................10

Software Requirements Specification

1. Introduction
[The introduction to the Software Requirements Specification should
be a summary of the entire document. Should include the purpose,
scope, definitions, acronyms, abbreviations, references, and executive
summary of this document]
 1.1. Purpose
The purpose of this document is to capture all of the software requirements of the
system, or a subset of the system.

[Note: Requirements that will be carried out using a transactional

framework must be specified in the appropriate document for that ]

1.2. Ambit
[Mandatory paragraph.]

[A description of the affected environment; which projects are

affected or influenced by this Software Requirements Specification.]

1.3. Definitions, Acronyms and Abbreviations

[Mandatory paragraph if there are terms, definitions, acronyms or
abbreviations.]

[This subsection should provide definitions of all terms, acronyms, and

abbreviations required to correctly interpret the Software Requirements
Specification. This information can be provided as a reference to the
project Glossary.]

[Recommendation: It is suggested to maintain only one glossary for the

project.]

1.4. References
[Mandatory paragraph if there are references.]

[This subsection should provide a list of all documents referenced

anywhere in this Software Requirements Specification. Each document
must be identified by title, edition (if applicable), date, and publisher.
Specify the sources from which these references can be obtained; this
information can be provided as a reference to an appendix or another
document.]

1.5. Executive Summary

[Paragraph NOT mandatory.]

[This subsection should describe the rest of the document containing and
explaining how it is organized.]
2. General Description
[The description of the main factors affecting the solution space is
considered in this part. Include those items such as product perspective,
product features, user features, limitations, assumptions and
dependencies. The description of the requirements is not included in this
section.]

2.1. Functional Specification

[Mandatory paragraph.]

[If you use use case modeling, this section should contain the reference
to it, and a description or summary of the model or the most
representative subset of it. This includes a list of names and brief
descriptions of the use cases, actors, applicable diagrams and
relationships...
 If there is no use case model, all existing descriptions of the
functionalities must be referenced, whether meeting minutes, emails, etc.
It is necessary to add those descriptions in this section and in section 1.4
References of the document all sources of the requirements need to be
mentioned.]

[This point can be replaced with the Requirements Management Excel

template making reference.]

2.2. Assumptions and Dependencies

[Mandatory paragraph.]

[This section describes any key technical feasibility, availability of

components or subsystems, or other assumptions made on which the
feasibility of the software described in this Software Requirements
Specification is based.]

2.3. Agreements with the Client for the Administration

of Requirements
[Mandatory paragraph.]

[This section defines how changes to the requirements will be treated.

Normally, the Service Order defines a percentage as a limit to make
possible changes to the requirements. This impact is measured in the
number of man-hours that this modification requires.]

3. Requirements Specification
[This section should describe in detail all the software requirements, in
order to allow the designers to design the system to satisfy the
requirements as well as the testers to design an appropriate test plan to
verify compliance with them. When use case modeling is used, these
requirements are captured in the use cases, and in the applicable
additional specifications. If use case modeling is not used, the definition
of additional specifications should be inserted directly here.]

3.1. Use Case Reports

[Mandatory paragraph.]

[In use case modeling, they define most of the functional requirements of
the system, and some non-functional requirements. For each use case in
the top model, or subset thereof, refer to or close the use case report in
this section. Make sure each requirement is clearly labeled.]

[For small projects, lasting less than a month and a team of less than 3
people, this paragraph can be replaced with a document reference
Analysis Preliminary.]

3.2. Functional Requirements

[Mandatory paragraph.]

[In this section all functional requirements should be described in detail.

This section should be used when the functionalities are not transactions
of some transactional framework. The description should be clear enough
to allow designers to make an appropriate design, programmers to
understand functionality, and testers to develop an appropriate test plan.]
[Data to be Defined for each non-Functional requirement]
Field What does it consist of
The digits must be separated by "commas".
The first digit indicates the phase in which the requirement was
entered. The second digit indicates the iteration.
Number (F,I,ID,V) The third digit indicates the ID of the requirement, which cannot be
repeated in any previous phase or iteration (IT IS UNIQUE).
The fourth indicates the version for the same requirement, in case a
requirement is modified.
Date Date on which the requirement or change is requested.
Functionality Corresponds to the requirement listed in the TEC form
It can have three values:
I: Initial Requirement
Guy
N: New Requirement
M: Modification of the Requirement
Reference to artifact where the written requirement is.
Origin The reference has the following format:
<relative address>\<artifact name>
Requested by Who requests the request
Assigned to Who is assigned to manage and resolve request
Priority assigned according to:
A: High
Priority
M: Medium
B: Low
It corresponds to the current status of the reported requirement,
according to:
PROPOSAL ACCEPTED
ASSIGNED
State BUILT VALIDATED
REVIEWED
CANCELED TERMINATED

Modification type of the requirement, applies only to changes.

According to:
Category
FUNCTIONAL
NOT FUNCTIONAL
 TECHNICAL PROCESS

Artifacts that need to be changed.

Including components, code, pages,… (not just documents). Default:
Impact of UNKNOWN
Request HIGH
3.3. Additional requirements
HALF
LOW
Description Brief description of the requirement - requirement text
Start date Implementation start date
End Date Implementation end date
Duration (hours) Estimated duration of requirement in hours.
Time for change Time in minutes spent to change the form (enter, delete or change
(*) requirements).
[Mandatory paragraph.]

[Additional specifications capture requirements that are not included in

the use cases. The specific requirements of the Additional Specifications,
which are applicable to this subsystem or feature. These may be captured
directly in this document or referenced in separate Additional
Specifications. Make sure each requirement is clearly labeled.]

[Additional requirements are also functional requirements.]

3.4. Non-Functional Requirements

[Mandatory paragraph.]

[This section describes non-functional aspects, such as response time,

application aesthetics, ease of navigation, etc.]

[Data to be Defined for each non-Functional requirement.]

Field What does it consist of
The digits must be separated by "commas".
The first digit indicates the phase in which the requirement was
entered. The second digit indicates the iteration.
Number (F,I,ID,V) The third digit indicates the ID of the requirement, which cannot be
repeated in any previous phase or iteration (IT IS UNIQUE).
The fourth indicates the version for the same requirement, in case a
requirement is modified.
Date Date on which the requirement or change is requested.
Functionality Corresponds to the requirement listed in the TEC form
It can have three values:
I: Initial Requirement
Guy
N: New Requirement
M: Modification of the Requirement
Reference to artifact where the written requirement is.
Origin The reference has the following format:
<relative address>\<artifact name>
Requested by Who requests the request
Assigned to Who is assigned to manage and resolve request
Priority assigned according to:
A: High
Priority
M: Medium
B: Low
State It corresponds to the current status of the reported requirement,
according to:
PROPOSED
ACCEPTED
ASSIGNED
BUILT
 VALIDATED
REVIEWED
CANCELLED
FINISHED
Modification type of the requirement, applies only to changes.
According to:
Category FUNCTIONAL
NOT FUNCTIONAL
TECHNICAL PROCESS

Artifacts that need to be changed.

Including components, code, pages,… (not just documents). Default:
Impact of UNKNOWN
Request HIGH
HALF
LOW
Description Brief description of the requirement - requirement text
Start date Implementation start date
End Date Implementation end date
Duration (hours) Estimated duration of requirement in hours.
Time for change Time in minutes spent to change the form (enter, delete or change
(*) requirements).
3.5. Technical requirements
[Mandatory paragraph.]

[This section describes the technical requirements, such as operating

system, architectural platform, for example WebSphere, .NET, etc.]

[This point can be replaced by referencing the Requirements Management

Excel template.]

3.6. Process Requirements

[Mandatory paragraph.]

[This section describes the process requirements. For example, for

development you need to use a waterfall development process, RUP, XP,
ITDA-KP,… This paragraph can be related to the Process Configuration
artifact or to the Project Plan.]

[This point can be replaced by referring to the Requirements Management

Excel template.]

4. Requirements Administration
[Mandatory paragraph.]
[This section specifies how the requirements will be monitored, and the
documents associated with this monitoring, likewise, this section
describes how possible changes or new modifications that exist during the
project will be made. This can normally be followed with the
Requirements Management template which should be referenced in this
section.]

Normally these controls are carried out using Excel for greater ease in
control and administration.
4.1. Set of Requirements
Result
Characteristic
R1 R2 R3 Observations
Complete
Consistent
Correct
Prioritized
Understandable
Organized

4.2. Individual Requirements

Unambiguou Understandabl
Complete Traceability to s Verifiable e
Independent
Case of use of Design and
/ Forward Back Implement
Requirement
(1) R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3

(1) Requirement refers to Non-Functional and Functional when they are expressed in
sentences and not in C
4.3. Requirements Review Criteria
APPLY TO THE SET OF REQUIREMENTS
Applies to
All system software requirements are taken. These can be given in use cases or specification in Action to follow if
statements. Case of NOT compliant
Judgment
use
The software requirement set is complete if:
to). It includes requirements aimed at: functionality,
performance, reliability, usability, availability, error handling,
x x ALERT
configuration, maintenance, data loading, backup, debugging
and external interfaces.

b). Each and every software requirement is associated with

Complete at least one business need,
product characteristic or user requirement. Because x x ARREST
traceability is bi-directional, it must also be verified that each
need has at least one characteristic and software
requirement associated with it.

c). In the use cases, the actors participating in them are

x ALERT
clearly described.
The set of software requirements is consistent if:

to). The use case diagram is consistent with the conventions

of UML, or another well-defined modeling language, where
x ALERT
graphic elements that represent relationships, actors and use
cases are well used.

b). There is no common behavior specified in two

x x ALERT
different requirements
c). There is no conflict between the traits of a behavior. For
example, a precondition of use case 'X' implies that the
behavior of use case 'Y' must have occurred, and a
precondition of use case 'Y' implies that some behavior of
x x ARREST
use case 'X' has occurred. '. Another example: one
requirement defines that behavior 'A' must always occur
before behavior 'B', but another requirement states that
behavior 'B' must always occur before behavior 'A'.
d). There is no more than one requirement stated by the
Consistent same
behavior or objective but using different terms. x x ALERT

and). The requirements of a given package are consistent

x x ALERT
with the theme or idea captured in the package name
F). All use cases are associated with at least
with an actor. If not, the use case must be associated with x ALERT
other use cases via extension, inclusion, generalization
relationships.
The software requirement set is correct if:
to). Each requirement represents a necessary part of the
Correct x x ALERT
system to be built.
b). The requirements have been reviewed and approved by
x x ARREST
the client/user
The set of software requirements is prioritized if:
to). The relative importance of each requirement is defined.
Prioritized For example, it can be prioritized by importance to the
x x ALERT
business, complexity to implement, architectural risk, cost to
develop, stability of the requirement, among others.
 The set of software requirements is understandable if:
to). Clearly presents the behavior of the system. That is, it is
easy to understand what the system does by reviewing the x x ALERT
model.
b). In use case diagrams there are no long chains of
x ALERT
inclusion and extension relationships.
c). There is no requirement for each graphical interface
x x ALERT
screen.
d). In use case diagrams there is no functional
decomposition or workflow, the symptoms of which are: use
Understandable cases that are too small; many cases of
use; difficulty understanding the model; use case names x ALERT
such as: “operation” + “object” or “function” + “data” (for
example Insert card); associations with arrowhead (or
without it) between use cases resembling a flow of activities
and). The model and/or diagram has a section where
describes its content, for example the most common x ALERT
sequence of use cases.
The set of software requirements is organized if:
to). They are organized using multiple diagrams or packages
to divide and organize the functionality of the system making
them understandable to stakeholders. When the model is
large and/or responsibilities are distributed in various parts of STOP, if there is not
Organized
the model, requirements packages should be used in a way x x at least one (1) CU
that is intuitive and makes the model easy to understand. diagram
Examples of packages are those organized by functional
area, by actor, by dependency, by relationship between
actors and the system, by iteration, among others.

APPLY TO INDIVIDUAL REQUIREMENTS

Applies to
Action to
specification in
follow if NOT
Software requirements can be given in use cases or statements. Case of
Judgment compliant
use
A software requirement is complete if:

to). The use case provides the interactions and behavior necessary to
x ARREST
satisfy the actors' goals or objectives.

b). The requirement contains only the functionality that will be

x x ARREST
performed by the system.

c). The use case has clearly stated: Purpose, Precondition,

x ARREST
Postcondition, Alternate and exception flows

d). For each use case, the software responses are defined.
Complete
to all actor inputs for both valid and invalid flows. x ARREST

and). The requirement expressed as a short (traditional) sentence has

Defined software responses for both valid and invalid behavior. x ARREST

F). The requirement expressed as a short (traditional) sentence takes

into account
the statement the type of user, desired result, object and measurable x ARREST
qualifier.

Forward A software requirement is forward traceable if:

 to). It has a unique name or reference number as well as the
traceability design components, implementation modules and all the x x ALERT
elements where it is referenced.

Backward A software requirement is traceable back if:

traceability
to). It has explicit reference to its origin or source. x x ALERT
A software requirement is unambiguous if:
to). It has a single interpretation by users and implementers. To do this,
there should be no words or phrases that favor multiple interpretations,
such as: Conjunction (and, with, also), since it possibly represents
several requirements; Disjunction (o), since it possibly does not x x ALERT
represent a specific behavior; and words like usually, frequently,
normally, flexible, versatile, efficient, user-friendly and meaning
possibility (can, perhaps, probably).
b). It is not excessively detailed with multiple and deep
Unambiguous
nesting, either by inclusions in use cases or by hierarchy in sentences. x x ALERT

A software requirement is verifiable if:

to). There are no non-verifiable words or phrases such as: works well,
x x ARREST
fast, good performance, usually happens, among others.
Verifiable b). The requirement is stated in quantifiable and verifiable terms
x x ARREST

c). In use cases the preconditions and post-conditions are declared so

x ARREST
that they can be tested.

A software requirement is independent of design and implementation if:

Independent
Design and to). Technical words or phrases are NOT used in the requirement, such
implementation as: name of components, database fields, software objects, design x x ALERT
restriction, among others.

A software requirement is understandable if:

to). The use case is self-explanatory. That is, the annotations, models,
and format of the use cases should allow the interested party to review, x ALERT
understand, and validate the use cases with a minimal amount of effort.

b). The requirement is written in the 'language' of the clients and users,
Understandable
using terms that are used in the business domain (Glossary). x x ALERT