Análisis de Sistemas de Información
Historias de Usuario
Ing. Ramiro Garbarini
Ver.200504
Jerarquía de Requerimientos Ágiles
• Strategic Theme (Iniciativa): Objetivo estratégico
• Ej: Mejorar la experiencia académica.
• Epic (Épica): Gran funcionalidad
• Ej: Acceso online a información académica.
• Feature: Funcionalidad concreta.
• Ej: Consulta de calificaciones.
• User Story (Historia de Usuario): Unidad mínima de valor.
• Ej: Recibir avisos por mail al publicarse notas.
Strategic Themes
Epics
Features
Estructura propuesta por
Dean Leffingwell, utilizada
en SAFe (Scaled Agile
User Stories Framework).
2
Jerarquía de Requerimientos Ágiles
¿Por qué descomponer en niveles?
• Se trabaja con distintos niveles de detalle según el avance.
• Las épicas representan la visión general (no hace falta mucho detalle al
principio).
• A medida que se avanza, se refinan en features e historias de usuarios, las
cuales son manejables.
• Esto permite planificar de forma progresiva, con menor carga documental y
más agilidad.
Strategic Themes
Epics
“The objective is vision, not specificity.”
Dean Leffingwell, Agile Software Requirements
El objetivo es transmitir una visión, no entrar en Features
especificaciones detalladas.
User Stories
3
Jerarquía de Requerimientos Ágiles
• Modelo de Requerimientos
4
De una Iniciativa a Historias de Usuario
Iniciativa
• Modernización de servicios académicos digitales
– Objetivo:
• Brindar a los estudiantes una experiencia académica más
ágil, accesible y autónoma, mediante la digitalización de
procesos clave como inscripciones, consultas,
notificaciones y gestión personal, desde cualquier
dispositivo y sin necesidad de trámites presenciales.
– Épicas:
• Autogestión académica
• Rediseño de la experiencia digital del estudiante
• Integración con sistemas externos
• Comunicación institucional automatizada
5
De una Iniciativa a Historias de Usuario
Épica
• Plataforma de Autogestión Académica
– Objetivo: Brindar a los estudiantes herramientas para gestionar
su cursada de forma autónoma.
– Hipótesis de valor: Mejora la experiencia estudiantil y reduce la
carga administrativa.
6
De una Iniciativa a Historias de Usuario
Épica: Autogestión Académica
• Feature #1: Consulta de calificaciones
– Hipótesis de beneficio:
• Brindar visibilidad inmediata sobre el desempeño académico.
– Criterios de aceptación:
• Mostrar todas las materias cursadas, notas parciales y
finales.
• Incluir opción de descarga en PDF.
• Feature #2: Gestión de inscripciones
– Hipótesis de beneficio:
• Facilitar la inscripción autónoma a materias y exámenes.
– Criterios de aceptación:
• Permitir inscripción en fechas habilitadas.
• Mostrar opciones compatibles con correlatividades y turnos.
7
¿Cómo se puede definir un Product Backlog Item?
Product Backlog Item
Un Product Backlog Item (PBI) es una unidad de valor que
representa algo que el sistema debe hacer o entregar.
- Para redactarlos pueden utilizarse varias técnicas
(requerimientos, casos de uso, escenarios, historias de usuario)
- Deben contener mínimamente:
- Descripción
- Estimación
- Un orden (respecto a los otros PBI)
El formato más usado para definirlo es: Historia de Usuario
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 8
HISTORIAS DE USUARIO
Una historia de usuario es una breve descripción de algo que el
sistema necesita hacer para satisfacer una necesidad del usuario
“A user story is a brief statement of intent that describes
something the system needs to do for the user.”
Dean Leffingwell, Agile Software Requirements
¿Para qué sirve?
• Para registrar qué necesita el usuario de forma clara y sencilla.
• Para facilitar el diálogo entre el equipo y los distintos actores del proyecto.
• Para asegurar que el desarrollo esté enfocado en generar valor real.
¿Cómo es?
• Es corta y fácil de entender.
• Está escrita en lenguaje cotidiano.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 9
Conceptos Generales - Historia de Usuario
Se compone de 3 elementos (3 Cs):
• Card (tarjeta)
• Conversation (conversación)
• Confirmation (confirmación).
Card Conversation Confirmation
Debe ser tan atómica que se Debe ser el resultado de una Debe estar redactada de forma
debe poder escribir en una conversación entre el equipo de que el equipo comprenda qué
tarjeta del tablero. Declaración trabajo y el Product Owner. se debe construir y cuáles
breve, clara y comprensible. son las condiciones para
considerar la historia como
finalizada.
Esto se conoce como criterios
de aceptación: una lista de
condiciones que deben
cumplirse para que la historia
pueda darse por completa.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 10
Historia de Usuario
Formato: Como - Quiero - Para
“Como <Rol del usuario>, Quiero <Funcionalidad/Necesidad>
Para <Beneficio a obtener>”
(Los roles pueden ser personas, dispositivos o sistemas)
Ejemplo:
Como comprador, Quién
Quiero poder pagar Esta estructura permite:
con transferencia Qué • Claridad en la necesidad del usuario.
• Enfoque en el valor de negocio.
bancaria • Facilitación del diálogo con el equipo de
Para poder hacerlo Para qué
desarrollo.
desde mi casa
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 11
Historia de Usuario
Ejemplo de Historia de Usuario con las 3 Cs
Card Conversation Confirmation
Poder hacerlo con
Como comprador, ¿Qué pasa con los
diferentes bancos? cualquier banco.
Quiero poder pagar con
transferencia bancaria Que la ejecución de la
Para poder hacerlo transacción no demore
desde mi casa más de 5 segundos.
Deberíamos permitir
Que al finalizar el pago me
transferencias desde
envíe un correo con la
cualquier banco
confirmación de realizado.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 12
Historia de Usuario
Ejemplo de Historia de Usuario con las 3 Cs
Card Conversation Confirmation
El sistema debe aceptar
¿Debe validarse el tarjetas Visa y Mastercard.
Como comprador, límite de la tarjeta
La transacción no debe
Quiero poder pagar con antes de autorizar?
demorar más de 5
tarjeta de crédito segundos.
Para evitar usar efectivo
Se debe mostrar un
Sí, se hace a través
del servicio de pago mensaje de confirmación.
del operador de la Se debe registrar la
tarjeta (gateway). operación en el historial
del usuario.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 13
Historia de Usuario
Otro Ejemplo de Historia de Usuario con las 3 Cs
Card Conversation Confirmation
Poder hacerlo con
¿Existe algún máximo
de dinero a retirar por cualquier sucursal del
Como cliente del banco, transacción? banco.
Quiero retirar dinero de Que el saldo de mi cuenta
mi cuenta Para hacer quede actualizado.
pagos en efectivo
Sí, $200 por Que al finalizar la
transacción, y $1.000 transacción me envíe un
por día correo con el saldo
actualizado.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 14
Historia de Usuario
Otro Ejemplo de Historia de Usuario con las 3 Cs
Card Conversation Confirmation
- ¿Qué información se
necesita ver?
¿Qué información se
Se necesita
→ necesita ver?ver el Poder acceder desde
Como consumidor, consumo diario en kWh en cualquier dispositivo con
Quiero ver mi consumo un gráfico de barras. conexión.
diario de energía Para
poder reducir mis Visualizar el consumo
costos y uso energético. Sí, $200
- ¿Con qué por se
frecuencia diario de los últimos 45
transacción, y $1.000 días.
actualizan los datos?
por día
→ Una vez por día, con
datos del día anterior.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 15
Historia de Usuario
Otro Ejemplo de Historia de Usuario con las 3 Cs
Card Conversation Confirmation
¿está bien
definido?
- ¿Qué información se
necesita ver?
¿Qué información se
Se necesita
→ necesita ver?ver el Poder acceder desde
Como consumidor, consumo diario en kWh en cualquier dispositivo con
Quiero ver mi consumo un gráfico de barras. conexión.
diario de energía Para
poder reducir mis Visualizar el consumo
costos y uso energético. Sí, $200
- ¿Con qué por se
frecuencia diario de los últimos 45
transacción, y $1.000 días.
actualizan los datos?
por día
→ Una vez por día, con
datos del día anterior.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 16
Historia de Usuario
Características de una historia de usuario: INVEST
I Independent Independiente
N Negotiable Negociable
V Valuable Valiosa
E Estimable Estimable
S Small (*) Pequeña (*)
T Testable Testeable
*Si no es estimable la historia es demasiado grande, o falta de
conocimiento funcional o falta de conocimiento técnico.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 17
Historia de Usuario - INVEST
Card Conversation Confirmation
- ¿Cómo se le avisa al estudiante?
- Al cargarse una nota el Sistema
Como estudiante, Quiero → Por mail. envía la notificación por mail.
recibir notificaciones cuando - La notificación incluye materia,
se publiquen mis notas Para - ¿Cuándo se notifica? nota y fecha.
estar al tanto de los resultados
de las cursadas → Apenas el docente carga la - Si se modifica la nota, se
nota en el sistema. manda una nueva notificación
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 18
De una Iniciativa a Historias de Usuario
Épica: Autogestión Académica
• Feature #1: Consulta de calificaciones
– Hipótesis de beneficio:
• Brindar visibilidad inmediata sobre el desempeño académico.
– Criterios de aceptación:
• Mostrar todas las materias cursadas, notas parciales y
finales.
• Incluir opción de descarga en PDF.
• Feature #2: Gestión de inscripciones
– Hipótesis de beneficio:
• Facilitar la inscripción autónoma a materias y exámenes.
– Criterios de aceptación:
• Permitir inscripción en fechas habilitadas.
• Mostrar opciones compatibles con correlatividades y turnos.
19
De una Iniciativa a Historias de Usuario
Épica: Autogestión Académica
• Feature #1: Consulta de calificaciones
– Historias de Usuario:
• Como estudiante, quiero ver mis calificaciones finales por materia, para
saber si promocioné.
• Como estudiante, quiero poder descargar un reporte de mis notas,
para tenerlo como respaldo.
• Feature #2: Gestión de inscripciones
– Historias de Usuario:
• Como estudiante, quiero inscribirme a materias desde la web de la
facultad, para no tener que ir a la facultad.
• Como estudiante, quiero visualizar los horarios disponibles antes de
inscribirme, para poder organizar mi semana.
• Como estudiante, quiero recibir una confirmación por mail al
inscribirme, para tener constancia de que quedó registrada.
20
Historia de Usuario
Ejercicio 1
• Escribir 2 historias de usuario del ejercicio
Un negocio de venta de electrodomésticos decidió implementar y
otorgar una línea de crédito a sus clientes para la compra de
productos. Los créditos son solicitados por los clientes al vendedor, al
momento de realizar la compra, y deben ser autorizados por un
representante de la gerencia de créditos. Son pagados por el cliente
a través de débito automático en tarjetas de crédito. Si el crédito se
acepta, se entrega el producto al cliente en forma inmediata.
Cada mes se debitará de manera automática el pago de las cuotas de
la tarjeta del cliente.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 21
Historia de Usuario
Resolución
1. Como cliente quiero solicitar un crédito para poder realizar una
compra en cuotas.
2. Como representante de la gerencia de créditos quiero poder aprobar
créditos a los clientes para que puedan realizar una compra.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 22
Ejercicio #2
Teniendo en cuenta el siguiente enunciado::
1) Detectar y listar al menos 3 historias de usuario relevantes del sistema descripto.
(Usar el formato: Como [rol], quiero [objetivo] para [beneficio])
El Sanatorio “Buena Salud” está planificando la implementación de un nuevo sistema web que permita a sus pacientes
gestionar turnos de manera online. El objetivo principal es brindar mayor comodidad a los usuarios y reducir las llamadas
telefónicas y los tiempos de espera.
El sistema deberá permitir que los pacientes tramiten turnos tanto para consultas médicas en consultorio como para estudios.
Para poder utilizar la plataforma, será necesario que cada paciente se registre online completando un formulario con su
nombre, DNI, cobertura médica y correo electrónico. Una vez finalizado el registro, el sistema enviará a ese correo un
usuario y una contraseña temporal, que deberá ser modificada por el paciente en su primer ingreso.
Al iniciar sesión, el sistema mostrará un menú con las acciones disponibles. Los pacientes podrán:
∙ Solicitar un nuevo turno.
∙ Modificar o anular un turno ya asignado.
∙ Reimprimir el comprobante de un turno vigente.
Para solicitar un turno, el sistema mostrará un listado de las especialidades médicas disponibles en el sanatorio. Al seleccionar
una especialidad, se visualizará una grilla con días, horarios disponibles y médicos asignados. El paciente podrá elegir el turno
que mejor se adapte a su disponibilidad.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 24
Ejercicio #2
Una vez seleccionado el turno, el sistema verificará si está disponible. En caso de que ya haya sido asignado a otro paciente, se
mostrará un mensaje informando la situación y se invitará a elegir otra opción. Si el turno está disponible, el sistema
verificará si la cobertura médica del paciente cubre la atención. Si la respuesta es afirmativa, se solicitará la confirmación
del turno. Al confirmar, el turno quedará registrado y se generará un comprobante en formato PDF, con la información del
paciente, la fecha, el horario, el médico y el sector correspondiente. Si el paciente no confirma el turno, la operación se
cancelará y se volverá al menú principal.
En los casos en que la cobertura médica no cubra el turno solicitado, el sistema deberá conectarse con el posnet de la obra
social para gestionar la autorización correspondiente.
El paciente también podrá modificar un turno ya asignado, pudiendo cambiar la especialidad, el médico y/u horario, siempre y
cuando haya disponibilidad. El sistema deberá validar nuevamente la disponibilidad del nuevo turno y si la cobertura lo
cubre, de la misma forma que en la solicitud inicial.
Asimismo, se podrá anular un turno existente. Una vez anulado, ese turno quedará liberado para que otros pacientes puedan
reservarlo.
El paciente tendrá acceso al listado de sus turnos asignados y podrá reimprimir el comprobante de cualquiera de ellos, el cual
estará disponible en formato PDF para descargar o imprimir.
Por su parte, cada secretaría de sector podrá ingresar al sistema al comenzar el día y obtener un listado de los turnos
asignados a su área, con el fin de organizar la jornada de atención médica. Este listado incluirá el nombre del paciente, la
hora del turno y el médico asignado, y podrá ser exportado o impreso en formato PDF.
Toda la información gestionada por el sistema deberá almacenarse en una base de datos SQL Server.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 25
Ejercicio #2 - Resolución
1. Como paciente, quiero registrarme online para obtener usuario y clave, y así poder ingresar al
sistema.
2. Como paciente, quiero solicitar un turno online para evitar tener que llamar o ir personalmente.
3. Como paciente, quiero modificar un turno ya solicitado para cambiar el horario por uno más
conveniente
4. Como paciente, quiero anular un turno que ya no voy a usar para liberar ese espacio.
5. Como paciente, quiero reimprimir el comprobante de un turno ya asignado para tenerlo disponible
en papel.
6. Como paciente, quiero recibir por mail la confirmación del nuevo turno asignado para asegurarme de
haber obtenido el turno.
7. Como paciente, quiero saber si mi cobertura está vigente para saber si debo pagar el canon por la
consulta.
8. Como secretaria, quiero obtener el listado diario de turnos para organizar la atención diaria.
9. Como secretaria, quiero obtener el listado diario de turnos para distribuir el listado a los médicos
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 26
Ejercicio #2 - Resolución
Historia 1
∙ Card:
o Como paciente, quiero registrarme online para obtener usuario y clave
para poder ingresar al sistema.
∙ Conversation:
o ¿Qué datos debo completar en el registro?
▪ Nombre, DNI, cobertura médica, correo electrónico.
o ¿Cómo recibo mi usuario y clave?
▪ Vía correo electrónico una vez completado el registro.
∙ Confirmation:
o Debe haber un formulario online para el registro.
o El sistema debe enviar las credenciales al correo ingresado.
o El usuario debe poder modificar la contraseña en el primer ingreso.
27
Ejercicio #2 - Resolución
Historia 5
∙ Card:
o Como paciente, quiero reimprimir el comprobante de un turno ya asignado para tenerlo
disponible en papel o digital.
∙ Conversation:
o ¿Puedo acceder a turnos pasados y futuros?
▪ El sistema debería permitir consultar el historial de turnos.
o ¿Puedo ver un comprobante sin descargarlo?
▪ Sería útil que se pueda previsualizar antes de descargar.
o ¿El sistema permite descargarlo en PDF?
▪ Lo esperado es que el comprobante se genere en PDF.
∙ Confirmation:
o El sistema debe mostrar una lista de turnos asignados.
o Debe permitir seleccionar uno y generar un comprobante.
o Debe emitirlo en formato PDF descargable e imprimible.
28
Ejercicio #2 - Resolución
Historia 8
∙ Card:
o Como secretaria, quiero obtener el listado diario de turnos para imprimirlo y
entregárselo a los médicos (o para organizar la atención médica del día)
∙ Conversation:
o ¿Qué información se debe mostrar?
▪ Debe incluir paciente, hora y médico asignado
o ¿Qué formato tiene el listado?
▪ Lo más conveniente sería que se genere en PDF.
∙ Confirmation:
o El sistema debe permitir consultar turnos por fecha y sector.
o Debe mostrar el listado con paciente, hora y médico asignado.
o Debe ofrecer una opción para imprimir o exportar en PDF.
29
Bibliografía
• User Stories Applied: For Agile Software Development
• Cohn, M. (2004). User stories applied: For agile software development.
Addison-Wesley Professional.
• Agile Software Requirements
• Leffingwell, D. (2011). Agile Software Requirements: Lean
Requirements Practices for Teams, Programs, and the Enterprise.
Addison-Wesley.
• SAFe 5.0 Distilled
• Knaster, R., Leffingwell, D. (2020). SAFe 5.0 Distilled: Achieving
Business Agility with the Scaled Agile Framework. Reino Unido: Pearson
Education.
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 30
Recursos Complementarios
• Agilidad y Complejidad ¿Cuándo, por y para qué? VUCA, Cynefin
y Stacey
• Cynefin: el GPS para la adaptabilidad
• Historias de Usuario - ¿Qué hay detrás de esas historias que
tanto nos movilizan?
• Historias de Usuairo - ¿Cómo hacer que sean una genial
inversión?
• Tablero Kanban
ANÁLISIS DE SISTEMAS DE INFORMACIÓN 31
