Embed Size (px)
Citation preview
Clase 8 Requerimientos de Usuario
Sonia Rueda
Req del Negocio
Req no Funcionales
Req del Usuario
Req Funcionales
Req para los datos
Captura Análisis Especificación 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
Completar
formulario
Ingresante
Emitir
comprobante
Obtener
identificación y
contraseña
Sistema de preinscripción
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
Sistema de Preinscripción
Ingresante
completar formulario
obtener contraseña
emitir comprobante
SIU Guaraní
Empleado Dpto.Ingreso
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.
Completar
formulario
Ingresante
Recuperar
formulario
Modificar
contraseña
Empleado Dpto.
Ingreso Validar
formulario
Migrar datos
Reporte
Aspirantes
Emitir
comprobante
Obtener
identificación y
contraseña
Sistema de preinscripción
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.
Completar
formulario
Ingresante
Recuperar
formulario
Modificar
contraseña
Empleado Dpto.
Ingreso Validar
formulario
Migrar datos
Reporte
Aspirantes
Emitir
comprobante
Obtener
identificación y
contraseña
Sistema de preinscripción
Notificar falta
documentación
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.
Cliente caja de
ahorro
Cajero Bancario
Iniciar sesión
Realizar
Transacción
Extracción Depósito
Plantillas
Consultar
saldo
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
Flujo Normal 1. El sistema solicita número de legajo del alumno (ahora graduado) 2. El usuario ingresa el número de legajo 3. El sistema busca el alumno de acuerdo a su legajo y muestra
nombre completo y DNI 4. El sistema pregunta si ese es el alumno buscado 5. El usuario confirma 6. Si el graduado terminó una única carrera se muestra la carrera. 7. El sistema pregunta si el reporte es completo o solo exámenes
aprobados 8. 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.
Flujo Normal 1. El sistema muestra una caja de texto con el formato establecido
por la regla GUI-009 2. El usuario tipea los cinco dígitos del legajo. 3. …
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 PL-
023, 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.
