Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017 - año 10 Nro. 90
Herramientas para el
Análisis de Negocios
HISTORIAS DE USUARIO, CASOS DE
USO Y ESCENARIOS
por Sergio Salimbeni
Diciembre, 2017
Basado en el “A GUI D E TO T H E BUS I N ES S A N A LYS I S BODY O F KNOWL EDGE ® v.3”
2 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
Historias de usuario, Casos de Uso
y Escenarios
Una historia de usuario es una representación de un
requisito escrito, en una o dos frases, utilizando el
lenguaje común del usuario típico, mientras que los
casos de uso y escenarios describen cómo una
persona o sistema interactúa con la solución que se
modela para lograr un objetivo.
Se desarrollan a continuación ambos conceptos.
Historias de usuario
Introducción
Una historia de usuario es una representación de un
requisito escrito, en una o dos frases, utilizando el
lenguaje común del usuario típico.
Cada historia de usuario debe ser limitada, y poder,
por ejemplo, escribirse en una nota adhesiva
pequeña. Es muy usado en metodologías Ágiles.
Dentro de la metodología XP (Extreme
Programming) las historias de usuario deben ser
escritas por los clientes.
Las historias de usuario son una forma rápida de
administrar los requisitos de los usuarios sin tener
que elaborar gran cantidad de documentos
formales y sin requerir de mucho tiempo para
administrarlos. Las historias de usuario permiten
responder rápidamente a los requisitos que
cambian permanentemente.
Los usuarios son lo primero
El autor Roman Pichler dice que: “como su nombre
lo sugiere, una historia de usuario describe cómo un
cliente o usuario emplea el producto; se cuenta
desde la perspectiva del usuario. Además, las
historias de los usuarios son particularmente útiles
para capturar una funcionalidad específica, como
buscar un producto o hacer una reserva. La
siguiente imagen ilustra la relación entre el usuario,
la historia y la funcionalidad del producto
(simbolizada por el círculo)”. (10 TIPS FOR WRITING
GOOD USER STORIES By Roman Pichler, 24th March
2016)
Ilustración. Fuente:10 TIPS FOR WRITING GOOD USER STORIES
Si no se sabe quiénes son los usuarios y los clientes
y por qué querrían usar el producto, entonces no se
debe escribir ninguna historia de usuario.
Primero se realiza la investigación necesaria del
usuario, por ejemplo, observando y
entrevistándolos, caso contrario, se arriesga a
escribir historias especulativas basadas en creencias
e ideas, pero no en datos y evidencia empírica.
Propósito
Una historia de usuario representa una declaración
pequeña, concisa de la funcionalidad o la calidad
3 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
necesaria para ofrecer valor a un interesado
específico.
Descripción
Las historias de los usuarios capturan las
necesidades de un interesado específico y permiten
a los equipos definir características de valor
utilizando documentación breve y simple. Pueden
servir como base para identificar necesidades y
permitir la priorización, estimación y planificación
de soluciones.
Una historia de usuario suele ser una oración o dos
que es descripta por quién tiene la necesidad, y
contiene el objetivo que el usuario intenta lograr y
cualquier información adicional que pueda ser
crítica para comprender el alcance de la misma. Con
un enfoque en el valor de las partes interesadas, las
historias de los usuarios invitan a explorar los
requisitos promoviendo conversaciones adicionales
con las partes interesadas y agrupando requisitos
funcionales de un producto o servicio.
Las historias de usuario se pueden usar:
• para capturar las necesidades de las partes
interesadas y priorizar el desarrollo de soluciones,
• como base para estimar y planificar la entrega de
la solución,
• como base para generar pruebas de aceptación
del usuario,
• como una métrica para medir la entrega de valor,
• como una unidad para el rastreo de requisitos
relacionados,
• como base para un análisis adicional, y
• como una unidad de gestión e informes de
proyectos.
Elementos
Título
El título de la historia, es opcional, y describe una
actividad que la parte interesada quiere llevar a
cabo con el sistema. Por lo general, es una frase de
objetivo verbo activo similar a la forma en que se
titulan los casos de uso.
Declaración de valor
No hay una estructura obligatoria para las historias
de los usuarios. El formato más popular incluye tres
componentes:
• Quién: un rol o persona de usuario.
• Qué: una acción, comportamiento, característica
o calidad necesaria.
• Por qué: el beneficio o valor recibido por el
usuario cuando se implementa la historia.
Por ejemplo, "Como <quién>, necesito <qué>,
entonces <por qué>". "Dado ... Cuando ... Entonces"
es otro formato común.
Conversación
Las historias de los usuarios ayudan a los analistas a
explorar y comprender la característica descripta en
la historia y el valor que brindará a la parte
interesada.
La historia en sí misma no captura todo lo que hay
que saber sobre las necesidades de las partes
interesadas, y la información en la historia se
4 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
complementa con más modelos a medida que se
avanza en la solución.
Criterios de aceptación
Se puede respaldar una historia de usuario a través
del desarrollo de criterios de aceptación detallados.
Los criterios de aceptación definen los límites de la
historia de un usuario y ayudan al analista a
comprender lo que la solución necesita
proporcionar para entregar valor a las partes
interesadas.
Los criterios de aceptación se pueden
complementar con otros modelos de análisis según
sea necesario.
Consideraciones de uso
Fortalezas
• Fácilmente comprensible para las partes
interesadas.
• Se puede desarrollar a través de una variedad de
técnicas de elicitación.
• Se centra en el valor para los interesados.
• Se mejora la comprensión compartida del dominio
empresarial a través de la colaboración para definir
y explorar historias de usuarios.
• Atado a porciones de funcionalidad pequeñas,
implementables y comprobables, lo que facilita la
entrega rápida y los comentarios frecuentes de los
clientes.
Limitaciones
En general, las historias de los usuarios están
pensadas como una herramienta para la colecta a
corto plazo y la priorización de requisitos y no para
la retención del conocimiento a largo plazo o para
proporcionar un análisis detallado. Descuidar este
principio puede llevar a los siguientes problemas:
• Este enfoque conversacional puede desafiar al
analista ya que no tiene todas las respuestas y
especificaciones detalladas por adelantado.
• Requiere contexto y visibilidad; el analista puede
perder de vista el panorama general si las historias
no se rastrean a través de la validación o se
complementan con análisis de alto nivel y
elementos visuales.
• Puede no proporcionar suficiente documentación
para cumplir con la necesidad de Gobierno
(Gerencia), una línea de base para el trabajo futuro
o las expectativas de los interesados. Puede ser, a
veces, que se requiera información adicional.
Casos de uso y escenarios
Propósito
Los casos de uso y escenarios describen cómo una
persona o sistema interactúa con la solución que se
modela para lograr un objetivo.
5 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
Descripción
Los casos de uso describen las interacciones entre el
actor principal, la solución, y los actores secundarios
necesarios para lograr el objetivo del actor
primario.
Los casos de uso generalmente son activados por el
actor principal, pero en algunos métodos también
pueden ser activados por otro sistema o por un
evento externo o temporizador.
Un caso de uso describe los posibles resultados de
un intento de lograr un objetivo particular que la
solución respaldará. Detalla diferentes caminos que
pueden seguirse definiendo flujos primarios y
alternativos.
El flujo primario o básico representa la forma más
directa de lograr el objetivo del caso de uso. Las
circunstancias especiales y las excepciones que
resultan en una falla para completar el objetivo del
caso de uso se documentan en flujos alternativos o
de excepción. Los casos de uso se escriben desde el
punto de vista del actor y evitan describir el
funcionamiento interno de la solución.
Los diagramas de casos de uso son una
representación gráfica de las relaciones entre los
actores y uno o más casos de uso admitidos por la
solución.
Algunos enfoques de casos de uso distinguen entre
casos de uso comercial y casos de uso del sistema.
Los casos de uso comercial describen cómo los
actores interactúan con un proceso particular o
función comercial, y los casos de uso de sistema
describen la interacción entre un actor y una
aplicación, en general de software.
Un escenario describe solo una forma en que un
actor puede lograr un objetivo en particular.
Los escenarios se escriben como una serie de pasos
realizados por los actores o por la solución que
permite a un actor alcanzar un objetivo. Un caso de
uso describe varios escenarios.
Elementos
No hay un formato fijo y universal para casos de
uso. Los siguientes elementos se capturan con
frecuencia en una descripción de caso de uso.
Diagrama de caso de uso
Un diagrama de casos de uso representa
visualmente el alcance de la solución, al mostrar los
actores que interactúan con la misma, que usan los
casos con los que interactúan, y cualquier relación
entre los casos de uso.
El “Unified Modeling Language ™ (UML®) describe
la notación estándar para un diagrama de caso de
uso.
Relaciones
Las relaciones entre los actores y los casos de uso se
llaman asociaciones. Una línea de asociación indica
que un actor tiene acceso a la funcionalidad
representada por el caso de uso. Las asociaciones
no representan entrada, salida, tiempo o
dependencia.
Hay dos relaciones comúnmente usadas entre casos
de uso:
• Extend (Extender): permite la inserción de un
comportamiento adicional en un caso de uso. El
caso de uso que se está extendiendo debe ser
completamente funcional por sí mismo y no debe
depender del caso de uso extendido para su
6 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
ejecución exitosa. Esta relación se puede usar para
mostrar que se ha agregado un flujo alternativo a
un caso de uso existente (que representa nuevos
requisitos).
• Include (Incluir): permite que el caso de uso haga
uso de la funcionalidad presente en otro caso de
uso.
El caso de uso incluido no necesita ser un caso de
uso completo en sí mismo si no es desencadenado
directamente por un actor. Esta relación se usa con
mayor frecuencia cuando varios casos de uso
requieren alguna funcionalidad compartida o para
abstraer una pieza lógica compleja.
Ilustración: Caso de Usuario. Fuente: BABoK, IIBA
Descripción del caso de uso
Nombre
El caso de uso tiene un nombre único. El nombre
generalmente incluye un verbo que describe la
acción tomada por el actor y un nombre que
describe ya sea lo que se está haciendo o el objetivo
de la acción.
Meta
La meta es una breve descripción de un resultado
exitoso del caso de uso desde la perspectiva del
actor principal. Esto actúa como un resumen del
caso de uso.
Actores
Un actor es cualquier persona o sistema externo a
la solución que interactúa con esa solución. A cada
actor se le asigna un nombre único que representa
el papel que desempeñan en las interacciones con
la solución. Algunos enfoques de autoría de casos
de uso recomiendan el uso de sistemas o eventos
como actores.
Un actor inicia un caso de uso, al que se hace
referencia como el actor principal para ese caso de
uso. Otros actores que participan en el caso de uso
en un papel de apoyo se llaman actores
secundarios.
Condiciones previas
Una condición previa es cualquier hecho que debe
ser cierto antes de que el caso de uso pueda
comenzar. La condición previa no se prueba en el
caso de uso, pero actúa como una restricción para
su ejecución.
Disparador
Un disparador es un evento que inicia el flujo de
eventos para un caso de uso. El desencadenante
7 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
más común es una acción tomada por el actor
principal.
Un evento temporal (por ejemplo, tiempo) puede
iniciar un caso de uso. Esto se usa comúnmente
para disparar un caso de uso que se debe ejecutar
en función de la hora del día o de una fecha de
calendario específica, como una rutina de fin de día
o una reconciliación de un sistema al final del mes.
Flujo de eventos
El flujo de eventos es el conjunto de pasos
realizados por el actor y la solución durante la
ejecución del caso de uso. La mayoría de las
descripciones de casos de uso separan un flujo de
éxito básico, primario o principal, que representa el
camino más corto o más simple que logra el
objetivo del actor.
Los casos de uso también pueden incluir flujos
alternativos y de excepción. Los flujos alternativos
describen otros caminos que pueden seguirse para
permitir al actor lograr con éxito el objetivo del caso
de uso. Los flujos de excepciones describen la
respuesta deseada por la solución cuando el
objetivo es inalcanzable y el caso de uso no se
puede completar con éxito.
Post-condiciones o Garantías
Una condición posterior o garantía es cualquier
hecho que debe ser cierto cuando el caso de uso
está completo. Las condiciones posteriores deben
ser verdaderas para todos los flujos posibles a
través del caso de uso, incluidos los flujos primario y
alternativo. El caso de uso puede describir las post-
condiciones de forma separadas. Eso es cierto para
las ejecuciones exitosas y fallidas del caso de uso.
Estas pueden llamarse garantías; la garantía de
éxito describe las postcondiciones para el éxito. Las
garantías mínimas describen las condiciones que
deben cumplirse, incluso si el objetivo del actor no
se cumple, y pueden abordar problemas tales como
los requisitos de seguridad o la integridad de los
datos.
Consideraciones de uso
Fortalezas
• Los diagramas de casos de uso pueden aclarar el
alcance y proporcionar una comprensión de alto
nivel de los requisitos.
• Las descripciones de los casos de uso se entienden
fácilmente por los interesados debido a su flujo
narrativo.
• La inclusión de un objetivo o resultado deseado
asegura que el valor comercial del caso de uso esté
articulado.
• Las descripciones de casos de uso articulan el
comportamiento funcional de un sistema.
Limitaciones
• La flexibilidad del formato de descripción de caso
de uso puede conducir a la incorporación de
información que se captaría mejor utilizando otras
técnicas, como las interacciones de la interfaz de
usuario, los requisitos no funcionales y las reglas
comerciales.
• Las decisiones y las reglas comerciales que las
definen no deben registrarse directamente en los
casos de uso, sino que deben gestionarse por
8 www.activus.com.ar [email protected]
Historias de Usuario, Casos de Uso y escenarios
Diciembre 2017
separado y vincularse desde el paso
correspondiente.
• El formato flexible de los casos de uso puede
resultar en la captura de detalles inapropiados o
innecesarios en el intento de mostrar cada paso o
interacción.
• Los casos de uso, intencionalmente, no se
relacionan con el diseño de la solución y, como
resultado, es posible que se requiera un esfuerzo
significativo en el desarrollo para mapear los pasos
del caso de uso.
Sergio Salimbeni
Top Related