Contenido
Ficha del documento 3
Contenido 4
1. Introducción 5
1.1. Propósito 5
1.2. Alcance 5
1.5. Referencias 6
1.6. Resumen 6
2. Descripción general 6
2.4. Restricciones 8
3. Requisitos específicos
3.3. Prototipos
Artículo I. 1 Introducción
Este documento corresponde a la Especificación de Requerimientos de Software para el
sistema de manejo y administración de un hotel. Esta especificación se ha estructurado
basándose en las directrices dadas por el estándar IEEE Práctica Recomendada para
Especificaciones de Requisitos Software ANSI/IEEE 830, 1998.
Para el desarrollo del programa se analizó posible alcance con respecto a a futuros
proyecto relacionados con el Hotel Malibú. Ahora al tratarse de un software lo que se
espera de este proyecto es que logre unificar la cadena hotelera en una misma, es
decir contar con un programa que permita manipular información de cada uno de las
sedes hoteleras dela franquicia, con esto la cadena hotelera podrá expandir su
mercado y potenciarlo con un sistema que ayude a mejorar los ingresos de la
compañía.
Nombre Descripción
Usuario Persona que usará el sistema para gestionar procesos
SH-1 Sistema Hotelero para la administración de información, cobro
de servicios, reservas del Hotel Malibú Quito
ERS Especificación de Requisitos Software
RF Requerimiento Funcional
RNF Requerimiento No Funcional
FTP Protocolo de Transferencia de Archivos
Moodle Aula Virtual
Para la segunda parte del documento se podrá visualizar la descripción general del
producto, la perspectiva del producto, los usuarios que intervienen en el proceso, las
restricciones, suposiciones y dependencia, además de los datos que van a estar
involucrados en el sistema sin entrar en mucho detalle.
Mientras la tercera parte obtendrá los requerimientos funciones y los no funcionales
que estarán involucrados en el sistema que deben ser incluidos en el sistema.
○ La estructura principal del sistema será de una red local privada, para los
dispositivos de todo el hotel.
○ Como parte de los del producto debe estar implementada una interfaz gráfica
amigable para todos los usuarios involucrados en el sistema.
.
Requerimientos Funcionales.
R 1 Ingresar Empleado
Fuentes Teclado
Precondiciones Ninguna.
Efectos Ninguno.
colaterales
Contactos Ninguno.
Fecha Ninguno.
[Tipo]
R 2. Ingresar Clientes
Fuentes Teclado.
Precondiciones Ninguna.
Pos condiciones Los datos del cliente se usarán para posteriores registros del
cliente en el hotel
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 3. Registrar Pago
Fuentes Teclado
Salidas Información del cliente seguida del total a pagar por los
servicios usados en el hotel.
Confirmación de pago.
Efectos Ninguno.
colaterales
Contactos Ninguno.
Fecha Ninguno.
[Tipo]
R 4. Asignar Habitación
Fuentes Teclado
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 5. Contrato de servicios
Fuentes Teclado
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 6. Eliminar Reserva
Fuentes Teclado
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Fuentes Teclado
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Fuentes Teclado
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Fuentes Teclado
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Entradas Ninguna.
Fuentes Ninguna
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Fuentes Teclado
Restricciones Ninguna.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Fuentes Teclado
Restricciones Ninguna
Precondiciones Ninguna.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
Fuentes Teclado
Pos Ninguna.
condiciones
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
No funcionales
requerimiento:
Nombre del Rapidez
Requerimiento:
Características: Tiempo de actualización de la pantalla: 1 segundo
Descripción del La pantalla debe actualizarse rápidamente para que el servicio no se
requerimiento: vea demorado.
Prioridad del requerimiento:
Alta
Descripción del Para determinar el valor antes planteado requerimos aplicar las
requerimiento: siguiente formula:
𝑛 4
𝑇𝑎𝑠𝑎 = ∗ 10𝑛 = ∗ 104 = 0.04 ∗ 10000 𝑝𝑟𝑢𝑒𝑏𝑎𝑠
𝑛𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 100
“n” representa el número de fallos en un periodo.
Prioridad del requerimiento:
Alta
Prototipos
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
Casos uso
1)
2)
3)
4)
5)
6)
7)
8)
9)
d. ¿Todos los requerimientos evitan conflictos con otros Los requerimientos del administrador
requerimientos? NO y de los recepcionistas tienen
ambigüedades.
b. ¿Se han especificado todas las salidas al sistema/software, No se han especificado todas las
incluyendo su destino, su exactitud, su rango de valores, su salidas necesarias, por ejemplo para
NO
frecuencia y su formato? la confirmación de pagos, creación,
recepción, etc.
d. ¿Se ha realizado el análisis para identificar los requerimientos No se han realizado análisis ya que
que no se han tenido en cuenta? NO aún se necesitan nuevos
requerimientos.
g. ¿Es posible implementar todos y cada uno de los No debido a que aún existen
requerimientos? NO requerimientos ambiguos y que
crean conflictos con otros
n. ¿Se han etiquetado de forma descriptiva todas las figuras, Falto especificación en las tablas de
tablas y diagramas? requerimientos tanto funcionales
como no funcionales, de igual
No
manera en los casos de uso no se
describen los procesos de manera
que no tenga algún inconveniente.
p. ¿Se han definido de forma apropiada todos los términos y las Para algunos requerimientos no
unidades de medición? funcionales se debe justificar la
No
magnitud de la medición, ya que no
se realizó una medida óptima.
a. ¿Los requerimientos evitan la especificación del diseño? Para el diseño de la interfaz del
sistema se requiere igual un análisis
No
y estudio de lo que requiere un
cliente.
b. ¿Se han especificado los requerimientos con un nivel de Falta especificar los requerimientos
detalle consistente? de tal manera que cualquier persona
pueda entenderlos, sin embargo, las
No
especificaciones están un poco
complejas para entender para
cualquier usuario.
d. ¿Algunos de los requerimientos deben ser especificados con Los detalles brindados en cada
menor detalle? No requerimiento son esenciales para
su entendimiento
a. ¿El lenguaje y vocabulario con el que están escritos los Los requerimientos deben detallarse
requerimientos es entendible para los stakeholders? ¿Los usando un vocabulario que sea
No
stakeholders coinciden? entendible para todas las personas
que los leen
b. ¿Cada requerimiento puede ser probado? A partir de pruebas Existen requerimientos un tanto
independientes, ¿puede ser posible determinar cuándo se No abstractos que son difíciles de
satisface cada requerimiento? probar
b. ¿Se ha identificado cada requerimiento con el fin de facilitar Los requerimientos no han sido bien
su referenciación en el futuro desarrollo o en los esfuerzos de No identificados, por lo que es difícil
mejora? referenciarlos
Guiones de pruebas
1. Funcionalidad: Ingresar empleados
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
encontrar la información.
4. En la parte posterior de la ventana se podrá ver
desplegada la información del usuario.
5. Si los datos están correctos se puede cerrar la ventana
caso contrario se reporta como error.
Resultados esperados: 1. Al poder ingresar nombre o cedula se deben notificar si
hay un error en los datos.
2. Cada usuario de tipo empleado debe visualizarse.
3. La información en el programa debe estar actualizada con
la base de datos.
4. Si se encuentra en un error estos deben poder editarse.
5. Si el contrato del empleado caduco ya no debe mostrarse
en el sistema.
Resultados obtenidos: El requerimiento cumple con cada uno de los pasos establecido y
está establecido de forma correcta en el SRS.
Observaciones: El requerimiento cumple con lo planteado en el SRS.
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Resultados obtenidos: En este caso el requerimiento cumple con los pasos planteados y
es funcional ya que realiza la actividad que se necesita.
Observaciones: El requerimiento cumple con lo planteado en el SRS.
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Observaciones: Realizar prototipos acorde a los guiones de prueba para que no se pierda el usuario.
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Nombre Nombre
(Ejecutor de la prueba). (Responsable del proyecto).
Estado:
Concluido Desechado
Diagramas de secuencia
1)
2)
3)
Diagrama de clase
1)
Diagrama de Estado
1)
2)
3)
Estudio de factibilidad
Diseñador 2
Hardware Servidor 2
(a) Servidor en torre
PowerEdge T630
4GB
1TB HD
Impresoras recibos 10
(b) Epson TM-T70II
Series