Introducción En este apartado se va a proporcionar una apreciación global del SRS.

Transcripción

1 INTRODUCCIÓN Se pretende desarrollar una aplicación web para la gestión de un restaurante que ofrece espectáculos en fechas determinadas con el fin de poner en práctica los principios de planificación y gestión de proyectos y de Ingeniería de Software mostrados en el programa teórico de la asignatura. La metodología de desarrollo a utilizar será el Proceso Unificado de Desarrollo y el lenguaje de modelado será UML. Se requiere que la interfaz de la aplicación sea gráfica y que todos los informes generados puedas ser exportados a hojas de cálculo de MS Excel. 2

2 DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar e incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios), que imponen restricciones al diseño o funcionamiento del sistema. Las estrategias recomendadas para la especificación de los requisitos del software están descritas según el estándar IEEE (IEEE Recommended Practice for Software Requirements Specifications). Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software. Introducción En este apartado se va a proporcionar una apreciación global del SRS. 1. Propósito El propósito del SRS es conseguir una estructura bien definida y un documento bien formado de los requisitos del sistema. El público intencional al que va dirigido el SRS es el cliente. En particular, para esta práctica los clientes serían los profesores de la asignatura. 2. Alcance El nombre correspondiente al producto software a desarrollar es Restaurant Aplication Web (RAW). Acciones que debe realizar el producto software: o Gestión de los recursos del restaurante: adición, modificación y eliminación por parte del administrador. o Emisión de resúmenes: procesamiento de las reservas registradas, de los resultados económicos y de la actividad de un cliente registrado. o Visualización de los próximos espectáculos y realización de reservas por parte de los usuarios. Acciones que no debe realizar el producto software: o El grupo de trabajo se ceñirá a las peticiones expresas del cliente sobre el funcionamiento básico de la aplicación. Beneficios, objetivos y metas del producto software: o Se pretende automatizar las gestiones de reserva y administración de recursos de un restaurante con servicio de espectáculos. Incrementando la eficiencia de las operaciones y pudiendo así incrementar los beneficios. o La aplicación pretende dar soporte a los usuarios permitiendo así el acceso y gestión en remoto de las actividades propias del restaurante. o Además de estas mejoras que se ofrecen de cara al público, el sistema también supondrá una mejora administrativa para el restaurante, ya que se darán opciones para la gestión de los gastos de cada usuario registrado además de poder llevar un control de los 3

3 gastos y disponibilidad de los recursos en cada momento. o Creación de una aplicación que permita gestionar todo lo referente a las reservas y tratamiento de los recursos de un restaurante mediante RAW, de manera fácil e intuitiva por parte del cliente. 3. Definiciones, siglas y abreviaciones No se utiliza ninguna. 4. Referencias Para la realización de este proyecto hemos utilizado únicamente las especificaciones facilitadas por el cliente en la solicitud del trabajo. 5. Apreciación global Para la realización de este documento SRS se ha utilizado la base estándar de especificación de requisitos software IEEE-STD

4 Descripción global 1. Perspectiva del producto El sistema a desarrollar es independiente y tiene total autonomía. Interfaces del sistema El sistema no interactúa con otro sistema, por lo que no hay interfaces de este tipo. Interfaces con el usuario La interfaz con la que interactuará el usuario es de tipo Web y será manejada a través de los clientes y el administrador. Para su correcto acceso se deberá introducir la dirección correcta en un navegador Web. Tras la conexión con la página principal de la aplicación, el usuario tendrá la opción de registrarse o de no hacerlo para tener acceso a las distintas funcionalidades de la aplicación. Dicha interfaz tendrá la opción de permitirle al cliente realizar una reserva de mesa o confirmar la asistencia a un determinado evento. También tendrá la posibilidad de imprimir un resumen de las acciones realizadas por él. El administrador tendrá la opción de realizar modificaciones en los clientes, reservas, espectáculos y mesas. Además será capaz de imprimir un resumen de los resultados económicos en un determinado momento y de visualizar la actividad de un cliente registrado. Interfaces con el hardware Para la interfaz hardware será necesario el uso de un computador debidamente configurado con posibilidad de conexiones TCP. Interfaces con el software El usuario no requiere un sistema operativo en concreto para el correcto funcionamiento de la aplicación Web. Además tendrá la posibilidad de ser ejecutada en cualquier tipo de navegador. En el servidor se utilizará una base de datos para el correcto almacenamiento de la información relativa al soporte del sistema. Interfaces de comunicaciones Se requerirá un dispositivo que soporte acceso a internet y un protocolo de transferencia de recursos HTTP debidamente configurados. Será necesario que el servidor soporte un gran número de conexiones externas simultáneas. Restricciones de memoria Para el funcionamiento de esta aplicación por parte del cliente no será necesario un gran uso de memoria. Sin embargo, en el servidor será necesaria una mayor capacidad en nuestros dispositivos de almacenamiento para dar cabida a toda la información requerida. 5

5 Funcionamientos Para el correcto funcionamiento de esta aplicación será necesario un servidor conectado permanentemente a internet y que sea siempre visible desde el entorno externo a su red local. Debido a que nuestra aplicación utiliza tanto una base de datos como un servidor web es posible que se produzcan fallos ajenos a la aplicación, en cuyo caso será competencia del equipo de mantenimiento solventar dichas anomalías técnicas para mantener el sistema inoperativo el menor tiempo posible. Por parte de usuario solo será necesario conocer la URL exacta a la que conectarse para iniciar el asistente y que el usuario tenga tanto unos conocimientos mínimos de navegación web, como una correcta configuración de su sistema local. Requisitos de adaptación del Site No existen requisitos de adaptación, a priori. 2. Funciones del producto Dividimos esta sección en dos partes bien diferenciadas que serán las funciones atribuidas al usuario y por otro lado las designadas al administrador Web. Funciones del usuario: o Visualizar los espectáculos: El sistema permitirá a través de esta función ver todos los espectáculos disponibles en un determinado rango de fechas. o Realizar reserva de espectáculo: El sistema ofrece la posibilidad de realizar una reserva para un espectáculo determinado, con o sin mesa. o Realizar reserva de una mesa: Se podrá realizar una reserva de una mesa en un día determinado, en el cual puede haber o no un espectáculo. Funciones del administrador Web: o Relativas a cliente: Añadir cliente: El sistema deberá permitir dar de alta a un nuevo cliente. Modificar cliente: El sistema permitirá actualizar los datos de un cliente determinado. Eliminar cliente: El sistema tendrá la posibilidad de dar de baja a un cliente. 6

6 o Relativas a reservas: Añadir reserva: El sistema deberá permitir la realización de una nueva reserva. Modificar reserva: El sistema permitirá actualizar los datos de una reserva. Eliminar reserva: El sistema tendrá la posibilidad de suprimir una reserva. o Relativas a espectáculos: Añadir espectáculo: El sistema deberá permitir la inclusión de un nuevo espectáculo. Modificar espectáculo: El sistema permitirá actualizar los datos de un espectáculo. Eliminar espectáculo: El sistema tendrá la posibilidad de eliminar un espectáculo determinado. o Relativas a mesas: Añadir mesa: El sistema deberá permitir añadir una nueva mesa en el restaurante. Modificar mesa: El sistema permitirá actualizar los datos de una mesa determinada. Eliminar mesa: El sistema tendrá la posibilidad de suprimir una mesa. o Resumen de las reservas registradas: El sistema debe ser capaz de mostrar los datos de las reservas realizadas para un espectáculo determinado. o Resumen de resultados económicos: El sistema será capaz de imprimir los resultados económicos entre un rango de fechas en función de las reservas realizadas en dicho periodo. o Resumen de la actividad de un cliente: El sistema mostrará el resumen de todas las actividades realizadas por un cliente. 7

7 o Listado de usuarios: El sistema será capaz de listar todos los usuarios dados de alta en el sistema. 3. Características del usuario Para el usuario común solo se requerirá un nivel educativo medio y unos conceptos básicos a nivel de usuario en aplicaciones informáticas, debido a la sencillez en la utilización de la aplicación no tendrá ningún tipo de dificultad en usarla. Por otra parte, el administrador Web necesitará una formación media para el control absoluto de la aplicación. 4. Restricciones Las restricciones o limitaciones que se nos pueden presentar en el desarrollo de la aplicación a nivel hardware en el servidor pueden ser: la capacidad de la memoria principal y la velocidad del procesador. 5. Atenciones y dependencias Para nuestra aplicación, de nuevo debemos dividir este punto en dos subapartados: Por parte del cliente: Solo necesitaremos un navegador WEB con acceso a internet, ya que nuestra aplicación está diseñada para funcionar en su mayor parte en un servidor. Por parte del administrador del sistema: En este caso necesitamos más recursos para el funcionamiento de la aplicación. En este caso necesitamos que el sistema sea estable, ya que si realizamos cambios en alguna de las herramientas necesarias para el correcto funcionamiento, se deberían reconfigurar todas las demás. 6. Prorratear los requisitos Debido a las cualidades de nuestro proyecto, la aplicación será estable y no requerirá de ninguna otra entrega. Por tanto no tenemos previsto realizar modificaciones posteriores. Requisitos específicos Interfaces externas Nuestra aplicación debe interactuar a través de las interfaces adecuadas con: la BBDD que almacena que almacena los usuarios, reservas, espectáculos y mesas. Estas interfaces serán sencillas con operaciones que permitan almacenar, recuperar, modificar los contenidos de las BBDD s. 8

8 Funciones Las funciones de nuestra aplicación son: Funciones del usuario: o Visualizar los espectáculos: Para realizar dicha función se procederá consultando los datos almacenados en la Base de Datos. o Realizar reserva de espectáculo y/o mesa: Se verificará la entrada de datos por parte del usuario, y una vez cotejados se procederá a la reserva, e inserción en la Base de Datos. Funciones del administrador Web: o Relativas a cliente: Añadir cliente: El sistema comprobará la veracidad de los datos introducidos por el usuario, además de la existencia de un nombre de usuario idéntico registrado previamente en el sistema. Modificar cliente: En este caso, el sistema buscará la existencia en la base de datos del usuario requerido para la modificación. Una vez localizado se procederá a la actualización en la Base de Datos con los nuevos datos introducidos. Eliminar cliente: Este funcionamiento es muy similar al de punto anterior, salvo que la actualización de datos en el sistema sería una eliminación de la ficha del cliente. o Relativas a reservas: Añadir reserva: El sistema comprobará la veracidad de los datos introducidos por el administrador, además de la existencia de la disponibilidad de recursos. Modificar reserva: El sistema comprobará que existe una reserva previamente realizada y modificará los datos siempre que sea posible. Eliminar reserva: Al igual que en el apartado anterior, el sistema localizará la reserva y la eliminará. 9

9 o Relativas a espectáculos: Añadir espectáculo/mesa: El sistema comprobará que no haya solapamiento en estos recursos. Modificar/Eliminar espectáculo/mesa: El sistema localizará la entrada correspondiente en la base de datos que represente el dato que queremos editar. o Resumen de las reservas registradas: El sistema buscará en la base de datos todas las reservas activas para posteriormente poder mostrarlas. o Resumen de resultados económicos: El sistema localizará todos los datos de cuentas, y realizará las operaciones a fin de generar un detallado informe con el balance económico de nuestro restaurante. o Resumen de la actividad de un cliente: El sistema reunirá todas las acciones llevadas a cabo por un cliente y las mostrará. o Listado de usuarios: El sistema buscará todos los clientes registrados en nuestra aplicación y realizará un documento con la información recolectada. Requisitos del desarrollo De manera estática tendremos un único terminal que será el servidor, siempre disponible para el funcionamiento de la aplicación. De manera dinámica tendremos un número de usuarios máximo determinado por un cierto límite establecido por los creadores de la aplicación. Requisitos del banco de datos lógicos Tenemos una BBDD que almacenará los datos que utilizará nuestra aplicación. Tanto los clientes como el administrador accederán a ella cada vez que necesiten consultar información o modificarla. Restricciones del diseño Nuestra aplicación no tiene ningún tipo de restricción por estándares o limitaciones del hardware. Atributos del software del sistema Fiabilidad La aplicación tendrá que ser fiable en cuanto a los datos se refiere para no generar ningún tipo de conflicto en las reservas y en la consulta de estas. 10

10 Disponibilidad Nuestra aplicación debe estar disponible en todo momento para mayor comodidad del cliente. Seguridad Por el diseño de nuestra aplicación el único que tendrá acceso a la información de los clientes almacenada en la base de datos será el administrador evitando así cualquier problema de privacidad. Mantenimiento Según está diseñada nuestra aplicación no debería tener ningún tipo de problema en el futuro con respecto al funcionamiento. Pero si sucediera el caso disponemos de un teléfono de atención al cliente disponible las 24 horas del día para solucionar el problema con la mayor brevedad posible. Portabilidad En la elaboración de nuestra aplicación se han tenido en cuenta las distintas plataformas utilizables y se ha intentando no utilizar nada concreto de ningún sistema para conseguir una mayor compatibilidad con todas las plataformas posibles. Organizar los requisitos específicos Modo del sistema Debido a la simplicidad de nuestra aplicación no disponemos de ningún modo de sistema. Clases de usuario Debido a nuestro diseño disponemos de dos clases de usuario, uno perteneciente al cliente y otro al administrador. Objetos Rasgo En nuestra aplicación podemos considerar como objetos tanto los clientes como el administrador en cuanto a personas que utilizaran la aplicación y en cuanto a objetos empotrados en el sistema tendremos mesas, espectáculos, menús, etc. Para nuestra aplicación los rasgos principales serian la agregación, consulta y modificación en la base de datos. 11

11 Estímulo En función de la información obtenida se procederá a realizar la acción adecuada. Contestación Confirmaciones de reservas, respuestas de consultas emitidas y resumen de actividad de cliente y reservas. 12