Documentacion Final Srs

Especificación de requisitos de software
Proyecto: Sistema Hotelero para la administración de

información, cobro de servicios, reservas del Hotel
Malibú Quito.
Junio del 2015

Sistema Hotelero para la administración de información,
Cobro de servicios, reservas del Hotel Malibú Quito. Pág. 2
Ficha del documento
Fecha Revisión Autor Verificado dep. Calidad.
17/06/2015 Alejandro Bejarano

David Ruano
Matthaeus Marten
Documento validado por las partes en fecha:
Por la comunidad Por la universidad
Hotel Malibú Quito Universidad de las Américas
Descripción de requisitos del software

Contenido
Ficha del documento 3
Contenido 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. Referencias 6
1.6. Resumen 6
2. Descripción general 6
2.1. Perspectiva del producto 6
2.2. Funcionalidad del producto 7
2.3. Características de los usuarios 7
2.4. Restricciones 8
2.5. Suposiciones y dependencias
3. Requisitos específicos
3.1. Requisitos Funcionales
3.2. Requisitos No Funcionales
3.3. Prototipos
3.4. Casos de Uso
3.5. Checklist de verificación
3.6. Guiones de prueba
3.7. Diagramas de secuencia
3.8. Diagramas de clase
3.9. Diagramas de estado

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.
Sección 1.01 1.1 Propósito
Para este documento el principal propósito es definir los requerimientos funcionales,

los no funciones, y los individuos involucrados en el sistema hotelero el cual tiene
varias especificaciones que deben ser definidas en el documento, de tal manera que
se pueden evidenciar en el producto final que es el sistema funcional, también debe
estar orientado para que pueda ser leído por cualquier persona que desee informarse
con respecto al software.
Sección 1.02 1.2 Alcance
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.
Sección 1.03 1.3 Personal involucrado
Nombre Alejandro Bejarano
Rol Analista, diseñador y programador
Categoría Profesional TSU-Informática
Responsabilidad Análisis de información, diseño y programación del SIS-I
Información de contacto dbejarano@udlanet.ec

Nombre David Ruano
Información de contacto druano@udlanet.ec
Nombre Matthaeus Marten
Información de contacto mmarten@udlanet.ec
Sección 1.04 1.1 Definiciones, acrónimos y

abreviaturas
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
Sección 1.05 1.2 Referencias
Titulo del Documento Referencia

Standard IEEE 830 - 1998 IEEE

Sección 1.06 1.3 Resumen
El siguiente documento cuenta con 3 secciones. para la primera sección se realiza

una introducción del documento, con partes del sistema cuenta, terminología que se
va usar, en si muestra una visión general de lo que abarca principalmente el
programa, con sus respectivas descripciones para que sea comprendido por el
cliente.
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.
Artículo II. 2 Descripción general
Sección 2.01 2.1 Perspectiva del producto

El producto presentado se desarrollará en una interfaz gráfica que está diseñado
para ser utilizado en un ordenador, el cual estará conectado en una red local en el
que se manipulara la información del Hotel, esto hará que se cuente con una base de
datos disponible para que sea actualizada por el servidor.
Sección 2.02 2.2 Funcionalidad del producto

Sección 2.03 2.3 Características de los usuarios

Tipo de usuario Administrador del sistema
Formación TSU en Informática
Actividades Control y manejo del sistema en general
Tipo de usuario Gerente de Recepción

Formación Administración Hotelera
Actividades Define las funciones de cada empleado, y
supervisa todo la administración en general
Tipo de usuario Supervisor de recepción

Formación Talento humano, especialidad en recursos
humanos
Actividades Supervisa a los recepcionistas para que realicen
correctamente su trabajo.
Tipo de usuario Recepcionista

Formación Recepcionista, secretaria
Actividades Toma la información del cliente, se relacionan
directamente con el cliente.
Tipo de usuario Cliente

Formación NA
Actividades Proporciona de información al recepcionista
para que esta sea guarda en el sistema.
Sección 2.04 2.4 Restricciones

○ Para su funcionamiento óptimo se requiere que conste con los SO base ya
sea MS Windows, IOS o Linux.
○ EL lenguaje de programación que se usara es Java, y en cuanto al manejo
de la base de datos se realiza en My SQL.
○ Se debe contar con servidores estables que atiendan a varios terminales
conectados al mismo tiempo y que puede desenvolverse correctamente.

○ 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.
.
Sección 2.05 2.5 Suposiciones y dependencias
● Las restricciones antes planteadas deben ser cumplidas para que el

funcionamiento del sistema sea óptimo.
● Al ser una compañía que brinda un servicio debe contar con los permisos de
facturación brindados por el Servicio de Rentas Internas, el sistema
despliega una plantilla certificada la cual permite imprimir facturas.
● Se trata de un servicio que se enfoca principalmente al turismo, es por eso
que debe contar con un registro de actividad turística.
● Se debe emitir un reporte de huéspedes diario para consultar actividades, los
organismos que podrían solicitarlos son:
○ Intendencia General de Policía.
○ Dirección Provincial de Salud.
○ Policía Técnica Judicial.
○ Migración.
○ Dirección Nacional de Investigación.
○ Seguridad Pública.
○ INTERPOL.
● Se debe tener un rol de pagos a todos los empleados, con su respectiva
fecha y cantidad todo esto que haya está establecido antes en un contrato.
Artículo III. 3 Requisitos específicos
Requerimientos Funcionales.
R 1 Ingresar Empleado
Función Registro de los empleados del hotel
Descripción El administrador del hotel ingresa la información de los

nuevos empleados al sistema.
Entradas Datos Personales: Nombres, apellidos, teléfono, dirección,

número de cédula, correo electrónico, sexo, cargo a
desempeñar, discapacidad
Fuentes Teclado
Salidas Aviso de confirmación de guardado en el sistema
Proceso En un formulario el administrador del hotel ingresa los datos

de los nuevos empleados del hotel.
Restricciones Deben existir validaciones correctas para evitar ingresar

datos no válidos.
El empleado debe contar con un contrato al día
Precondiciones Ninguna.
Pos condiciones La información del empleado se registra, el sistema del hotel

puede usar esta información para el registro de roles de
pagos.
Efectos Ninguno.
colaterales
Contactos Ninguno.
Fecha Ninguno.
[Tipo]
R 2. Ingresar Clientes
Función Registro de los clientes en una lista de clientes
Descripción El recepcionista del hotel ingresa los datos de un nuevo

cliente al sistema.
Entradas Datos Personales: Nombres, Apellidos, teléfono casa,

dirección casa, C.I., Currículo (hoja de vida)
Fuentes Teclado.
Salidas Confirmación de registro exitoso.
Proceso Se despliega un formulario en el cual el recepcionista

ingresará los datos iniciales de registro del cliente. Una vez
realizado este proceso los datos del cliente se almacenan
para futuros procesos
Restricciones La CI se deberá ingresar correctamente ya que se la

verifica.
No pueden existir dos clientes con la misma cédula.

Pos condiciones Los datos del cliente se usarán para posteriores registros del
cliente en el hotel
Efectos El cliente se registra en las listas del hotel

colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 3. Registrar Pago
Función Pago de servicios
Descripción Asigna un valor a la lista de pagos de un cliente.
Entradas Datos del cliente: nombres, apellidos, número de cédula,

tipo de servicio contratado, valor a pagar.
Fuentes Teclado
Salidas Información del cliente seguida del total a pagar por los
servicios usados en el hotel.
Confirmación de pago.
Proceso El empleado ingresa la información del cliente, el sistema

despliega la información del cliente y el costo de los
servicios.
Se registra la información del pago
Restricciones Se debe tener ingresada la información del cliente en el

sistema.
Precondiciones Ingreso de la información del cliente.

Pos condiciones Se registra el pago del cliente.
Efectos Ninguno.
colaterales
Contactos Ninguno.
Fecha Ninguno.
[Tipo]
R 4. Asignar Habitación
Función Registra al cliente en una habitación
Descripción El administrador del hotel asigna una habitación al cliente.
Entradas Número de habitación, días de estadía, numero de cedula
Fuentes Teclado
Proceso Por medio de la interfaz del sistema el administrador del

hotel hace escoger una habitación disponible al cliente.
Restricciones La habitación que se desea escoger debe estar disponible,

caso contrario la asignación no se podrá hacer.
Precondiciones Ingreso de información del cliente.
Pos El pago que el cliente debe realizara a la salida del hotel se

condiciones requiere tener la habitación en la cual estuvo hospedado
para poder realizar el pago.

Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 5. Contrato de servicios
Función Se solicita algún servicio, de los que presenta el hotel.
Descripción El cliente solicita un servicio a algún administrador del hotel
Entradas Tipo de servicio, horario
Fuentes Teclado
Proceso Se añade un servicio a la información de pagos del cliente, y

se procede a realizar una reserva.
Restricciones Los servicios deben estar disponibles.

El cliente no puede solicitar dos servicios o más al mismo
horario.
Precondiciones Ingreso de información del cliente.
Pos El cliente realiza la contratación de servicios por ende el

condiciones pago se incrementará al final de estadía.

Efectos Registrar pago.

colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 6. Eliminar Reserva
Función Se elimina de la lista la reserva seleccionada.
Descripción El recepcionista ingresando el número de cedula selecciona

la opción sacar de lista de reservas.
Entradas Número de cedula.
Fuentes Teclado
Salidas Aviso de confirmación de eliminación de reserva
Proceso El recepcionista ingresa el número de cédula del cliente,

después la interfaz gráfica dará la reservación su nombre, y
dará la opción de eliminar la reserva.
Restricciones La reserva tuvo que haber realizado.

No se puede cancelar una reserva faltando 48 horas.
Precondiciones Ingreso de información del cliente
Pos Se modificará la información del cliente en la base de datos

condiciones sacándole de las reservas para habitaciones.

Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]
R 7. Rol de pagos de empleados
Función Desplegar un documento que registre la cantidad de dinero

que se paga al empleado.
Descripción Un usuario de tipo administrador solicita que se imprima la

tabla de roles de pagos, el cual deben estar en orden por
ordenanza de hotelera.
Entradas Ingresar usuario, información de pagos
Fuentes Teclado
Salidas Documento con una tabla de roles de pagos.
Proceso El usuario de tipo administrador ingresa su usuario,

posteriormente se desplegará una ventana, la cual
desplegará la información del empleado y finalmente será la
encargada de generar el rol de pagos en un documento
PDF.

Restricciones Si se desea generar un rol de pagos de un mes este debe

haber terminado por completo es decir se puede solicitar
cada primero de cada mes.
Precondiciones Se tuvo que haber registrado cada usuario de tipo empleado

con su respectivo pago para que pueda ser desplegado.
Pos Ya desplegado el rol de pagos, el administrador del hotel

condiciones puede tener sus papeles en orden y manejar la parte
económica del hotel de una manera óptima.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 8. Consultar información de Usuario

Función Desplegar el contrato de un usuario, con su respectivo
historial en la compañía
Descripción Usuario de tipo administrador ingresa el número de cédula
del empleado para poder desplegar su información.
Entradas Número de cédula del usuario
Fuentes Teclado
Salidas Documento de hoja de vida de cada empleado.
Proceso Usando la interfaz gráfica del usuario se seleccionará el
empelado, al que se desea ver la información. Ya que el
sistema cuenta con una base de datos, esta función ayuda a
buscar la información y la despliega.
Restricciones El usuario ya tuvo que haber estado registrado, es decir si no
se ha creado el usuario no se desplegará la información.
Precondiciones Se debe tener ingresadas las hojas de vida de los
empleados.
Pos Para el administrador es de suma importancia saber con qué
condiciones empleados cuenta, y confirmar alguna información referente a
el mismo.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 9. Desplegar habitaciones disponibles

Función Mostar al usuario las habitaciones disponibles por el
momento.
Descripción El usuario ingresa una fecha y se desplegará las habitaciones
disponibles para ese día.
Entradas Fecha
Fuentes Teclado
Salidas Información referente a las habitaciones del hotel, con
respecto a su disponibilidad.
Proceso El empleado al momento de realizar una reserva requiere
saber que habitaciones están disponibles para el momento,
es por eso que en base a una cierta fecha ingresada por
teclado se podrá ver las habitaciones disponibles para que
puedan ser utilizadas.
Restricciones En esta funcionalidad no se puede desplegar, asignar, ni
consultar habitaciones usadas por algún cliente, eso es un
proceso posterior.
Precondiciones Se tuvo que actualizar la disponibilidad del hotel para que los
datos sean reales y actuales
Pos Una vez consultado la habitación el empelado de tipo
condiciones recepcionista puede proceder a asignar una habitación, para
algún cliente o simplemente consultar alguna duda.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 10. Clientes en actividad

Función Mostrar los clientes que se encuentran hospedados en ese
momento.
Descripción Se selecciona la opción para desplegar la información de la
actividad
Entradas No consta de entradas ya que es una consulta general.
Fuentes Teclado
Salidas Se despliega todos los clientes que se encuentran
hospedados en ese momento.
Proceso Por medio de la interfaz de sistema se selecciona la opción
de mostrar la actividad actual, posteriormente esta orden
consulta a la base de datos los clientes que se encuentran en
ese momento hospedados en el hotel.
Restricciones Para que el cliente pueda desplegarse su estadía tiene que
estar vigente, es decir que se encuentre en el hotel.
No se puede proporcionar esta información a cualquier
persona, debe estar autorizado por el cliente.
Precondiciones El cliente tiene que estar asignado una habitación por un
tiempo determinado para desplegar su información.
Pos Al consultar la actividad actual se puede confirmar si es que
condiciones el cliente se encuentra hospedado en el hotel o no.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 11. Asignar Tipo de Usuario

Función El administrador asigna a el tipo de usuario que le dará una
clase de permisos
Descripción El usuario administrador da los permisos a los usuarios del
sistema para que estos puedan tener funcionalidades.
Entradas Número de cedula del usuario, tipo de usuario
Fuentes Teclado
Salidas Confirmación de asignación de tipo al usuario.
Proceso Un usuario de tipo administrador después de haber
identificado el número de cédula de su empleado asigna su
tipo de permisos que tendrá en el sistema, ya sea este de
usuario empleado, recepcionista, supervisor de recepcionista,
o administrador
Restricciones El tipo de empleado debe ser igual al que está registrado en
el contrato de trabajo.
Precondiciones Se tuvo que haber ingresado la información previa del
empleado.
Pos Ahora el empleado puede acceder a ciertas funcionalidades
condiciones del sistema y su información ha sido modificada, si es que se
desea consultar su información de usuario posteriormente.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 12. Eliminar Usuario del sistema

Función Sacar un usuario de la lista de todo el sistema.
Descripción El administrador desea eliminar un usuario para que no tenga
acceso al sistema de ninguna manera.
Entradas Número de cedula del usuario, motivo de eliminación.
Fuentes Teclado
Salidas Confirmación de eliminación del empleado.
Proceso El administrador desea que se elimine un cliente para esto
selecciona la opción eliminar cliente, posteriormente, el
sistema solicita ingresar cédula y que escriba el motivo de la
eliminación, este para que este sea desplegado al momento
de ingresar ese usuario de nuevo, y que también sirva de
justificación de la eliminación, por último se selecciona el
botón confirmar para proceder a que sea eliminado.
Restricciones El empleado debe estar informado de que se procederá a
borrar su usuario del sistema, y los motivos.
Precondiciones Para que el usuario sea borrado antes tuvo que haberse
ingresado, caso contrario no se borrara nada.
Pos La base de datos será actualizada sin el empleado que se
condiciones acaba de eliminar.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 13. Facturación (checkout)

Función Se realiza la facturación de todos los servicios contratados a
lo largo de la estadía del cliente.
Descripción El recepcionista entrega la factura del pago de los servicios
antes contratados, para que estos sean cancelados.
Entradas Número de cédula del usuario
Fuentes Teclado
Salidas Confirmación de pago y checkout del cliente.
Proceso El recepcionista ingresa a la opción de facturación la cual
desplegará un recuadro que solicite que se ingrese el número
de cédula, este dato ayuda a que se consulte la información
de pagos del cliente, para que estos valores se cancele y el
cliente pueda salir del hotel.
Restricciones Ninguna.
Precondiciones El usuario tiene que haber realizado algún consumo para
proceder a pagarlo
Pos El cliente deja de estar activo y pasa a estar en el registro de
condiciones la base datos del hotel.
Efectos Ninguno
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 14. Modificar información de un empleado
Función Modificar la información de los empleados del hotel.
Descripción El empleado puede solicitar modificar su información.
Entradas Información personal a modificar: nombres, apellidos, estado

civil, dirección, número de teléfono.
Fuentes Teclado
Salidas Aviso de confirmación de guardado en el sistema.
Proceso El administrador mediante un formulario modifica la

información de cualquier empleado.
Restricciones No se puede modificar el número de cédula

El empleado debe tener un mínimo de un año trabajando en
el hotel.
Precondiciones La información del empleado debe estar en la base de datos

del hotel.
Pos La información se almacena en la base de datos para

condiciones posteriores modificaciones.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 15. Modificar información del cliente
Función Modificar la información registrada de un cliente del hotel.
Descripción El cliente puede solicitar modificar su información.
Entradas Información personal a modificar: nombres, apellidos, estado

civil, dirección, número de teléfono.
Fuentes Teclado
Proceso El empleado del hotel mediante un formulario modifica la

información de cualquier cliente que lo solicita.
Restricciones No se puede modificar el número de cédula

El cliente no puede realizar más de dos modificaciones al
año.
Precondiciones La información del cliente debe estar en la base de datos del

hotel.

condiciones posteriores modificaciones.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 16. Desplegar reporte diario de huéspedes
Función El hotel genera un reporte diario de los huéspedes que

ingresan al hotel.
Descripción Se genera un informe de los huéspedes que ingresan

diariamente al hotel, dichos reportes pueden ser usados para
investigaciones de la policía.
Entradas Ninguna.
Fuentes Ninguna
Salidas Reporte de huéspedes.
Proceso Se genera un informe de los huéspedes, que puede ser

impreso.
Restricciones Únicamente se genera reportes de los huéspedes que

ingresan.
Precondiciones Los clientes deben estar registrados en el hotel.
Pos El informe puede ser usado para posteriores investigaciones

condiciones de la policía.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 17. Registrar gastos del hotel
Función Se registran mensualmente los gastos del hotel.
Descripción Se genera mensualmente un informe con todos los gastos

del hotel.
Entradas Gastos del hotel: luz, agua, internet, teléfono, sueldos.
Fuentes Teclado
Salidas Reporte de gastos.
Proceso El administrador del hotel, después de ingresar los gastos

mensuales puede generar un informe.
Restricciones Ninguna.
Precondiciones Se debe tener una contabilidad sobre los gastos.
Pos El informe es usado para posteriores pagos de servicios.

condiciones
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 18. Realizar presupuestos del mes
Función Realización del presupuesto del mes.
Descripción El administrador del hotel realiza un aproximado del

presupuesto mensual.
Entradas Costos de los servicios: luz, agua, internet, teléfono

Costos de los Sueldos
Fuentes Teclado
Salidas Informe de presupuestos.
Proceso El administrador realiza un aproximado del presupuesto

mensual.
Restricciones Ninguna

condiciones realizar la posterior contabilidad en el hotel.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 19. Control de entrada y salida de empleados
Función Controlar el ingreso y salida de empleados.
Descripción Se controla la hora de ingreso, salida y la hora de almuerzo

de los empleados.
Entradas Huella digital, hora
Fuentes Lector biométrico
Salidas Aviso de confirmación entrada o salida.
Proceso El lector registra la huella digital del empleado así como la

hora de entrada o salida, ésta información se almacena en la
base de datos.
Restricciones El empleado debe avisar con anticipación si alguien va a

cubrir su puesto.
Precondiciones La información del empleado debe estar registrada.
Pos La información se almacena para posteriores descuentos en

condiciones el sueldo por impuntualidad o posteriores incentivos por
puntualidad.
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

R 20. Control de propinas
Función Control y asignación de propinas a los empleados.
Descripción El administrador asigna las propinas a los empleados en su

rol de pagos.
Entradas Propinas que reciben los empleados
Fuentes Teclado

Incremento en los roles de pagos
Proceso El administrador incrementa las propinas en los roles de

pagos mensuales de cada empleado.
Restricciones La información del empleado debe estar almacenada
Precondiciones El empleado debe recibir propinas del cliente.
Pos Ninguna.
condiciones
Efectos Ninguno.
colaterales
Contactos Ninguno
Fecha Ninguno
[Tipo]

No funcionales
Identificación del RNF01

requerimiento:
Nombre del Rapidez
Requerimiento:
Características: Transacciones procesadas por segundo: 500 transacciones
Descripción del Este requerimiento está dado por la siguiente fórmula:
requerimiento:
𝑁𝑢𝑚. 𝑑𝑒 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑐𝑖𝑜𝑛𝑒𝑠 500
𝑇𝑃𝑆 = = = 500
𝑡𝑖𝑒𝑚𝑝𝑜 (𝑠𝑒𝑔) 1
El sistema podrá soportar 500 transacciones por segundo en caso de

que todas las habitaciones del hotel estén siendo reservadas al mismo
tiempo.
Prioridad del requerimiento:
Alta

requerimiento:
Nombre del Facilidad de Uso
Requerimiento:
Características: Tiempo de formación: 16 semanas
Descripción del El tiempo de formación para cada empleado está dado por la siguiente
requerimiento: fórmula:
𝐻𝑇𝐶 = 𝐻𝑜𝑟𝑎𝑠 𝑑𝑒 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑎𝑐𝑖ó𝑛 𝑝𝑜𝑟 𝑝𝑒𝑟𝑠𝑜𝑛𝑎 ∗ 𝑁𝑢𝑚. 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠

= 120 ∗ 200 = 24000 = 16 𝑠𝑒𝑚𝑎𝑛𝑎𝑠
Este tiempo se calculó en base al número de empleados y las horas que

cada persona debe recibir de capacitación.
Alta

requerimiento:
Nombre del Rapidez
Requerimiento:
Características: Tiempo de respuesta al usuario y eventos: 1 segundo
Descripción del El sistema debe trabajar rápidamente para ofrecer un servicio más
requerimiento: eficiente

Alta

requerimiento:
Nombre del Facilidad de Uso
Requerimiento:
Características: Número de cuadros de ayuda: 4 cuadros por pantalla
Descripción del La interfaz se creó con 4 cuadros de ayuda, los empleados ya están
requerimiento: familiarizados con el sistema después de la capacitación
Alta

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.
Alta

requerimiento:
Nombre del Tamaño
Requerimiento:
Características: K bytes: 300 por pantalla desplegada
Descripción del El sistema deberá soportar 300 k bytes por cada pantalla que se
requerimiento: despliegue, un número mayor podría hacer más lento al sistema

Alta

requerimiento:
Nombre del Fiabilidad
Requerimiento:
Características: Tiempo medio entre fallos: 33.6 horas
Descripción del Para calcular el tiempo medio entre fallos aplicamos la siguiente fórmula:
requerimiento:
𝑇𝑖𝑒𝑚𝑝𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑜𝑝𝑒𝑟𝑎𝑐𝑖ó𝑛 168
𝑇𝑀𝐸𝐹 = = = 33.6 ℎ𝑜𝑟𝑎𝑠
𝑁𝑢𝑚. 𝑑𝑒 𝑓𝑎𝑙𝑙𝑜𝑠 𝑑𝑒𝑡𝑒𝑐𝑡𝑎𝑑𝑜𝑠 5
En una semana de operación, después de detectarse 5 errores se

encontró un tiempo medio de 33.6 horas
Alta
Identificación del RNF 8

requerimiento:
Nombre del Fiabilidad
Requerimiento:
Características: Probabilidad de no disponibilidad es de 0,05 %.
Descripción del Para determinar este valor aplicamos la siguiente formula:
requerimiento: 𝑁𝑢𝑚. 𝑟𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑓𝑎𝑏𝑜𝑟𝑎𝑏𝑙𝑒𝑠 5
Pr(𝑥) = = = 0.05
𝑁𝑢𝑚. 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑟𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 100
En este caso los resultados favorables son la no disponibilidad del
sistema que son 5, en un total de 100 pruebas.
Alta

requerimiento:
Nombre del Factibilidad
Requerimiento:
Características: Tasa de ocurrencia de fallos es de 0.04 por 10000 pruebas

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.
Alta

requerimiento:
Requerimiento:
Características: Disponibilidad del 100% es decir las 24 horas
Descripción del Para determinar la disponibilidad aplicamos la siguiente formula:
requerimiento: 𝐻𝑜𝑟𝑎𝑠 𝑑𝑒 𝑠𝑒𝑟𝑣𝑖𝑐𝑖𝑜 𝑑𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒 24
𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = ∗ 100% = ∗ 100
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠 𝑎𝑙 𝑑𝑖𝑎 24
= 100%
Alta
Identificación del SNF 11

requerimiento:
Nombre del Robustez
Requerimiento:
Características: Tiempo de reinicio después de fallos, de 5 minutos
Descripción del Para determinar el tiempo de reinicio de fallos se aplica la formula
requerimiento: siguiente:
𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑖𝑛𝑖𝑐𝑖𝑜 = ℎ𝑜𝑟𝑎 𝑑𝑒𝑙 𝑓𝑎𝑙𝑙𝑜 − ℎ𝑜𝑟𝑎 𝑑𝑒 𝑟𝑒𝑔𝑟𝑒𝑠𝑜 𝑑𝑒𝑙 𝑠𝑖𝑠𝑡𝑒𝑚𝑎
= 10: 30 − 10: 35 = 5 𝑚𝑖𝑛
Alta

requerimiento:
Requerimiento:
Características: Porcentaje de eventos que provocan fallos tiene un porcentaje de 0.5%
Descripción del Se aplica la siguiente formula:
requerimiento: 𝐸𝑣𝑒𝑛𝑡𝑜𝑠 𝑓𝑎𝑙𝑙𝑜𝑠 5
% 𝑑𝑒 𝑒𝑣𝑒𝑛𝑡𝑜𝑠 𝑓𝑎𝑙𝑙𝑜𝑠 = ∗ 100% = ∗ 100% = 0.5%
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑒𝑣𝑒𝑛𝑡𝑜𝑠 1000
Alta

requerimiento:
Nombre del Portabilidad
Requerimiento:
Características: Números sistemas objetivos son 3
Descripción del El sistema ha sido implementado en los 3 Sistemas operativos
requerimiento: principales como son MS Windows, IOS MAC y Linux, por lo tanto se
puede decir que tiene una portabilidad muy alta.
Alta


requerimiento:
Nombre del Portabilidad
Requerimiento:
Características: Porcentaje de declaración dependientes del objetivo
Descripción del El
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)

Artículo IV. Checklist de Verificación de los

Requerimientos
Para la verificación de:
Nombre de la Agencia Hotel Malibú
Sistema Hotelero para la administración de información, cobro de servicios, reservas

Nombre del Proyecto
del Hotel Malibú Quito
Nombre del Documento N / A
Fecha 18 de junio del 2015
Criterio Sí / No / NA Por qué?
1. Correctitud — La Especificación de un Requerimiento es

correcta si, y solo si, el sistema/software alcanza todos y cada
uno de los requerimientos en él especificados.
a. Desde el punto de vista del usuario, ¿se ha especificado el

tiempo de respuesta esperado de todas las operaciones NA
necesarias?
b. ¿Se han especificado otras consideraciones temporales tales

como el tiempo de procesamiento, el de transferencia de datos NA
o la tasa de transferencia?
c. ¿Se han especificado todas las tareas que debe realizar el

NA
sistema/software?
d. Para cada tarea especificada, ¿se ha detallado el contenido

de datos/información utilizado por la tarea y el contenido de
NA
datos/información que se obtendrá como resultado de la
misma?
e. ¿Se han establecido los requerimientos sobre la seguridad

NA
física?
f. ¿Se han establecido los requerimientos sobre la seguridad

NA
operacional?
g. ¿Se ha especificado la fiabilidad del sistema/software,

incluyendo las consecuencias en el caso de que falle, la
NA
información vital a proteger en caso de caída, la detección de
los errores o el proceso de recuperación?
h. ¿Las compensaciones establecidas entre los atributos que

compiten son aceptables, por ejemplo, entre robusteza y NA
correctitud?
i. ¿Se han definido las interfaces internas, como por ejemplo el

NA
software o el hardware?
j. ¿Se han definido las interfaces externas, como por ejemplo

NA
usuarios o hardware?
k. ¿Se ha incluido la definición de éxito? ¿Se ha incluido la

NA
definición de fracaso?
l. ¿Cada requerimiento es relevante para el problema y su

NA
solución?

2. No Ambiguo — Una Especificación de los Requerimientos es

no ambigua si, y solo si, cada requerimiento especificado en ella
posee exclusivamente una única interpretación.
a. ¿Los requerimientos se han especificado de forma

No, ya que aún se tiene
suficientemente clara para que si se entregan a un grupo
NO requerimientos que generan
independiente para la implementación, dicho grupo sea capaz
ambigüedad.
de entenderlos?
b. ¿Los requerimientos funcionales se encuentran separados de

SI NA
los no-funcionales?
c. ¿Los requerimientos están especificados de forma concisa, Existen requerimientos muy

de modo que evitan la posibilidad de hacer múltiples generales que dejan muchas
NO
interpretaciones de ellos? posibilidades es decir no son
específicos.
d. ¿Todos los requerimientos evitan conflictos con otros Los requerimientos del administrador
requerimientos? NO y de los recepcionistas tienen
ambigüedades.
3. Completitud — Una Especificación de los Requerimientos es

completa si, y solo si, incluye los siguientes elementos:
Todos los requerimientos significativos, ya sea relacionados con
la funcionalidad, con el rendimiento, las limitaciones de
diseño, los atributos o las interfaces externas.
Las definiciones de las respuestas del sistema/software a todas
las clases posibles de datos de entrada en todos los tipos
posibles de situaciones.
Etiquetas descriptivas y referencias a todas las figuras, tablas y
diagramas de la Especificación de los Requerimientos, así
como la definición de todos los términos y unidades de
medición.
a. ¿Se han especificado todas las entradas al sistema/software, No se especifican detalladamente

incluyendo su origen, su exactitud, su rango de valores y su las entradas en algunos de los
frecuencia? NO ingresos se requiere más
información sobre los nuevos
recepcionistas
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.
c. ¿Se han especificado todas las interfaces de comunicación,

incluyendo su aceptación de la negociación, su control de SI NA
errores y los protocolos de comunicación?
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.
e. ¿Se han especificado las áreas de incompletitud para cuando

SI NA
la información no esté disponible?
f. ¿Los requerimientos son completos, tales que si el producto

SI NA
satisface todos estos requerimientos, será aceptable?
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

h. ¿Se ha especificado la mantenibilidad del sistema/software, Aun se tienen dudas en el

incluyendo la habilidad de respuesta a los cambios en el entorno funcionamiento debido a la
operativo, las interfaces, la precisión, el rendimiento, y otras No ambigüedad de los requerimientos,
capacidades adicionales predecibles? esto no ha permitido predecir la
mantenibilidad.
i. ¿Se han especificado los requerimientos para la comunicación

Si
entre los componentes del sistema/software?
j. ¿Se ha definido la funcionalidad y el comportamiento global de Al tratarse un programa que requiere

todo el sistema/software? varios requerimiento no se ha podido
No
lograr que todos funcionen sin
ningún error
k. ¿Se han establecido de forma explícita y sin ambigüedades

Si
las restricciones, suposiciones y dependencias apropiadas?
l. ¿Se ha especificado adecuadamente la infraestructura Al proyecto le falta hacer el estudio

tecnológica para el sistema/software? adecuado de la infraestructura
tecnológica que resulte la más
No
óptima para el programa, la cual no
se ha tomado en cuenta para el
trabajo.
m. ¿Se ha limitado el ámbito del sistema/software? No se ha hecho todo el análisis de la

parte tecnológica, sin embargo no se
ha limitado exclusivamente al
No software ya que en el proceso se
requiere especificar por lo menos
algún requerimiento en el ámbito
tecnológico
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.
o. ¿Se han referenciado dentro del documento todas las figuras,

Si
tablas y diagramas?
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.
4. Consistencia — La consistencia se refiere a la consistencia

interna. Si la Especificación de los Requerimientos no
concuerda con el resto de documentación de la organización y
del proyecto, significa que no es correcta.
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.

c. ¿Algunos de los requerimientos tienen que especificarse con

Los requerimientos están
mayor detalle? No
especificados de manera correcta
d. ¿Algunos de los requerimientos deben ser especificados con Los detalles brindados en cada
menor detalle? No requerimiento son esenciales para
su entendimiento
e. ¿Los requerimientos están en concordancia con el contenido

Si
del resto de documentación de la organización o del proyecto?
5. Categorizado por importancia y/o estabilidad – Una

Especificación de los Requerimientos se categoriza por
importancia y/o estabilidad si cada requerimiento particular
especificado en ella posee un identificador que establece su
importancia o estabilidad. Ejemplos de rangos de categorización
incluyen esencial, condicional u opcional. La estabilidad puede
ser especificada en términos del número de cambios esperados
para un requerimiento.
a. ¿Los requerimientos poseen asociado un identificador para

No se especifica un orden o
indicar la importancia o la estabilidad de un requerimiento en No
prioridad en los requerimientos
particular?
b. ¿Existen conflictos en relación a la categorización de la

Si
importancia y/o estabilidad de los requerimientos?
6. Verificable — Una Especificación de los Requerimientos es

verificable si, y solo si, cada requerimiento especificado en ella
es verificable. Un requerimiento es verificable si, y solo si, existe
un proceso finito y rentable con el cual una persona o máquina
puede comprobar que el sistema/software cumple con dicho
requerimiento.
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
7. Modificable — Una Especificación de los Requerimientos es

modificable si, y solo si, su estructura y estilo son tales que
cualquier cambio en los requerimientos puede realizarse de
forma fácil, completa y consistente, conservando la estructura y
el estilo.
a. ¿Los requerimientos se identifican de forma única? Si
b. ¿Se han consolidado los requerimientos redundantes? Los requerimientos redundantes no

No
han sido clarificados
c. ¿Cada requerimiento se ha especificado de forma separada, Existen requerimientos demasiado

evitando requerimientos compuestos? No largos, que pueden ser tratados por
separado
8. Trazable — Una Especificación de los Requerimientos es

trazable si el origen de cada uno de sus requerimientos es claro
y si facilita la referenciación de cada requerimiento en el
desarrollo futuro o mejora la documentación.

a. ¿Puede trazarse cada requerimiento hacia su fuente de

Los requerimientos no son del todo
origen, como una declaración de su ámbito, una petición de No
trazables
cambio o una legislación?
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
c. ¿Cada requerimiento posee una referencia a los

Los requerimientos no están
requerimientos previos del proyecto que están relacionados con No
referenciados a su origen
él?
Guiones de pruebas
1. Funcionalidad: Ingresar empleados
Id: R.1 Módulo a Probar: Administración Fecha: 10-07-2015

Nombre del Proyecto: Sistema Hotelero para la Plataforma: Aplicación Java
administración de información, cobro de servicios,
reservas del Hotel Malibú Quito.
Pre Requisitos:  Contar con el administrador asignado al sistema
 Contar con una conexión con la base de datos
 Tener establecido el contrato de trabajador, con su respectiva
información.
Pasos o secuencia lógica: 1.

El administrador inicia sesión en el sistema.
2.
Después de desplegará un formulario llenar con la información
del empleado.
3. El usuario administrador llena la información del empelado
según la información que tiene.
4. Se procede a seleccionar el botón guardar, ya terminar el
proceso de ingreso.
5. Se desplegara la información ingresada para la confirmación del
usuario.
Resultados esperados: 1. Se guardara la información del empleado en una base de datos
2. El sistema debe detectar si algún dato está mal ingresado.
3. Con estos datos ingresados en una base de datos se puede
realizar una búsqueda de empleado y se encontrara la
información.
4. A partir de ahora el empleado cuenta con un usuario el cual le
permitirá acceder a algunas funcionalidades
5. La información del empleado puede ser modificada, sin
embargo es un proceso que solo el administrador puede
realizar.
Resultados obtenidos: Este requerimiento o se pudo efectuar ya que el paso 4 no está
especificado en ningún momento en el SRS, no se despliega la
información ingresada para una verificación del administrador.
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

2. Funcionalidad: Ingresar cliente

Pre Requisitos:  Empleado debe contar con una cuenta
 El empleado debe contar con un contrato vigente.
Pasos o secuencia 1.El empleado inicia sesión en el sistema.

lógica: 2.Se desplegara una interfaz con varias pestañas.
3.Ahora selecciona la pestaña de Ingreso de cliente.
4.Va a desplegarse un formulario el cual solicita el ingreso
de información del cliente.
5. Ingresamos la información respetiva, y seleccionamos el
boto de guardar.
Resultados esperados: 1. Se debe guardar la información del cliente en una base
de datos.
2. No puede haber un cliente con la misma cedula
3. Sin embargo se puede modificar la información
posteriormente.
4. La información del cliente se podrá obtener ingresando
el número de cedula.
5. Se desplegara un cuadro con un mensaje que indica
que los datos fueron guardados con éxito.
Resultados obtenidos: El cliente está guardado en el sistema, y se puede citarlo con el
número de cedula, además no se puede ingresar en un cliente
con el mismo número de cedula.
Observaciones: El requerimiento cumple con sus objetivos planteados en el SRS.
Nombre Nombre
Estado:
Concluido Desechado
3. Funcionalidad: Agregar Reserva

Pre Requisitos:  Cliente ingresado en el sistema
 Empleado debe tener ingresado sección.
Pasos o secuencia 1. Después de ingresar la información del cliente vamos a

lógica: las pestañas de agregar reserva.
2. El programa desplegara un formulario el cual solicita la
cedula del cliente como datos.
3. Al ingresar la cedula se despliega el nombre del cliente.

4. Posteriormente se procede a ingresar la información de

la reservó, como es el número de habitación, la fecha y
el tipo de habitación.
5. Se despliega la información ingresada para que sea
confirmada, por el empleado.
Resultados esperados: 1. En la base de datos se debe agregar la información de
la reserva.
2. No se podrá utilizar esa habitación para otra reserva.
3. Se debe despliegue un mensaje que confirme que se
guardó la información.
4. Posteriormente el sistema debe permitir cambiar o
eliminar la reserva.
5. Al momento de ingresar la cedula se be reconocer le
cliente y vincular con la información ya ingresa en el
sistema.
Resultados obtenidos: No se puede realizar el requerimiento ya que no se despliega el
mensaje de confirmación e ingreso, además no se encuentra el
cliente con el número de cedula.
Observaciones: No cumple lo que tiene planteado en el SRS, por lo tanto se debe replantear
el requerimiento para que este sea funcional.
Nombre Nombre
Estado:
Concluido Desechado
4. Funcionalidad: Asignación de habitación

 Contar con una conexión a la base de datos
 Tener ingresado los tipos de habitaciones y sus costos
Pasos o secuencia 1. Ingresar el número de cédula del cliente

lógica: 2. Consulta de habitaciones disponibles
3. Ingresar la fecha en la que el cliente desea la habitación
4. Ingresar el número de habitaciones que requiere el cliente
5. Efectuar la asignación
Resultados esperados: 1. Se despliega la información del cliente

2. Se despliega el número de habitaciones con sus costos
3. Se registra la fecha de entrada del cliente y la fecha de
salida
4. Se registra el número de habitaciones que desea el cliente
y los días que las va a ocupar
5. Se realiza la reserva y se ocupan las habitaciones que
requiere el cliente

Resultados obtenidos: El requerimiento es fallido ya que en el SRS nunca se especificó

el ingreso de los tipos de habitaciones y sus costos
Observaciones: No El requerimiento no cumple con lo planteado en el SRS, por lo cual
deberá ser modificado
Nombre Nombre
Estado:
Concluido Desechado
5. Funcionalidad: Pago de servicios

 Tener conexión con la base de datos
Pasos o secuencia 1. Ingresar la información del cliente

lógica: 2. Realizar el check out de los gastos del cliente
3. Cargar el costo de servicios adicionales e impuestos a la
factura
4. Ingresar el método de pago
5. Autorizar la facturación de los servicios
Resultados esperados: 1. Mostrar la información del consumo del cliente
2. Se despliega la información de los gastos
3. En la factura se despliega el valor de los nuevos servicios
y el total a pagar
4. Se obtiene la autorización del banco para el pago
5. Se despliega la factura para su impresión
Resultados obtenidos: El requerimiento es fallido ya que en el SRS nunca se especificó
el paso 3 “Se debe ingresar el tipo de dato correcto según el
campo escogido”
Observaciones: El requerimiento no cumple con lo planteado en el SRS.
Nombre Nombre
Estado:
Concluido Desechado

6. Funcionalidad: Generar Rol de pagos

Pre Requisitos:  Contar con una cuenta de administrador.
 Haber ingresado los ingresos del hotel con sus egresos.
 Contar con disponibilidad de la base de datos.
Pasos o secuencia 1. Se despliega una ventana la cual solicita entras el mes y el

lógica: año para mostrar el roll de pagos.
2. Después se solicita seleccionar el tipo de documento que
desea descargar.
3. Posterior a descargar se puede visualizar en una tabla los
datos del documento que se va imprimir.
4. Se seleccione el botón de descargar.
5. El Documento será descargado.
Resultados esperados: 1. Al momento de ingresar la fecha debe estar en el rango
de fechas en la que la compañía a realizado los roles de
pagos.
2. Se debe generar un documento en el que se pueda
visualizar el rol de pagos.
3. La conexión con la base de datos debe ser exitosa caso
contrario no se desplegara la información.
4. Al ingresar la fecha se debe visualizar en la vista previa,
antes de generar el archivo.
5. Cada error debe ser reportado y puede ser cambiado
para que se despliegue la información correcta.
Resultados obtenidos: El requerimiento cumple con cada uno de los paso, planteados
anteriormente.
Observaciones: El requerimiento cumple con lo planteado en el SRS.
Nombre Nombre
Estado:
Concluido Desechado
7. Funcionalidad: Consultar Información de Usuario

Pre Requisitos:  El usuario de tipo empleado debe haber sido creado.
 El empleado debe contar con un contrato vigente.
Pasos o secuencia 1. El administrador procede a iniciar sesión.

lógica: 2. Selecciona la opción de consultar información e usuario.
3. Ingresando el número de cedula o nombre permitirá

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.
Nombre Nombre
Estado:
Concluido Desechado
8- Funcionalidad: Desplegar habitaciones disponibles.
Id: R.8 Módulo a Probar: Empleado Fecha: 10-07-2015

Pre Requisitos:  El empleado debe tener una cuenta registrada y
funcional.
 Tener conexión con la base de datos.
Pasos o secuencia 1. El sistema solicitara iniciar sección para acceder a la

lógica: funcionalidad.
2. Después se ingresara a la opción desplegar habitación
disponible.
3. Se ingresa la fecha en la cual se necesita saber que
habitaciones están disponibles.
4. Se desplegaran las habitaciones disponibles.
5. De igual manera de despliega el tiempo en el que están
disponibles, el tipo de habitación que es entre otras
características.
Resultados esperados: 1. Al momento de iniciar sección debe estar la clave y el
usuario ingresados correctamente.
2. Los datos citados en la base de datos deben ser los
correctos.
3. Al ingresar la echa debe ser una fecha vigente, con la
información que se tiene en la base de datos.
4. Si se encuentra una falla el sistema debe dar la
posibilidad de ser editado.
5. La información debe estar actualizada con la de la base

de datos, esto se puede lograr con una conexión estable.
Resultados obtenidos: En este caso el requerimiento cumple con los pasos planteados y
es funcional ya que realiza la actividad que se necesita.
Nombre Nombre
Estado:
Concluido Desechado
9- Funcionalidad: Clientes en actividad
Id: R.9 Módulo a Probar: Empleado Fecha: 10-07-2015

Pre Requisitos:  Usuario en el sistema debe estar registrado
Pasos o secuencia 1. Para comenzar el sistema solicita ingresar sección como

lógica: Empleado.
2. Se selecciona la opción para mostrar los clientes en
actividad.
3. Después solicita ingresar la fecha para ver la actividad de
los clientes.
4. Se desplegará la información en una tabla.
5. Se puede proceder a imprimir, el documento con la
información.
Resultados esperados: 1. Se debe contar con una conexión a la base de datos.
2. Si la fecha no está vigente en el sistema debe botar error.
3. Los datos que se muestran en la base de datos deben ser
los correctos.
4. Cada etapa debe ser confirmado con el uso de la base de
datos, caso contrario debe botar un error.
5. La información debe ser actualizada con la base de datos.
Resultados obtenidos: Los resultados mostrados en la guía de uso son los mismo que
están en el SRS por lo tanto el requerimiento esta concluido y
acorde a lo plantado anteriormente.
Nombre Nombre
Estado:
Concluido Desechado

10- Funcionalidad: Registrar tipo de Usuario

Pre Requisitos:  Se debe constar con la información de los empleados.
Pasos o secuencia 1. Se ingresa información del usuario a ingresar

lógica: 2. El administrador debe ingresar el tipo de usuario en el
sistema.
3. Se genera una clave para el usuario
4. El usuario debe ingresar solamente con su usuario
Resultados esperados: 1. La información se almacena en la base de datos.
2. Se ingresa el tipo de usuario y se almacena en el sistema
3. El sistema genera una clave única para el usuario
4. El sistema puede ser accesado únicamente con esa clave
Resultados obtenidos: El requerimiento es acorde a lo que está planteado en el SRS, por
lo tanto esta aprobado.
Nombre Nombre
Estado:
Concluido Desechado
11. Funcionalidad: Control de entrada y salida de empleados

 Tener la información de los empleados en el sistema.
 Tener conexión con el lector biométrico
Pasos o secuencia lógica: 1. El empleado ingresa su huella digital en el lector biométrico

2. La información del empleado se almacena en el sistema
3. Los ingresos y salida se guardan en el registro personal de
cada empleado
4. Por cada falta se registra un descuento en el rol de pagos
del empleado
Resultados esperados: 1. La información se compara con la información registrada en
el sistema
2. La información se guarda en la base de datos
3. En la ficha personal de cada empleado se almacena su

información de entradas y salidas

4. En el rol de pagos se realiza un descuento del mensual, y
se notifica al empleado
Resultados obtenidos: Este requerimiento no se pudo efectuar ya que el paso 4 no está
especificado la conexión con el lector, no se despliega la información
ingresada para una verificación de entradas y salidas.
Nombre Nombre
Estado:
Concluido Desechado
12 Funcionalidad: Presupuesto del mes

 Tener información del departamento comercial
Pasos o secuencia lógica: 1. El usuario administrador ingresa sesión

2. Se compara datos con el departamento comercial
3. Se realiza las cuentas de los gastos del hotel
4. Se realiza un reporte mensual con el presupuesto
Resultados esperados: 1. Sólo usuarios administradores pueden acceder al sistemas
2. Los datos del departamento comercial se ingresan en el
sistema
3. Las facturas de gastos y demás son revisad para su pago
4. Realizar el reporte de presupuesto en un documento PDF
Nombre Nombre
Estado:
Concluido Desechado

13. Funcionalidad: Gastos del hotel

 Tener la información del departamento comercial.
Pasos o secuencia lógica: 1. El usuario administrador ingresa al sistema

2. Se revisa el reporte de los gastos
3. Se coteja el reporte de gastos con el presupuesto
4. Se acepta el pago
Resultados esperados: 1. Sólo se acepta el ingreso a usuarios administradores
2. Después de revisado el reporte de gastos se ingresa la
información en el sistema
3. Si la comparación es correcta se procede al pago
4. Se paga a las entidades involucradas
Nombre Nombre
Estado:
Concluido Desechado
14 Funcionalidad: Reporte diario de huéspedes

 Tener toda la información de los huéspedes del hotel.
Pasos o secuencia lógica: 1. El usuario administrador ingresa al sistema

2. Se verifica las habitaciones disponibles
3. Se revisa los nombres de los huéspedes del hotel
4. Se genera el reporte de huéspedes
5. El reporte puede ser usado por entidades de seguridad
Resultados esperados: 1. Solo se permite el acceso a usuarios administradores
2. Las habitaciones no disponibles son verificadas
3. Se saca los nombres de la base de datos
4. Se genera un reporte en formato PDF
5. Entidades policiacas pueden hacer uso del reporte para sus
investigaciones

Nombre Nombre
Estado:
Concluido Desechado
15 Funcionalidad: Eliminar usuario del sistema

Pasos o secuencia lógica: 1. Login de un usuario administrador

2. Ingresar a la base de datos
3. Verificar la información del usuario
4. Se actualiza la base de datos
Resultados esperados: 1. Solo los usuarios administradores pueden ingresar al sistema
2. Se verifica la información con la base de datos
3. Se elimina al usuario
4. Se actualiza la base de datos sin el empleado eliminado
Resultados obtenidos: Este requerimiento o se pudo efectuar ya que el paso 4 no está
especificado en ningún momento en el SRS, no se despliega la
información ingresada para una verificación del administrador.
Nombre Nombre
Estado:
Concluido Desechado

Diagramas de secuencia
1)
2)
3)

Diagrama de clase
1)

Diagrama de Estado
1)
2)
3)
Estudio de factibilidad
RECURSOS TÉCNICOS PARA EL DESARROLLO DEL PROYECTO
Tipo de recurso Nombre del recurso Descripción Cantidad
Recursos Experto en el área de Analistas 5

Humanos Desarrollo
Diseñador de Base de 6
Datos y Programador

Diseñador 2
Hardware Servidor 2
(a) Servidor en torre
PowerEdge T630
Intel Xeon E5-2603v3
4GB
1TB HD
Puntos de recepción Inspiron One 23 with Touch 10

Screen
Core I5, 4gb RAM, 100GB

HDD
Impresoras recibos 10
(b) Epson TM-T70II
Series
Impresoras multifunción Artículo V. Xpress ,SL- 2

M2675F
Software SQL Server 2015 v.5.6.24 Software de base de datos 1
Microsoft Visual Studio Herramienta para el 1

2013 Update 4 desarrollo de la aplicación
Windows 7 Enterprise. Sistema operativo 2
Microsoft Office 2013 Herramienta para 1

aplicación de ofimática
Microsoft Project Gestión del proyecto 1

14.0.6123.5001 (SP1)
(2011)
Herramienta Case Studio Herramienta Case para el 1

análisis.
Dreamweaver CC (Creative Herramienta de diseño 1

cloud) grafico
Comunicaciones WAN Tipo de Red Red

del proyecto

Señal eléctrica Tipo de conexión
Estrella extendida Topología de Red
Cable UTP categoria 6 Tipo de Cable
IP v6 automática Tipo de Direccionamiento

IP
Router Cisco Router
Switch Cisco Switch Cisco

Documentacion Final Srs

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Documentacion Final Srs

Enviado por

Direitos autorais:

Formatos disponíveis

Especificación de requisitos de software

Proyecto: Sistema Hotelero para la administración de

Junio del 2015

Ficha del documento

Fecha Revisión Autor Verificado dep. Calidad.

17/06/2015 Alejandro Bejarano

Documento validado por las partes en fecha:

Por la comunidad Por la universidad

Hotel Malibú Quito Universidad de las Américas

Descripción de requisitos del software

1.3. Personal involucrado 5

1.4. Definiciones, acrónimos y abreviaturas 6

2.1. Perspectiva del producto 6

2.2. Funcionalidad del producto 7

2.3. Características de los usuarios 7

2.5. Suposiciones y dependencias

3.1. Requisitos Funcionales

3.2. Requisitos No Funcionales

3.4. Casos de Uso

3.5. Checklist de verificación

3.6. Guiones de prueba

3.7. Diagramas de secuencia

3.8. Diagramas de clase

3.9. Diagramas de estado

Descripción de requisitos del software

Sección 1.01 1.1 Propósito

Para este documento el principal propósito es definir los requerimientos funcionales,

Sección 1.02 1.2 Alcance

Sección 1.03 1.3 Personal involucrado

Nombre Alejandro Bejarano

Rol Analista, diseñador y programador

Categoría Profesional TSU-Informática

Responsabilidad Análisis de información, diseño y programación del SIS-I

Información de contacto dbejarano@udlanet.ec

Descripción de requisitos del software

Nombre David Ruano

Rol Analista, diseñador y programador

Categoría Profesional TSU-Informática

Responsabilidad Análisis de información, diseño y programación del SIS-I

Información de contacto druano@udlanet.ec

Nombre Matthaeus Marten

Rol Analista, diseñador y programador

Categoría Profesional TSU-Informática

Responsabilidad Análisis de información, diseño y programación del SIS-I

Información de contacto mmarten@udlanet.ec

Sección 1.04 1.1 Definiciones, acrónimos y

Sección 1.05 1.2 Referencias

Titulo del Documento Referencia

Descripción de requisitos del software

Sección 1.06 1.3 Resumen

El siguiente documento cuenta con 3 secciones. para la primera sección se realiza

Artículo II. 2 Descripción general

Sección 2.01 2.1 Perspectiva del producto

Sección 2.02 2.2 Funcionalidad del producto

Descripción de requisitos del software

Sección 2.03 2.3 Características de los usuarios

Tipo de usuario Gerente de Recepción

Tipo de usuario Supervisor de recepción

Tipo de usuario Recepcionista

Tipo de usuario Cliente

Sección 2.04 2.4 Restricciones

Descripción de requisitos del software

Sección 2.05 2.5 Suposiciones y dependencias