Métodos ágiles e

ingeniería de requisitos
con historias de
usuario
M.sC. Fredy Barrientos
Marzo 2019

[email protected]
 Contenido
• Ingeniería de requisitos
• Historias de usuario
– Introducción
– Formato
– Granularidad
– Requisitos no funcionales
– Elaboración
Ingeniería de requisitos con
historias de usuario
Métodos ágiles
 Ingeniería de requisitos
• Uso sistemático de principios contrastados,
técnicas, lenguajes y herramientas para el
análisis efectivo en coste, documentación y
evolución de las necesidades de usuario y la
especificación del comportamiento externo
del sistema para satisfacer dichas necesidades
 Ingeniería de requisitos
Ingeniería de requisitos

Desarrollo de requisitos Gestión de requisitos

Captura Análisis Especificación Validación

 Ingeniería de requisitos
Desarrollo de requisitos
• Identificar, acordar y documentar el conjunto
de requisitos y características de producto que
permitan alcanzar los objetivos de negocio
planteados
Gestión de requisitos
• Gestión de la evolución de los requisitos del
sistema: control de estado y seguimiento en la
evolución de requisitos, trazado de
dependencias entre requisitos adelante y
atrás a lo largo del ciclo de vida, …
 Requisitos
• Un requisito es una capacidad, característica o
factor de calidad que un sistema software
necesita para tener valor y utilidad para un
usuario
• Un objetivo básico de la ingeniería del
software es utilizar un enfoque sistemático
para encontrar, documentar, organizar y
monitorizar los requisitos cambiantes de un
sistema
• El modelo de proceso determina el enfoque
de gestión de los requisitos del sistema
 Clasificación de requisitos
• Los requisitos del software se clasifican
tradicionalmente en:
o Funcionales: Funciones o características que
describen qué debe hacer el sistema
o Reglas de dominio: Restricciones generales del
campo de aplicación o negocio: políticas,
estándares, normativas, etc.
o No funcionales: Atributos de calidad del sistema
• Hay varias clasificaciones
o ESA-SRD: Funcionales y no funcionales
o Proceso Unificado: FURPS+
o ISO/IEC 25000
 Descripción de requisitos de usuario
Enfoque centrado en producto
• Descripción de características que el sistema
ha de implementar para cumplir su objetivo:
funciones, objetos, atributos de calidad
• Apropiado para aplicaciones de sistema,
tiempo-real, empotradas, intensivas en
computación o tratamiento de datos, etc.
 Descripción de requisitos de usuario
Enfoque centrado en uso/usuario
• Descripción de usuarios y objetivos de
usuario, anticipando el uso que éstos harán
del sistema para cumplir sus objetivos
• Apropiado para aplicaciones de negocio
intensivas en interacción con los usuarios
 Historias de usuario
• Técnica de captura de requisitos centrada en
uso/usuario.
• Descripción concisa por escrito de un requisito
funcional del sistema software que
proporciona valor para un usuario (en general,
stakeholder)
• Se enfatiza el cumplimiento de objetivos de
usuario y el valor proporcionado
• Técnica vinculada a procesos ágiles y al
tratamiento de los requisitos
 Historias de usuario: formato

• As a [user role] I want to [goal] so as to [reason]

Quién Qué Por qué

• Yo como rol quiero un objetivo de forma que una

razón

• Como (rol) yo quiero (algo) para (beneficiarme)

 Historias de usuario: formato

• As a… Persona para que la que se cubre una

necesidad
• I want… lo que queremos que ocurra, por
ejemplo una característica o una funcionalidad
• So that… el valor que obtiene la persona de la
implementación de la característica o
funcionalidad
 Historias de usuario: formato
• En la primera parte de la historia de usuario, es
muy útil hacer referencia a usuarios de nuestro
producto
• En la segunda parte de la historia de usuario, se
explica lo que desde el punto de vista de la
persona debería suceder, sin entrar en
descripciones técnicas
• En la tercera parte se expresa el valor que la
persona quiere obtener, lo cual ayuda a entender
y refinar, o incluso cambiar la forma en la que
usuario obtiene el esperado
 Historias de usuario: ejemplos
• Como usuario típico quiero leer críticas
objetivas de las restaurantes próximos a una
localización con objeto de decidir a dónde
puedo ir a cenar
• Como usuario wiki quiero subir un fichero a la
wiki para compartirlo con mis colegas
• Como estudiante quiero consultar mis notas
online para no esperar hasta una
comunicación formal para saber si he
aprobado
Historias de usuario: ejemplos
 Historias de usuario: ejemplos
Listado de morosos
 Historias de usuario: ejemplos
• Ingreso al sistema: http://www.lecciones-
aprendidas.info/2015/03/ejemplo-de-historias-
de-usuario-ingreso.html
• Solicitud de información laboral del cliente:
http://www.lecciones-
aprendidas.info/2013/11/como-es-una-historia-
de-usuario-un.html
• Historias de usuario de sistema (procesos batch
etc.): http://www.lecciones-
aprendidas.info/2016/02/historias-de-usuario-
de-sistema-una.html
Historias de usuario: ejemplos
 Historias de usuario: formato
Tarjeta
• Descripción escrita de la historia de usuario a
efectos de descripción de requisitos y
planificación y como referencia para discusión
posterior
Conversación
• Sección para recoger información adicional en
relación con la historia de usuario y detalles
surgidos de conversaciones posteriores
 Historias de usuario: formato
Confirmación
• Sección que recoge condiciones de
satisfacción o pruebas de aceptación a realizar
para comprobar que la historia está completa
y funciona como se espera
 Historias de usuario: granularidad
• Las historias de usuario pueden escribirse con
diferente nivel de abstracción
– Epics. Grandes historias de usuario que pueden
abarcar meses de desarrollo y una más entregas
de producto
– Features. Historias de usuario de tamaño
intermedio, aunque demasiado grande para
implementar en un único sprint.
 Historias de usuario: granularidad
• Las historias de usuario pueden escribirse con
diferente nivel de abstracción (2)
– Stories. Historias de tamaño adecuado para
implementar en un sprint (días). Se implementan
mediante una serie de tareas.
– Theme. Contenedor de historias relacionadas
 Historias de usuario no funcionales
• Los requisitos no funcionales también pueden
escribirse como historias de usuario
o Como usuario quiero que el sistema soporte los
navegadores Firefox y Chrome
• Sin embargo, es recomendable incluir este tipo
de requisito en la definición de hecho, como
condición a comprobar con todas las historias de
usuario
• También es posible incluir actividades técnicas o
exploratorias en el product backlog como forma
de adquirir información o resolver riesgos
técnicos
 Historias de usuario: criterios
• INVEST
– Independent. Deben ser independientes entre si o
estar débilmente relacionadas
– Negotiable. No son un contracto ni una
especificación sino una referencia a una
característica que el equipo debe discutir y
clarificar para su desarrollo
– Valuable. Deben proporcionar valor al usuario (en
general, stakeholder) y describir características del
sistema, no tareas
 Historias de usuario: criterios
• INVEST
– Estimatable. Deben contener suficiente detalle
como para estimar el esfuerzo/coste de desarrollo
– Small. Su tamaño debe permitir su
implementación en un Sprint
– Testable. Deben ser comprobables mediante
pruebas
GRACIAS!

M.sC. Fredy Barrientos

Marzo 2019

[email protected]