Especificación de requisitos de

software
Proyecto: AeroGlobal
Revisión 1.0
 Ficha del documento

Fecha Revisión Autor Verificado dep. calidad.

02/05/2019 1.0 Angelica Maria Peña Espinal

Documento validado por las partes en fecha: 05/05/2019

Contenido

Ficha del documento 2

Contenido 3
1 INTRODUCCIÓN ....................................................................................................................... 6 3
2 DESCRIPCIÓN GENERAL ........................................................................................................ 7 3
3 REQUISITOS ESPECÍFICOS .................................................................................................... 7 3
3.1 Requisitos comunes de los interfaces ................................................................................ 8 3
3.2 Requisitos funcionales ......................................................................................................... 8 4
3.3 Requisitos no funcionales .................................................................................................... 9 4
1 introducción 5
1.1 Propósito 5
1.2 Alcance 5
1.3 Personal involucrado 5
1.4 Definiciones, acrónimos y abreviaturas 6
1.5 Resumen 7
2 Descripción general 7
2.1 Perspectiva del producto 7
2.2 Funcionalidad del producto 7
2.3 Restricciones 8
3 Requisitos específicos 8
3.1 Requisitos comunes de los interfaces 8
3.1.1 Interfaces de usuario 8
3.1.2 Interfaces de hardware 10
3.1.4 Interfaces de comunicación 10
3.2 Requisitos funcionales 10
3.2.1 Requisito funcional 1 10
3.2.2 Requisito funcional 2 11
3.2.3 Requisito funcional 3 11
3.2.4 Requisito funcional 4 12
3.3 Requisitos no funcionales 12
3.3.1 Requisitos de rendimiento 12
3.3.2 Seguridad 13
3.3.3 Fiabilidad 13
3.3.4 Disponibilidad 13
3.3.5 Mantenibilidad 13
1 introducción
La presente Especificación de requerimientos de software (SRS) del sistema a construir
surge para ser un conjunto de información necesaria que ayuda a los
desarrolladores del software a analizar y entender todos los requisitos y
requerimientos que nuestro cliente desea , de la misma forma como este constituye
un informe útil para que el cliente del producto final describa lo que el realmente
desea obtener, y de esta manera lograr tener un documento necesario cuya
información en el futuro servirá para el desarrollo del software, es decir en la
codificación correcta del mismo.

Se describe en forma detallada las interfaces de usuario, de software, del hardware y

comunicaciones, así como de los requerimientos del cliente, atributos del sistema
entre otros.

1.1 Propósito
◦ Permitir establecer las bases de acuerdo entre usuarios en lo que al proyecto de
software se refiere.
• Ayudar a los usuarios finales del software a entender exactamente qué es lo que el
cliente de software desea.

1.2 Alcance
• Identificación del producto de software “AeroGlobal”
• Objetivos del Sistema
• Permitir a los usuarios poder comprar sus vuelos.
• Administrar sus vuelos.
• Registro de usuarios.
• Login de usuarios.

1.3 Personal involucrado

Nombre Erica Ross
Rol Programador
Categoría Analista
profesional
Responsabilidad Programar los módulos del sistema
es
Información de Ergerica76@gmail.com
contacto
Aprobación

Nombre Julio Pereyra

Rol Gestor de proyecto
Categoría Analista
profesional
 Responsabilida Diseño de la arquitectura del sistema
d es
Información de julio_martinez25@live.com
contacto
Aprobación

Nombre Alan Hosking

Rol Diseñador de base de datos
Categoría Analista
profesional
Responsabilida Diseño de la base de datos
d es
Información de alanhoskingrivera@gmail.com
contacto
Aprobación

Nombre Angelica Maria Peña

Rol Analista de requerimientos
Categoría Analista
profesional
Responsabilida Analisis y especificación de requerimientos
d es
Información de angelicamariapena014@gmail.com
contacto
Aprobación

1.4 Definiciones, acrónimos y abreviaturas

SRS​: ​La especificación de requisitos de software (ERS) es una descripción completa del
comportamiento del sistema que se va a desarrollar. Incluye un conjunto de ​casos
de uso​ que describe todas las interacciones que tendrán los usuarios con el
software. Los casos de uso también son conocidos como ​requisitos funcionales​.
IEEE​: ​Es una asociación mundial de ingenieros dedicada a la ​estandarización​ y el desarrollo
en áreas técnicas. Con cerca de 425 000 miembros y voluntarios en 160 países, es
la mayor asociación internacional sin ánimo de lucro formada por profesionales de
las nuevas tecnologías, como ​ingenieros electricistas​, ​ingenieros en
electrónica​, ​científicos de la computación​, i​ ngenieros en computación​, matemáticos
aplicados, ​ingenieros en biomedicina​, ​ingenieros en telecomunicación​, i​ ngenieros en
mecatrónica​, ​ingenieros en telemática​, ​ingenieros sociales​, ​cibernéticos​, ​ingenieros
de sistemas​, ​ingenieros en software​, etc.
Base de datos​: ​Es una colección de información organizada de forma que un programa de
ordenador pueda seleccionar rápidamente los fragmentos de datos que necesite.
Una base de datos es un sistema de archivos electrónico.
Mongo: E​s un sistema de ​base de datos​ ​NoSQL​ orientado a documentos, desarrollado bajo
el concepto de ​código abierto​.
JDBC: ​Es una ​API​ que permite la ejecución de operaciones sobre ​bases de datos​ desde
el ​lenguaje de programación Java​, independientemente del sistema operativo donde
se ejecute o de la base de datos a la cual se accede, utilizando el dialecto SQL del
modelo de base de datos que se utilice.
PayPal: ​E​s una ​empresa​ estadounidense que opera en casi todo el mundo un sistema de
pagos ​en línea​ que soporta transferencias de dinero entre usuarios y sirve como una
alternativa electrónica a los métodos de pago tradicionales como ​cheques​ y g ​ iros
postales​. PayPal es una de las mayores compañías de pago por Internet del mundo.

1.5 Resumen
El SRS está compuesto de la siguiente manera:

​Introducción​: ​En esta sección se detalla los objetivos que tiene el SRS y de
nuestro sistema en forma general.
​Descripción General​: Describe una perspectiva general del producto a
desarrollarse, como también las características del usuario y las limitaciones
que podría tener.
​Requerimientos Específicos​: Muestra paso a paso todos los requerimientos que
el usuario desea en el producto final. Para el cual se ha utilizado el “Prototipo 2
del Estándar IEEE 830”.

2 Descripción general
2.1 Perspectiva del producto
El sistema que se va a desarrollar es independiente, y tendrá un diseño modular para
gestionar los vuelos de diferentes aerolíneas sin ninguna preferencia.
 2.2 Funcionalidad del producto

2.3 Restricciones
1. Se utilizará JavaScript como tecnología de trabajo para el proyecto.

2. Se programará una API para el manejo de funcionalidades cross-platform y reusabilidad

del código más eficiente.

3. Se utilizará un témplate preferiblemente en React.js para la elaboración del front end y

reusabilidad de componentes cross-platform.

4. Se utilizará mongo para el manejo de la base de datos.

2.4 Suposiciones y dependencias

Ninguno.

2.5 Evolución previsible del sistema

Airport Maps: ​Funcionalidad que permitirá al usuario tener un mapa del

aeropuerto que se encuentra actualmente.
Track Fly: Funcionalidad del sistema que notificara al usuario al momento de encontrar
un vuelo de oportunidad.

News: Funcionalidad del sistema que mantendrá al usuario informado de todas las
novedades del mercado.

3 Requisitos específicos
R1: Permitir la autenticación de los usuarios.
R2: Permitir a los usuarios poder registrarse al sistema.
R3: Permitir a los usuarios realizar sus compras de los vuelos.
R4: Permitir a los usuarios visualizar con detalles los vuelos comprados.

3.1 Requisitos comunes de los interfaces

3.1.1 Interfaces 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.

Es importante mencionar que las interfaces de usuario también abarcan las ayudas
correspondientes en cada uno de los procesos que realice el sistema.

Las interfaces de usuario ayudarán al usuario final trabajando en un ambiente Form, por lo
que se dichas interfaces incluirán:
• Botones
• Menús despegables
• Mensajes informativos
• Mensajes de error
• Cuadros de diálogo

A continuación, se muestra una previa de lo que será las interfaces de usuario. El usuario
previamente debe tener su cuenta de usuario en el sistema para poder
acceder.
 3.1.2 Interfaces de hardware
La pantalla del smartphone. - El software deberá mostrar información al usuario a través
de la pantalla del celular.

3.1.4 Interfaces de comunicación

La interfaz de comunicación entre el servidor de base de datos MongoDB y la aplicación
desarrollada en JavaScript se lo realiza mediante JDBC.

3.2 Requisitos funcionales

3.2.1 Requisito funcional 1

Número de requisito RF1

Nombre de requisito Permitir la autenticación de los usuarios.
Tipo Requisito Restricción

Fuente del requisito BD Tabla: Usuario Campos: Usuario y Contraseña

Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

INTRODUCCION
El sistema debe permitir el ingreso del nombre y contraseña del usuario.

ENTRADAS
Usuario, contraseña.

PROCESOS

Simplemente se debe acceder al sistema. Este nos mostrara una pantalla con dos campos a
llenar que son: Usuario y contraseña. Como usuario simplemente debemos
llenar con los datos anteriormente ingresados en el apartado del registro para
así el sistema darnos acceso.

SALIDAS
Mensaje de error en el caso de no haber llenado algún campo.
Mensaje de error en el caso de ingresar un usuario incorrecto.
Mensaje de error en casos de ingresar incorrectamente los datos es decir que el formato de
los datos sea incorrecto.

3.2.2 Requisito funcional 2

Número de requisito RF2

Nombre de requisito Permitir a los usuarios poder registrarse al sistema.
Tipo Requisito Restricción

Fuente del requisito BD Tabla: Usuario.

Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

INTRODUCCION
El sistema debe permitir a los usuarios registrarse al sistema.
ENTRADAS
Nombres, apellido, usuario, contraseña, edad.

PROCESOS
Para cumplir con este requerimiento se le presentará una sola pantalla donde el sistema
pedirá la correspondiente identificación. El sistema pedirá los correspondientes
datos del nuevo usuario, verificará que no haya espacios en blanco, en el caso
de ningún error guardará los datos del nuevo usuario.

SALIDAS
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 formato de
los datos sea incorrecto.

3.2.3 Requisito funcional 3

Número de requisito RF3

Nombre de requisito Permitir a los usuarios realizar sus compras de los vuelos.
Tipo Requisito Restricción

Fuente del requisito BD Tabla: Vuelos.

Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

INTRODUCCION
El sistema debe permitir a los usuarios poder realizar sus vuelos de una manera sencilla.

ENTRADAS
Punto de partida, Punto de destino, asiento, tipo de clase, cupones promocionales y
números de pasajeros

PROCESOS
Para cumplir con este requerimiento se le presentará una pantalla divida en tres secciones
opcionales las cuales son: Round-Trip, One-Way, Multi-City, donde el sistema
pedirá la correspondiente información para efectuar la tarea. El sistema pedirá
los correspondientes datos al cliente, el mismo que verificará los datos
ingresados a la base de datos.

SALIDAS
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 formato de
los datos sea incorrecto.

3.2.4 Requisito funcional 4

Número de requisito RF4

Nombre de requisito Permitir a los usuarios visualizar con detalles los vuelos
comprados.
Tipo Requisito Restricción
 Fuente del requisito BD Tabla: Usuario, Vuelos.
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

INTRODUCCION
El sistema debe permitir a los usuarios poder visualizar todos sus vuelos comprados.

ENTRADAS
Esta pantalla no tiene entradas.

PROCESOS
Para cumplir con este requerimiento se le presentará una sola pantalla donde el sistema
mostrara únicamente todos los vuelos que el usuario logueado al sistema tiene
comprado.

SALIDAS
Lista de todos los vuelos comprados.

3.3 Requisitos no funcionales

3.3.1 Rendimiento

o Número de usuarios simultáneos:

El número de usuarios que se espera que van a interactuar oscila entre 20,000 – 30,000
diarios.

3.3.2 Seguridad
La seguridad del sistema es por:
▪ Uso de contraseñas para cada usuario. Esto permitirá que tengan
acceso al sistema solo las personas que tienen autorización.
▪ Registros de ingreso al sistema.

3.3.3 Fiabilidad
Es uno de los factores que dará confianza al cliente, para lo cual el sistema estará
controlando todo tipo de transacción utilizando el servicio de PayPal y está
apto a responder todo tipo de incidente.

3.3.4 Disponibilidad
El sistema ha sido desarrollado tomando en cuenta las necesidades, requerimientos, reglas,
política, misión, objetivos, etc. De las agencias de viaje, por lo que se
encuentra disponible el 99% del tiempo del día.

3.3.5 Mantenibilidad
El sistema cuenta con características parametrizables lo que permitirá futuros
mantenimientos. Es decir, cada tres meses se va a realizar un mantenimiento
preventivo, encargado de hacerlo están los desarrolladores.
.
Diagrama De EVENTOS
​