30. Características de un buen requerimiento
Un requerimiento no es bueno solamente porque describe una idea del usuario. Es bueno cuando puede ser entendido, analizado, acordado, implementado, probado y mantenido sin generar interpretaciones contradictorias.
La calidad de los requerimientos influye directamente en el éxito del proyecto. Un requerimiento mal escrito puede provocar retrabajo, discusiones, defectos, estimaciones incorrectas y entregas que no resuelven la necesidad real.
30.1 Introducción
En los temas anteriores se estudiaron distintas formas de obtener, organizar, validar y gestionar requerimientos. En este tema nos concentramos en las características que debe cumplir cada requerimiento individual para ser útil dentro del desarrollo de software.
Estas características funcionan como criterios de revisión. Permiten detectar si un requerimiento está listo para pasar a diseño, desarrollo, pruebas o planificación, o si todavía necesita aclaraciones.
30.2 Por qué importa la calidad de un requerimiento
Un requerimiento de baja calidad puede parecer aceptable al inicio, pero suele causar problemas más adelante. Si es ambiguo, cada persona puede interpretarlo de una manera diferente. Si no es verificable, no se podrá comprobar si fue cumplido. Si no es factible, el equipo puede comprometerse con algo que no puede entregar.
Por eso, antes de considerar un requerimiento como aprobado, conviene revisarlo con una lista clara de atributos de calidad.
30.3 Claridad
Un requerimiento claro expresa una necesidad de manera directa y comprensible. Debe evitar frases confusas, palabras vagas y explicaciones innecesariamente extensas.
Por ejemplo, la frase "el sistema debe ser fácil de usar" no es clara porque no indica qué significa "fácil". En cambio, una redacción más clara podría indicar que "un usuario registrado debe poder completar la carga de un pedido en menos de cinco pasos".
30.4 Ausencia de ambigüedad
Un requerimiento no ambiguo permite una sola interpretación razonable. Si dos personas leen el mismo requerimiento y llegan a conclusiones diferentes, el requerimiento necesita ser corregido.
La ambigüedad suele aparecer con expresiones como "rápido", "adecuado", "normal", "cuando sea necesario", "mejorar la experiencia" o "de forma eficiente", si no se definen criterios concretos.
30.5 Completitud
Un requerimiento completo incluye la información necesaria para entender qué se espera del sistema. No debe dejar vacíos relevantes sobre actores, condiciones, datos, reglas, excepciones o resultados esperados.
Un requerimiento incompleto obliga al equipo a suponer. Las suposiciones no validadas son una fuente frecuente de defectos y cambios tardíos.
30.6 Consistencia
Un requerimiento consistente no contradice otros requerimientos, reglas de negocio, restricciones técnicas o decisiones ya aprobadas. La consistencia debe revisarse tanto dentro del mismo requerimiento como en relación con el conjunto completo de requerimientos.
Por ejemplo, no sería consistente que un requerimiento indique que el usuario puede cancelar un pedido en cualquier momento y otro indique que no puede cancelarlo después de confirmado, sin explicar la regla exacta.
30.7 Verificabilidad
Un requerimiento verificable permite comprobar objetivamente si fue cumplido. Debe ser posible diseñar una prueba, inspección, demostración o medición que confirme su cumplimiento.
Si no se puede probar, el requerimiento queda abierto a discusiones subjetivas. Por eso, los requerimientos deben incluir resultados observables, condiciones medibles o criterios de aceptación.
30.8 Factibilidad
Un requerimiento factible puede implementarse con la tecnología, el presupuesto, el tiempo, el conocimiento y las restricciones del proyecto. No basta con que sea deseable; también debe ser posible.
La factibilidad no significa elegir siempre lo más simple, sino evaluar si la solución propuesta puede entregarse de manera realista y sostenible.
30.9 Necesidad
Un buen requerimiento debe responder a una necesidad real del negocio, del usuario, de una regulación o de una restricción técnica justificada. Si no aporta valor ni resuelve un problema, debe cuestionarse.
Esta característica ayuda a evitar funcionalidades innecesarias que aumentan el costo, complican el producto y consumen tiempo del equipo.
30.10 Trazabilidad
Un requerimiento trazable puede relacionarse con su origen, con los objetivos que satisface, con los elementos de diseño que lo implementan, con las pruebas que lo verifican y con los cambios que lo afectan.
La trazabilidad permite responder preguntas como: quién pidió este requerimiento, por qué existe, dónde fue implementado, cómo se prueba y qué impacto tendría modificarlo.
30.11 Priorización
Un requerimiento debe tener una prioridad definida. No todos los requerimientos tienen el mismo valor, urgencia, riesgo o costo. La prioridad ayuda a decidir qué construir primero y qué puede postergarse.
La priorización debe ser acordada con los interesados, especialmente cuando existen restricciones de tiempo o presupuesto.
30.12 Atomicidad
Un requerimiento atómico expresa una sola necesidad principal. Cuando un requerimiento combina varias necesidades, se vuelve más difícil de estimar, implementar, probar y mantener.
Por ejemplo, "el sistema debe registrar clientes, generar facturas y enviar notificaciones" debería dividirse en requerimientos separados, porque cada acción tiene reglas, datos y pruebas diferentes.
30.13 Comprensión para su audiencia
Un requerimiento debe estar escrito en un lenguaje adecuado para quienes lo usarán. Los interesados de negocio necesitan comprender la necesidad y el valor; el equipo técnico necesita comprender el comportamiento esperado y las restricciones.
Esto no significa eliminar todo detalle técnico, sino ubicarlo donde corresponda y evitar que el lenguaje impida la validación por parte de los usuarios y responsables del negocio.
30.14 Modificabilidad
Un requerimiento modificable puede actualizarse sin generar confusión. Para lograrlo, debe estar bien identificado, organizado, versionado y separado de otros requerimientos.
La modificabilidad es importante porque los requerimientos cambian. Un documento difícil de modificar se vuelve rápidamente obsoleto o contradictorio.
30.15 Corrección
Un requerimiento correcto representa una necesidad verdadera y aceptada por los interesados correspondientes. Puede estar bien escrito y, aun así, ser incorrecto si describe algo que el negocio no necesita o que contradice una regla real.
La corrección se valida con usuarios, responsables del proceso, expertos del dominio y otros interesados con autoridad sobre el contenido.
30.16 Ejemplo de requerimiento débil y mejorado
Requerimiento débil: "el sistema debe permitir buscar clientes rápidamente".
Problemas: no define quién busca, por qué criterios se busca, qué significa rápidamente, qué datos se muestran ni cómo se verifica el resultado.
Versión mejorada: "el usuario del área de ventas debe poder buscar clientes por nombre, documento o correo electrónico. El sistema debe mostrar los resultados coincidentes en menos de dos segundos para una base de hasta cien mil clientes".
30.17 Lista de verificación
Antes de aprobar un requerimiento, se puede revisar con preguntas simples:
- ¿Se entiende sin explicaciones adicionales?
- ¿Tiene una sola interpretación razonable?
- ¿Incluye la información necesaria?
- ¿No contradice otros requerimientos?
- ¿Puede probarse o medirse?
- ¿Es posible implementarlo en el contexto del proyecto?
- ¿Responde a una necesidad real?
- ¿Puede rastrearse hasta su origen y sus pruebas?
30.18 Calidad en requerimientos funcionales
En los requerimientos funcionales, la calidad se observa especialmente en la descripción del comportamiento. Deben quedar claros los actores, entradas, validaciones, reglas, pasos principales, excepciones y salidas esperadas.
Un requerimiento funcional de buena calidad permite imaginar qué hará el usuario y cómo responderá el sistema en condiciones normales y alternativas.
30.19 Calidad en requerimientos no funcionales
En los requerimientos no funcionales, la calidad depende mucho de la posibilidad de medirlos. Expresiones como "seguro", "rápido", "usable" o "estable" deben convertirse en condiciones verificables.
Por ejemplo, en lugar de decir "el sistema debe estar siempre disponible", conviene indicar un porcentaje de disponibilidad, un período de medición y las condiciones bajo las cuales se evalúa.
30.20 Errores frecuentes
Algunos errores habituales al escribir requerimientos son mezclar varios requerimientos en uno, usar palabras subjetivas, omitir excepciones, describir soluciones técnicas sin justificar la necesidad, no definir prioridades y no acordar criterios de aceptación.
También es frecuente copiar frases generales de otros proyectos sin adaptarlas al contexto real. Un requerimiento debe tener sentido dentro del dominio, los objetivos y las restricciones del producto que se está construyendo.
30.21 Buenas prácticas
Para mejorar la calidad de los requerimientos conviene escribirlos en forma simple, revisar cada uno con una lista de criterios, pedir validación a los interesados, agregar ejemplos cuando ayuden y relacionarlos con criterios de aceptación.
También es útil mantener una identificación única para cada requerimiento, registrar su estado, conservar su historial de cambios y evitar aprobar requerimientos que todavía dependen de suposiciones importantes.
30.22 Qué debes recordar
Un buen requerimiento debe ser claro, no ambiguo, completo, consistente, verificable, factible, necesario, trazable, priorizado, atómico, comprensible y modificable.
Estas características no son teoría aislada. Son herramientas prácticas para reducir errores, mejorar la comunicación y aumentar la probabilidad de construir el producto correcto.
30.23 Conclusión
La calidad de los requerimientos se construye mediante escritura cuidadosa, revisión, validación y acuerdos explícitos. Un requerimiento bien formulado ayuda al negocio a expresar lo que necesita y al equipo técnico a construirlo con menor incertidumbre.
En el siguiente tema estudiaremos cómo redactar requerimientos de manera clara, precisa y verificable, aplicando en la práctica los criterios vistos en este capítulo.