Especificación de Requisitos IEEE 830 Sistema Aeropuerto

Especificación de requisitos de
software
Proyecto: Sistema de un Aeropuerto (Gestión de
Boletos o tickets)
Enero del 2021

.
Ficha del documento
Fecha Revisión Autores Códigos
Anderson Tufiño 6807

20/01/2021 21/01/2021
Cristhian Romero 6805
Sistema de un Aeropuerto (Gestión de Boletos o tickets)
Pág. 4
Especificación de requisitos de software
Contenido
FICHA DEL DOCUMENTO 3
CONTENIDO 4
1 INTRODUCCIÓN 5
1.1 Objetivos SRS 5
1.2 Ámbito 5
1.3 Definiciones, acrónimos y abreviaturas 6
1.4 Referencias 6
1.5 Visión General 6
2 DESCRIPCIÓN GENERAL 6
2.1 Perspectiva del producto 6
2.2 Funciones del producto 7
2.3 Características de los usuarios 7
2.4 Limitaciones Generales 8
2.5 Supuestos y dependencias 8
3 REQUISITOS ESPECÍFICOS 8
3.1 Requisitos Funcionales 8

3.1.1 Requerimiento Funcional 1 8
3.2.1.2 Requerimientos de Interfases Externas 11
3.2 Requerimientos de Rendimiento 14
3.3 Limitaciones del Diseño 15
3.4 Atributos 15
3.4.1 Seguridad 15
3.4.2 Mantenibilidad 15
3.4.3 Disponibilidad 15
3.4.4 Fiabilidad 15
3.5 Requisitos no funcionales 15
Descripción de requisitos del sofware

Pág. 5
1 Introducción
Este documento es una Especificación de Requisitos Software (ERS) para el Sistema de
un aeropuerto para la gestión de boletos o tickets. Esta especificación se ha estructurado
basándose en las directrices dadas por el estándar IEEE ANSI/IEEE 830, 1998.
El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del desarrollo
de software, puesto que en ella se determinan los “planos” de la nueva aplicación.
En cualquier proyecto software los requisitos son las necesidades del producto que se debe
desarrollar.
Por ello, en la fase de análisis de requisitos se deben identificar claramente estas necesidades
y documentarlas. Como resultado de esta fase se debe producir un documento de
especificación de requisitos en el que se describa lo que el futuro sistema debe hacer.
Por tanto, no se trata simplemente de una actividad de análisis, sino también de síntesis.
Así pues, el documento de especificación de requisitos debe ser legible por el cliente, con lo
que se evita el malentendido de determinadas situaciones, ya que el cliente participa
activamente en la extracción de dichos requisitos.
Basándose en estos requisitos, el ingeniero de software procederá al modelado de la futura
aplicación.
Para ello, se pueden utilizar diferentes tipos de metodologías entre las que destacan la
metodología estructurada y la metodología orientada a objetos.
La metodología estructurada está basada en la represe
1.1 Objetivos SRS

El presente documento tiene como propósito definir las especificaciones funcionales, no
funcionales para el desarrollo de un sistema de un aeropuerto que permitirá gestionar los
boletos o tickets. Esto será utilizado por los administradores, azafatas y técnicos.
 Ayudar a los clientes a describir claramente lo que se desea obtener mediante un

determinado sistema implantado en un aeropuerto.
 Establecer una base para los administradores, técnicos y azafatas en el uso de un
sistema estándar para la gestión de los boletos de un cliente o pasajero.
1.2 Ámbito
Esta especificación de requisitos está dirigida al administrador del sistema, para continuar
con el desarrollo del sistema sobre un aeropuerto y para profundizar en la automatización de
ésta, la cual tiene por objetivo principal el gestionar los boletos o tickets.
Este sistema no servirá para que un pasajero reserve un vuelo en un determinado

aeropuerto, únicamente se agendará su boleta cuando lo haya registrado en el sistema o lo
haya comprado.

Pág. 6
1.3 Definiciones, acrónimos y abreviaturas
Nombre Descripción
Usuario Persona que usará el sistema para gestionar procesos
SIS-I Sistema de Información para la Gestión de boletos.
ERS Especificación de Requisitos Software
RF Requerimiento Funcional
RNF Requerimiento No Funcional
FTP Protocolo de Transferencia de Archivos
AFA Aeropuerto Internacional
1.4 Referencias
Titulo del Documento Referencia

Standard IEEE 830 - 1998 IEEE
1.5 Visión General

Este documento consta de tres secciones.
En la primera sección se realiza una introducción y se proporciona una visión general de la

especificación de recursos del sistema.
En la segunda sección del documento, se realiza una descripción general del sistema, con
el fin de conocer las principales funciones que éste debe realizar, los datos asociados y los
factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en
excesivos detalles.
Por último, la tercera sección del documento es aquella en la que se definen

detalladamente los requisitos que debe satisfacer el sistema.
2 Descripción general
2.1 Perspectiva del producto

El sistema del aeropuerto para la gestión de boletos, será un producto diseñado para
trabajar en una aplicación WEB, lo que permitirá su utilización de forma rápida y eficaz,
además se podrá dar la opción de integrar conjuntamente con un dispositivo móvil, para
lograr una mejor respuesta.

Pág. 7
2.2 Funciones del producto
2.3 Características de los usuarios
Tipo de Usuario Usuario

Formación Conocimientos básicos de informática
Habilidades Manejo de computadora y sistema de información
Actividades Realizar operaciones de emisión de tickets y control de la
información de los clientes y otros argumentos.
Tipo de Usuario Gerente

Formación Conocimientos solidos de informática tercer o cuarto nivel
Habilidades Manejo de computadora y sistema de información
Actividades Analizar, Generar, Modificar y tomar decisiones en función de
los reportes que genere el sistema

Pág. 8
Tipo de Usuario Técnicos en sistemas o Operadores

Formación Conocimientos básicos de informática y analista en sistemas
informáticos
Habilidades Conocimientos en programación y bases de datos, hardware del
computador y redes LAN
Actividades Realizar mantenimiento de los equipos, revisar, evaluar las
condiciones que se dan en el sistema y las redes de las
mismas.
2.4 Limitaciones Generales

 Interfaz para ser usada con internet.
 Uso de Dominio (X)
 Lenguajes y tecnologías en uso: HTML, C#, JAVA.
 El sistema debe ser desarrollado con Modelos Ágiles.
 El sistema se diseñará según un modelo cliente/servidor.
 El sistema deberá tener un diseño e implementación sencilla, independiente de la
 plataforma o del lenguaje de programación.
.
2.5 Supuestos y dependencias

 Se asume que los requisitos aquí descritos son estables y confiables.
 Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos
mínimos de Hardware esto para garantizar una ejecución correcta de la misma.
3 Requisitos específicos
3.1 Requisitos Funcionales
3.1.1 Requerimiento Funcional 1
Número de requisito RF1

Nombre de requisito Permitir la autenticación de los usuarios.
Tipo Requisito Restricción
Fuente del requisito Usuario Campos: Usuario y Contraseña
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
3.1.1.1 Especificaciones
3.1.1.1.1 Introducción
El sistema debe permitir el ingreso del nombre y contraseña del usuario para
realizar las diferentes funciones que tendrá cada uno.

Pág. 9
3.1.1.1.2 Entradas
Cedula, Nombres, Apellidos, Contraseña, Tipo de Usuario (Técnico, Usuario,
Gerente).
3.1.1.1.3 Proceso
El sistema pedirá la correspondiente identificación como administrador. Nos
ubicamos en la parte de Administrar del menú principal y escogemos Usuario. El
sistema pedirá los correspondientes datos del nuevo usuario luego verificara que
no haya espacios en blanco, en el caso de ningún error guardara los datos del
nuevo usuario.
3.1.1.1.4 Salidas
Las salidas van dirigidas al Gerente.
 Mensaje de error en el caso de no haber llenado algún campo.
 Mensaje de error en el caso de ingresar un numero de cedula ya existente en la
base de datos
 Mensaje de error en casos de ingresar incorrectamente los datos es decir que el
formato de los datos sea incorrecto.

Nombre de requisito Permitir la gestión (crear, modificar, eliminar) de tipos, usuarios,
clientes.
Fuente del requisito Usuario, Clientes, Gerente
El sistema debe permitir gestionar es decir crear, modificar y eliminar las cuentas
de tipos, usuarios, clientes.
3.1.1.2.2 Entradas
Cedula, Nombres, Apellidos, Tipo de Usuario, Dirección, Teléfono. (Técnico,
Usuario, Gerente).
3.1.1.2.3 Proceso
Para cumplir con este requerimiento se le presentara una sola pantalla donde el
sistema pedirá la correspondiente identificación como administrador. Nos
ubicamos en la parte de Administrar del menú principal y escogemos Usuario El
sistema pedirá los correspondientes datos del nuevo usuario, cliente o tipo luego
verificara que no haya espacios en blanco, en el caso de ningún error guardara
los datos del nuevo usuario. En este mismo formulario podrá crear, modificar y
guardar.

Pág. 10
3.1.1.2.4 Salidas
Las salidas van dirigidas al Gerente.
 Mensaje de error en el caso de ingresar un numero de cedula ya existente o mal
Ingresada, ya que eso se ve en la base de datos.
 Mensaje de error al eliminar una cuenta, ya que no se permite eliminaciones en
cascada.

Nombre de requisito Permitir la gestión (crear, modificar, eliminar) de tipos de
pasajeros o tipos de aviones
Fuente del requisito Usuario, Cliente.
El sistema debe permitir gestionar las clases de aviones es decir, crear, modificar
y eliminar los tipos de pasajeros o tipos de aviones.
3.1.1.3.2 Entradas
Número de Asiento, Clase de Vuelo, Cedula, Nombres, Apellidos, Dirección,
Teléfono.
3.1.1.3.3 Proceso
sistema pedirá la correspondiente identificación como administrador. Nos
ubicamos en la parte de Administrar del menú principal y escogemos Usuario El
sistema pedirá los correspondientes datos del nuevo usuario, cliente o tipo luego
verificara que no haya espacios en blanco, en el caso de ningún error guardara
los datos del nuevo usuario. En este mismo formulario podrá crear, modificar y
guardar.
3.1.1.3.4 Salidas
Las salidas van dirigidas al Gerente, Usuario.
 Mensaje de error en el caso de ingresar un número de asiento o clase de vuelo
ya existente o mal ingresado en la base de datos.
 Mensaje de error al eliminar un número de asiento o clase de vuelo ya que no
se permite eliminaciones en cascada.

Pág. 11

Nombre de requisito Emitir reportes de: tablas de vuelos
Fuente del requisito BD Tabla: Ventas, Amortización
El sistema debe emitir reportes de Tablas de vuelos.
3.1.1.4.2 Entradas
Origen, Destino, Id avión, Id vuelo, Hora de llegada, Hora de salida.
3.1.1.4.3 Proceso
sistema pedirá la correspondiente identificación como Gerente para efectuar la
tarea. Nos ubicamos en la parte de “Reportes”. Para realizar esta operación debe
ingresar el número de cedula o pasaporte. La salida de los reportes es en los
siguientes formatos pdf, html, cvs. Y con opción a imprimir.
3.1.1.4.4 Salidas
Las salidas van dirigidas a: Gerente, Usuario.
 Mensaje de aviso: operaciones efectuadas satisfactoriamente.
 Mensaje de error: en el caso de no haber llenado algún campo.
 Mensaje de error: en casos de ingresar incorrectamente los datos es decir que el
3.2.1.2 Requerimientos de Interfases Externas
3.1.1.2.1 Interfases de Usuario

Las interfaces de usuario están relacionadas con las pantallas, ventanas
(formularios) que debe manipular el usuario para realizar una operación
determinada. Dicha manipulación el usuario la realizará por medio del teclado y
el mouse (ratón).
Es fundamental nombrar que las interfaces de cliente además abarcan las
ayudas que corresponden en todos los procesos que haga el sistema.
Las interfaces de usuario ayudaran hacer un trabajo, en un ambiente, por lo cual
se dichas interfaces incluirán:
• Botones
• Menús despegables
• Mensajes informativos
• Mensajes de error
• Cuadros de diálogo
• Cuestionarios para el ingreso, modificación, actualización y supresión de
datos. Así como para las operaciones y las ayudas que se comentó previamente.
• Otros

Pág. 12
A continuación, se muestra una previa de lo cual va a ser las interfaces de usuario.

El usuario a cargo del sistema debería tener su cuenta en el sistema para lograr
entrar.
En caso de que no ingrese de manera correcta el Usuario o la Contraseña se

desplegara un mensaje de datos incorrectos. Como a continuación se muestra.
A continuación, se muestra una previa de lo cual va a ser las interfaces de usuario,

Clientes, tipos. El sistema debe permitir gestionar es decir crear, modificar y eliminar las
cuentas de tipos, usuarios, clientes.

Pág. 13
En caso de que no ingrese de manera correcta la información requerida se

A continuación se muestra una previa de lo cual va a ser las interfaces de usuario,

Clientes , tipos. El sistema debe permitir gestionar las clases de aviones es decir,
crear, modificar y eliminar los tipos de pasajeros o tipos de aviones.


Pág. 14
A continuación, se muestra una previa de lo cual va a ser las interfaces de usuario,

Gerente. El sistema debe emitir reportes de vuelos.

3.1.1.2.2 Interfases de Hardware
Pantalla del monitor: El programa tendrá que demostrar información al

cliente por medio de la pantalla del monitor
Mouse: El programa debería interactuar con el desplazamiento del mouse y los
botones respectivamente.
El mouse se activan las regiones de entrada de datos, botones de comando y
seleccione las posibilidades de los menús.
Teclado: El programa deberá interactuar con las pulsaciones del teclado.
El teclado de entrada de datos en el área activa de la base de datos.
Impresora: El programa imprimirá los reportes en la impresora instalada.
3.1.1.2.3 Interfases de Software

Ninguno
3.1.1.2.4 Interfases de Comunicación

Ninguno
3.2 Requerimientos de Rendimiento

La infraestructura de red, así como sus terminales tienen que llevar a cabo con
reglas de acuerdo con la IEEE en la manera de conexión a los conjuntos, para tener
tiempos de contestación mínimos.

Pág. 15
3.3 Limitaciones del Diseño
 El sistema deberá seguir el diseño establecido, no debe existir modificaciones.

 El diseño deberá ser lo más simple e intuitivo posible.
 Diseño fácil de usar.
3.4 Atributos
3.4.1 Seguridad
 Registros de ingreso al sistema.

 Uso de contraseñas para cada usuario (Gerente, Usuario, Cliente). Esto
dejará que tengan ingreso al sistema solo los individuos que poseen
autorización.
 Creación de usuarios y clientes, asignarlos a cada uno dependiendo su
funcionalidad dentro del sistema.
3.4.2 Mantenibilidad
 El sistema cuenta con propiedades parametrizables lo cual dejará

futuros mantenimientos.
 O sea, cada 3 meses se va a hacer un mantenimiento preventivo,
delegado de realizarlo permanecen los desarrolladores.
3.4.3 Disponibilidad
 El sistema deberá estar disponible todos los días laborables para

garantizar que los procesos se cumplan a cabalidad.
 El sistema ha sido desarrollado tomando en cuenta las necesidades,
requerimientos, reglas, política, misión, objetivos etc.
3.4.4 Fiabilidad
 Confianza al usuario y al cliente, para lo que el sistema está

controlando toda clase de información y está apto a responder toda
clase de incidente.
3.5 Requisitos no funcionales
 Registro de datos en el sistema

 No tener antecedentes penales
 Costo de licencia de producto basado al número de usuarios que se conecten
 Espacio físico para un manejo adecuado y libre
 Cuenta bancaria legal

Especificación de Requisitos IEEE 830 Sistema Aeropuerto

Cargado por

Copyright:

Formatos disponibles

Especificación de Requisitos IEEE 830 Sistema Aeropuerto

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Especificación de Requisitos IEEE 830 Sistema Aeropuerto

Cargado por

Copyright:

Formatos disponibles

Especificación de requisitos de

Enero del 2021

Fecha Revisión Autores Códigos

Anderson Tufiño 6807

1.1 Objetivos SRS 5

1.3 Definiciones, acrónimos y abreviaturas 6

1.5 Visión General 6

2.1 Perspectiva del producto 6

2.2 Funciones del producto 7

2.3 Características de los usuarios 7

2.4 Limitaciones Generales 8

2.5 Supuestos y dependencias 8

3.1 Requisitos Funcionales 8

3.2 Requerimientos de Rendimiento 14

3.3 Limitaciones del Diseño 15

3.5 Requisitos no funcionales 15

Descripción de requisitos del sofware

La metodología estructurada está basada en la represe

1.1 Objetivos SRS

 Ayudar a los clientes a describir claramente lo que se desea obtener mediante un

Este sistema no servirá para que un pasajero reserve un vuelo en un determinado

Descripción de requisitos del sofware

1.3 Definiciones, acrónimos y abreviaturas

Titulo del Documento Referencia

1.5 Visión General

En la primera sección se realiza una introducción y se proporciona una visión general de la

Por último, la tercera sección del documento es aquella en la que se definen

2.1 Perspectiva del producto

Descripción de requisitos del sofware

2.2 Funciones del producto

2.3 Características de los usuarios

Tipo de Usuario Usuario

Tipo de Usuario Gerente

Descripción de requisitos del sofware

Tipo de Usuario Técnicos en sistemas o Operadores

2.4 Limitaciones Generales

2.5 Supuestos y dependencias

3.1 Requisitos Funcionales

3.1.1 Requerimiento Funcional 1

Número de requisito RF1

Descripción de requisitos del sofware

3.1.2 Requerimiento Funcional 2

Número de requisito RF2

Descripción de requisitos del sofware

3.1.3 Requerimiento Funcional 3

Número de requisito RF3

Descripción de requisitos del sofware

3.1.4 Requerimiento Funcional 4

Número de requisito RF4

3.2.1.2 Requerimientos de Interfases Externas

3.1.1.2.1 Interfases de Usuario

Descripción de requisitos del sofware

A continuación, se muestra una previa de lo cual va a ser las interfaces de usuario.

En caso de que no ingrese de manera correcta el Usuario o la Contraseña se

A continuación, se muestra una previa de lo cual va a ser las interfaces de usuario,

Descripción de requisitos del sofware

En caso de que no ingrese de manera correcta la información requerida se

A continuación se muestra una previa de lo cual va a ser las interfaces de usuario,