ERS | reservesoft

Especificación de requisitos del sistema

1. Introducción

1.1. Propósito

El presente documento presentará de forma organizada los requisitos que son indispensables para desarrollar un sistema de información, en función al software que se desea desarrollar.

Este documento está estructurado en base al estándar IEEE Recommended Practice for Software Requirements Specification ANSI/IEEE 830 1998.

1.2. Alcanse

El propósito general de este documento es darle a conocer al cliente una visión general, detalla y especificada de lo que se pretende desarrollar a partir de los requisitos del negocio, además de la forma correcta de trabajar en el sistema ReserveSoft.

1.3. Personal involucrado

1.4. Definiciones, acronimos y abreviaturas

HW – Hardware

SF – Software

BD - Base de datos

SGBD – Sistema gestor de base de datos

CU – Caso de uso

CUN – Caso de uso del negocio

Red LAN – Red local

Hosting – Alojamiento web

So – Sistema operativo

1.5. Referencias

1.6. Resumen

Este documento sirve como referencia entre el cliente y la empresa desarrolladora acerca de las características del software ReserveSoft a desarrollar.

2. Descripción general

En esta sección se describen las características del producto ReserveSoft a desarrollar.

Misión: Crear un sistema de información que permita el manejo de los procesos de paquetes turísticos entre otros de la empresa El ‘Dorado’.

Visión: Desarrollar un software de calidad que permita a la empresa desarrolladora posicionarse en el mercado de desarrollo de software al nivel nacional y mundial.

Logotipo

Colore

Celeste: la elección del color celeste fue por porque dentro de los valores de en nuestra empresa destacamos el valor del cuidado ambiental.

Grises (escala): la elección del color gris fue por que el sistema es tan adaptable como el color en su forma natural apto para cualquier persona que lo usa.

Forma

Cubos: porque nuestro sistema cuenta con diversas aplicaciones: altas, bajas y cambios.

2.1. Perspectiva del producto

Este sistema funcionará en un ambiente donde exista una red LAN, el cual contendrá un manejo de una base de datos sobre los paquetes turísticos entre otros.

Se desarrollará el sistema en una versión de escritorio y web, los usuarios utilizarán las aplicaciones a través de menus que serán validados previamente.

2.2. Funcionalidad del producto

El sistema se encargará de las siguientes funciones:

Gestión Administrativa
- Reporte
- Gestión de usuarios del sistema
Gestión de alquiler de hospedaje
Gestión de reserva de hospedaje

2.3. Caracteristicas de los usuarios

2.4. Restricciones

SO:El SW a desarrollar funcionará en Windows 7 o versiones posteriores.

Navegador:Para el entorno web se utilizará IE 9 en adelante y navegadores compatibles

Red LAN:Debe existir un Red LAN para las reservas de las habitaciones dentro de la agencia, así como la gestión del sistema

Servidores:Debe existir un servidor web y hosting para que el software pueda ejecutarse en un entorno web.

Seguridad:Debe implementarse políticas de seguridad para el manejo de la información tanta del HW y SW.

Autenticación: Sólo los usuarios registrados podrán hacer uso del sistema.

2.5. Suposiciones y dependencias

En caso de que el equipo de cómputo utilice un SO diferente a los mencionados en la sección anterior, el sistema no podrá ejecutarse.

2.6. Evolución previsible del sistema

En caso de que la tienda cuente, en un futuro, con una sucursal, el sistema se modificará para convertirlo en un sistema distribuido.
En caso de que la tienda cuente con internet, las compras se podrán realizar en línea, si así lo deseara el usuario administrador.
Se podrá implementar una versión móvil para dispositivos móviles.
Se podrá actualiza el software con nuevas versiones de acuerdo a la evolución de las tecnologías de información

Todos estos cambios son sujetos a nuestro contrato de desarrollo de software.

3. Requisitos específicos

3.1. Requisitos comunes de interfaces

La interfaz de login necesita como entrada un usuario y contraseña válidos para poder dar acceso a la siguiente interfaz.
La interfaz del módulo de registros necesita como entrada el identificador del tipo de habitación que quiere reservar el cliente. Como salida arrojará el total a pagar por la reserva que deberá pagar el cliente.
La interfaz del módulo de clientes necesita como entrada los datos del cliente en caso de que se le otorgue por primera vez un crédito.

Para consultar el saldo de un cliente, la interfaz necesita como entrada el identificador del cliente, arrojando como salida el nombre y el saldo.

Para abonar una cuenta, la interfaz necesitará como entrada el identificador del cliente y el monto que deja, arrojando como salida el saldo que le resta después de restar el monto del abono.

3.1.1. Interfaces del usuario

La interfaz en uso deberá mostrar a los usuarios solamente la información necesaria para realizar cualquier operación.
La interfaz en uso deberá mostrarle al usuario administrador sólo la información necesaria para realizar una modificación.

3.1.2. Interfaces del hardware

El monitor: éste deberá mostrar las interfaces así como la información necesaria para que el usuario pueda trabajar adecuadamente con el sistema
El ratón: el sistema requerirá del ratón para que el usuario pueda realizar selecciones y oprimir botones.
El teclado: el sistema permitirá al usuario introducir datos mediante el teclado.
La impresora de comprobantes de pago: el sistema arrojará el desglose de la compra a través un ticket para el cliente.

3.1.3. Interfaces de software

El sistema interactuará con la interfaz de impresión. El cual imprimirá los comprobantes de pago

3.1.4. Interfaces de comunicación

El sistema se comunica con su base de datos a través del SGBD SQLServer.

3.2. Requisitos funcionales

El sistema permitirá la entrada a los usuarios que cuenten con la autorización necesaria.
El sistema recibirá los datos de clientes y reservas almacenándolos en la base de datos para futuras consultas y diversas operaciones.
Si se hubiera algún error al momento de la reserva, el sistema deberá permitir retroceder, es decir, deshacer la operación.

3.2.1. Requisito funcional 1

El usuario deberá proporcionar un usuario y contraseña válidos para poder tener acceso al sistema.

3.2.2. Requisito funcional 2

El sistema calculará el monto de la reserva a partir de los identificadores de los precios de las habitaciones que el cliente desee reservar, buscando con ellos el precio de cada uno.

3.2.3. Requisito funcional 3

Para poder imprimir un comprobante de pago al cliente primero deberá registrarse dicha venta (sin importar su naturaleza) en la base de datos.

3.3. Requisitos no funcionales

El SI permitirá el horario de atención por consultorio externo desde las 8:00 am hasta las 9:00 pm
El SI generará reportes en el plazo no mayor de 1 minuto.
El SI generará la contabilidad de los servicios en un tiempo no mayor a 2 minutos.

3.3.1. Requisitos de rendimiento

Requisito de respuesta

El sistema ofrecerá respuesta al usuario en tiempo real.

3.3.2. Requisitos de seguridad

Requisito no funcional-Seguridad 1: Requisito de autenticación

El sistema requerirá de un usuario y contraseña válidos para poder permitir el acceso.

Requisito no funcional-Seguridad 2: Requisito de división de módulos

El sistema tendrá separados los módulos a los que puede acceder un usuario convencional de los módulos a los que puede acceder el usuario administrador.

Requisito no funcional-Seguridad 3: Requisito de conexión.

El sistema sólo tendrá abierta la conexión a la base de datos mientras se ejecuta la transacción.

Requisito no funcional-Seguridad 4: Requisito de copia de seguridad

El sistema realizará una copia de seguridad periódicamente siempre y cuando encuentre la conexión cerrada, de lo contrario lo intentará más tarde.

3.3.3. Requisitos de fiabilidad

Requisito no funcional-Fiabilidad 1: Requisito de conexión.

El sistema cerrará las conexiones inmediatamente terminando cualquier ejecución para evitar pérdida de datos a cualquier percance inesperado.

3.3.4. Requisitos de disponidad

Requisito no funcional-Disponibilidad 1: Requisito de funcionamiento.

En funcionamiento normal el sistema estará disponible el 70% del tiempo.

3.3.5. Requisitos de mantenibilidad

Requisito funcional-Mantenibilidad 1: Requisito de mantenimiento

El sistema recibirá mantenimiento una vez por semana los primeros 6 meses.

Requisito funcional-Mantenibilidad 2:

Requisito de depuración de respaldos de bases de datos.

Se revisarán los respaldos de la base de datos para decidir si es necesaria una depuración.

Requisito funcional-Mantenibilidad 3: Requisito de actualización de estadísticas.

Se actualizarán las estadísticas manualmente para no perjudicar el rendimiento con una actualización automática.

Requisito funcional-Mantenibilidad 4: Requisito de comprobación de integridad de datos.

Se comprobará la integridad y asignación estructural de objetos e índices de la base de datos.

3.3.6. Requisitos de portabilidad

Requisito funcional-Portabilidad 1:

ReserveSoft será portable siempre y cuando el equipo en que se quiera instalar cuente con un SO igual o de versión posterior al primer equipo donde se instaló.

Requisito funcional-Portabilidad 2: Requisito de HW

ReserveSoft será portable siempre y cuando el equipo en el que se instale tenga especificaciones de HW iguales o superiores al primer equipo donde se instaló.

3.4. Otros requisitos

Si el usuario empleado quiere realizar alguna modificación deberá ser necesario que se presente el usuario administrador con su contraseña, salir de la sesión del usuario empleado y entrar a la suya.

4. Apendices

Entrevista

Entrevista realizada para recopilar los requerimientos del sistema, por Anabelen Mendoza y Jeyffer Vargas López.

1. ¿Qué módulos desea se encuentren en el sistema?

Registro de reservas

Registro de alquiler

Reportes

2. ¿Necesita que tenga diferentes sesiones, o sólo será una?

Diferentes como la del administrador y la de los recepcionistas.

3. ¿Necesita que la o las sesiones tengan contraseña?

Si. Porque es más seguro para el manejo

Contraseña sugerida por el cliente: FG7415369