Historias de Usuario con ATDD

1

AntecedentesEl desarrollo dirigido por comportamiento (BDD por sus siglas en inglés, Behaviour Driven Development) es una metodología de “afuera hacia adentro”. Comienza desde afuera identificando resultados de negocio, y de ahí profundiza hasta el conjunto de características que alcanzará dichos resultados.

Cada característica es capturada como una “historia”, que definirá el alcance de la característica junto con su criterio de aceptación. Este artículo introduce la manera en que BDD define e identifica historias y sus criterios de aceptación.

El recordatorio de la conversación con el cliente

Características

28/04/2023 UPC - Ingeniería de Requerimientos 3

Independientes. Deben ser atómicas en su definición. Es decir, se debe intentar que no dependa de otras historias para poder completarla.

Negociables. Como he dicho anteriormente, son entidades vivas. Deben ser ambiguas en su enunciado para poder debatirlas, dejando su concreción a los criterios de aceptación.

Valoradas. Deben ser valoradas por el cliente. Para poder saber cuanto aporta al Valor de la aplicación y junto con la estimación convertirse en un criterio de prioridad.

Características

4

Estimables. Aunque sea siempre un poco como leer de una bola de cristal, deben poder ser estimadas. Tener su alcance lo suficientemente definido como para poder suponer una medida de trabajo en la que pueda ser completarla.

Pequeñas. Para poder realizar una estimación con cierta validez y no perder la visión de la Historia de Usuario, se recomienda que sean mayores de dos días y menores de dos semanas.

Verificables. Este es el gran avance de las Historias de Usuario. Que, junto con el cliente, se acuerdan unos Criterios de Aceptación que verifican si se ha cumplido con las funcionalidades descritas y esperadas.

Sintaxis:

28/04/2023 UPC - Ingeniería de Requerimientos 5

Descripción: Como (Rol) requiero (funcionalidad) para (beneficio).

Criterios de aceptación: Verificar (Resultado), cuando (Condición).

Composición de una Historia de Usuario Simple

28/04/2023 UPC - Ingeniería de Requerimientos 6

Partes de la Historia de Usuario

7

Código: Es un valor único que identifica la historia de usuario de otras historias dentro de un proyecto. Se puede presentar en cualquier formato. Ejemplos: 01, 001, HU001.

Nombre: Es el título de la historia de usuario como resumen de la funcionalidad que se describirá en ella. Generalmente se presenta en infinitivo como la acción que se desarrollará. Ejemplos: Iniciar sesión, Ingresar nómina, Registrar datos.

Actor: Es el rol que tendrá la persona que realiza la funcionalidad de la historia de usuario en el sistema a construir. Ejemplos: Administrador, Coordinador, Auxiliar.

Partes de la Historia de Usuario

8

Descripción:

“Como (Actor) quiero (funcionalidad) que (beneficio).”

En dónde,

-El actor es el rol descrito anteriormente.

-La funcionalidad es la necesidad del interesado.

-La funcionalidad tendrá la siguiente estructura: Verbo + Concepto.

-El beneficio es lo que se obtiene al ejecutar dicha funcionalidad. La cláusula “que (beneficio)” es opcional.

Ejemplo Historia de Usuario

9

Ejemplo:

Como estudiante quiero comprar un tiquete de bus que sirva para ir a la escuela.

En dónde,

Actor: Estudiante

Funcionalidad:

Verbo: Comprar

Concepto: tiquete de bus.

Beneficio: sirva para ir a la escuela.

Criterios de aceptación

10

Compone de condición + resultado

En donde la condición representa lo que se debe cumplir para obtener dicho resultado.

Estructurado debería de quedar de la siguiente manera:

“Cuando se” + Acción + Concepto

Ejemplo:

Cuando se busca los criterios de búsqueda, se debe cumplir que si los campos no tienen valor, se presente un mensaje.