Captura y Modelado de Requisitos

Transcripción

1 UCLM E.S. de Informática Ingeniería en Informática Sistemas de Información Práctica 3 Captura y Modelado de Requisitos Autor: Francisco Ruiz, mar-2016 Objetivo: Aprender a capturar las necesidades de información de una organización (real o virtual) y su representación mediante una especificación de requisitos del sistema en forma de texto organizado y en forma de modelos sencillos. Aprender a usar de forma básica herramientas de gestión de requisitos. Fundamentos: Temas 3, 4 y 5 de teoría. Ayuda de la herramienta REM (REquirements Management). Valoración: % nota de la asignatura = 8 % Total a repartir: 40 puntos. Máximo por alumno: 16 puntos. Plan de trabajo: Esfuerzo previsto: 12 horas. Sesiones presenciales: 4'75 horas (3 sesiones y sesión de tutoría) o Primera sesión: presentación, uso de la herramienta, necesidades del usuario. o Segunda sesión: trabajar con el caso para preparar la especificación de requisitos usando REM. o Tercera sesión : Tutorías de grupo: por grupo. o Cuarta sesión: Sesión para finalizar la práctica. Tiempo no presencial para preparar práctica y entregables: 7'25 horas. Lista de Tareas 1. Realizar el tutorial sobre captura de requisitos mediante la herramienta REM, practicando lo indicado en dicho tutorial. SI- Práctica 3: Captura y Modelado de Requisitos - 1

2 2. Leer con detalle las necesidades iniciales del cliente enunciadas en el anexo A y entrevistar al cliente (profesor) para aclarar dudas. 3. Escribir un documento de necesidades del cliente que indique los requisitos de dominio, negocio y usuario (punto de vista de lo que el cliente necesita) a partir de las necesidades iniciales (anexo A) y de los resultados de la entrevista. 4. Usando la herramienta REM, crear el documento de especificación de requisitos del sistema siguiendo el formato/estructura indicado en el anexo B. Requisitos de la Práctica: Condiciones que debe cumplir el documento de necesidades obtenido en la tarea 2: - Debe estar expresado de forma no técnica como si estuviera realmente preparado por el cliente. - Cualquier consideración que se haga adicional a lo indicado en el enunciado del caso (ver anexo A) deberá ser explícitamente indicada en un apartado final de aclaraciones y explicaciones y deberá ser coherente con dicho enunciado. Condiciones que debe cumplir el documento de requisitos del sistema obtenido en la tarea 2: - La estructura del documento será la indicada en el anexo B. Todos los apartados y subapartados deberán incluir al menos un elemento. - Debe expresar de una forma adecuada (en forma de objetivos, restricciones, casos-escenarios, etc.) los contenidos-necesidades ya indicados en el documento anterior. - Los requisitos del sistema propiamente dichos deben ser adecuados para que el sistema de información pueda satisfacer las necesidades del cliente/usuario manifestadas en el documento anterior. - Usar al menos un elemento de cada uno de los siguientes tipos manejados por REM: sección, apéndice, párrafo, elemento de glosario, gráfico, organización, participante, reunión, objetivo, actor, requisito de almacenamiento, restricción, caso de uso, requisito funcional, requisito no funcional, matriz. - Incluir al menos dos objetivos, dos organizaciones y dos roles y tres tipos de usuarios. - En el modelo del negocio incluir al principio un párrafo explicativo. El organigrama deberá incluir un dibujo realizado con alguna herramienta de diagramación. Los modelos del dominio y de la información manejada se pueden realizar con diagramas de clase UML (vistos en Programación) o con mapas de conceptos. Añadir también algún texto complementario. - Indicar entre 10 y 12 escenarios o casos de uso de forma que cada tipo de usuario/actor participe en al menos una interacción con el sistema. - Incluir al menos dos reglas de negocio y una restricción de los demás apartados. - Añadir entre 10 y 20 requisitos funcionales; al menos un requisito no funcional en cada subapartado. Incluir también entre 4 y 6 requisitos de almacenamiento. - Crear dos matrices de rastreabilidad (trazabilidad) entre: i) objetivos y casos de uso; objetivos y restricciones. SI- Práctica 3: Captura y Modelado de Requisitos - 2

3 Entregables: Las memorias (documentos de texto) deben incluir una portada en la que se indique el nombre de la asignatura, la práctica y entregable, el equipo de trabajo y nombre de sus miembros, así como la fecha. En la segunda página del primer entregable se incluirá un índice con el reparto de los puntos entre los miembros del equipo. El formato deberá usar páginas de tamaño A4, preferible texto Times New Roman de 11 e interlineado sencillo. El formato del documento podrá ser DOC, RTF, HTML, PDF o algún otro estándar. 1. Entregable P3.1 Memoria escrita con el documento de necesidades del cliente resultado de la tarea 3 (entre 3 y 6 páginas). Al principio se deberá indicar el reparto de puntos entre los autores. Incluir también un apartado final de aclaraciones y explicaciones sobre cómo se ha hecho (técnicas empleadas, problemas y dificultades encontrados, decisiones adoptadas,..) (entre 1 y 2 páginas). 2. Entregable P3.2 El archivo.rem creado por la herramienta REM con la especificación de requisitos del sistema resultado de la tarea 4. El nombre del archivo deberá indicar el equipo de trabajo y un nombre corto del sistema elegido (p.e., E16-ventacatalogo.rem). 3. Entregable P3.3 El documento de requisitos generado por REM. Deberá ser un archivo ÚNICO en algún formato estándar de documentos (PDF, RTF, DOC, HTML, ). Anexo A Necesidades Iniciales del Cliente La Dirección General de Tráfico (DGT) desea desarrollar un sistema de información para la gestión del sistema de carnet de conducir por puntos (SGCP, sistema de gestión del carnet por puntos). Las necesidades manifestadas por el cliente son las siguientes: 1. Se debe administrar la adjudicación de los carnets de conducir a los conductores. 2. Para obtener el carnet de conducir es necesario aprobar en primer lugar un examen teórico de tipo test y posteriormente un examen de tipo práctico. 3. Antes de la realización de un examen (teórico o práctico) las autoescuelas remiten a la DGT los datos personales de los alumnos que van a examinarse (dni, nombre y apellidos), junto con la fecha deseada (de acuerdo a las fechas oficiales de la DGT) y el tipo de examen. 4. Como resultado el sistema envía a las autoescuelas una lista con las personas autorizadas a examinarse, la fecha y hora prevista del examen y el edificio y aula (examen teórico) o el punto de partida (examen práctico). 5. Una vez finalizados los exámenes, los examinadores envían a la DGT una lista de calificaciones indicando para cada examinado su DNI, tipo de examen y resultado (APTO, NO APTO). La DGT a su vez envía a las autoescuelas los resultados correspondientes a sus alumnos. Todos aquellos SI- Práctica 3: Captura y Modelado de Requisitos - 3

4 que han superado todas las pruebas obtienen el carnet de conducir con un saldo inicial de 12 puntos. 6. El saldo del carnet de conducir puede reducirse ante posibles infracciones de los usuarios. Según la clasificación actual (es importante tener en cuenta que puede variar en el tiempo) la DGT clasifica las infracciones en tres tipos: Muy Grave (ejemplo: provocar accidente bajo los efectos del alcohol, sobrepasar el límite de velocidad en más de 40 Km/h, culpabilidad de accidente...), Grave (sobrepasar el límite de velocidad entre 20 y 40 Km/h, saltarse un semáforo o stop...) y Leve (uso del teléfono móvil, sobrepasar límite de velocidad hasta 20 Km/h ). La sanción equivale a la pérdida de 8, 4 y 2 puntos respectivamente según su tipo. 7. La Guardia Civil de Tráfico (GCT) dispondrá de PDAs para la comunicación y aplicación de sanciones ante las infracciones de los conductores: a) Cuando un conductor comete una infracción y es detenido por la GCT, el agente debe comunicar a la DGT (previa autentificación) el DNI del conductor infractor y los datos de la infracción: tipo, código (de acuerdo a los códigos oficiales de la DGT), lugar y, de forma opcional, comentarios-detalles adicionales de la infracción cometida. b) El sistema de la DGT recibe la información, actualiza el saldo del carnet del infractor y envía al agente el nuevo saldo del carnet del conductor infractor. c) Si este saldo es igual o inferior a 0, el agente procede a la retirada del carnet de conducir del usuario y a la inmovilización del vehículo. En este caso la DGT actualiza su información y el usuario debe realizar de nuevo los exámenes (si así lo desea) para obtener de nuevo el carnet. 8. Al cabo de 4 años de no haber recibido sanciones, un conductor recibe un premio de 4 puntos mas, hasta un máximo de 20 puntos. 9. Los usuarios con carnet de conducir pueden conocer su saldo enviando un SMS a la DGT con el siguiente contenido: SALDO + <DNI>. También pueden conocerlo accediendo a la web de la DGT y usando su dni digital o una certificación electrónica oficialmente reconocida en España. 10. El administrador de la DGT también debe poder consultar una serie de estadísticas básicas accediendo al sistema web de la DGT (autentificación previa requerida). Los tipos de consulta que puede realizar son: a) Número de infracciones por tipo, periodo de tiempo (años o meses) y lugar (carretera, provincia, autonomía). b) Número de carnets retirados por provincia y autonomía de residencia del conductor. c) Número total de puntos restados en los carnets de los usuarios. d) Listado con las infracciones (código, fecha, lugar y detalles) cometidas por un determinado usuario (identificado por su DNI). e) Estadística de alumnos aptos y no aptos por tipo de examen (teórico, práctico), periodo de tiempo (meses, años), autoescuela, provincia o autonomía. SI- Práctica 3: Captura y Modelado de Requisitos - 4

5 Anexo B Estructura del documento de requisitos del sistema a incluir en el entregable P Introducción 1.1. Resumen 1.2. Objetivos 1.3. Participantes en el proyecto Organizaciones Roles 1.4. Definiciones y abreviaturas 1.5. Referencias 2. Descripción General 2.1. Tipos de usuarios/actores 2.2. Modelos del negocio Organigrama Dominio Información 2.3. Casos-Escenarios de uso 2.4. Restricciones Reglas de negocio De interfaz de usuario De hardware De software De comunicaciones Otras 3. Requisitos Específicos del Sistema 3.1. Requisitos funcionales 3.2. Requisitos no funcionales De rendimiento De seguridad Otros 3.3. Requisitos de Almacenamiento. 4. Comentarios adicionales 4.1. Incidencias 4.2. Aclaraciones SI- Práctica 3: Captura y Modelado de Requisitos - 5