1.1.

2 IEEE830 Standard
Standardization is a process through which we seek to achieve the quality of
products and/or services. In the case of software engineering, a series of regulations
are followed that allow standardizing the processes that make up the life cycle of the
systems.
In the definition of the system, it is important to document the requirements
preferably under a standardized document such as the IEEE 830-1998 Software
Requirements Specification (SRS), where each of them and their attributes are
described in detail, and which serves as a basis for change control, since within each
document the associations of each requirement with the various modules of the
system or with other requirements are specified, which will facilitate the tracking and
impact of each of the changes requested and made.
This standard seeks to generate good content and specification of software
requirements through various schemes. Its objective is to specify the requirements
of the software to be developed and establish a documented agreement between
the client and the system developers, on the system to be built.

Structure of a requirements document according to the IEEE 830-1998 standard

Within table 1 is the structure of the requirements specification according to the IEEE
830 standard, according to(Cristiá, 2011) :
1.1 Purpose
1.2 Scope
1. Introduction 1.3 Definitions, acronyms and
abbreviations
1.4 References
1.5 General Overview.
2.1. Product perspective.
2.2. Product features.
2. System Overview 2.3. User profile.
2.4. Limitations.
2.5. Assumptions and dependencies.
3.1 Functional and non-functional
requirements.
3. Specific requirements. 3.2 External Interface Requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Attributes
4. Appendix
Table 1. Document structure according to IEEE 830 standard

1. Introduction. This section is in turn subdivided into the following:

 1.1. Purpose . Describes the purpose of the requirements document and the
audience it is intended for.
1.2. Scope . You should identify the products to be produced by name, briefly
explain what those products will do, and describe the business behind the
system.
1.3. Definitions, acronyms and abbreviations . This subdivision shall provide
definitions of all conditions, acronyms, and abbreviations that require proper
interpretation of the SRS. This information may be provided by reference to
one or more appendices in the SRS or by reference to other documents.
1.4. References . This subdivision must:
a) Provide a complete list of all references to documents elsewhere in
the SRS;
b) Identify each document by title, report number (if applicable), date,
and organization publication;
c) Specify the sources of the references from which they were
obtained.
1.5. General view . This subdivision should describe what the rest of the SRS
contains and how it is organized.
2. System overview. This section of the SRS should describe the general factors
that affect the product and its requirements, maintaining a background of those
requirements that are defined in detail and made easier to understand.
2.1. Product perspective. The product is described in relation to the other systems
with which it interacts. If it is a component of a larger system then this
situation must be clarified and the interfaces that unite them and which of the
requirements of the larger system this component meets must be described.
2.2. Product features . This section will summarize the main functions that the
product will fulfill. A broad summary of the functions of the future system must
be shown, the functions must be presented in an organized way and you can
use graphs but as long as these graphs reflect the relationships between
functions and not the design of the system.
2.3. User profile. This should specify the logical characteristics of each interface
between the software product and its users, and all aspects of perfecting the
interface with the person who is to use the system.
2.4. Limitations . Any other issues that limit the developer's options for designing
and implementing the system should be listed and explained in this section.
These include: regulation policies, hardware limitations, interfaces with other
applications, whether the system should operate in parallel or not, audit
functions, control functions, programming language requirements,
communication protocols, criticality of the application and safety and security
considerations.
2.5. Assumptions and dependencies . The assumptions and dependencies that,
if not met, will imply changes in one or more of the requirements described
below must be listed.
3. Specific requirements. Specific requirements are listed here. In general terms
it corresponds to what we call "structured list of requirements". In that section we
said that this list be divided into sections, subsections, etc. in order to organize it
in such a way that it allows finding a specific requirement more easily.
3.1. Functional Requirements. This is the most extensive part of the document,
here all the functions that must be executed by the system are specified.
These functions are expressed in a natural way with specific statements of
the form “the system shall.”, and graphical tools can be used to help in its
definition, but always arriving at a statement.
3.2. External Interface Requirements . Within this, those requirements are written
that describe the way in which communication will be carried out between
the system and its environment (including users).
3.3. Performance requirements. These are the requirements associated with the
performance of the system, such as response times, forms of data storage,
among others.
3.4. Design constraints. These are all those factors that limit the design of the
system, such as: hardware, other standards or the organization's regulations.
3.5. Attributes . Within this section, the attributes that define the quality of the
system are described. It is necessary to detail the way in which each of them
will be implemented, for example, username and password formats, user
access restrictions, data recovery mechanisms, among others.
4. Appendix. The appendix section includes all the information that may be
necessary for the construction of the system that is not included in the SRS
document, such as interviews, reports, time analysis, costs, etc.
 Example of software requirements specification

Project: Web information system for the management of Administrative and

Academic Processes of the Metalminero Socialist Training Center of La
Victoria, Edo. Aragua
Instructions for using this format

This format is a typical template for software requirements documents.

It is based on and complies with the IEEE Std 830-1998 standard.

Sections that are not considered applicable to the described system may
justifiably be indicated as not applicable (NA).

Grades:
The texts in blue are indications that must be eliminated and, where
appropriate, replaced by the contents described in each section.

The texts in brackets of the type “[Inserte aquí el texto] ” allow the direct
inclusion of text with the color and style appropriate to the section, by clicking
on them with the mouse pointer.

The titles and subtitles of each section are defined as MS Word styles, so that
their consecutive numbering is automatically generated depending on whether
they are “Title1, Title2 and Title3” styles.

The indentation of the texts within each section is generated automatically

when you press Enter at the end of the title line. (Normal indented 1, Normal
indented 2 and Normal indented 3 styles).

The document index is a table of contents that MS Word updates based on the
titles of the document.
Once you have finished writing, you must tell Word to update all of its content to
reflect the final content.
Document file

Date Revision Author Verified dep. Quality.

Rodriguez Juan
12/04/2012 Tapias Juan
Leonardo Mendoza
Document validated by the parties on date:

For the community By the University

Socialist Training Center “Metalminero de Territorial Polytechnic University of

la Victoria.” Aragua Doct. Federico Brito Figueroa
Content
1.1.2 IEEE830 Standard 1
Structure of a requirements document according to the IEEE 830-1998 standard 1
Example of software requirements specification 4
Instructions for using this format 5
General description 10
Specific requirements 12
BIBLIOGRAPHIES 27
Introduction

This document is a Software Requirements Specification (ERS) for the

Information System for process management and inventory control. This
specification has been structured based on the guidelines given by the IEEE
standard Recommended Practice for Software Requirements Specifications
ANSI/IEEE 830, 1998.

Purpose

The purpose of this document is to define the functional and non-functional

specifications for the development of a web information system that will allow
managing different administrative and academic processes. This will be used
by students, teachers and managers.

Scope

This specification of requirements is aimed at the user of the system, to

continue with the development of educational applications about the institution
and to deepen its automation, which has as its main objective managing the
different administrative processes (Inventory, Events, Course and Information)
and academic (Virtual Classroom).

Personnel involved
At this point, the personnel who will be in charge of monitoring and preparing
the document are specified. Data such as: name, role, professional category,
responsibility, contact information must be entered.

Name Juan Rodriguez

Role Analyst, designer and programmer
Professional TSU-Informatics
category
Responsibility Information analysis, design and programming
of the SIS-I
Contact information Elgranjuan138@hotmail.com

Name Leonardo Mendoza

Role Analyst, designer and programmer
Professional TSU-Informatics
category
Responsibility Information analysis, design and programming
of the SIS-I
Contact information Leonardomendoza_98@hotmail.com

Name Juan Tapias

Role Analyst, designer and programmer
Professional TSU-Informatics
category
Responsibility Information analysis, design and programming
of the SIS-I
Contact information Juan_23571011@hotmail.com

Definitions, acronyms and abbreviations

The terms must be defined. Acronyms and abbreviations that will be used in
the ERS.

Name Description
User Person who will use the system to manage
processes
YES Web Information System for the Management of
YES Administrative and Academic Processes
ERS Software Requirements Specification
RF Functional Requirement
RNF Non-Functional Requirement
FTP File Transfer Protocol
Moodle Virtual classroom

References

Document title Reference

IEEE Standard 830 - IEEE
1998

Summary

This document consists of three sections. The first section introduces it and
provides an overview of the system resource specification.
 In the second section of the document, a general description of the system is
made, in order to know the main functions that it must perform, the associated
data and the factors, restrictions, assumptions and dependencies that affect
the development, without going into excessive details.
Finally, the third section of the document is the one in which the requirements
that the system must satisfy are defined in detail.

General description

Product outlook
The SIS-I system will be a product designed to work in WEB environments, which will
allow its use quickly and efficiently, and will also be integrated together with Moodle
(Virtual Classroom) to achieve a better response.
Product functionality

User characteristics
Type of user Administrator
Training TSU in Computer Science
Activities Control and management of the system in general

Type of user Teacher

Training Educator
Activities Facilitate the learning process

Type of user Student

 Training Bachelor
Activities Active participation in courses and forums

Type of user Visitor

Training NA
Activities Observe and investigate information and pre-
register for courses

Restrictions
 Interface to be used with the internet.
 Domain Use (X)
 Languages and technologies in use: HTML, JAVA.
 Servers must be able to serve queries concurrently.
 The system will be designed according to a client/server model.
 The system must have a simple design and implementation,
independent of the platform or programming language.
.

Assumptions and dependencies

 The requirements described here are assumed to be stable

 The computers on which the system is going to be executed must
meet the requirements indicated above to guarantee its correct
execution.

Specific requirements

Functional Requirements

Identification of RF01
the
requirement:
Name of the User Authentication.
Requirement:
Characteristics: Users must identify themselves to access any part of the
system.
Description of The system can be consulted by any user depending on the
the module in which it is located and its level of accessibility.
requirement:
NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF08
Requirement priority:
high

Identification of RF02
the
requirement:
Name of the Register Users.
Requirement:
Characteristics: Users must register in the system to access any part of the
system.
Description of The system will allow the user (student, teacher and
the Administrator) to register. The user must provide data such
requirement: as: CI, First Name, Last Name, Email, Username and
Password.
NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF08
Requirement priority:
high

Identification of RF03
the
requirement:
Name of the Consult information.
Requirement:
Characteristics: The system will offer the user general information about Academic
Instruction, subjects, Calendar of events.

Description of Consult Academic Instruction: Shows general information

the about the courses that the institution offers, what they
requirement: consist of, duration per academic period.
NON-functional  RNF01
requirement:  RNF02
Priority of the requirement:
high
Identification of RF04
the
requirement:
Name of the Consult information.
Requirement:
Characteristics: The system will offer the user general information about Academic
Instruction, subjects, Calendar of events.

Description of Consult Academic Instruction: Shows general information

the about the courses that the institution offers, what they
requirement: consist of, duration per academic period.
NON-functional  RNF01
requirement:  RNF02
Priority of the requirement:
high

Identification of RF05
the
requirement:
Name of the Consult information.
Requirement:
Characteristics: The system will offer the user general information about Academic
Instruction, subjects, Calendar of events.

Description of Consult Event Calendar: Show users information relevant

the to news or other planned events.
requirement:
NON-functional  RNF01
requirement:  RNF02
Requirement priority:
high

Identification of RF06
the
requirement:
Name of the Modify.
Requirement:
Characteristics: The system will allow the administrator, teacher and
students to modify personal data, subjects created regarding
the teacher and implemented tasks.
Description of Allows the administrator to modify user data, subjects and created
the accounts.
requirement:
NON-functional  RNF01
requirement:  RNF02
 RNF05
Requirement priority:
high

Identification of RF07
the
requirement:
Name of the Virtual Classroom Management.
Requirement:
Characteristics: Allows you to manage information regarding the virtual
classroom.
Description of Create Courses: Allows the teacher, once they have accessed the
the virtual classroom with their account, to create their subject and
requirement: provide relevant information to the students, maintaining active
communication.

NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF06
 RNF07
 RNF08
Priority of the requirement:
high

Identification of RF08
the
requirement:
Name of the Virtual Classroom Management.
Requirement:
Characteristics: Allows you to manage information regarding the virtual
classroom.
Description of Register Student The student must provide their identity card and
the name along with a password to be able to enroll in a subject.
requirement:
o Virtual Classroom: The student must provide their
name along with a password to register in the
system.
o Subject: The student must enter the password
provided by the teacher to be enrolled in the
subject.
NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF06
 RNF07
 RNF08
Priority of the requirement:
high

Identification of RF09
the
requirement:
Name of the Virtual Classroom Management.
Requirement:
Characteristics: Allows you to manage information regarding the virtual
classroom.
Description of Consult courses: allows students to see information about pending
the activities and notes from evaluations carried out.
requirement:
NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF06
 RNF07
 RNF08
Priority of the requirement:
high

Identification of RF010
the
requirement:
Name of the Virtual Classroom Management.
Requirement:
Characteristics: Allows you to manage information regarding the virtual
classroom.
Description of Downloads: Allows students to download guides and information
the relevant to the subjects they are taking only if they are enrolled in
requirement: them.

NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF06
 RNF07
 RNF08
Requirement priority:
high

Identification of RF11
the
requirement:
Name of the Virtual Classroom Management.
Requirement:
Characteristics: Allows you to manage information regarding the virtual
classroom.
Description of Forums: The student will be able to have a discussion and see
the information on a topic determined by the teacher.
requirement:
o It allows user interaction and discussion on topics
previously raised.
o Raising topics about a task or problem to be
developed.
NON-functional  RNF01
requirement:  RNF02
 RNF05
 RNF06
 RNF07
 RNF08
Priority of the requirement:
high

Identification of RF12
the
requirement:
Name of the Component Integration.
Requirement:
Characteristics: The system will have administrative and academic
management.
Description of The inventory component together with Moodle must be
the integrated into the web information system, providing the
requirement: necessary resources, so that the interaction with users is beneficial
in the administration of academic information.

NON-functional  RNF01
requirement:  RNF02
 RNF05
Requirement priority:
high

Identification of RF13
the
requirement:
Name of the Manage Reports.
Requirement:
Characteristics: The system will allow you to generate reports.
Description of Allows the administrator to print reports of the events to be carried
the out or completed, as well as view lists of students by subject and
requirement: active teachers

NON-functional  RNF01
requirement:  RNF02
Requirement priority:
high

Identification of RF14
the
requirement:
Name of the Accredit.
Requirement:
Characteristics: It guarantees students that they have completed the courses
taken through a document.
Description of It allows the administrator and teacher to certify that the student
the participated and completed the course or event for which he or she
requirement: was enrolled.

NON-functional  RNF01
requirement:  RNF02
Priority of the requirement:
high

Identification of RF15
the
requirement:
Name of the System audit
Requirement:
Characteristics: Guarantee solutions to existing problems through the use of
the system.
Description of Evaluate and analyze system processes, proposing solutions to
the existing problems within the system used.
requirement:
NON-functional  RNF03
requirement:  RNF04
 RNF06
 RNF07
 RNF08
Priority of the requirement:
high

Non-Functional Requirements.

Identification of RNF01
the
requirement:
Name of the System interface.
Requirement:
Characteristics: The system will present a simple user interface to make it
easy for system users to use.
Description of The system must have an intuitive and simple user interface.
the
requirement:
Requirement priority:
high

Identification of RNF02
the
requirement:
Name of the Help in using the system.
Requirement:
Characteristics: The user interface must present a help system so that the users of
the system themselves can make their work easier in terms of
managing the system.

Description of The interface must be complemented by a good help system

the (administration may fall to personnel with little experience in using
requirement: computer applications).

Requirement priority:
high

Identification of RNF03
the
requirement:
Name of the Maintenance.
Requirement:
Characteristics: The system must have an installation manual and user manual to
facilitate the maintenance that will be carried out by the
administrator.

Description of The system must have easily updateable documentation that

the allows maintenance operations to be carried out with the least
requirement: possible effort.

Priority of the requirement:

high

Identification of RNF04
the
requirement:
Name of the Interface design to the web feature.
Requirement:
Characteristics: The system must have a user interface, taking into account the
characteristics of the institution's website.

Description of The user interface must adjust to the characteristics of the

the institution's website, within which the process and inventory
requirement: management system will be incorporated.

Priority of the requirement:

high

Identification of RNF05
the
requirement:
Name of the Performance
Requirement:
Characteristics: The system will guarantee users performance regarding the data
stored in the system, offering reliability to it.

Description of Guarantee the performance of the computer system to different

the users. In this sense, the stored information or records made may
requirement: be consulted and updated permanently and simultaneously,
without affecting the response time.

Priority of the requirement:

high

Identification of RNF06
the
requirement:
Name of the User Level
Requirement:
Characteristics: It will guarantee the user access to information according to the
level he or she has.

Description of Facilities and controls to allow access to information to authorized

the personnel through the Internet, with the intention of consulting
requirement: and uploading relevant information for each of them.

Priority of the requirement:

high

Identification of RNF07
the
requirement:
Name of the Continued system reliability.
Requirement:
Characteristics: The system will have to be in operation 24 hours a day, 7
days a week. Since it is a web page designed for data
loading and communication between users.
Description of The availability of the system must be continuous with a
the service level for users of 7 days for 24 hours, guaranteeing
requirement: an adequate scheme that allows for possible failure in any of
its components, having a contingency, generation of alarms.
Priority of the requirement:
high

Identification of RNF08
the
requirement:
Name of the Information security
Requirement:
Characteristics: The system will guarantee users security regarding the
information that is processed in the system.
Description of Guarantee the security of the system with respect to the
the information and data that is handled, such as documents, files and
requirement: passwords.

Priority of the requirement:

high

Common interface requirements

.

User interfaces

The user interface will consist of a set of windows with buttons, lists
and text fields. This must be built specifically for the proposed system
and will be viewed from an internet browser.

Hardware interfaces

It will be necessary to have computer equipment in perfect condition

with the following characteristics:

 Network adapters.
 1.66GHz or higher processor.
 Minimum memory of 256Mb.
 Mouse.
 Keyboard.
 Software interfaces

 Operating System: Windows XP or higher.

 Explorer: Mozilla or Chrome.

Communication interfaces

Servers, clients and applications will communicate with each other,

using standard Internet protocols, whenever possible. For example,
existing protocols (FTP or other convenient ones) must be used to
transfer files or documents.

Functional requirements

Functional requirement 1

 User Authentication: users must identify themselves to access

any part of the system.

 The system can be consulted by any user depending on

the module in which it is located and its level of
accessibility.

Functional requirement 2

 Consult Information: The system will offer the user general

information about Academic Instruction, subjects, Calendar of
events.

 Consult Academic Instruction: Shows general

information about the courses that the institution offers,
what they consist of, duration per academic period.
 Consult Subjects: Allows students to see the assignments
that teachers have published, download guides and
information relevant to the subject and see grades obtained
in evaluations.
 Consult Event Calendar: Show users information relevant
to news or other planned events.

Functional requirement 3
  Register Users: The system will allow the user (student, teacher
and Administrator) to register. The user must provide data such
as: CI, First Name, Last Name, Email, Username and Password.

Functional requirement 4

 Modify: Allows the administrator to modify user data, subjects and

created accounts.

Functional requirement 5

 Manage Virtual Classroom: Allows information regarding the

virtual classroom.
 Create Courses: Allows the teacher, once they have
accessed the virtual classroom with their account, to create
their subject and provide relevant information to the
students, maintaining active communication.
 Register Student: The student must provide their identity
card and name along with a password to be able to enroll in
a subject.
o Virtual Classroom: The student must register by
entering a username along with a password to be able
to enter the system.
o Subject: The student must enter the password
provided by the teacher to be enrolled in the subject.
 Consult courses: Allows students to see information about
pending activities and notes from evaluations carried out.
 Downloads: Allows students to download guides and
information relevant to the subjects they are taking only if
they are enrolled in them.
 Forums: The student will be able to have a discussion and
see information on a topic determined by the teacher.
o It allows user interaction and discussion on topics
previously raised.
o Raising topics about a task or problem to be
developed.
 o Allows you to upload files and documents linked to a
link to download and to have better communication
and interaction between users
o Users who participate in the forum must have
previously registered for the subject.

Functional requirement 6

 Integration of Components: The inventory component together

with Moodle must be integrated into the web information system,
providing the necessary resources, so that the interaction with
users is beneficial in the administration of academic information.

Functional requirement 7

 Manage Reports: Allows the administrator to print reports of the

events to be carried out or completed, as well as view lists of
students by subject, active teachers, among others.

Functional requirement 8

 Accredit: Allows the administrator and teacher to certify that the

student participated and completed the course or event for which
he or she was enrolled.

Functional requirement 9

 Audit: Evaluate and analyze the system processes, proposing

solutions to existing problems within the system used

Non-functional requirements

Performance requirements

 Ensure that the design of queries or other processes does not

significantly affect database performance or network traffic.

Security

 Guarantee the reliability, security and performance of the

computer system to different users. In this sense, the stored
information or records made may be consulted and updated
permanently and simultaneously, without affecting the response
time.
  Guarantee the security of the system with respect to the
information and data that is handled, such as documents, files and
passwords.

 Facilities and controls to allow access to information to authorized

personnel through the Internet, with the intention of consulting and
uploading relevant information for each of them.

Reliability

 The system must have an intuitive and simple user interface

 The user interface must adjust to the characteristics of the

institution's website, within which the process management
system and inventory will be incorporated.

Availability

 The availability of the system must be continuous with a service

level for users of 7 days for 24 hours, guaranteeing an adequate
scheme that allows for possible failure in any of its components,
having a contingency, generation of alarms.

Maintainability

 The system must have easily updateable documentation that

allows maintenance operations to be carried out with the least
possible effort.

 The interface must be complemented by a good help system

(administration may fall to personnel with little experience in using
computer applications).

Portability

 The system will be implemented under the Windows platform.

 BIBLIOGRAPHIES

Mendez, G. (2008). Requirements Specification according to the IEEE 830

standard. Faculty of Informatics, Complutense University of Madrid.
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
Martínez de Morentín Góngora, M. d. Q. (2011). Considerations as a guide based
on IEEE standards for quality and good practices in software development
(Bachelor's thesis).
https://elvex.ugr.es/idbis/db/docs/design/2-requirements.pdf

https://es.slideshare.net/amerino2010/ieee-830