4 Análisis y Priorización

🎯 Introducción al Análisis y Priorización

El análisis y priorización de requerimientos es un proceso crítico en la ingeniería de software que permite determinar qué requerimientos deben implementarse primero, considerando múltiples factores como valor de negocio, riesgo técnico, dependencias y recursos disponibles.

📊 Clasificación por Importancia o Urgencia

La clasificación de requerimientos es el proceso de categorizar y ordenar los requerimientos según diferentes dimensiones que reflejan su relevancia para el proyecto y el negocio.

🔍 Dimensiones de Clasificación

Importancia (Valor de Negocio)

Mide el impacto que tiene el requerimiento en los objetivos del negocio.

Criterios de evaluación:
- Contribución a objetivos estratégicos
- Impacto en ingresos o reducción de costos
- Ventaja competitiva proporcionada
- Número de usuarios beneficiados
- Cumplimiento regulatorio o legal
Urgencia (Tiempo)

Mide la presión temporal para implementar el requerimiento.

Criterios de evaluación:
- Fechas límite contractuales
- Dependencias con otros proyectos
- Ventanas de oportunidad de mercado
- Compromisos con clientes
- Eventos externos (regulaciones, competencia)
Riesgo Técnico

Mide la complejidad e incertidumbre de implementación.

Criterios de evaluación:
- Complejidad técnica
- Tecnologías no probadas
- Dependencias externas
- Disponibilidad de expertise
- Impacto en arquitectura
Costo de Implementación

Mide los recursos necesarios para desarrollar el requerimiento.

Criterios de evaluación:
- Esfuerzo de desarrollo (persona-horas)
- Infraestructura requerida
- Licencias de software
- Capacitación necesaria
- Costos de mantenimiento

📈 Matriz de Eisenhower Adaptada

La matriz de Eisenhower, originalmente para gestión del tiempo, se adapta efectivamente para priorización de requerimientos.

🎯 Métodos de Priorización

Método MoSCoW

Técnica de priorización que clasifica requerimientos en cuatro categorías.

Categorías:

Categoría	Significado	Descripción	% Típico
Must have	Debe tener	Requerimientos críticos sin los cuales el sistema no funciona	60%
Should have	Debería tener	Importantes pero no críticos, pueden posponerse si es necesario	20%
Could have	Podría tener	Deseables pero no necesarios, se implementan si hay tiempo/recursos	15%
Won’t have (this time)	No tendrá (esta vez)	Fuera del alcance actual, considerados para futuras versiones	5%

Ventajas:

Simple y fácil de entender
Comunicación clara con stakeholders
Enfoque en lo esencial

Desventajas:

Tendencia a clasificar todo como “Must have”
No considera esfuerzo de implementación
Puede ser demasiado simplista para proyectos complejos

Análisis Valor vs Costo

Prioriza basándose en la relación entre el valor de negocio y el esfuerzo de implementación.

Fórmula:

Puntuación = (Valor × Peso_Valor) / (Costo × Peso_Costo)

WSJF (Weighted Shortest Job First)

Método usado en SAFe (Scaled Agile Framework) que considera múltiples factores.

Fórmula:

WSJF = Costo de Retraso / Duración del Trabajo

Costo de Retraso = Valor de Negocio + Criticidad Temporal + Reducción de Riesgo

Componentes:

Factor	Descripción	Escala
Valor de Negocio	Beneficio económico directo	1-20
Criticidad Temporal	Urgencia, ventana de oportunidad	1-20
Reducción de Riesgo	Mitigación de riesgos técnicos/negocio	1-20
Duración del Trabajo	Esfuerzo estimado (story points, horas)	1-20

Interpretación:

WSJF > 5: Alta prioridad
WSJF 2-5: Prioridad media
WSJF < 2: Baja prioridad

📊 Comparación de Métodos

Método	Complejidad	Mejor para	Ventajas	Desventajas
MoSCoW	Baja	Proyectos pequeños, comunicación con stakeholders	Simple, fácil de entender	Subjetivo, no considera esfuerzo
Kano	Media	Productos orientados al usuario	Enfoque en satisfacción del cliente	Requiere investigación de usuarios
Valor vs Costo	Media	Optimización de ROI (Return on Investment)	Balance entre beneficio y esfuerzo	Requiere estimaciones precisas
WSJF	Alta	Entornos ágiles a escala	Considera múltiples factores	Complejo, requiere métricas

⚖️ Resolución de Conflictos

Los conflictos en requerimientos son inevitables cuando múltiples stakeholders tienen intereses, perspectivas y prioridades diferentes. La resolución efectiva de conflictos es crucial para el éxito del proyecto.

🔍 Tipos de Conflictos

🛠️ Técnicas de Resolución

Negociación

Proceso de diálogo para llegar a un acuerdo mutuamente aceptable.

Estrategias:
- Win-Win: Buscar soluciones que beneficien a ambas partes
- Trade-offs: Intercambiar concesiones
- Priorización conjunta: Usar métodos objetivos (MoSCoW, WSJF)
Análisis de Impacto

Evaluación objetiva de las consecuencias de cada opción mediante matriz de decisión con criterios ponderados.
Mediación por Terceros

Involucrar a una persona neutral para facilitar la resolución.

Roles de mediador:
- Product Owner (en metodologías ágiles)
- Arquitecto de Software
- Gerente de Proyecto
- Comité de Change Control
Prototipado

Crear prototipos para validar opciones en conflicto con evidencia tangible y testing con usuarios reales.
Escalamiento

Elevar el conflicto a niveles superiores de autoridad cuando otras técnicas fallan.

📋 Proceso de Resolución

✅ Validación con el Cliente

La validación con el cliente es el proceso de confirmar que los requerimientos capturados, analizados y priorizados reflejan correctamente las necesidades del negocio y son técnicamente viables.

🎯 Objetivos de la Validación

🔍 Técnicas de Validación

Revisiones Formales

Sesiones estructuradas donde stakeholders revisan y aprueban requerimientos.

Tipos:
- Walkthroughs: Presentación informal de requerimientos
- Inspecciones: Revisión formal con checklist
- Revisiones técnicas: Evaluación de viabilidad técnica
Prototipado

Validar requerimientos mediante representaciones visuales o funcionales del sistema.

Beneficios:
- Validación temprana de usabilidad
- Identificación de requerimientos faltantes
- Reducción de ambigüedad
Casos de Prueba

Crear casos de prueba a partir de requerimientos para verificar su testabilidad.

Criterio: Si no se puede crear un caso de prueba, el requerimiento es ambiguo.
Simulaciones y Modelado

Usar modelos para validar comportamiento del sistema antes de implementar.

Técnicas:
- Diagramas de flujo
- Modelos de datos
- Diagramas de secuencia
Validación con Usuarios Finales

Involucrar a usuarios reales para confirmar que los requerimientos satisfacen sus necesidades.

Métodos:
- Focus groups
- Entrevistas de validación
- Sesiones de demostración

📊 Proceso de Validación

✅ Criterios de Aceptación

Los criterios de aceptación son condiciones específicas y medibles que deben cumplirse para que un requerimiento se considere satisfactoriamente implementado.

Características de buenos criterios:

Característica	Descripción	Ejemplo
Específico	Detallado y sin ambigüedad	”El sistema debe procesar pagos en < 3 segundos”
Medible	Cuantificable y verificable	”Disponibilidad de 99.9%“
Alcanzable	Técnicamente factible	”Soportar 10,000 usuarios concurrentes”
Relevante	Alineado con objetivos	”Reducir tiempo de checkout en 50%“
Temporal	Con marco de tiempo	”Implementar en Sprint 3”

📋 Plantilla de Validación

SESIÓN DE VALIDACIÓN DE REQUERIMIENTOS

Proyecto: [Nombre del Proyecto]
Fecha: [DD/MM/AAAA]
Versión del Documento: [v1.0]

PARTICIPANTES:
- Cliente: [Nombre, Rol]
- Product Owner: [Nombre]
- Analista: [Nombre]
- Arquitecto: [Nombre]

REQUERIMIENTOS REVISADOS:
Total: [X requerimientos]
- Funcionales: [Y]
- No Funcionales: [Z]

RESULTADOS DE LA VALIDACIÓN:

✅ Aprobados sin cambios: [Lista de IDs]
- RF-001: Login de usuario
- RF-005: Carrito de compras
- RNF-010: Seguridad TLS 1.3

⚠️ Aprobados con modificaciones: [Lista de IDs]
- RF-015: Procesamiento de pagos
Cambio: Agregar soporte para PayPal además de tarjetas

- RNF-020: Tiempo de respuesta
Cambio: Ajustar de < 1s a < 2s (más realista)

❌ Rechazados: [Lista de IDs]
- RF-030: Integración con blockchain
Razón: Fuera de alcance, posponer para v2.0

🆕 Nuevos requerimientos identificados:
- RF-035: Recuperación de carrito abandonado
Prioridad: Should have

- RNF-040: Compatibilidad con navegadores
Detalle: Chrome, Firefox, Safari últimas 3 versiones

ACCIONES A TOMAR:
1. Actualizar documento de requerimientos con cambios aprobados
2. Crear RF-035 y RNF-040 en backlog
3. Revisar estimaciones afectadas por cambios
4. Programar próxima sesión de validación: [Fecha]

APROBACIÓN:
Cliente: _________________ Fecha: _______
Product Owner: ___________ Fecha: _______

PRÓXIMOS PASOS:
- Establecer baseline de requerimientos v1.0
- Iniciar proceso de change control
- Comunicar cambios al equipo de desarrollo

🎓 Resumen

🎯 Análisis y Priorización: Proceso sistemático para determinar qué requerimientos implementar primero, optimizando valor de negocio y recursos limitados.
📊 Clasificación: Evaluar requerimientos según múltiples dimensiones: importancia, urgencia, riesgo técnico y costo de implementación.
🎯 Métodos de Priorización: MoSCoW (simple), Kano (satisfacción del cliente), Valor vs Costo (ROI), WSJF (múltiples factores). Elegir según contexto del proyecto.
⚖️ Resolución de Conflictos: Técnicas incluyen negociación, análisis de impacto, mediación, prototipado y escalamiento. Enfocarse en intereses, no posiciones.
✅ Validación con Cliente: Confirmar que requerimientos son correctos, completos, viables y consensuados. Técnicas: revisiones formales, prototipos, casos de prueba, validación con usuarios.
📋 Criterios de Aceptación: Condiciones específicas, medibles, alcanzables, relevantes y temporales que definen cuándo un requerimiento está satisfactoriamente implementado.
🔄 Iteración Continua: Análisis, priorización y validación son procesos iterativos que se repiten a lo largo del ciclo de vida del proyecto.

🐝