1

GA1-220501092-AA4-EV02
Documento con especificación de requerimientos

Juan Camilo Agudelo Vargas

Melisa Bedoya Murillo
Daniel Araque

Instructores
Jhon Faiber Cerquera Sánchez
Jorge Hernán Becerra Peña

Centro de Gestión y Desarrollo Sostenible Sur colombiano

Análisis y Desarrollo de Software 2977498
2024
 2

INTRODUCCIÓN

El desarrollo de sistemas de reservas y pagos para hoteles juega un papel crucial en la

optimización de la gestión hotelera y la experiencia del cliente. Este documento se centra
en la especificación detallada de los requisitos funcionales y no funcionales para un sistema
web dedicado a la reserva de habitaciones y procesamiento de pagos. Siguiendo las
directrices del estándar IEEE830, cada requisito está meticulosamente definido para
garantizar que todas las necesidades tanto de usuarios como del negocio sean satisfechas de
manera efectiva.
 3

Requisitos Funcionales

1. Gestión de Reservas
o Perspectiva del producto:
 El sistema permite a los usuarios gestionar reservas de habitaciones
de hotel de manera eficiente y segura.
o Funciones del producto:
 Permitir a los usuarios seleccionar fechas de estancia.
 Validar las fechas seleccionadas para disponibilidad.
 Permitir a los usuarios seleccionar el tipo de habitación.
 Mostrar las habitaciones disponibles según fechas y tipo
seleccionados.
 Permitir a los usuarios introducir su información personal.
 Permitir a los usuarios seleccionar un método de pago.
 Procesar la información de pago y validar la transacción.
 Enviar una confirmación de reserva por correo electrónico.
o Características de los usuarios:
 Usuarios que desean realizar reservas de habitaciones de hotel de
manera conveniente y segura.
o Restricciones:
 El sistema debe cumplir con las regulaciones de protección de datos
locales e internacionales.

o Requisitos funcionales (FORMATO DE CASOS DE USO):

 Caso de uso: Realizar Reserva
 Actor primario: Usuario
 Precondiciones: El usuario está autenticado y ha
seleccionado fechas válidas y tipo de habitación.
 Flujo principal:
1. El usuario selecciona fechas de estancia.
2. El sistema valida la disponibilidad de las fechas.
3. El usuario elige el tipo de habitación.
4. El sistema procesa el pago y valida la transacción.
5. El sistema envía una confirmación de reserva por
correo electrónico al usuario.
 Postcondiciones: Se registra una reserva válida en el sistema.
o Requisitos no funcionales:
 Usabilidad: La interfaz debe ser intuitiva y fácil de usar para
facilitar la reserva de habitaciones.
 Rendimiento: Las solicitudes de reserva deben procesarse en menos
de 3 segundos incluso bajo carga máxima.
 Seguridad: Los datos personales y de pago deben estar encriptados
y protegidos según estándares de seguridad.
 4

2. Autenticación y Autorización
o Perspectiva del producto:
 El sistema garantiza la autenticación segura de usuarios y gestiona
adecuadamente los roles de usuario.
o Funciones del producto:
 Permitir a los usuarios registrarse y crear una cuenta.
 Permitir a los usuarios iniciar sesión con sus credenciales.
 Gestionar diferentes roles de usuario (administrador, usuario
registrado).
o Características de los usuarios:
 Usuarios que requieren acceso seguro y personalizado a las
funcionalidades del sistema.
o Restricciones:
 Las contraseñas deben cumplir con criterios de seguridad mínimos
establecidos por el sistema.
o Requisitos funcionales (formato de casos de uso):
 Caso de uso: Iniciar Sesión
 Actor primario: Usuario
 Precondiciones: El usuario ha creado una cuenta registrada.
 Flujo principal:
1. El usuario ingresa sus credenciales (nombre de
usuario y contraseña).
2. El sistema valida las credenciales.
3. El sistema proporciona acceso a las funcionalidades
según el rol del usuario.
 Postcondiciones: El usuario tiene acceso autorizado al
sistema.
 5

o 3. Requisitos funcionales (formato de casos de uso):

 Caso de uso: Gestionar Cuentas de Usuario
 Actor primario: Administrador
 Precondiciones: El administrador ha iniciado sesión en el
sistema.
 Flujo principal:
1. El administrador selecciona la opción de gestionar
cuentas de usuario.
2. El sistema muestra la lista de usuarios con opciones
para añadir, editar o eliminar cuentas.
3. El administrador realiza las acciones necesarias
(añadir, editar, eliminar).
 Postcondiciones: Los cambios en las cuentas de usuario se
reflejan correctamente en el sistema.
o Requisitos no funcionales:
 Mantenibilidad: El sistema debe permitir una fácil administración
de cuentas de usuario mediante interfaces claras y procesos
eficientes.

4. Gestión de Habitaciones
a. Perspectiva del producto:
i. El sistema facilita la administración de habitaciones y su
disponibilidad para reservas.
b. Funciones del producto:
i. Permitir a los administradores gestionar (añadir, editar, eliminar)
habitaciones.
ii. Permitir a los administradores gestionar la disponibilidad de las
habitaciones.
c. Características de los usuarios:
i. Administradores del hotel que necesitan controlar y actualizar la
información de las habitaciones.
d. Restricciones:
i. Las habitaciones deben ser gestionadas dentro de las capacidades de
espacio y categorización del hotel.
e. Requisitos funcionales (formato de casos de uso):
i. Caso de uso: Gestionar Habitaciones
1. Actor primario: Administrador
2. Precondiciones: El administrador ha iniciado sesión en el
sistema.
3. Flujo principal:
 6

a. El administrador selecciona la opción de gestionar

habitaciones.
b. El sistema muestra la lista de habitaciones con
opciones para añadir, editar o eliminar habitaciones.
c. El administrador realiza las acciones necesarias
(añadir, editar, eliminar).

5. Postcondiciones: Los cambios en las habitaciones se

actualizan correctamente en el sistema.

Requisitos Funcionales

1. Gestión de Reservas
o Número de historia: REF01
o Nombre de la historia: Realizar reserva de habitación
o Usuario: Cliente
o Puntos estimados de esfuerzo: 7
o Descripción de la historia de usuario: Como cliente, quiero poder realizar
una reserva de habitación seleccionando fechas de estancia, tipo de
habitación y método de pago, para planificar mi alojamiento de manera
conveniente.
o Observaciones: Esta historia debe integrarse con el sistema de gestión de
pagos y enviar confirmaciones por correo electrónico.
o Criterios de aceptación:
 El cliente puede seleccionar fechas de estancia válidas.
 El sistema valida la disponibilidad de las fechas y muestra las
habitaciones disponibles.
 El cliente elige el tipo de habitación y proporciona información
personal.
 El sistema procesa el pago de manera segura y envía una
confirmación por correo electrónico.
2. Autenticación y Autorización
o Número de historia: REF02
o Nombre de la historia: Gestionar acceso al sistema
o Usuario: Usuario registrado
o Puntos estimados de esfuerzo: 1.25
o Descripción de la historia de usuario: Como usuario registrado, quiero
poder iniciar sesión en el sistema con mis credenciales y gestionar mi perfil,
para acceder a las funcionalidades según mi rol.
o Observaciones: Esta historia debe garantizar la seguridad de la
autenticación y la gestión adecuada de roles.
o Criterios de aceptación:
 El usuario puede iniciar sesión con su nombre de usuario y
contraseña.
 El sistema valida las credenciales y redirige al usuario a la página
principal.
 El usuario puede actualizar su información personal si es necesario.
 7

3. Gestión de Usuarios
o Número de historia: REF03
o Nombre de la historia: Administrar cuentas de usuario
o Usuario: Administrador del sistema
o Puntos estimados de esfuerzo: 3
o Descripción de la historia de usuario: Como administrador del sistema,
quiero poder gestionar (añadir, editar, eliminar) cuentas de usuario y
exportar informes de reservas, para mantener la base de usuarios y generar
análisis de rendimiento.
o Observaciones: Esta historia requiere privilegios de administrador y
funcionalidades de exportación de datos.
o Criterios de aceptación:
 El administrador puede añadir, editar y eliminar cuentas de usuario.
 El sistema permite exportar informes de reservas semanales,
quincenales, mensuales o anuales en formatos estándar.
4. Gestión de Habitaciones
o Número de historia: REF04
o Nombre de la historia: Administrar disponibilidad de habitaciones
o Usuario: Administrador del hotel
o Puntos estimados de esfuerzo: 2.6
o Descripción de la historia de usuario: Como administrador del hotel,
quiero poder gestionar (añadir, editar, eliminar) habitaciones y actualizar su
disponibilidad, para garantizar una gestión eficiente del inventario.
o Observaciones: Esta historia debe estar integrada con la gestión de reservas
para reflejar disponibilidad actualizada.
o Criterios de aceptación:
 El administrador puede añadir nuevas habitaciones y actualizar
información existente.
 El sistema permite marcar habitaciones como disponibles o no
disponibles según la demanda.
5. Gestión de Pagos
o Número de historia: REF05
o Nombre de la historia: Procesar pagos de reservas
o Usuario: Cliente
o Puntos estimados de esfuerzo: 1.1
o Descripción de la historia de usuario: Como cliente, quiero poder realizar
pagos seguros para confirmar mi reserva de habitación, utilizando diferentes
métodos de pago disponibles.
o Observaciones: Esta historia debe integrarse con pasarelas de pago seguras
y garantizar la confidencialidad de los datos.
o Criterios de aceptación:
 El cliente puede seleccionar entre al menos dos métodos de pago
(por ejemplo, tarjeta de crédito y transferencia bancaria).
 El sistema procesa el pago de manera exitosa y registra la
transacción en el historial del cliente.
 8

Requisitos No Funcionales

1. Usabilidad
o Número de historia: RENF01
o Nombre de la historia: Interfaz intuitiva y asistencia en línea
o Usuario: Todos los usuarios
o Puntos estimados de esfuerzo: 2.33
o Descripción de la historia de usuario: Como usuario del sistema, quiero
una interfaz de usuario intuitiva y asistencia en línea disponible, para
facilitar la navegación y el uso del sistema.
o Observaciones: La usabilidad juega un papel crucial en la satisfacción del
usuario y la efectividad del sistema.
o Criterios de aceptación:
 La interfaz de usuario es clara y fácil de navegar.
 Se proporciona acceso rápido a guías de uso y soporte en línea.
2. Rendimiento
o Número de historia: RENF02
o Nombre de la historia: Optimización del rendimiento
o Usuario: Todos los usuarios
o Puntos estimados de esfuerzo: 6
o Descripción de la historia de usuario: Como usuario del sistema, quiero
que las operaciones de reserva y consulta se realicen en menos de 3
segundos, para una experiencia fluida y eficiente.
o Observaciones: El rendimiento es crucial para evitar la pérdida de usuarios
debido a tiempos de carga prolongados.
o Criterios de aceptación:
 Todas las operaciones principales (reserva, consulta de
disponibilidad, etc.) se completan en menos de 3 segundos bajo
condiciones normales de carga.
3. Seguridad
o Número de historia: RENF03
o Nombre de la historia: Protección de datos sensibles
o Usuario: Administradores y clientes
o Puntos estimados de esfuerzo: 4.5
o Descripción de la historia de usuario: Como usuario del sistema, quiero
que mis datos personales y de pago estén encriptados y protegidos, para
garantizar la confidencialidad y seguridad de la información.
o Observaciones: La seguridad es crucial para cumplir con regulaciones de
protección de datos como PCI-DSS.
o Criterios de aceptación:
 Todos los datos personales y de pago se almacenan encriptados
según estándares de seguridad reconocidos.
 El sistema cumple con las normativas de protección de datos
vigentes.
 9

4. Escalabilidad
o Número de historia: RENF04
o Nombre de la historia: Escalabilidad del sistema
o Usuario: Administradores del sistema
o Puntos estimados de esfuerzo: 1.25
o Descripción de la historia de usuario: Como administrador del sistema,
quiero que el sistema sea escalable para manejar un crecimiento en el
número de usuarios y transacciones, para adaptarse a la demanda fluctuante.
o Observaciones: La escalabilidad es esencial para evitar problemas de
rendimiento con el aumento de la carga de trabajo.
o Criterios de aceptación:
 El sistema puede manejar al menos 100 usuarios simultáneamente
sin degradación significativa del rendimiento.
 Se implementan estrategias para escalar recursos según sea necesario
sin impacto negativo en el servicio.
5. Disponibilidad
o Número de historia: RENF05
o Nombre de la historia: Alta disponibilidad del sistema
o Usuario: Todos los usuarios
o Puntos estimados de esfuerzo: 1.14
o Descripción de la historia de usuario: Como usuario del sistema, quiero
que el sistema esté disponible el 99.9% del tiempo, para poder realizar
reservas y consultas en cualquier momento.
o Observaciones: La disponibilidad es crítica para la satisfacción del cliente y
la operatividad continua del negocio.
o Criterios de aceptación:
 El sistema está disponible y operativo el 99.9% del tiempo,
excluyendo mantenimientos programados.
6. Compatibilidad
o Número de historia: RENF06
o Nombre de la historia: Compatibilidad con navegadores y dispositivos
o Usuario: Todos los usuarios
o Puntos estimados de esfuerzo: 0.60
o Descripción de la historia de usuario: Como usuario del sistema, quiero
que el sistema sea compatible con los principales navegadores web y
accesible desde dispositivos móviles y de escritorio, para poder acceder y
utilizar las funcionalidades sin restricciones.
o Observaciones: La compatibilidad garantiza que todos los usuarios puedan
acceder al sistema independientemente del dispositivo o navegador
utilizado.
o Criterios de aceptación:
 El sistema es compatible con los navegadores web más populares
como Chrome, Firefox, Safari y Edge.
 El sistema es accesible desde dispositivos móviles y de escritorio sin
comprometer la experiencia de usuario.
 10

7. Mantenibilidad
o Número de historia: RENF07
o Nombre de la historia: Mejora continua del sistema
o Usuario: Desarrolladores y administradores del sistema
o Puntos estimados de esfuerzo: 0.66
o Descripción de la historia de usuario: Como desarrollador o administrador
del sistema, quiero que el código esté bien documentado y estructurado, para
facilitar futuras actualizaciones y mejoras sin interrumpir el servicio.
o Observaciones: La mantenibilidad asegura que el sistema pueda adaptarse
fácilmente a cambios y nuevas funcionalidades sin afectar su estabilidad.
o Criterios de aceptación:
 El código del sistema está documentado de manera clara y completa.
 Se pueden realizar actualizaciones y mejoras de forma regular sin
impactar negativamente la operación del sistema.

Estas historias de usuario complementan los requisitos funcionales y no funcionales,

proporcionando una visión detallada de cómo los usuarios interactúan con el sistema y qué se
espera lograr con cada funcionalidad y característica del sistema de reservas y pagos para el hotel.
Podremos de manera más dinámica y por medio de tablas podremos identificar los requisitos
funcionales y NO funcionales.
 11

Conclusión

Con esta estructura detallada, cada requisito funcional y no funcional está claramente
descrito según los elementos del estándar IEEE 830. Esto proporciona una guía completa
para el desarrollo, implementación y evaluación del sistema de reservas y pagos para el
hotel, asegurando que todos los aspectos críticos del proyecto sean adecuadamente
abordados y documentados. Se deben abordar una variedad de requisitos para satisfacer las
expectativas de los usuarios y cumplir con las demandas del negocio. Esto facilita el
desarrollo de un sistema robusto y adaptado a las necesidades específicas del sector
hotelero, mejorando así la experiencia del cliente y optimizando la eficiencia operativa del
hotel.