Requirements Document

User / Software

Example System
Comment: everything that is in parentheses is a comment,
therefore it must be instantiated or removed... including this
comment

Date: [date of last change]

Version: [current version]

Development Team:
Place here the most relevant members (interlocutors and/or responsible persons) of the team of
development.
Name 1 (Role, Contact)
2
Name 3 (Role, Contact)
Name 4 (Role, Contact)
For example:
Name Rol Contact
Juan Carlos Pérez Project Manager jcp@[Link]
(56 2) 345-4369
Juana Alvarez Analyst juana@[Link]
(56 2) 345-4363

System Requirements Document

Example Page 1
 Alberto González Designer alberto@[Link]
(56 2) 345-4367
Pedro Gutiérrez Analyst/Implementer pedro@[Link]
(56 2) 345-4364
José Fleitas Implementer pepe@[Link]
(56 2) 345-4365
Jorge Rodríguez Tester jorge@[Link]
(56 2) 345-4363
]

Counterpart:
Place here the most relevant members (interlocutors and/or responsible parties) of the counterpart.
These people are members of the client organization, and they have some kind of commitment to
support the development of this project.
Name 1 (Role, Contact)
Name 2
Name 3 (Role, Contact)
Name 4 (Role, Contact)
For example:
Name Roll Contact
Sergio F. Ochoa Client/Teacher sochoa@[Link]
(56 2) 678-4364
María Cecilia Rivara Client/Coordinator/Teachermcrivara@[Link]
(56 2) 678-4365
Francia Ormeño Secretariat francia@[Link]
(56 2) 678-4366
Margarita Serei Accountant mserei@[Link]
(56 2) 678-4367
José A. Pino Professor jpino@[Link]
(56 2) 678-4368

System Requirements Document

Example Page 2
 History of the Document

Version Date Reason for Change Author(s)

0.1 08/08/2005 First draft

System Requirements Document

Example Page 3
 Index

History of the Documento ...........................................................................................................iii

1 Introduction .................................................................................................................... 1
1.1 Purpose of the System
1.2 Project Scope...................................................................................................... 1
1.3 Context.
1.4 Definitions, Acronyms and Abbreviations............................................................. 1
1.5 References .

2 General Description ....................................................................................................... 3

2.1 User Characteristics ...................................................................................... 3
2.2 Product Perspective According to Users/Clientss ................................................... 4
2.3 Operational Environment of the Solution............................................................................. 4
2.4 Relationship with Other Projects ........................................................................................ 5
2.5 Model Description .................................................................................................. 5

3 System Requirements ............................................................................................10

3.1 User Requirements .................................................................................................10
3.2 Software Requirements..................................................................................................11
3.3 User Requirements vs. Software Requirements Traceability Matrix ...........................12

4 System Tests .......................................................................................................13

4.1 User Tests.......................................................................................................13
4.2 User Requirements vs. Testing Traceability Matrix ..................................................13

System Requirements Document

Example Page 4
1 Introduction
This introduction briefly describes the context, objectives, and scope of the
system to be developed, as well as the related documentation. This information
it is based on the Project Proposal Document (PPD) of the System of
Example.
To use this template, you must remove all paragraphs that are between brackets,
like this, and replace them with appropriate text (this is the only paragraph between
brackets that are not replaced by anything). In addition, it should go to the File menu,
optionProperties(properties), and modify the propertiesSubject(Subject) and
Comments. Once modified, update the references.
select all the document and press F9. Select the footer and
Update the reference to the system name.

1.1 Purpose of the System

Describe here what the system does and what it is. For small projects, half a page.
it should be more than enough.

1.2 Project Scope

Describe the scope of the project: what it is and what it is not. For projects
small ones, half a page should be more than enough.

1.3 Context
Providing information regarding the context of development and the context in which it is placed.
what to insert into the system. Technologies that will be involved, previous work,
links with other systems, etc. Write what you need, in general the graphics are
welcome, they help a lot with understanding

1.4 Definitions, Acronyms, and Abbreviations

Indicate here the definition of the 'keywords' that will be used in
the document, and that the reader does not necessarily know. In the same way,
put the meaning of all acronyms or abbreviations that are used. Both the acronyms
how the definitions have to express what the author(s) of the document
they understand, and not necessarily give general definitions. The idea is to be able to
understand the document being read in all its magnitude, and nothing more. The list
It must be in alphabetical order to facilitate the search for concepts. Examples of
Definitions, acronyms, and abbreviations are as follows:

Wireless Communication: Type of data communication that is carried out through

embedded or attached antennas to computing devices.
TCP (Transmission Control Protocol): Data communication protocol oriented
to the connection. Generally used in computer networks.
URD (User Requirement Document): Document that expresses the requirements of the
users/customers of a system.

System Requirements Document

Example Page 1
 This will be referred to as the sales reports that the system must
issue at the end of the workday.

1.5 References
List the documentation and bibliography used as support to build this.
document. Include dates and document versions when appropriate. For
example:

1. ESA Software Engineering Standards. PSS-05-0 Issue 2. ESA Board for

Software Standardization and Control (BSSC) - European Space Agency.
(1991). URL:[Link]/ECOSIM/[Link]
2. URD (User Requirement Document) 3.1.
3. SRD (Software Requirement Document) 2.0.]

System Requirements Document

Example Page 2
2General Description
This section describes the functional requirements of Users/Clients (section 2.1 system,
its external interfaces, the exception conditions, and the test classes that will be conducted for
verify that the requirements are met.

2.1 Characteristics of Users

Here, the types of users, the general attributes of each type, and the quantity must be identified.
of people in each category. For example:

The users of the system are:

Type of Description Actual # Users
User Future Contactables
(1 year)
User You can only make a reservation for one. 25 30 Sergio Ochoa, (56
678-4364
Common specific resource in modules in the sochoa@[Link]
that the resource is available, that is, .com
has not been reserved by another user
previously. In addition, it can Pedro Peralta, (56
cancel your own reservation and modify it 678-4365
pp@[Link]
as long as the schedule is
available.
Super You can make reservations for a resource. 2 2 Jaime Rodríguez,
(56 2) 678-4364
User about any module, even if it is jrodrig@[Link].
occupied by another user. In addition with
can cancel and modify any
Reservation made in the system.
User Handles all resource management and 2 2 Andrés Neyem, (56
678-4365
Administrator statistics, that is, can add, aneyem@[Link]
delete, modify, disable or [Link]
enable any system resource and
manages the statistics, customizing Lucía Ortega, (56
the statistic that wants to be obtained 678-4365
lucia@[Link].c
displaying it on the screen. The handling of om
Users are managed through the SAU.
User This is anyone who visits the 50 by 70 per Juan Aguirre, (56
2) 678-43647
general or system page, can only consult day (very day (very juanaa@[Link].
visitor the information about the reservations and the variable) variable) com
available resources.

System Requirements Document

Example Page 3
The following scheme reflects the interaction of each user with the system modules:

Consult: Book Management of Management of Management of

Resources Resources Users
reservations
Administrator User SAU
General User Common User

Super User

2.2 Product Perspective According to Users/Customers

Here should be placed the perspective that clients and users have about the product.
Each type of user has different expectations, and each type of customer does too. The customer is
the one who provides the vision of the organization. That should be expressed here. Just place it
A prayer for each type of user.

2.3 Operational Environment of the Solution

Here the main components of the operational environment are briefly described, where
you must live the solution that is being developed. This can describe the current scenario,
or the future, if a purchase of equipment is going to be made. For example:

The operational environment involved in this system is as follows:

The system will run a server with the following characteristics:

Pentium at 2.4 Ghz, with
motherboard D845
1.5 G RAM DDR
2 SCSI 18 GB Barracuda disks
2 D-link 10/100 network interfaces
The server runs on a Redhat 8 operating system (with up-to-date updates). This server
has a configuration aimed at providing web services with characteristics of
security and functionality of the highest level. As a web server, SID uses Apache 2.0.40 with
the PHP4 module and with the SSL module. The latter allows the server to establish connections
secure of the HTTPS type. The management system will be implemented in PHP4 and will be accessible
from the Internet and will have its own database. Additionally, it must look at the information from the
workflow database, which will be present on the same server.

The MySQL databases used by the system are running on the same server.
SID. The installed version of MySQL is 3.23.55a (mysql-max). The application must be usable.
since browsers MSIE 5.0, Netscape 4.78, Opera 7.0, and Konqueror 3.04.

For the proper functioning of the system, the user must access it through a
computer that has at least the capabilities of a Pentium III PC at 300 MHz with 64
MB of RAM, with a 17-inch monitor with a resolution of 1024x768 pixels.

System Requirements Document

Example Page 4
Communication within the organization is carried out through Ethernet networks at 100mbps.
wired with UTP, cat.5, and wireless networks IEEE 802.11b/g at 10Mbps. Both types of networks
They use TCP/IP as a communication protocol. For the macro-distribution of packets, ...
They mostly use smart routers and switches.

2.4 Relationship with Other Projects

Here it should be specified whether this project is related to any already implemented system, with
another project in progress or planned. For example:

The system does not depend on other systems, nor do other systems depend on it. However, for
to be a project for the DCC in which users belonging to the DCC are involved, there is a
coordination relationship with other systems associated with user profile management, whether
for academics, students, secretaries or others.

In particular, the user management of the system will be integrated with 2 other projects that
they are currently being developed for the DCC, these are: the management system of
scientific publications (group 6, course cc51a) and the accounting system of the PEC (group 5, course
Thus, access to the system will be carried out jointly with the other 2 systems through
from the DCC website whose address is:[Link] the entry of a
username and a password for each user directly for academics connected from
your PC in the DCC. This will create a user session, which will allow you to access our site.
project with the assigned role. This will be very convenient for users of the 3
systems, primarily academic as they will have a common identifier for all
systems entering any of them in the form of an Intranet.

This will mean associated coordination among users between the 3 systems regarding management.
Common tables associated with users, the coordination will be handled by the course assistant Renzo.
Angles. Furthermore, the systems must have a look & feel similar to the current DCC site.
using the same CSS as the DCC site.

2.5 Model Description

Here you need to present a general use case diagram, block diagram or a
Level 1 or 2 DFD that reflects current operation. If necessary, it can be
add an explanation of the general functioning of the current system. For example:

System Requirements Document

Example Page 5
 The logical model of the system will be shown through use case diagrams that show

Reserves

Check reservation

Reserve resource in
available schedules
General User

Cancel own reservation

Common User

the basic functionalities of the system and its actors, this is the following:

System Requirements Document

Example Page 6
 Resources

General User

Super User
reservation

System Requirements Document

Example Page 7
 Consult Resource

Add resource

SAU
Delete resource

Modify information of the

resource

Administrator User
Disable resource

Enable resource

System Requirements Document of

Example Page 8
 Users

Add user

Delete Users

Modify information of
user

Statistics

Obtaining statistics

Administrator User

System Requirements Document

Example Page 9
3System Requirements
This section describes the requirements of Users and Clients (section 3.1), and the
software requirements (section 3.2) that the system must meet. [To facilitate the
specification and requirements management, the tool ReqAdmin can be used,
which is available in ChileForge:[Link]

3.1 User Requirements

This section describes the user requirements of the system, by category. The defined form for
specifying the requirements contains the following attributes:
Attribute Description
Identifier This is a unique code used to identify or recognize the
requirement. The format will be used for user requirements
RUXXXX and for the software RSXXXX
Name Name in plain language of the requirement
Description Requirement description. What aspects does it involve, in what
consists, etc.
Priority Priority associated with the requirement, this can be critical, desirable
or unnecessary. A requirement is critical if it affects an operation
business critique. If there is any process that you want to include
to improve current processes, we are facing a requirement
desirable and if it is an informational requirement or one that can
wait for later stages, the requirement is cataloged as
unnecessary.
Source Document or person from which the requirement arose
Stability This field aims to indicate whether the requirement can or
cannot be subject to change during the life cycle of
software (translatable or untranslatable). The ESA standard defines it
how stable or unstable.
State Current state of the requirement within development (Meets, Does not meet
Fulfill, Ambiguous
User List They are the types of users that are associated with the requirement.
Test Case Case in which it will be tested whether or not the requirement is met.
the system.

3.1.1 Capability Requirements

Here is where the list of capacity requirements that the product should meet should be placed.
according to the clients and the users involved. These requirements can be ambiguous, and in that
If they need to be disambiguated through the use of rapid prototypes, for example. Once that
the requirements have been disambiguated, they must be specified as software requirements (that
is presented in section 3.2). An example of the specification of a user requirement is the
next:

UR100 Embed Discussion Priority: High

System Requirements Document

Example Page 10
 Users must be able to embed a configurable component in a component of
content in the CDS client. And in doing so, they must have the option to configure it by defining the
name of the discussion
to have associated the author, the creation date, and a discussion identifier.
Source: Interview with the client Users: Teacher, Assistant (Client Users)
CDS
Stability: Unyielding Not fulfilled CP005

3.1.2 Quality Requirements

Here is where to place the list of quality requirements that the product should meet.
These requirements cannot be ambiguous, and therefore they should be disambiguated at this stage.
(if necessary). These requirements must be specified according to the format
pre-established.

3.1.3 Restriction Requirements

Here is where to place the list of requirements that specify restrictions about how it should be
be built (refers to connections with other systems, or adherence to standards of the
company) and operated the software. These requirements cannot be ambiguous, and because of this in this
phases should be disambiguated (if necessary). These requirements must be
specify according to the established format.

3.2 Software Requirements

Software requirements are based on user requirements, and represent
the vision of the developing company regarding what needs to be designed and built. These
requirements cannot be ambiguous. The form defined to specify the requirements contains
the following attributes:
Attribute Description
Identifier This is a unique code that is used to identify or recognize the
requirement. The user requirements will use the format
RUXXXX and for the software RSXXXX
Name Name in plain language of the requirement
Description Description of the requirement. What aspects it involves, in what
consists, etc.
Priority Priority associated with the requirement, this can be critical, desirable
or unnecessary. A requirement is critical if it affects an operation
business critique. If there is any process that you want to include
to improve the current processes, we are faced with a requirement
desirable and if it is an informative requirement or that can
waiting for later phases, the requirement is categorized as
unnecessary.
Source Document or person from which the requirement originated

System Requirements Document

Example Page 11
 Stability This field is intended to indicate whether the requirement can or
cannot be subject to change during the life cycle of the
software (translatable or non-translatable). The ESA standard defines it.
as stable or unstable.
State Current status of the requirement within the development (Meets, Does Not Meet
Fulfill, Ambiguous
User List They are the types of users that are associated with the requirement.
Test Case Case in which it will be tested whether or not the requirement is met
the system.

In the same way, a classification was also created for software requirements. The
defined categories for software requirements are as follows:

. Functional: Indicate what the software capabilities should be. They are derived from the model.
logical.

. Interface: Specify the hardware, software, or database elements with which the
system or its components interact or communicate.

. Operational: They specify how the system will run and how it will communicate with the
human operators. They include all user interfaces, human interaction-
computer, and logistical and organizational requirements.

. Resources (Operational Environment): Specify the upper limits of physical resources

such as processing capacity, main memory, disk space, etc.

. Usability: These are related to the effort of use and the evaluation of use.
performed by the users.

. Maintainability: Requirements related to the effort of making modifications. They specify

How easy is it to fix faults and adapt the software to new requirements?

. Portability: It has to do with the ability to be transferred from one environment to another.

. Reliability: They are those that are related to the ability to maintain a level
adequate service, under certain conditions and for a certain time. They specify the times
means among acceptable failures.

. Interoperability: Ability to interact with certain systems.

. Performance: They establish numerical values for measurable variables that are related.
with the system performance.

. Documentation: Specifies particular project requirements for documentation.

. Scalability: Specifies the system's ability to maintain, if not improve, its

average performance increases as the number of users grows.

3.3 User Requirements vs. Requirements Traceability Matrix

Software

System Requirements Document

Example Page 12
System Tests

4.1 User Testing

This section will specify the tests that will be carried out on the system to determine
that the user requirements are met. A test can lead to many cases of
test.

4.2 User Requirements vs. Test Traceability Matrix

Table 1: User requirements matrix versus tests

RP1 RP2 RP3 RP4 RP5 RP6 RP7 RP8 RP9 RP10
RU1 x X
RU2 x X x
RU3
RU4 x

System Requirements Document

Example Page 13