8.2 - Historias de Usuarios

1
. Ingeniería de Requerimientos
. Requerimientos y Negocios
. Ciclo de Vida de Sistemas
Temas a desarrollar 2
• Historias de Usuario
➢ ¿ Qué es?
➢ ¿ Cuál es su estructura?
➢ ¿ Cuáles son sus componentes?
➢ ¿ Qué son los criterios de Aceptación?
➢ ¿ Como escribir criterios de Aceptación?
➢ Características de historias de usuario.
➢ ¿ Qué es una Épica?
• Lo qué NO son Historias de Usuario.

• Guía para escribir Historias de Usuario.
3
Requerimientos y Problemas de comunicación

4
Enfocarse en El Foco
Entender el
soluciones es no perder
problema
no en el el foco
software
5
¿ Qué es una historia de usuario?

Historias de Usuario 6
¿ Qué es?
Una historia de usuario (o user story en inglés)

describe una funcionalidad que, por sí misma, aporta
valor al usuario/negocio.
Es una descripción breve de algo que el usuario

quiere, una necesidad del negocio.
Es una representación de una funcionalidad o

característica que el usuario necesita.
Historias de Usuario
7
¿ Cuál es su estructura?
COMO [rol del usuario],

QUIERO [una funcionalidad/ Característica]
PARA [alcanzar un objetivo /Resultado
/ Beneficio]
¿QUIEN?
¿QUE?
¿PARA QUE?
8
¿ Cuáles son sus componentes ?

9
Tienen 3 componentes claves (CCC)
Tarjeta (Card): ficha de papel pequeña donde se

describe la información que detalla la historia
Conversación (Conversation): usuario y miembros

del equipo discuten verbalmente la historia para
ampliar detalles, disipar dudas, alinear expectativas
y lograr entendimiento común.
Confirmación (Confirmation): la historia de usuario

debe estar lo suficientemente especificada para
que el equipo de desarrollo sepa que hacer y que
espera el usuario (Criterios de Aceptación)
10
Tienen 3 componentes claves (CCC)
Como un cliente registrado quiero acceder al sitio

xxx para poder ver los productos disponibles.
?Cuantos intentos
?Qué pasa si la tiene para ingresar?
clave expiro?
❑ Las claves expiradas no acceden.

❑ Después de 3 intentos la cuenta queda
bloqueada
11
¿ Qué son los criterios de Aceptación?

Criterios de Aceptación
➢ Son las condiciones que ( el producto de software) la historia

de usuario debe satisfacer para ser aceptado por un usuario,
cliente o stakeholder.
➢ Conjunto de sentencias redactadas de tal manera que
conduzcan a una respuesta clara de “aceptado/rechazado”.
➢ Pueden especificar reglas / restricciones tanto funcionales
como no funcionales.
➢ Deben ser entendibles por cualquier usuario y no dar lugar a
la ambigüedad.
➢ Deben ser testeables o verificables.
➢ El criterio de aceptación se cumple o no se cumple. No existe
el concepto de cumplir parcialmente un criterio de
aceptación.
13
Los criterios de aceptación cumplen 2 funciones
Clarificar el contexto en el que Facilitar el saber cuando una

ocurre la historia de usuario. historia está realmente terminada
Los buenos criterios de Los criterios de aceptación
aceptación son: Claros, también son el medio por el
concisos, expresan una sola cual el equipo de desarrollo es
cualidad de la historia. capaz de saber cuando está
terminada la historia y ser
En la mayoría de las ocasiones
capaces de testar los
son redundantes, explicando
elementos de la historia en
desde múltiples puntos de vista
conjunto.
cual es la imagen finalizada de
la historia de usuario.
14
¿ Cómo escribir criterios de Aceptación?

Como escribir criterios de Aceptación
Se pueden especificar usando la estructura Dado-Cuando-Entonces

 Dado <escenario o estado inicial>
 Cuando <evento o comportamiento realizado>
 Entonces <cambios o resultados esperados luego del comportamiento
especificado>
Ejemplo
 Dado estoy en la pantalla de login e ingreso usuario y contraseña correctos
 Cuando envío la información de usuario y contraseña
 Entonces visualizo la página de inicio de la aplicación
Como escribir criterios de Aceptación
Pueden escribirse como una sola sentencia

❑ La pantalla de login tiene dos campos: usuario, contraseña.
❑ Después de presionar cancelar, se muestra un mensaje de confirmación.
❑ El reporte que se muestra en pantalla puede ser ordenado por los campos legajo
de alumno y Apellido.
Pueden escribirse como una sola sentencia (reglas de negocio)

 La contraseña es alfanumérica de 10 caracteres.
 Cada 24 horas se cancelan automáticamente las reservas no confirmadas.
17
Características de historias de usuario

18
Características de historias de Usuario son 6
Independiente
Negociable
INVEST Valorable
Estimable
Small
Testeable
19
Características de historias de Usuario
Independiente • La Historia de Usuario debe ser independiente, de manera

que no haya dependencia con otra Historia
• Las Historias de Usuario pueden ser cambiadas, reescritas o

Negociable desechadas hasta el momento en que se empieza el
desarrollo de la misma.
Valorable
• Una Historia de Usuario debe proveer valor agregado al
usuario final
20
Características de historias de Usuario
Estimable • Siempre se debe poder estimar el tamaño de una Historia

de Usuario.
• Las Historias de Usuarios deben tener un tamaño tal que sea

Small
posible planificarlas/estimarlas, con cierto nivel de certeza.
• La Historia de Usuario o su descripción relacionada deben

Testeable proveer la información necesaria para que el desarrollo de
tests sea posible.
21
¿ Qué es una Épica?

¿ Qué es una Épica?
Una Épica puede verse como una historia de usuario muy

grande.
Es un agrupador conceptual.
Se componen de historias de usuario.
Épica
COMO empleado de la Universidad QUIERO realizar altas, bajas y
modificaciones de estudiantes PARA mantener registro de los mismos.
COMO empleado de la Universidad QUIERO dar de alta un estudiante

PARA ingresar sus datos al sistema.
COMO empleado de la Universidad QUIERO modificar información de

un estudiante PARA corregir o complementar su información
COMO empleado de la Universidad QUIERO dar de baja un

estudiante PARA no tener información innecesaria en el sistema
COMO empleado de la Universidad QUIERO visualizar información de

estudiantes PARA poder acceder a sus datos
24
Lo que NO son Historias de Usuario

Lo que NO son historias de usuario HU:
No son Requerimientos Funcionales (RF) y No funcionales (RNF)
Los requerimientos Funcionales y No Funcionales se enfocan en las características que debe

tener el software en cambio las historias de usuario se enfocan en el problema que el usuario
quiere resolver.
No son Casos de Usos (CU)

En general las HU son mas pequeñas (tienen un menor alcance) que los CU.
Tienen distinto nivel de completitud.
Los CU son artefactos que generalmente demandan mayor tiempo de desarrollo y las HU se
desarrollan y se archivan en un periodo de tiempo corto (no mas de 2 semanas).
Los CU suelen tener mas detalles de la IU.
Los CU suelen trazar con varios RF y RNF.
26
Ejemplos
Requerimiento de Sistema
RF1. El sistema debe enviar solicitudes de inscripción a los cursos, a través de
mensajes de correo electrónico.
Los requerimientos de sistema están escritos desde la perspectiva del

sistema y no en la interacción del usuario, representan las
características en estado puro.
27
Ejemplos
Casos de Uso
ID: CU001
Nombre: Enviar un mensaje de correo
Actor: Postulante
Pre condición: existen direcciones de correo electrónico válidas.

Post Condición: Mensaje de correo enviado.
Flujo Básico:
1. El Actor selecciona “Nuevo Mensaje”
2. El sistema muestra la caja de dialogo “Escribir nuevo mensaje”
3. El Actor edita el cuerpo del mail y completa el asunto y la(s)
direccione(s) destino
4. El Actor hace click en el botón “Enviar”
5. El sistema envía el correo
Los Casos de Uso están escritos como
6. …. una serie de interacciones entre el
.Flujo Alternativo: actor y el sistema. Hacen hincapié en
el contexto orientado al rol que
interactúa con el sistema.
28
Ejemplos
Historia de Usuario
COMO postulante QUIERO enviar un mensaje de correo PARA inscribirme en un

curso.
Criterios de aceptación:
❑ Se muestra la pantalla para redactar el mensaje de inscripción con los campos:
x, y x z
❑ La dirección del destinatario es: abcdf@ejemplo.edu.ar
….
Las Historias de Usuario describen lo que el usuario desea

ser capaz de hacer. Se centran en el valor que se obtiene
de la funcionalidad en lugar de especificar paso a paso
lo que el sistema debe hacer.
Historia de Usuario
29
Guía Para escribir buenas Historias de usuario:
➢ Para identificar las Historias de Usuario comenzar considerando los

objetivos de cada rol o tipo de usuario que va a utilizar el sistema.
➢ Al dividir Historias o Épicas, intentar crear nuevas Historias de Usuario que
corten “transversalmente” todas las capas de la aplicación.
➢ Crear Historias de Usuario pequeñas y lo mas especificas posibles.
➢ Las Historias de Usuario siempre deben agregar valor tangible al cliente o
usuario final.
➢ El cliente o usuario (o quien lo represente) es quien debe escribir las
Historias de Usuario.
➢ Agregar la documentación necesaria a cada Historia de Usuario
(restricciones, validaciones, dependencias, RNF, casos de prueba, etc.)
de manera colaborativa.
➢ Respetar la estructura (COMO-QUIERO-PARA) + Criterios de Aceptación.
Historia de Usuario
30
¿Porque usar historias de usuario?
➢ Las Historias de Usuario enfatizan la comunicación y

colaboración.
➢ Las Historias de Usuario son comprensibles por ambas partes,
equipo de desarrollo y clientes o usuarios.
➢ Las Historias de Usuario tienen el tamaño ideal para estimar y
planificar.
➢ Las Historias de Usuario son ideales para trabajar de manera
iterativa e incremental (de a pequeños pasos).
➢ Las Historias de Usuario alientan a escribir los detalles recién
cuando se tiene un entendimiento claro de lo que se necesita.
Ejemplos
Sistema Bancario Créditos

Ejemplo 1: COMO Ejecutivo de cuenta, QUIERO que el sistema
indique cuales son los documentos que debo solicitar al cliente PARA
procesar su solicitud de crédito hipotecario.
Criterios de Aceptación:
❑ xx
❑ xxxx
Ejemplos
Sistema Compras Online

Ejemplo 2: COMO un Cliente, QUIERO que los productos
seleccionados para la compra queden en un carrito de compras
PARA poder visualizar todos los productos que seleccione y el precio
total.
❑ xx
❑ xxxx
Ejemplos
Sistema RRHH
 Ejemplo 3: COMO Jefe de RRHH, QUIERO que el sistema xxxx se
conecte con el sistema yyyyy PARA importar los resultados de las
evaluaciones de desempeño de los empleados.
❑ xx
❑ xxxx

8.2 - Historias de Usuarios

Cargado por

Copyright:

Formatos disponibles

8.2 - Historias de Usuarios

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

8.2 - Historias de Usuarios

Cargado por

Copyright:

Formatos disponibles

1

• Lo qué NO son Historias de Usuario.

Requerimientos y Problemas de comunicación

¿ Qué es una historia de usuario?

Una historia de usuario (o user story en inglés)

Es una descripción breve de algo que el usuario

Es una representación de una funcionalidad o

COMO [rol del usuario],

¿ Cuáles son sus componentes ?

Tienen 3 componentes claves (CCC)

Tarjeta (Card): ficha de papel pequeña donde se

Conversación (Conversation): usuario y miembros

Confirmación (Confirmation): la historia de usuario

Tienen 3 componentes claves (CCC)

Como un cliente registrado quiero acceder al sitio

❑ Las claves expiradas no acceden.

¿ Qué son los criterios de Aceptación?

➢ Son las condiciones que ( el producto de software) la historia

Clarificar el contexto en el que Facilitar el saber cuando una

¿ Cómo escribir criterios de Aceptación?

Se pueden especificar usando la estructura Dado-Cuando-Entonces

Como escribir criterios de Aceptación

Pueden escribirse como una sola sentencia

Pueden escribirse como una sola sentencia (reglas de negocio)

Características de historias de usuario

Independiente • La Historia de Usuario debe ser independiente, de manera

• Las Historias de Usuario pueden ser cambiadas, reescritas o

Estimable • Siempre se debe poder estimar el tamaño de una Historia

• Las Historias de Usuarios deben tener un tamaño tal que sea

• La Historia de Usuario o su descripción relacionada deben

¿ Qué es una Épica?

¿ Qué es una Épica?

Una Épica puede verse como una historia de usuario muy

COMO empleado de la Universidad QUIERO dar de alta un estudiante

COMO empleado de la Universidad QUIERO modificar información de

COMO empleado de la Universidad QUIERO dar de baja un

COMO empleado de la Universidad QUIERO visualizar información de

Lo que NO son Historias de Usuario

Los requerimientos Funcionales y No Funcionales se enfocan en las características que debe

No son Casos de Usos (CU)

Los requerimientos de sistema están escritos desde la perspectiva del

Pre condición: existen direcciones de correo electrónico válidas.

COMO postulante QUIERO enviar un mensaje de correo PARA inscribirme en un

Las Historias de Usuario describen lo que el usuario desea

➢ Para identificar las Historias de Usuario comenzar considerando los

➢ Las Historias de Usuario enfatizan la comunicación y

Sistema Bancario Créditos

Sistema Compras Online

También podría gustarte