Análisis de requisitos

El oficio: descubrir el problema antes de describir la solución

Un analista de requisitos no toma nota de lo que se le pide: averigua qué necesidad hay detrás y la deja escrita de forma que pueda construirse, comprobarse y, llegado el caso, cambiarse. La disciplina tiene un cuerpo de conocimiento reconocido (la guía BABOK del IIBA) y normas internacionales para la especificación (ISO/IEC/IEEE 29148, que sustituyó a la antigua IEEE 830).

Hay una razón económica para tomárselo en serio: un requisito mal entendido es el defecto más barato de evitar y el más caro de corregir. Descubrirlo en una conversación cuesta minutos; descubrirlo con el sistema en producción obliga a rehacer diseño, código, pruebas y, a veces, la confianza del cliente.

Las seis áreas de conocimiento de BABOK

La guía organiza el trabajo del analista de negocio en áreas que conviene tener presentes como mapa:

Entender el contexto: interesados y objetivos

Antes de recoger ningún requisito hay que saber para qué se hace el proyecto y quién tiene voz en él.

Mapa de interesados

Un interesado (stakeholder) es cualquier persona u organización afectada por el sistema o con capacidad de afectarlo. Se suelen olvidar tres grupos: quien mantiene el sistema, quien opera la infraestructura y quien audita (legal, seguridad, protección de datos).

Esta rejilla poder-interés (atribuida a Mendelow) no sustituye a la conversación, pero obliga a hacerse la pregunta: ¿a quién no hemos escuchado todavía?

Del objetivo al requisito

Un requisito que no se puede conectar con un objetivo de negocio es un candidato a eliminar. Conviene subir de nivel hasta encontrar el objetivo con preguntas encadenadas, como las cinco preguntas «por qué»:

1. «Necesitamos un botón para exportar a hoja de cálculo.» ¿Por qué?
2. «Para enviar un informe cada semana.» ¿Por qué?
3. «Porque dirección pide ver las ventas por zona.» ¿Por qué?
4. «Para decidir dónde abrir la siguiente tienda.»

El requisito real era un informe de ventas por zona que sirva para decidir aperturas. Quizá la exportación sea la solución, quizá no.

El mapa de impacto (Gojko Adzic) formaliza esta cadena: objetivo, actores que pueden ayudar a conseguirlo o estorbar, cambios de comportamiento deseados y, solo al final, entregables.

Elicitación: obtener información que nadie sabe que tiene

La elicitación no es preguntar «¿qué quieres?». Mucho conocimiento es tácito: quien lo posee no lo verbaliza porque para él es evidente.

Preguntar bien

• Preguntas abiertas para explorar («¿Cómo lo haces hoy?») y cerradas para confirmar («¿Siempre se aprueba antes del viernes?»).
• Pedir ejemplos concretos y casos recientes en lugar de generalidades.
• Preguntar por la excepción: «¿Qué pasa cuando falta ese dato?», «¿Quién lo aprueba si el responsable está de vacaciones?».
• Evitar preguntas que sugieren la respuesta o que proponen la solución.
• Cerrar cada sesión devolviendo un resumen por escrito para que el entrevistado lo corrija.

Jobs to be done

Otra forma de plantear la entrevista es preguntar por el trabajo que la persona intenta resolver y qué contrata hoy para hacerlo: «Cuando [situación], quiero [motivación], para [resultado esperado]». Es útil cuando los usuarios no saben describir la funcionalidad, pero sí cuentan con claridad qué les frustra.

Tipos y niveles de requisito

Clasificación

Requisitos no funcionales con rigor

«Debe ser rápido» no es un requisito. La norma ISO/IEC 25010 ofrece una lista de características de calidad para no olvidar ninguna: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad.

Para hacerlos medibles, la técnica del Software Engineering Institute son los escenarios de atributo de calidad, con seis partes: fuente del estímulo, estímulo, artefacto, entorno, respuesta y medida de la respuesta.

Fuente:     usuario autenticado
Estímulo:   solicita el listado de pedidos del último año
Artefacto:  servicio de consulta de pedidos
Entorno:    funcionamiento normal, hasta 200 usuarios simultáneos
Respuesta:  se muestra la primera página de resultados
Medida:     el 95 % de las peticiones responde en menos de 800 ms

Cada línea elimina una ambigüedad: quién, cuándo, con qué carga y cómo se comprueba.

Cualidades de un buen requisito

La norma ISO/IEC/IEEE 29148 enumera las características que debe tener un requisito individual y el conjunto:

Palabras que delatan un requisito débil

• Subjetivas: rápido, fácil, intuitivo, robusto, moderno, flexible.
• Cuantificadores vagos: algunos, muchos, normalmente, a menudo.
• Escapatorias: «si es posible», «en la medida de lo posible», «etc.».
• Voz pasiva sin sujeto: «se notificará al usuario» (¿quién lo hace y cuándo?).
• Comparativos sin referencia: «más rápido», «mejor» (¿que qué?).

Plantillas de redacción: EARS

EARS (Easy Approach to Requirements Syntax) propone un puñado de frases con estructura fija. Reduce la ambigüedad sin exigir formación formal.

Siempre:         El sistema deberá registrar cada acceso en el registro de auditoría.
Evento:          Cuando el usuario confirme el pedido, el sistema deberá enviarle un correo de confirmación.
Estado:          Mientras la sesión esté inactiva más de quince minutos, el sistema deberá bloquear la pantalla.
No deseado:      Si el pago es rechazado, entonces el sistema deberá conservar el carrito durante 24 horas.
Opcional:        Donde el cliente tenga activada la autenticación en dos pasos, el sistema deberá pedir el segundo factor.

Una norma práctica: «deberá» para lo obligatorio, «debería» para lo recomendable y «podrá» para lo opcional, usados siempre con el mismo sentido en todo el documento.

Historias de usuario

La historia es una promesa de conversación, no un contrato. Su forma habitual es la plantilla de rol, acción y beneficio, pero el valor está en lo que se habla alrededor de ella.

Las tres C de Ron Jeffries

• Card (tarjeta): el texto breve que identifica la historia.
• Conversation (conversación): el diálogo entre negocio y equipo que aclara los detalles.
• Confirmation (confirmación): los criterios de aceptación que dicen cuándo está terminada.

Criterio INVEST

Bill Wake propuso seis propiedades para saber si una historia está en condiciones de entrar a trabajar:

Un ejemplo completo

Historia:  Como cliente registrado, quiero recuperar mi contraseña por correo,
           para volver a entrar sin tener que llamar a soporte.
 
Reglas:
  - El enlace caduca a los 30 minutos.
  - El enlace solo puede usarse una vez.
  - La respuesta es la misma exista o no el correo en el sistema.
 
Fuera de alcance: recuperación por mensaje de texto.

La tercera regla es una decisión de seguridad que sale de la conversación, no de la plantilla: no revelar qué correos están registrados.

Dividir historias grandes

Una historia que no cabe en una iteración se divide por cortes verticales: cada trozo atraviesa todas las capas y entrega algo utilizable.

Patrones de división que funcionan: por paso del flujo, por variante de datos o de rol, por regla de negocio, por operación (crear, consultar, modificar, borrar), por nivel de calidad (primero funciona, luego es rápido) o separando una investigación con tiempo limitado cuando hay mucha incertidumbre.

Mapa de historias

Jeff Patton propone ordenar las historias en un mapa: en horizontal, el recorrido del usuario (las actividades en el orden en que ocurren); en vertical, la prioridad de cada historia. La primera franja horizontal es el esqueleto andante (walking skeleton): lo mínimo que permite recorrer todo el flujo de principio a fin. Ayuda a ver el producto completo, algo que una lista plana de tareas esconde.

Criterios de aceptación y especificación por ejemplos

Un criterio es bueno cuando cualquier persona del equipo puede responder «sí» o «no» sin interpretar. Dos formatos habituales:

• Lista de comprobación: reglas breves, válidas para criterios sencillos.
• Escenarios Given-When-Then (Dado-Cuando-Entonces), del lenguaje Gherkin, ideales cuando hay precondiciones y variantes.

Característica: Recuperar contraseña
 
  Escenario: Enlace válido
    Dado un cliente registrado que ha solicitado recuperar su contraseña
    Cuando abre el enlace antes de 30 minutos y escribe una contraseña nueva válida
    Entonces la contraseña queda cambiada
    Y el enlace deja de ser válido
 
  Escenario: Enlace caducado
    Dado un enlace de recuperación emitido hace más de 30 minutos
    Cuando el cliente lo abre
    Entonces ve un aviso de que ha caducado
    Y se le ofrece solicitar uno nuevo
 
  Esquema del escenario: Contraseña nueva no válida
    Dado un enlace de recuperación vigente
    Cuando el cliente escribe la contraseña "<valor>"
    Entonces ve el mensaje "<mensaje>"

Cada escenario describe comportamiento observable, no clics ni detalles de interfaz. El conjunto sirve a la vez de especificación, de prueba de aceptación y de documentación viva.

Los tres amigos y el mapa de ejemplos

La Specification by Example de Gojko Adzic y el mapa de ejemplos de Matt Wynne proponen una reunión corta, antes de desarrollar, entre negocio, desarrollo y pruebas.

Se usan cuatro colores de tarjeta: la historia, las reglas que la gobiernan, un ejemplo concreto por cada regla y las preguntas sin respuesta. Si salen demasiadas preguntas, la historia no está lista; si salen demasiadas reglas, probablemente es más de una historia.

Definición de listo y definición de hecho

Modelado: ver lo que el texto esconde

El texto es lineal y los sistemas no. Algunos modelos aclaran lo que cien párrafos no consiguen:

Glosario del dominio

Si «cliente», «usuario» y «cuenta» significan lo mismo para todos, nadie ha preguntado. Mantener un glosario compartido y usar siempre el mismo término evita buena parte de los malentendidos. Es, además, la base del lenguaje ubicuo del diseño orientado al dominio.

Priorización

Priorizar es decidir qué no se hace todavía. Sin un criterio explícito, manda la persona con más autoridad o más insistencia.

El modelo de Kano merece atención: las características básicas no se agradecen cuando están, pero indignan cuando faltan; las de rendimiento satisfacen en proporción a cuánto se cumplen; las de deleite sorprenden porque nadie las esperaba. Con el tiempo, lo que deleita pasa a ser básico.

Validación y verificación

Son dos preguntas distintas y ambas necesarias:

• Validación: ¿estamos especificando lo que el negocio necesita? (se hace con los interesados)
• Verificación: ¿el sistema cumple lo que se especificó? (se hace con pruebas)

Técnicas de validación: revisión por pares o inspección, recorrido guiado con los usuarios, prototipo que se enseña antes de construir, escenarios que se leen en voz alta y pruebas de aceptación escritas antes del desarrollo.

Trazabilidad y gestión del cambio

La trazabilidad une cada requisito con su origen (objetivo, interesado) y con lo que lo cumple (diseño, código, pruebas).

Para qué sirve en la práctica: saber qué prueba cubre cada requisito, qué se rompe si uno cambia (análisis de impacto), y detectar requisitos huérfanos (sin objetivo) o sin cubrir (sin prueba).

Un identificador estable y un estado bastan para empezar:

Control de cambios

Los requisitos cambian y eso es sano. Lo dañino es el cambio silencioso: modificaciones que entran sin que nadie evalúe su coste.

Medir la volatilidad (cuántos requisitos cambian por iteración) da una señal temprana: si es alta, quizá el problema aún no se ha entendido bien.

Especificar el alcance también por exclusión

Una buena especificación enumera lo que no se hace. Es la mejor defensa contra la deriva del alcance (scope creep).

Dentro del alcance:
  - Alta, consulta y baja lógica de proveedores.
  - Importación inicial desde un fichero CSV.
 
Fuera del alcance (primera versión):
  - Integración con el sistema contable.
  - Aplicación para móvil.
 
Supuestos:
  - Los proveedores tienen un identificador fiscal único.
Dependencias:
  - El equipo de contabilidad entrega la lista de campos obligatorios antes del día 15.

Los supuestos y las dependencias son requisitos disfrazados: cuando un supuesto resulta falso, hay que volver a analizar.

Compromisos habituales

Lista de comprobación antes de dar por buena una especificación

• Cada requisito se enlaza con un objetivo de negocio.
• No hay palabras vagas sin un criterio medible.
• Los requisitos no funcionales relevantes están cuantificados.
• Hay criterios de aceptación con casos de error y casos límite.
• El alcance dice qué queda fuera.
• Los términos del dominio están definidos y se usan con coherencia.
• Hay un responsable por cada decisión pendiente y una fecha.
• Quien lo pidió ha leído y confirmado la versión final.

Errores y antipatrones

• Saltar a la solución. «Necesitamos una aplicación móvil» no es un requisito, es una respuesta a una pregunta que no se ha hecho.
• Análisis eterno. Intentar cerrar todo antes de empezar. La incertidumbre se reduce construyendo y enseñando, no solo escribiendo.
• Requisitos copiados de la competencia. Lo que otro ha construido no demuestra que sea lo que tu usuario necesita.
• Preguntar a un solo interesado y generalizar.
• Confundir deseos con necesidades. Si se preguntó a cada usuario lo que quería, hay una lista de funciones; si se observó lo que hace, hay un problema.
• Requisitos no funcionales como adorno. Una frase genérica de rendimiento no condiciona nada ni se puede probar.
• Historias técnicas disfrazadas. «Como desarrollador, quiero una tabla de pedidos» no tiene valor visible; mejor describir el resultado que obtiene un usuario.
• Criterios que describen la interfaz en lugar del comportamiento: se rompen al cambiar un botón de sitio.
• Dar por cerrada la especificación sin que nadie con autoridad la haya validado.
• Perder el porqué. Se guardan las decisiones pero no los motivos, y años después nadie sabe si se puede cambiar.