Uno de los objetivos principales del análisis de requerimientos es mejorar su calidad. Para lograrlo, es necesario detectar ambigüedades, contradicciones y omisiones.
Estos problemas pueden parecer pequeños al leer una especificación, pero suelen generar interpretaciones diferentes, retrabajo, defectos, conflictos con usuarios y demoras en la aceptación del producto.
Detectarlos temprano es mucho más barato que descubrirlos cuando el sistema ya fue diseñado, desarrollado o entregado.
Una ambigüedad aparece cuando un requerimiento puede interpretarse de más de una forma razonable.
Ejemplo ambiguo:
La palabra "recientes" puede significar pedidos del día, de la semana, del mes o de los últimos 30 días. El requerimiento necesita precisión.
| Requerimiento ambiguo | Problema | Versión más clara |
|---|---|---|
| El sistema debe ser rápido. | No indica operación ni tiempo esperado. | La búsqueda de clientes debe responder en menos de 2 segundos con hasta 100.000 clientes. |
| El usuario podrá modificar datos importantes. | No define usuario ni datos importantes. | El supervisor podrá modificar el límite de crédito de un cliente activo. |
| El sistema debe mostrar reportes completos. | No indica contenido, filtros ni formato. | El reporte mensual debe incluir ventas por vendedor, zona, producto e importe total. |
| El sistema debe notificar al responsable. | No define quién es responsable ni por qué canal. | El sistema debe enviar un correo al supervisor asignado cuando un reclamo de prioridad alta quede sin atender por más de 2 horas. |
Algunas palabras son señales de posible ambigüedad si no se acompañan con criterios concretos.
Estas palabras no están prohibidas, pero deben aclararse con medidas, condiciones, ejemplos o criterios verificables.
Una contradicción ocurre cuando dos o más requerimientos, reglas o restricciones no pueden cumplirse al mismo tiempo.
Ejemplo:
Ambas afirmaciones no pueden ser verdaderas sin una regla adicional que las diferencie, como plazo, estado, tipo de pedido o autorización especial.
Las contradicciones pueden aparecer de varias formas.
| Tipo | Ejemplo |
|---|---|
| Entre requerimientos funcionales | Un requerimiento permite editar facturas emitidas y otro lo prohíbe. |
| Entre reglas de negocio | Una regla permite descuentos hasta 30% y otra exige aprobación desde 20%. |
| Entre alcance y requerimiento | El alcance excluye pagos en línea, pero un requerimiento los incluye. |
| Entre seguridad y usabilidad | Se exige autenticación en cada operación, pero también completar la tarea sin interrupciones. |
| Entre normativa y operación | Los usuarios quieren eliminar datos, pero la normativa exige conservarlos. |
Una omisión ocurre cuando falta información necesaria para comprender, construir, probar o aceptar un requerimiento.
Ejemplo incompleto:
Faltan datos obligatorios, estados, reglas de prioridad, permisos, validaciones, notificaciones, criterios de aceptación y excepciones. La función está nombrada, pero no suficientemente especificada.
| Requerimiento incompleto | Información omitida |
|---|---|
| El sistema debe permitir registrar usuarios. | Datos obligatorios, roles, validación de correo, estado inicial, permisos. |
| El sistema debe calcular descuentos. | Fórmula, límites, productos incluidos, autorización, redondeo. |
| El sistema debe enviar notificaciones. | Evento disparador, destinatario, canal, contenido, errores de envío. |
| El sistema debe generar reportes. | Datos, filtros, formato, periodicidad, permisos, totales. |
Estos problemas pueden originarse por varias razones:
Reconocer las causas ayuda a elegir mejores técnicas de revisión.
Algunas técnicas útiles son:
Si un requerimiento no puede probarse ni explicarse con ejemplos, probablemente necesita refinamiento.
Para detectar contradicciones conviene comparar requerimientos entre sí y con otros artefactos.
Las contradicciones muchas veces aparecen cuando se juntan visiones que fueron relevadas por separado.
Para detectar omisiones, conviene revisar cada requerimiento desde varias perspectivas.
Las omisiones suelen detectarse recorriendo escenarios y flujos alternativos.
Una revisión por pares consiste en que otra persona revise los requerimientos para detectar problemas que el autor no vio.
Puede participar:
Cada perfil detecta problemas distintos. Por eso, las revisiones multidisciplinarias suelen ser más efectivas.
Una lista de verificación ayuda a revisar requerimientos de forma ordenada.
Ejemplo de preguntas:
Las listas reducen olvidos en revisiones repetitivas.
Requerimiento inicial:
Problemas detectados:
Versión refinada:
Cuando se detecta un problema en un requerimiento, conviene registrarlo de forma clara.
| Requerimiento | Problema | Tipo | Acción |
|---|---|---|---|
| El sistema debe ser fácil de usar. | No define tarea ni criterio de facilidad. | Ambigüedad | Definir tarea, usuario y medida observable. |
| Pedidos confirmados pueden cancelarse. | Contradice regla que impide modificar pedidos confirmados. | Contradicción | Revisar con negocio condiciones de cancelación. |
| Registrar pagos. | Faltan datos, estados, permisos y errores posibles. | Omisión | Refinar con administración y equipo técnico. |
Los criterios de aceptación ayudan a detectar ambigüedades y omisiones. Si no se pueden escribir criterios claros para un requerimiento, probablemente el requerimiento no está suficientemente entendido.
Ejemplo:
Al revisar requerimientos, suelen cometerse estos errores:
Algunas buenas prácticas son:
Detectar ambigüedades, contradicciones y omisiones es una actividad central para mejorar la calidad de los requerimientos. Estos problemas afectan la comprensión compartida y pueden causar errores costosos si se descubren tarde.
La revisión cuidadosa, los ejemplos concretos, los criterios de aceptación y la participación de distintos perfiles ayudan a convertir requerimientos débiles en requerimientos más claros y verificables.
En el próximo tema estudiaremos la priorización de requerimientos, necesaria para decidir qué se construirá primero cuando existen muchas necesidades y recursos limitados.