SIBO Sistema de Información de Boletería Especificación de Requerimientos Versión 1.0
Historial de Revisión Fecha Versión Descripción Autor 14/09/2009 1.0 Documento que contiene los principales requerimientos de la aplicación. Andres Botia, Juan Corchuelo, Jose Moreano, Camilo Prieto, Alirio Rivera. Derechos Reservados SIBO, 2009 Página 2
Tabla de Contenido 1. Introducción 4 2. Descripción General 4 2.1 Modelo de Casos de Uso 2.2 Inspección del Modelo de Casos de Uso 5 3. Requerimientos Específicos 6 3.1 Reportes de Casos de Uso 6 Derechos Reservados SIBO, 2009 Página 3
1. Introducción Especificación de Requerimientos Se analizan las principales necesidades que la aplicación va a solucionar usando el modelo de casos de uso. Luego se presentan los diferentes requerimientos, con su respectiva descripción donde se reflejan los actores que intervienen junto a sus actividades. Finalmente se presenta el flujo principal y los flujos alternativos para los diferentes casos de uso garantizando un buen análisis en el funcionamiento del sistema. 2. Descripción General 2.1 Modelo de Casos de Uso Figura 1. Diagrama de Casos de Uso Derechos Reservados SIBO, 2009 Página 4
2.2 Inspección del Modelo de Casos de Uso Código Caso de Uso Actores participantes 1 Validar ingreso Administrador, Vendedor 2 Registrar evento Administrador 3 Eliminar evento Administrador 4 Registrar vendedor Administrador 5 Generar reporte de ventas Administrador 5.1 Por fecha Administrador 5.2 Por evento Administrador 6 Vender boleta Vendedor 7 Imprimir boleta Vendedor 8 Cancelar venta de boleta Vendedor 9 Consultar boletería evento Vendedor, Administrador, Usuario 10 Registrar usuario Usuario 11 Comprar boleta Usuario 12 Reservar boleta Usuario 13 Consultar datos Vendedor Administrador Derechos Reservados SIBO, 2009 Página 5
3. Requerimientos Específicos 3.1 Reportes de Casos de Uso Caso de Uso: Validar Ingreso ID: 1 Actores primarios: Administrador, Vendedor Actores secundarios: Pre-condiciones: Ninguna Flujo principal 1. El sistema muestra los campos donde el actor deberá ingresar sus datos de nombre de usuario y contraseña, el botón de acceso al sistema y una lista desplegable donde podrá escoger el rol que desempeña, bien sea administrador o vendedor. 2. El actor ingresa todos los datos solicitados para ingresar al sistema. 3. El actor oprime el botón de acceso al sistema. 4. Los datos son verificados por el sistema. 5. Los datos son validos y el actor ingresa exitosamente. Post-condiciones: El actor ingresa al sistema identificado con un rol que le permitirá manipular el sistema con actividades muy específicas. Flujos alternativos - El actor en el paso 2 coloca datos inválidos o deja campos sin llenar, por lo tanto en el paso 4 el sistema le avisara las inconsistencias y el usuario no podrá acceder al sistema. - El actor cancela la operación antes de llegar al paso 3. Derechos Reservados SIBO, 2009 Página 6
Caso de Uso: Registrar Evento ID: 2 Actores primarios: Administrador Actores secundarios: Pre-condiciones: Haber validado el ingreso al sistema identificado con el rol de administrador. Flujo principal 1. El sistema le muestra al actor las opciones establecidas para el rol de administrador. 2. El actor escoge la opción de registrar un nuevo evento. 3. El sistema muestra los campos necesarios para que el actor ingrese la información necesaria de un evento, el botón de envío de la información y el botón para cancelar la operación. 4. El actor ingresa la información pertinente del evento en los campos dispuestos para ello. 5. El actor oprime el botón para el envío de la información. 6. Los datos son verificados por el sistema. 7. Los datos son validos y el sistema registra en su base de datos el nuevo evento. Post-condiciones: Un nuevo evento es registrado en el sistema con toda la información pertinente para que pueda ser consultado por otros usuarios del sistema. Flujos alternativos - El actor en el paso 2 escoge una opción diferente. - El actor en el paso 4 deja campos sin llenar por lo tanto el sistema en el paso 6 notificará la inconsistencia. - El actor cancela la operación antes de llegar al paso 5. Derechos Reservados SIBO, 2009 Página 7
Caso de Uso: Eliminar Evento ID: 3 Actores primarios: Administrador Actores secundarios: Pre-condiciones: Haber validado el ingreso al sistema identificado con el rol de administrador. Flujo principal 1. El sistema le muestra al actor las opciones establecidas para el rol de administrador. 2. El actor escoge la opción de eliminar un evento. 3. El sistema muestra un listado de los eventos disponibles para eliminación, el botón de eliminar y el botón para cancelar la operación. 4. El actor escoge un evento de la lista 5. El actor oprime el botón para eliminar el evento. 6. El sistema pide confirmación de la operación. 7. El actor confirma la operación. 8. El evento es eliminado de la base de datos del sistema. Post-condiciones: Un evento escogido por el actor es eliminado de la base de datos del sistema bien sea por la cancelación del mismo o por cualquier otra situación. Flujos alternativos - El actor en el paso 2 escoge una opción diferente. - El actor en el paso 4 no escoge un evento para eliminar por lo tanto el sistema avisará este hecho al actor y volverá a pedir al actor que escoja un evento para eliminación. - El actor cancela la operación antes de llegar al paso 5. - El actor en el paso 7 no confirma la operación y el sistema volverá a pedir al actor que escoja un evento para eliminación. Derechos Reservados SIBO, 2009 Página 8
Caso de Uso: Registrar Vendedor ID:4 Actores primarios: Administrador Actores secundarios: Pre-Condiciones: Ninguna Flujo Principal: 1. El actor se identifica dentro del sistema, colocando los datos de nombre de usuario y contraseña 2. El Sistema muestra una ventana con las opciones que de acuerdo a su rol puede realizar el actor en el sistema. 3. El actor elije la opción de registrar un nuevo vendedor 4. El sistema muestra una nueva ventana con un formulario en el cual se podrán ingresar todos los datos necesarios para registrar el nuevo vendedor. 5. El actor oprime el botón de registro de nuevo vendedor 6. El sistema valida los datos que fueron ingresados en busca de errores como falta de datos o tipo de datos ingresados en algunos campos. 7. Los datos son validos y se registra el nuevo vendedor dentro de la base de datos del sistema. Post-Condiciones: El actor vuelve a la ventana de elección de acciones de acuerdo al rol con el cual ingreso al sistema. Flujos Alternativos: 1. El actor en el paso 4 coloca datos que no son validos en términos de tipo de datos o espacios en blanco, por lo tanto el sistema en el paso 6 avisa al actor de las inconsistencias presentadas durante la validación. 2. El actor cancela la operación antes de llegar al paso 4 Derechos Reservados SIBO, 2009 Página 9
Caso de Uso: Generar reporte de ventas ID: 5 Actores Primarios: Administrador Actores Secundarios: Precondiciones: Ninguna Flujo Principal: 1. El actor se identifica dentro del sistema colocando datos de nombre de usuario y contraseña. 2. El sistema muestra una ventana con las opciones que de acuerdo a su rol puede realizar el actor en el sistema. 3. El actor elije la opción generar reportes oprimiendo el botón con esa opción. 4. El sistema muestra una ventana en la cual en la cual se muestra un formulario con el cual el actor elije el tipo de reporte que necesita- 5. El actor elije la opción generación por fecha o evento 6. El actor oprime el botón generar reporte. 7. El sistema muestra una nueva ventana en la cual se muestra el reporte que el actor eligió. Post-Condiciones: El actor vuelve a la ventana de elección de actividades de acuerdo a su rol. Flujos Alternativos: - El actor cancela la operación antes de llegar al punto 3 del flujo principal. - El actor elige otra opción dentro de la ventana que se muestra en el punto 2 del flujo principal. Puntos de extensión: - Caso de uso 5.1 - Caso de uso 5.2 Derechos Reservados SIBO, 2009 Página 10
Caso de Uso: Generar reporte de ventas por fecha ID: 5.1 Actores Primarios: Administrador Actores Secundarios: Precondiciones: Ninguna Flujo Principal: 1. El actor se identifica dentro del sistema colocando datos de nombre de usuario y contraseña 2. El sistema muestra una ventana con las opciones que de acuerdo a su rol puede realizar el actor en el sistema. 3. actor elije la opción generar reportes oprimiendo el botón con esa opción 4. El sistema muestra una ventana en la cual en la cual se muestra un formulario con el cual el actor elije el tipo de reporte que necesita. 5. El actor elije la opción generación por fecha y elije desde un calendario las fechas para mostrar el reporte 6. El actor oprime el botón generar reporte. 7. El sistema muestra una nueva ventana en la cual se muestra el reporte que el actor eligió. Post-Condiciones: - El actor vuelve a la ventana de elección de actividades de acuerdo a su rol. Flujos Alternativos: - El actor cancela la operación antes de llegar al punto 3 del flujo principal. - El actor elige otra opción dentro de la ventana que se muestra en el punto 2 del flujo principal. Derechos Reservados SIBO, 2009 Página 11
Caso de Uso: Generar reporte de ventas por evento ID: 5.2 Actores Primarios: Administrador Actores Secundarios: Precondiciones: Ninguna Flujo Principal: 1. El actor se identifica dentro del sistema, colocando datos de nombre de usuario y contraseña. 2. El sistema muestra una ventana con las opciones que de acuerdo a su rol puede realizar el actor en el sistema. 3. El actor elije la opción generar reportes oprimiendo el botón con esa opción 4. El sistema muestra una nueva ventana en la cual se muestra un formulario con el cual el actor elije el tipo de reporte que necesita. 5. El actor elije la opción generación por evento y elije desde una lista los eventos que existen dentro de la base de datos del sistema. 6. El actor oprime el botón generar reporte 7. El sistema muestra una nueva ventana en la cual se muestra el reporte que el actor eligió. Post-Condiciones: - El actor vuelve a la ventana de elección de actividades de acuerdo a su rol. Flujos Alternativos: - El actor cancela la operación antes de llegar al punto 3 del flujo principal. - El actor elige otra opción dentro de la ventana que se muestra en el punto 2 del flujo principal. Derechos Reservados SIBO, 2009 Página 12
Caso de Uso: Vender Boleta ID: 6 Actores primarios: Vendedor Actores secundarios: Pre-condiciones: - Haber validado el ingreso al sistema identificado con el rol de vendedor. - Que exista al menos una boleta disponible para el evento. Flujo principal 8. El sistema le muestra al actor las opciones establecidas para el rol de vendedor. 9. El actor escoge la opción de vender una boleta. 10. El sistema muestra una lista de los eventos que tienen boletería disponible, organizados por fecha. 11. El actor selecciona el evento para el cual se venderá la boleta. 12. El sistema muestra una lista desplegable con la ubicación y el precio. Los campos para ingresar el número de boletas a vender, nombre del comprador, cedula del comprador, un recuadro que indica las boletas disponibles y un botón para confirmar. 13. El actor ingresa todos los datos solicitados por el sistema. 14. El actor oprime el botón de confirmación. 15. Los datos son verificados por el sistema. 16. Los datos son validos y el sistema registra en su base de datos la nueva venta. Post-condiciones: Una nueva venta es registrada en el sistema con toda la información pertinente para que pueda ser consultada posteriormente. Flujos alternativos - El actor en el paso 2 escoge una opción diferente. - El sistema en el paso 3 no encuentra eventos con boleteria disponible, mostrará un mensaje notificando boleteria agotada y regresara al paso 1. - El actor en el paso 6 no selecciona ubicación, ingresa datos inválidos ó deja campos sin llenar, por lo tanto en el paso 8 el sistema le avisará las inconsistencias y volverá al paso 5. Derechos Reservados SIBO, 2009 Página 13
Caso de Uso: Imprimir Boleta ID: 7 Actores primarios: Vendedor Actores secundarios: Pre-condiciones: - Haber validado el ingreso al sistema identificado con el rol de vendedor. - Que la boleta se encuentre vendida y aun no haya sido impresa. Flujo principal 9. El sistema le muestra al actor las opciones establecidas para el rol de vendedor. 10. El actor escoge la opción de imprimir boleta. 11. El sistema muestra un listado de los eventos que tienen boletas vendidas y no impresas, un campo donde el actor deberá ingresar la cedula del comprador, el botón de imprimir y el botón para cancelar la operación. 12. El actor escoge un evento de la lista e ingresa el número de cédula del comprador. 13. El actor oprime el botón de imprimir. 14. El sistema verifica los datos. 15. El sistema valida los datos e inicia la impresión de la boleta. Post-condiciones: La boleta correspondiente al evento y comprador elegido por el actor, es impresa para obtenerla así en medio físico. Flujos alternativos - El actor en el paso 2 escoge una opción diferente. - El sistema no encuentra eventos con boletas vendidas y no impresas, mostrará un mensaje notificando que no hay boletería para impresión y regresará al paso 1. - El actor cancela la operación antes de llegar al paso 4, regresará al paso 1. - El actor en el paso 4 no selecciona evento, introduce datos inválidos ó deja el campo sin llenar; por lo tanto en el paso 6 el sistema le informará las inconsistencias y volverá al paso 3. Derechos Reservados SIBO, 2009 Página 14
Caso de Uso: Cancelar Venta de Boleta ID: 8 Actores primarios: Vendedor Actores secundarios: Pre-condiciones: Ninguna Flujo principal 1. El actor se identifica dentro del sistema, colocando los datos de nombre de usuario y contraseña 2. El Sistema muestra una ventana con las opciones que de acuerdo a su rol puede realizar el actor en el sistema. 3. El actor elije la opción de cancelar boleta vendida 4. El sistema muestra un formulario en el cual se debe elegir a través de unas listas desplegables, con las cuales se discrimina, el evento, de tal forma que se pueda elegir por fecha, lugar y evento. 5. El actor al encontrar el evento procede a buscar la identificación de la persona que compro la boleta 6. ella actor cancela la venta de la boleta al ubicar a la persona que la compro en la base de datos. Post-condiciones: El sistema muestra una confirmacion de que la venta de la boleta fue cancelada, con lo cual se sabe que la operación fue realizada satisfactoriamente. Flujos alternativos 1. El actor en el paso 1 coloca datos que no son validos por lo tanto el sistema antes del paso 2 avisa al actor de las inconsistencias presentadas durante la validación. 2. El actor cancela la operación antes de llegar al paso 4 3. El actor no encuentra la identificación de la persona en el paso 5 luego de haber identificado el evento para el cual fue comprada la boleta. 4. El actor no encuentra el evento en el paso 4, por lo cual se cancela la busqueda de la boleta vendida para retirarla de la base de datos. Derechos Reservados SIBO, 2009 Página 15
ID: 9 Actores primarios: Vendedor, Usuario Actores secundarios: Administrador Pre-condiciones: Caso de Uso: Consultar Boletería Evento Flujo principal 1. El actor entra a la ventana principal de la aplicación 2. El actor digita su búsqueda en el formulario de búsqueda de la aplicación 3. El actor oprime el boton buscar. Post-condiciones: 1. En una nueva ventana se muestran los resultados de la busqueda dependiendo de lo que el usuario haya digitado en el cuadro de busqueda. Flujos alternativos Derechos Reservados SIBO, 2009 Página 16