25. Análisis de requerimientos: clasificación, refinamiento y consistencia

25.1 Introducción

Después de elicitar información mediante entrevistas, talleres, observación, documentos o prototipos, el equipo no obtiene automáticamente requerimientos finales. Obtiene datos, ideas, problemas, reglas, restricciones, necesidades, opiniones y posibles soluciones.

El análisis de requerimientos permite ordenar esa información, clasificarla, refinarla y revisar su consistencia. Es la actividad que transforma información dispersa en requerimientos más claros, útiles y verificables.

Sin análisis, el proyecto puede acumular una lista larga de pedidos sin saber cuáles son verdaderos requerimientos, cuáles se contradicen, cuáles son incompletos y cuáles no son factibles.

25.2 ¿Qué es analizar requerimientos?

Analizar requerimientos significa estudiar la información obtenida para comprenderla mejor, detectar problemas y mejorar su calidad antes de especificarla o implementarla.

El análisis de requerimientos responde a la pregunta: ¿esta información es clara, necesaria, consistente, factible y suficiente para orientar la solución?

No se trata solo de ordenar textos. Implica razonar sobre necesidades, reglas, dependencias, conflictos, prioridades, riesgos y condiciones de aceptación.

25.3 Objetivos del análisis

Los principales objetivos del análisis de requerimientos son:

  • Separar necesidades, requerimientos, reglas, restricciones e ideas de solución.
  • Clasificar requerimientos por tipo.
  • Detectar ambigüedades, omisiones y contradicciones.
  • Refinar requerimientos demasiado generales.
  • Evaluar factibilidad técnica, operativa y económica.
  • Identificar dependencias entre requerimientos.
  • Reconocer conflictos entre interesados.
  • Preparar información para priorización, especificación y validación.

25.4 Clasificación de requerimientos

Clasificar requerimientos ayuda a organizarlos y analizarlos con criterios adecuados.

Tipo Descripción Ejemplo
Funcional Describe una función o comportamiento del sistema. El sistema debe permitir registrar pedidos.
No funcional Describe una condición de calidad. La consulta de pedidos debe responder en menos de 2 segundos.
Regla de negocio Define una condición propia del dominio. Un cliente bloqueado no puede comprar a crédito.
Restricción Limita alternativas de solución. El sistema debe integrarse con el sistema contable existente.
Dato requerido Información necesaria para operar. Todo reclamo debe tener motivo, cliente y descripción.

25.5 Separar problema, necesidad y solución

Durante la elicitación, muchos interesados proponen soluciones directamente. En el análisis conviene separar la solución sugerida de la necesidad que la origina.

Ejemplo:

Frase inicial Análisis
Necesitamos un botón para reenviar correos. Puede indicar una necesidad de reenviar confirmaciones cuando el correo original no llegó.
Queremos una app móvil. Puede indicar necesidad de operar fuera de la oficina o desde visitas a clientes.
Hace falta un reporte más completo. Puede indicar necesidad de tomar decisiones con datos que hoy están dispersos.

Esta separación permite evaluar alternativas y evitar comprometerse con una solución prematura.

25.6 Refinamiento de requerimientos

Refinar un requerimiento significa mejorar su precisión, completitud y verificabilidad. Muchos requerimientos comienzan como frases generales y deben trabajarse.

Ejemplo:

  • Inicial: el sistema debe gestionar clientes.
  • Refinado: el sistema debe permitir registrar, consultar, modificar y desactivar clientes.
  • Más refinado: el sistema debe permitir registrar clientes con nombre, documento, correo y teléfono, validando que el documento no exista en otro cliente activo.

El refinamiento agrega información necesaria sin caer en detalles técnicos innecesarios.

25.7 Preguntas para refinar

Para refinar requerimientos, conviene hacer preguntas como:

  • ¿Quién necesita esta función?
  • ¿Qué problema resuelve?
  • ¿Qué datos se necesitan?
  • ¿Qué reglas se aplican?
  • ¿Qué ocurre si los datos son inválidos?
  • ¿Qué permisos se requieren?
  • ¿Qué resultado debe producir?
  • ¿Cómo se verificará que está cumplido?
  • ¿Existen casos alternativos o excepciones?

25.8 Consistencia

La consistencia significa que los requerimientos no se contradicen entre sí ni con reglas, restricciones u objetivos del proyecto.

Ejemplos de inconsistencias:

  • Un requerimiento dice que el cliente puede cancelar pedidos confirmados, pero otro indica que los pedidos confirmados no pueden modificarse.
  • Una regla indica que solo supervisores aprueban descuentos, pero un requerimiento permite que vendedores los aprueben.
  • El alcance excluye pagos en línea, pero aparece un requerimiento para pagar con tarjeta en la primera versión.
  • Un requerimiento exige conservar datos por 5 años y otro eliminarlos después de 1 año.

Detectar estas inconsistencias temprano evita conflictos posteriores.

25.9 Completitud

Un requerimiento es más completo cuando contiene la información necesaria para entenderlo, construirlo y verificarlo. No significa que deba ser largo, sino suficiente.

Aspectos a revisar:

  • Actor o usuario involucrado.
  • Datos de entrada.
  • Reglas aplicables.
  • Resultado esperado.
  • Casos alternativos.
  • Errores o excepciones.
  • Criterios de aceptación.
  • Relación con otros requerimientos.

25.10 Factibilidad

La factibilidad indica si un requerimiento puede realizarse con las tecnologías, recursos, tiempos, presupuesto y restricciones disponibles.

Puede analizarse desde varias dimensiones:

  • Técnica: ¿es posible con la arquitectura, tecnología e integraciones disponibles?
  • Operativa: ¿la organización puede usarlo y sostenerlo?
  • Económica: ¿el costo es razonable frente al valor esperado?
  • Legal: ¿cumple normas y restricciones aplicables?
  • Temporal: ¿puede entregarse en el plazo requerido?

Un requerimiento puede ser deseable, pero no factible en la versión actual.

25.11 Dependencias entre requerimientos

Algunos requerimientos dependen de otros. Identificar dependencias ayuda a planificar y priorizar.

Ejemplos:

  • Para registrar pedidos, primero debe existir registro de clientes y productos.
  • Para enviar notificaciones, debe estar configurado el servicio de correo.
  • Para aprobar descuentos, deben existir roles y permisos.
  • Para generar reportes, deben registrarse datos con suficiente detalle.

Ignorar dependencias puede producir planes de trabajo poco realistas.

25.12 Conflictos entre interesados

El análisis también permite detectar conflictos entre necesidades de distintos interesados.

Ejemplos:

  • Ventas quiere confirmar pedidos rápidamente, pero administración exige controles de crédito estrictos.
  • Usuarios quieren menos pasos, pero auditoría exige más trazabilidad.
  • Un área quiere personalización, pero tecnología busca estandarización.
  • El patrocinador quiere una entrega rápida, pero usuarios piden muchas funciones en la primera versión.

El objetivo no es ocultar estos conflictos, sino hacerlos visibles para negociarlos.

25.13 Requerimientos duplicados

Durante la elicitación pueden aparecer requerimientos duplicados escritos de formas distintas.

Ejemplo:

  • El sistema debe permitir buscar clientes por documento.
  • El usuario debe poder encontrar un cliente usando su número de identificación.
  • La pantalla de clientes debe tener búsqueda por DNI.

El análisis debe consolidar estas expresiones, aclarar términos y evitar duplicación innecesaria.

25.14 Requerimientos candidatos

No toda idea obtenida durante la elicitación debe convertirse inmediatamente en requerimiento aprobado. Puede registrarse como requerimiento candidato.

Un requerimiento candidato es una necesidad o solicitud que debe analizarse, refinarse, validar su valor, revisar factibilidad y priorizar.

Esta categoría evita perder ideas sin comprometerlas antes de tiempo.

25.15 Matriz simple de análisis

Una matriz puede ayudar a ordenar requerimientos durante el análisis.

Requerimiento Tipo Estado Duda o acción
Registrar reclamos con cliente, motivo y descripción. Funcional Refinado Confirmar si canal de ingreso es obligatorio.
La consulta debe ser rápida. No funcional Ambiguo Definir tiempo, operación y volumen de datos.
Integrarse con sistema contable. Restricción / integración Pendiente Solicitar documentación técnica.
Clientes bloqueados no pueden comprar a crédito. Regla de negocio Validar Confirmar excepciones con administración.

25.16 Estados de análisis

Los requerimientos pueden tener estados durante el análisis. Por ejemplo:

  • Candidato: surgió como necesidad o idea, pero todavía no fue analizado.
  • En análisis: se está refinando y revisando.
  • Ambiguo: requiere aclaración.
  • En conflicto: contradice otro requerimiento o decisión.
  • Validado: fue revisado con interesados adecuados.
  • Descartado: se decidió no incluirlo.
  • Postergado: se considera para una versión futura.

Estos estados ayudan a gestionar la información sin mezclar niveles de certeza.

25.17 Relación con priorización

El análisis prepara el camino para priorizar. Antes de decidir qué se hará primero, conviene saber qué significa cada requerimiento, qué valor aporta, qué costo puede tener, qué dependencias posee y qué riesgos implica.

Priorizar requerimientos ambiguos puede llevar a decisiones equivocadas. Por eso, los requerimientos más importantes deberían refinarse antes de priorizarlos definitivamente.

25.18 Errores frecuentes

Al analizar requerimientos, suelen aparecer estos errores:

  • Convertir todo pedido en requerimiento sin análisis.
  • No separar necesidades de soluciones propuestas.
  • No clasificar los requerimientos por tipo.
  • Ignorar contradicciones entre interesados.
  • No revisar factibilidad con el equipo técnico.
  • Dejar requerimientos ambiguos para etapas posteriores.
  • No identificar dependencias.
  • Confundir cantidad de requerimientos con calidad de requerimientos.

25.19 Buenas prácticas

Algunas buenas prácticas son:

  • Clasificar información obtenida durante la elicitación.
  • Separar problema, necesidad, requerimiento, regla, restricción e idea de solución.
  • Refinar requerimientos importantes antes de priorizar.
  • Buscar contradicciones y duplicaciones.
  • Validar reglas y datos con responsables adecuados.
  • Revisar factibilidad técnica, operativa y económica.
  • Registrar dudas, supuestos y pendientes.
  • Mantener trazabilidad con fuentes e interesados.
Analizar requerimientos es convertir información obtenida en conocimiento útil para decidir, construir y verificar.

25.20 Qué debes recordar de este tema

  • El análisis de requerimientos transforma información dispersa en requerimientos más claros.
  • Clasificar ayuda a distinguir funciones, calidad, reglas, restricciones y datos.
  • Refinar significa mejorar precisión, completitud y verificabilidad.
  • La consistencia evita contradicciones entre requerimientos.
  • La factibilidad revisa si un requerimiento puede realizarse en el contexto del proyecto.
  • Las dependencias afectan planificación y prioridad.
  • No todo pedido inicial debe convertirse automáticamente en requerimiento aprobado.

25.21 Conclusión

El análisis de requerimientos es una etapa esencial para ordenar y mejorar la información obtenida durante la elicitación. Permite clasificar, refinar, detectar inconsistencias, evaluar factibilidad y preparar decisiones de prioridad.

Un proyecto con buen análisis evita acumular requerimientos ambiguos o contradictorios que luego generan retrabajo.

En el próximo tema estudiaremos con más detalle la detección de ambigüedades, contradicciones y omisiones, problemas frecuentes que afectan la calidad de los requerimientos.