Software Requirements Document Template
Uploaded by
ScribdTranslationsSoftware Requirements Document Template
Uploaded by
ScribdTranslationsRequirements document of
software
[Project Name]
[dd/mm/yyyy]
Table of contents
Version History3
Project Information3
Approvals3
1. Purpose4
2. Product Scope / Software4
3. References4
4. Product features5
5. Classes and characteristics of users..................................................................5
6. Operating environment5
7. Functional requirements6
9.1. (Functionality Name 1)....................................................................6
9.2. (Name of Functionality 2)....................................................................7
9.3. (Name of the functionality N)....................................................................7
8. Business rules8
9. Requirements for external interfaces9
9.1. User interfaces9
9.2. Hardware interfaces9
9.3. Software interfaces9
9.4. Communication interfaces9
10. Non-functional requirements 10
11. Other requirements11
12. Glossary12
Version History
Date Version Author Organization Description
Project Information
Company / Organization
Project
Preparation date
Client
Main sponsor
Manager / Project Leader
Manager / Analysis Leader
business and requirements
Approvals
Name and Surname Cargo Department u Date Company
Organization
1. Purpose
This section defines the name or title of the software being specified.
in the document, including its version number or Release.
Then it describes which components or parts of the product scope are
included in the document, determining whether this document covers the entirety of the
software, just a part of the system, subsystem, or subgroup of processes.
2. Scope of the product / Software
A brief description of the scope of the software being included.
specifying, including:
Its general purpose or objective.
Benefits that it provides to the business area and organization.
Objectives and goals. It is advisable to establish the relationship of the objectives.
of the software with corporate objectives and business strategies.
You can refer to other documents, such as a definition.
of scope or act of constitution of the project.
3. References
Here you can include other printed documents, electronic documents or
electronic addresses that complement the documentation of requirements
of the software, for example: Vision documents, scope definition, others
software requirements specification documents, flowcharts,
policies, procedures of the organization, among others.
For each reference, it is recommended to include the title, author, version, date and
physical or electronic location.
4. Product features
List of software features that are being specified in the
requirements document. Each functionality may consist of one
or various functional requirements of software.
Here is only a numbered list of the main features, the
Detailed information on functional requirements is documented in section 7
from this document.
5. Classes and characteristics of users
This section classifies the users who will use the product.
classification can be based on frequency of use, group of functionalities
used, security privileges, level of experience and other parameters.
A list can be used to enumerate the types of users who will use the software.
describing the characteristics of each one.
For each type of user, the product features can be mentioned.
(Section 4) that are relevant to you. Similarly, mention can be made of which
users make greater use of the system and more frequently, to
distinguish them from occasional users or those who access few functionalities.
6. Operating environment
This section describes the operational environment in which it will develop.
system, software, module or group of functionalities, mentioning aspects
like the hardware platform, operating system versions, and other systems
the components with which it must coexist.
7. Functional requirements
The functional requirements of a system are those that describe
any activity that it must carry out, in other words, behavior or
particular function of a system or software when certain conditions are met
conditions.
In this section of the template, we illustrate how to organize the requirements.
software functionalities by product or system functionality. Here are listed the
functionalities and for each one the functional requirements are listed.
Functional requirements can also be documented in a matrix.
traceability of requirements. Follow the next link and we will show you one
template
> Requirements Traceability Matrix Template
The following shows how to document each feature:
9.1. (Name of functionality 1)
In the title of the functionality, it is recommended to use names that are as descriptive as possible.
possible for each functionality. Do not limit to naming them 'Functionality 1'. A
A good example could be 'Purchase order authorization.'
Short description of the functionality.
Priority: Low, medium, or high priority level. This must be established by the
functional area.
Initiating actions and expected behavior: Sequence of actions of
user and expected system responses for this functionality.
Functional requirements: Detailed list of functional requirements
associated with this functionality.
For each functional requirement, it is established how the software should be displayed.
and what behaviors must be performed so that the user can carry out the
function that is needed.
It is advisable to include how the software should respond to error conditions and
invalid data entries.
Each requirement must be uniquely identified, for which
It is recommended to use a sequence number that has some meaning and of
common format throughout the organization. For example:
REQ-1:
REQ-2:
REQ-3:
To see some examples of how functional requirements are written, you
we recommend the following link:
> 40 Examples of functional software requirements
9.2. (Name of functionality 2)
Follow the same guidelines of functionality 1 for as many functionalities.
have the system.
9.3. (Name of the feature N)
Follow the same guidelines as functionality 1 for as many functionalities
have the system.
8. Business Rules
List of rules and principles that apply to the entire set of requirements
software contained in the document. An example is which individuals or roles
they can perform a certain function under certain circumstances.
To enforce the business rules, defining may be necessary
functional requirements that apply to the entire system, not to a functionality
specific.
9. Requirements for external interfaces
9.1. User Interfaces
Here the characteristics of each user interface are described.
They can be classified by types or areas of the system with different interfaces.
Screenshots can be included.
Describe the graphical user interface (GUI) standards.
Style guides on screen organization, standards for buttons,
functions that will be displayed on all screens.
9.2. Hardware interfaces
Information about which types of devices the system supports, for example:
Computers, mobile devices, printers, other devices.
Communication protocols supported.
Data and control interactions between software and hardware.
9.3. Software Interfaces
Here the interactions between the software and other components are described,
including: Other software and system components, and if applicable, bases
data, operating systems, tools, libraries, software components
commercial, among others.
9.4. Communication interfaces
Requirements for the communication functions that the product needs,
including email, web browsers, network communication protocols,
electronic forms, among others.
Includes messaging formats, communication standards (e.g. FTP, HTTP,
etc.). Also describe encryption and security requirements in the
communications.
10. Non-functional requirements
Thenon-functional requirementsthey are the ones that specify criteria for evaluating the
operation of an information technology service, in contrast to
the functional requirements that specify specific behaviors.
To see some examples of how requirements are not written
functional, we recommend the following link:
> Examples of non-functional software requirements
11. Other requirements
Requirements not covered in any other section of the document
software requirements, for example: Database requirements,
internationalization, legal aspects, and goals of software component reuse.
12. Glossary
Description of terms and acronyms necessary for understanding the document
of software requirements.
