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.
Descargar