Historias de usuraio casos de uso y escenarios

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]


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

http://www.activus.com.ar/



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




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.




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




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




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




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

[email protected]


Historias de usuraio casos de uso y escenarios

Business

Transcript of Historias de usuraio casos de uso y escenarios