Modelo de Casos de Uso
Anuncio
Clase 8 Requerimientos de Usuario Sonia Rueda Req del Negocio Captura Req no Funcionales Análisis Req del Usuario Req Funcionales Especificación Req para los datos Validación Un modelo de casos de uso (MCU) ofrece una representación abstracta de problema desde la perspectiva del usuario. Está conformado por: diagramas de casos de uso especificaciones de casos de uso La construcción del modelo es iterativa, partiendo de algunos casos de uso muy generales y agregando luego otros más específicos o relacionándolos entre sí. Los diagramas de casos de uso brindan una representación visual de alto nivel para modelar las interacciones del sistema con su entorno. Cada caso de uso describe una interacción particular entre el sistema y al menos un actor del entorno. Para cada interacción es posible establecer con precisión el comienzo y la terminación. Cada diagrama contiene: Actores Casos de Uso Vinculaciones entre Actores y Casos de Uso Además, puede contener: Vinculaciones entre Casos de Uso Vinculaciones entre Actores La creación de un DCU puede encararse de a partir de: Una descripción de un proceso Los actores El diagrama de contexto Un conjunto de escenarios o instancias de caso de uso Un conjunto de eventos externos A partir de una descripción de un proceso identificar los actores y preguntar ¿Cuáles son las tareas del proceso que el sistema realiza a partir de datos suministrados por los actores? ¿Qué información necesitan obtener los actores del sistema para realiza su tarea? A partir de las respuestas a estar preguntas se definen casos de uso que especifican qué tareas se realizan con el sistema, sin definir cómo se realiza. Trámite de inscripción Preinscripción online Inscripción presencial Revisación médica Acreditación Título Secundario aspirante empleado Dpto. Ingreso empleado Serv. Sanidad empleado Dpto. Ingreso Identificar los actores primero, luego diagramar el proceso que debe soportar el sistema para reconocer: Qué cambios externos va a detectar el sistema?¿Con qué frecuencia? ¿Cómo debe informar a los demás actores? Qué información generada por el sistema deben recibir los actores? Por último definir los casos de uso para modelar las tareas en las cuales los actores interactúan con el sistema. Trámite de inscripción Preinscripción online Inscripción presencial Revisación médica Acreditación Título Secundario aspirante empleado Dpto. Ingreso empleado Serv. Sanidad Preinscripción Obtener identificación y contraseña Completar formulario Emitir comprobante aspirante Sistema de preinscripción Obtener identificación y contraseña Ingresante Completar formulario Emitir comprobante Examinar el diagrama de contexto y preguntar ¿Qué necesidades debe satisfacer cada una de las entidades externas con la ayuda del sistema? Trámite de inscripción SIU Guaraní completar formulario Sistema de Preinscripción Empleado Dpto.Ingreso obtener contraseña emitir comprobante Ingresante Identificar un conjunto de escenarios específicos a partir de la observación de las tareas del usuario y generalizar hasta definir los casos de uso. En la generalización se reúnen varios escenarios en un mismo caso de uso y se distinguen de otros que se agruparán para definir casos de uso diferentes. Es posible reconocer escenarios actuales, futuros, de validación y de entrenamiento. Trámite de inscripción Preinscripción Escenarios antes del sistema: Candela Donini completa su formulario de preinscripción en julio. En septiembre presenta en el Dpto. de Ingreso el formulario y el certificado de ser alumna del último año. El empleado valida los datos y confirma la inscripción que la habilita para rendir los exámenes diagnóstico. Le informa que tiene que volver en diciembre con el certificado de título en trámite para que se le pueda asignar su número de legajo y más adelante cuando obtenga su Título secundario. Trámite de inscripción Preinscripción Escenarios con del sistema: Candela Donini obtiene su clave y contraseña en el sistema de preinscripción , completa su formulario online en julio y emite el comprobante. En septiembre presenta en el Dpto. de Ingreso el comprobante de preinscripción y el certificado de ser alumna del último año. El empleado valida los datos y confirma la inscripción que la habilita para rendir los exámenes de los cursos virtuales. Le informa que tiene que volver en diciembre con el certificado de título en trámite para que se le pueda asignar su número de legajo y más adelante cuando obtenga su Título secundario. Trámite de inscripción Preinscripción Escenarios antes del sistema: Marcos Peralta registra sus datos en el formulario de preinscripción en octubre. En diciembre se presenta con su formulario y el certificado de título secundario en trámite en el Dpto. de Ingreso, para realizar la inscripción. El empleado valida los datos y los carga en el sistema SIU-Guaraní, que le asigna número de legajo, nombre de usuario y clave. Trámite de inscripción Preinscripción Escenarios con del sistema: Marcos Peralta obtiene su nombre de usuario y constraseña en el sistema, registra parcialmente sus datos en el formulario de preinscripción en octubre. En noviembre modifica su contraseña y completa el resto del formulario. En diciembre se presenta con su comprobante y el certificado de título secundario en trámite en el Dpto. de Ingreso, para realizar la inscripción. El empleado valida los datos y los migra al sistema SIU-Guaraní, que le asigna número de legajo, nombre de usuario y clave. Sistema de preinscripción Obtener identificación y contraseña Recuperar formulario Ingresante Completar formulario Validar formulario Emitir comprobante Modificar contraseña Migrar datos Reporte Aspirantes Empleado Dpto. Ingreso Identificar los eventos externos a los cuales el sistema debe responder y relacionarlos con eventos en los que participen actores y casos de uso específicos. Trámite de inscripción El primer lunes de diciembre de 2015 serán automáticamente dados de baja por falta de documentación los ingresantes 2015 que no presenten el Título Secundario. Sistema de preinscripción Obtener identificación y contraseña Recuperar formulario Ingresante Completar formulario Validar formulario Emitir comprobante Modificar contraseña Notificar falta documentación Migrar datos Reporte Aspirantes Empleado Dpto. Ingreso Combinar una estrategia: bottom up en la cual los usuarios enumeren las tareas que necesitan ejecutar con el nuevo sistema. Cada una de estas tareas se transforma en un candidato a caso de uso. Enfoque centrado en el usuario top down en la cual se identifican los procesos que el sistema debe soportar y luego se define una lista de tareas por proceso. Cada tarea es un caso de uso. Enfoque centrado en el producto La unión de las dos listas evitará pasar por alto tareas o procesos relevantes. De hecho probablemente haya que descartar algunos que quedan fuera del alcance. También es posible notar que dos o más casos de uso podrían consolidarse en uno, ya que describen escenarios similares. Cada caso de uso del diagrama puede ser descripto por una especificación breve o detallada. Una especificación breve se escribe en lenguaje natural. Una especificación detallada habitualmente se escribe usando lenguaje natural estructurado o una plantilla Una plantilla es una estructura para organizar la descripción detallada de un CU. Permite registrar información que ayuda a comprender el flujo normal de interacción, sus variantes y la información relacionada. En general no se llena en forma lineal, es más, es muy probable que no se complete. ID: SP-1001 Nombre: completar formulario Autores: Natalia Martínez Creado:10-10-2010 Ultima Modificación:10-10-2010 Actores: ingresante Descripción Breve: el ingresante completa total o parcialmente el formulario de ingreso consignando datos en tres pestañas: personales, laborales y académicos. Para que los datos se almacenen el ingresante debe haber completado al menos los datos personales mínimos y confirmar el formulario. Precondiciones: El ingresante está registrado en el sistema e ingresó con su clave y contraseña. Poscondiciones: se almacenaron al menos los datos personales mínimos o no hay datos del ingresante. La sesión sigue abierta. Presunción: si el ingresante no muestra actividad por 3 minutos seguido, la sesión se cierra sin guardar. Flujo Normal 1.0 Si no hay datos almacenados del ingresante, el sistema inicializa el formulario en blanco y genera un número de preinscripción único. 2.0 El sistema muestra la pestaña datos personales. 3.0 En cada campo con opciones el ingresante selecciona un valor y en cada campo libre el ingresante ingresa un valor. 4.0 El ingresante confirma la pestaña. 5.0 Si los datos mínimos están completos, el sistema muestra la pestaña datos académicos. 6.0 En cada campo con opciones el ingresante selecciona un valor y en cada campo libre el ingresante ingresa un valor. Flujo Normal … 7.0 Si el ingresante confirma la pestaña y el sistema muestra la pestaña datos laborales. 8.0 En cada campo con opciones el ingresante selecciona un valor y en cada campo libre el ingresante ingresa un valor. 9.0 Si el ingresante confirma la pestaña aparece un cuadro de confirmación del formulario , indicando que si confirma el formulario los datos se almacenarán actualizados. 10.0 Si el ingresante confirma el formulario se guardan los datos actualizados y los anteriores se borran. 11.0 Termina Flujo Alternativo 1 1.1 Si hay datos del ingresante el sistema inicializa el formulario con los datos almacenados y sigue en el paso 2.0 del flujo normal. Flujo Alternativo 2 4.2 El ingresante cancela la tarea y pasa a 11.0 del flujo normal Flujo Alternativo 3 5.3 Si los datos mínimos no están completos, el sistema muestra un mensaje, pinta con rojo los campos incompletos y sigue en el paso 3.0 del flujo normal. Flujo Alternativo 4 7.4 El ingresante cancela la tarea y pasa a 11.0 del flujo normal Flujo Alternativo 5 9.5 El ingresante cancela la tarea y pasa a 11.0 del flujo normal Flujo Alternativo 6 10.6 El ingresante cancela la tarea y pasa a 11.0 del flujo normal Flujo excepcional: La conexión web se interrumpe La información almacenada no se modifica, los datos ingresados se pierden y pasa a 11.0 del flujo normal Prioridad: alta Frecuencia de Uso : muy frecuente Reglas del Negocio : Res. Privacidad de los datos. Requisitos de datos censales mínimos establecidos por el Ministerio de Educación. En general las fallas en los dispositivos y los problemas de conexión no se consideran excepciones, ya que en una aplicación web habría que incluir esta excepción en todos los CU. Sin embargo, en este caso lo consideramos ya que estamos indicando qué hacer con los datos. Un identificador único que permita referenciar al caso de uso y el nombre del caso de uso que establece en forma sucinta la tarea del usuario El autor, la fecha de creación y la fecha de la última modificación. Una descripción breve que establece el propósito del caso de uso. Un disparador que indica cuando se inicia el caso de uso. Cero o más precondiciones Una o más postcondiciones Una lista numerada que muestra el flujo normal que conduce desde las precondiciones hacia las poscondiciones. Una lista numerada para cada flujo alternativo. Una lista numerada para cada excepción. La prioridad Las reglas del negocio que afectan al CU La frecuencia de uso Las precondiciones establecen los requisitos que deben satisfacerse para que el sistema pueda empezar a ejecutar el caso de uso. Describen el estado del sistema que le permite alcanzar los resultados esperados. Previenen algunos errores porque el sistema ya sabe que si no se cumplen todos las precondiciones, la ejecución del caso no puede ejecutarse exitosamente. El sistema debe tener la capacidad de controlar si las precondiciones se satisfacen antes de comenzar a ejecutarse, es decir, en el momento que se activa el disparador. Los usuarios suelen ser un poco reticentes a considerar todas las precondiciones. El analista debe insistir en este punto porque determina la robustez del producto. Las poscondiciones describen el estado del sistema después de que se completa el caso de uso. Pueden describir: Un mensaje observable por el usuario (en pantalla, en papel) Un objeto tangible (el vaso lleno de café) Un cambio interno (la cantidad de ingrediente café disminuye) Cada uno estos elementos es fundamental para los desarrolladores que deben conocer las consecuencias de la ejecución del caso de uso. En muchas aplicaciones el usuario puede enlazar juntas una secuencia de casos de uso en un caso de uso macro que describe una tarea mayor. Cuando no es posible establecer una condición general el analista puede especificar la poscondición de éxito, esto es, si se completa el flujo normal. El flujo normal o escenario principal representa la secuencia de eventos que modela cualquier escenario básico. Los flujos alternativos o escenarios secundarios pueden producir el mismo resultado, o con alguna variación, pero representan una secuencia menos frecuente. En el flujo normal los pasos se numeran en secuencia indicando que entidad ejecuta cada uno. El flujo normal puede dividirse en varios flujos alternativos en algún punto de decisión de la secuencia de diálogo y puede luego, o no, volver a unirse en un único flujo. Cuando un caso de uso es extendido por otro se especifica con precisión el punto de extensión. Los diagramas de actividad de UML permiten para visualizar los puntos de decisión y las condiciones que provocan que el flujo normal se transforme en flujo alternativo. Otra alternativa para modelar flujo de datos son justamente los diagramas de Flujo de Datos Las excepciones son situaciones potenciales que es necesario prevenir en el caso de uso. Anticipan errores que podrían ocurrir durante la ejecución del caso de uso y establecen un mecanismo para manejarlos. Cuando se alcanza un estado que debería haber sido descripto como una excepción y el caso de uso no estableció como actuar, el desarrollador debe decidir cómo manejar la situación. Si el desarrollador tampoco identifica la excepción el sistema no es robusto. Algunas excepciones pueden afectar a varios casos de uso o varios pasos en un mismo caso de uso. Estos casos se deben considerar requerimientos funcionales a implementar, en lugar de repetirlos como excepciones que potencialmente pueden afectar a distintos casos de uso. La meta es no forzar a encajar toda funcionalidad conocida en un caso de uso. El enfoque centrado en el uso trata de descubrir tantos aspectos de la funcionalidad esencial del sistema como sea posible. Una de las principales carencias en los requerimientos suele ser pasar por alto excepciones. En muchas ocasiones el usuario no las identifica o no les da importancia. El analista debe insistir durante la captura y por supuesto los desarrolladores deben luego tenerlas en cuenta. ID: SP-1001 Nombre: completar formulario Autores: Natalia Martínez Creado:10-10-2010 Ultima Modificación:11-11-2011 Actores: ingresante Descripción Breve: el ingresante completa total o parcialmente el formulario de ingreso consignando datos en tres pestañas: personales, laborales y académicos. Para que los datos se almacenen el ingresante debe haber completado al menos los datos personales mínimos y confirmar el formulario. Precondiciones: El ingresante está registrado en el sistema e ingresó con su clave y contraseña. Poscondiciones: se almacenaron al menos los datos personales mínimos o no hay datos del ingresante. La sesión sigue abierta. Presunción: uno de los datos indispensables es la dirección de correo electrónico. Flujo Normal … 7.0 Si el ingresante confirma la pestaña y el sistema muestra la pestaña datos laborales. 8.0 En cada campo con opciones el ingresante selecciona un valor y en cada campo libre el ingresante ingresa un valor. 9.0 Si el ingresante confirma la pestaña aparece un cuadro de confirmación del formulario, indicando que si confirma el formulario los datos se modificarán y recibirá un mail en la dirección de correo indicada. 10.0 Si el ingresante confirma el formulario se guardan los datos del formulario, los anteriores se borran y se envía un mail al ingresante informando que los datos del formulario se han almacenado exitosamente en el sistema. 11.0 Termina No hay una regla estricta que distinga a un flujo alternativo de una excepción. Algunos autores consideran que los flujos alternativos no son indispensables, es decir son requerimientos que no inciden en la aceptación del producto. En cambio, las excepciones afectan a la robustez del producto y por lo tanto deben modelarse desde la primera versión del producto. Con frecuencia en una iteración se implementa el flujo normal y los flujos alternativos se postergan en iteraciones posteriores, explicitando esta decisión. Las excepciones en cambio deben ser implementadas para evitar que el sistema colapse y favorecer la robustez. En las metodologías ágiles el usuario debe formular historias de usuario que modelen las situaciones excepcionales que el sistema debe prevenir porque estas van a estar incluidas en el test de aceptación. Si una situación anormal se va a modelar como un flujo alternativo, la condición que provoca el división entre el flujo normal y el alternativo se especifica en el flujo normal. Si una situación anormal se va a modelar como una excepción, la condición que la provoca no se especifica como parte del flujo normal. Algunos autores distinguen el flujo alternativo de una excepción por la recuperación. Consideran que una excepción se caracteriza porque el caso de uso termina sin alcanzar un estado de éxito. Otros autores consideran que aun produciéndose una excepción, es posible que el usuario pueda intervenir y realizar una acción que permitan reanudar el flujo normal y completar el caso de uso con éxito. Plantillas Cajero Bancario Cliente caja de ahorro Iniciar sesión Consultar saldo Realizar Transacción Depósito Extracción ID: CB-001 Nombre: Iniciar sesión Autores: Delfina Moreno Creado:14-4-2014 Ultima Modificación: Actores: cliente caja de ahorro Descripción Breve: el cliente inserta su tarjeta en el cajero y si lo hace correctamente el sistema le solicita su clave. Si la clave es correcta, habilita las transacciones. Precondiciones: El cajero está en servicio. Poscondición de éxito: la sesión se inicia correctamente, esto es, el sistema aceptó la tarjeta y el cliente ingresó su clave Flujo Normal 1.0 El cliente coloca la tarjeta correctamente 2.0 El sistema solicita la clave 3.0 El usuario ingresa los cuatro dígitos de la clave 4.0 El sistema controla si la clave es válida 5.0 Si la clave es válida el cajero queda habilitado 6.0 Terminar Flujo Alternativo 1 1.1 El cliente no coloca la tarjeta correctamente 2.1 El sistema muestra un mensaje de error y solicita que se retire la tarjeta 3.1 Vuelve al último paso del flujo normal Flujo Alternativo 2 5.2 Si la clave no es válida el sistema incrementa la cantidad de intentos 6.2 El sistema controla la cantidad de intentos, si es 3 se bloquea la cuenta 7.2 Vuelve al último paso del flujo normal Flujo Alternativo 3 5.3 Si la clave no es válida el sistema incrementa la cantidad de intentos 6.3 El sistema controla la cantidad de intentos, si menor a 3 vuelve al paso 3.0 del flujo normal Flujo Alternativo 4 3.4 El usuario oprime cancelar 4.4 El sistema devuelve la tarjeta 5.4 Vuelve al último paso del flujo normal Flujo excepcional E2.1 el sistema no reconoce la tarjeta E2.2 El sistema muestra un mensaje de error y vuelve al último paso del flujo normal. ID: CB-002 Nombre: Realizar Transacción Autores: Delfina Moreno Creado:14-4-2014 Ultima Modificación: Actores: cliente caja de ahorro Descripción Breve: el sistema muestra un menú con los distintos tipos de transacción que puede realizar el cliente y el cliente elige una opción o bien oprime cancelar. Precondiciones: La sesión se inició correctamente. Poscondición : queda habilitada un tipo de transacción o termina la sesión. Flujo Normal 1.0 Si la cuenta no está bloqueada el sistema muestra los tres tipos de transacción 2.0 El usuario elige un tipo de transacción 3.0 Terminar Flujo Alternativo 1 1.1 Si la cuenta está bloqueada el sistema solo muestra la opción consultar saldo 2.1 Vuelve al último paso del flujo normal Flujo Alternativo 2 2.2. El usuario elige cancelar 3.2 El sistema muestra un mensaje, se cierra la sesión y devuelve la tarjeta 4.2 Vuelve al último paso del flujo normal ID: CB-003 Nombre: Extraer de caja de ahorro Autores: Delfina Moreno Creado:15-4-2014 Ultima Modificación: Actores: cliente caja de ahorro Descripción Breve: el cliente extrae un monto del cajero, menor a su saldo y considerando que el total extraído en el día sea menor al valor máximo establecido por la reglamentación. Precondiciones: se habilitó la transacción de extracción. Poscondición de éxito: el cliente obtiene el dinero que necesita; su saldo y el monto extraído en el día se actualizan Flujo Normal 1.0 El cliente ingresa el monto que desea extraer 2.0 Si el monto es menor o igual al saldo y el monto más el monto extraído en el día es menor o igual al máximo permitido, el sistema muestra un mensaje indicando que autoriza la extracción 3.0 El sistema selecciona los billetes y los entrega 4.0 El cliente retira el dinero 5.0 El sistema actualiza el saldo del cliente y el monto total extraído en el día y muestra ambos valores actualizados. 6.0 Termina Flujo Alternativo 1 1.1 El cliente cancela sin ingresar un monto y pasa a 6.0 del flujo normal Flujo Alternativo 2 2.2 Si el monto es mayor al saldo el sistema rechaza la extracción, muestra un mensaje de error y pasa a 6.0 del flujo normal Flujo Alternativo 3 2.3 Si el monto más el monto extraído en el día es mayor al máximo permitido, el sistema rechaza la extracción, muestra un mensaje de error y pasa a 6.0 del flujo normal El flujo alternativo 3 modela el incumplimiento de una regla del negocio que impone una restricción. Flujo Excepcional 1 E1.1 Si el monto es mayor al dinero disponible en el cajero, el sistema rechaza la extracción, muestra un mensaje de error y pasa a 6.0 del flujo normal Flujo Excepcional 2 E3.2 Si los billetes se atascan, se muestra un mensaje de error, la sesión se interrumpe anormalmente y el cajero se bloquea. Prioridad: alta Frecuencia de Uso : muy frecuente Reglas del Negocio : Resolución Banco Central xxx-13 Claramente cuando el objetivo es especificar los CU de un conjunto de diagramas, el encuentro de captura se orienta a identificar : Actores que se benefician con el caso de uso Frecuencia de uso y Reglas del Negocio Precondiciones y poscondiciones que establecen los límites para el caso de uso. Descripción de cómo los usuarios imaginan que realizarán sus tareas usando el sistema. Secuencia de acciones normal y alternativas Excepciones que afecten el criterio de aceptabilidad del producto Cuando el diálogo lo inicia un actor, no el sistema, el disparador debe ser una acción de un actor y el sistema debe emitir al menos una respuesta. El foco está en la interacción, no en las actividades internas ni en la interface El flujo normal no incluye más de 20 pasos El tiempo de respuesta ante una búsqueda no puede superar los 2 segundos. La cantidad de usuarios que simultáneamente pueden acceder a un mismo ítem es menor a 100. No siempre es necesario obtener una especificación detallada completa de cada caso de uso. La plantilla se completa en forma exhaustiva en los CU más complejos o que puedan provocar situaciones de riesgo, cuando el dominio de aplicación es totalmente ajeno al equipo de desarrollo o cuando los usuarios no van a interactuar con los desarrolladores o los responsables del testing. Por supuesto es válida cualquier alternativa intermedia. Cada caso de uso puede ser documentado con un nivel de detalle diferente. Los requerimientos de interface pueden capturarse en el mismo encuentro, pero deberían especificarse por separado. A pesar de que cada participante puede tener una imagen mental diferente respecto a como debe ser la interface de usuario, el grupo debe acordar una visión compartida acerca del protocolo de interacción básico entre cada actor y el sistema. Un protocolo de interacción ofrece un patrón para el diálogo entre los dos interlocutores. Pocos días después el analista envía el diagrama de casos de uso y otros diagramas a los participantes del encuentro, que deben revisarlos antes del siguiente encuentro. Durante la revisión pueden surgir nuevos flujos alternativos, nuevas excepciones, requerimientos funcionales que surgieron de presunciones o malentendidos. Idealmente el analista debería conocer estas acotaciones antes del nuevo encuentro, pero con frecuencia no es así. Es importante no dejar pasar demasiado tiempo entre el primer encuentro, la especificación, la revisión y el segundo encuentro, pero tampoco es aconsejable hacerlo en un par de días. Es bueno que los participantes se relajen y tomen perspectiva. Si hubo discusiones es bueno que el ambiente se refresque. Los desarrolladores pueden conocer los Requerimientos del Negocio y los Requerimientos del Usuario pero van a implementar los Requerimientos Funcionales, que describen el comportamiento esperado del sistema. Si las especificaciones de CU solo describen el comportamiento externo del sistema desde la perspectiva del usuario, no contienen toda la información que el desarrollador necesita para producir software. Hay detalles y decisiones que son transparentes para el usuario pero el desarrollador necesita conocer. Así, muchos RF surgen directamente de los diálogos entre el actor y el sistema, pero otros RF no surgen de la interacción. Una alternativa es que en las especificaciones detalladas se expliciten requerimientos funcionales. Ya sea que se resuelva incluir o no a los RF derivados, el criterio debe ser consistente y acordado por todo el equipo. Aun cuando las especificaciones detalladas de CU incluyan a los RF derivados de los RU, el desarrollador puede plantear muchas preguntas. En particular, en la mayoría de las especificaciones no se establece qué debe hacer el sistema si no se satisfacen las precondiciones. ID: CU-897 Nombre: Generar Ficha Académica Graduado Autores: Martín Parodi Creado: 15-3-2015 Ultima Modificación: Actores: administrativo del DAE Descripción Breve: Precondiciones: se habilitó al usuario con autorización para generar el reporte. Poscondición de éxito: el administrativo guarda o imprime la ficha académica del graduado 1. 2. 3. 4. 5. 6. 7. 8. Flujo Normal El sistema solicita número de legajo del alumno (ahora graduado) El usuario ingresa el número de legajo El sistema busca el alumno de acuerdo a su legajo y muestra nombre completo y DNI El sistema pregunta si ese es el alumno buscado El usuario confirma Si el graduado terminó una única carrera se muestra la carrera. El sistema pregunta si el reporte es completo o solo exámenes aprobados El usuario indica reporte completo Toda las acciones de la lista generan interacciones entre el usuario y el sistema, es un diálogo que generaliza a varios escenarios equivalentes. Los flujos alternativos modela a otros escenarios, por ejemplo, el graduado terminó más de una carrera. 1. 2. 3. Flujo Normal El sistema muestra una caja de texto con el formato establecido por la regla GUI-009 El usuario tipea los cinco dígitos del legajo. … En esta alternativa la especificación del flujo normal establece características de la interfaz gráfica de usuario. Flujo Normal 10. El sistema genera el encabezamiento de acuerdo a la plantilla PL023, considerando que el promedio se calcula de acuerdo a lo establecido por la resolución CSU-152/99 y el año de ingreso a la carrera se consigna de acuerdo a la resolución CSU-025/12. 11. El sistema genera el bloque de materias rendidas consignando para cada una la fecha, el código de materia, el nombre de la materia y la nota. La lista se ordena por nombre de materia. 12. El sistema genera el bloque de materias otorgadas por equivalencia consignando para cada una los códigos y los nombres de las materias rendidas, los código y los nombres de las materias otorgadas por equivalencia. La lista se ordena por nombre de materia. 13. El sistema genera el pie de la ficha consignando la fecha del reporte. Ninguna de estas acciones generan interacciones con el usuario. En este caso la especificación incluye a los requerimientos funcionales que surgen de las acciones internas del sistema. Podría detallarse aun más explicitándose las fórmulas. Flujo Normal 14. El sistema consulta al usuario si quiere guardar o imprimir la ficha 15. El usuario elige guardar o imprimir y el caso de uso termina. El analista puede decidir qué CU especifica a través de una descripción breve, una detallada o o un diagrama. Decide también cómo documentar las especificaciones de RU y RF Ningún método es perfecto. Cada equipo de desarrollo en cada proyecto puede decidir que alternativa le resulta más adecuada. Se genera un único documento con el MCU y se lo completa con los RF Una posibilidad es generar un único documento de CU y encajar los requerimientos funcionales en las especificaciones detalladas de caso de uso, a partir de las cuales se han derivado. Observemos que en este caso el MCU, que combina descripciones en lenguaje natural y representaciones gráficas, modela RU y RF. Se genera un único documento con el MCU y se lo completa con los RF Esta alternativa no es adecuada cuando hay requerimientos funcionales que no se derivan de ningún CU. También es inadecuada cuando un mismo RF queda asociado a distintos CU, porque al no estar separado en un documento de RF hay que repetirlo en cada CU. Se generan dos documentos, uno con el MCU orientado principalmente a usuarios y otro es el DER (SRS) orientado al equipo de desarrollo. Una alternativa es modelar RU en el MCU y documentar los RF en el Documento de Especificación de Requerimientos. Observemos que en este caso el MCU, que combina descripciones en lenguaje natural y representaciones gráficas, modela solo RU. Se generan dos documentos, uno con el MCU orientado principalmente a usuarios y otro es el DER (SRS) orientado al equipo de desarrollo. En general, si se va a generar el DER, el MCU se documenta parcialmente. Solo se producen especificaciones detalladas de algunos CU y los RF que se derivan se especifican en el DER. Se generan dos documentos, uno con el MCU orientado principalmente a usuarios y otro es el DER (SRS) orientado al equipo de desarrollo. El principal inconveniente es que al haber redundancia se puede producir inconsistencia entre los documentos cuando los requerimientos evolucionan. Hay que asignar identificadores que permitan establecer el vínculo entre CU y sus RF de modo que al cambiar los primeros puedan rastrearse rápidamente los RF afectados. Actualmente, existen herramientas de administración de requerimientos que permiten evitar las inconsistencias. Se genera únicamente el Documento de Especificación de Requerimientos y se lo completa con descripciones breves de CU. Una opción es ordenar los requerimientos funcionales por caso de uso o por característica e incluir tanto los casos de uso como los RF en el Documento de Especificación de Requerimientos. En este caso solo se escribe una descripción breve de cada caso de uso, los detalles se completan cuando se especifican los requerimientos funcionales en el Documento de Especificación de Requerimientos. MCU & test Una alternativa es producir el MCU completo y además escribir los test de aceptación que permitan verificar si el sistema brinda el comportamiento que establecen los CU, tanto en el flujo normal como los alternativos. Nuevamente en esta alternativa el MCU modela RU y RF.
