2. Javier Sánchez Ramírez
Máster Dirección de Sistemas de Información y
Comunicaciones MDSIC ( UPM)
Empresas: Cibernos Consulting, CH2Mhill, Genasys,
evergreenpm
15 años involucrado en desarrollo y gerencia de
Proyectos Software.
info@evergreenpm.com

3. Obtener una visión general de qué es la Gestión de Requisitos, su
posicionamiento dentro del Análisis de Negocio, la Gestión de Proyectos y la
Ingeniería del Software.
Adquirir conciencia de la importancia e influencia en el éxito de los proyectos.
Conocer los principales modelos y las herramientas disponibles para su gestión
desde áreas de negocio a requisitos de solución.

4. Seminario Ingeniería de Requisitos – 12 Febrero de 2013
¿Por qué necesitamos mejorar la gestión de Requisitos?
Los Niveles de la gestión de Requisitos NEGOCIO
Análisis Empresarial STAKEHOLDERS
Gestión de Requisitos de Stakeholders
SOLUCIÓN
Gestión de Requisitos de Sistema
Retos a los que nos enfrentamos en cada nivel
Principales modelos de gestión en cada nivel

5. Estadísticas generales de éxito de los proyectos
1 2 3
100% Proyectos que se completaron en tiempo y
16%
80% presupuesto.
60% 53% Proyectos que costaron más del 189% de
la estimación.
40%
20% Proyectos que se cancelaron antes de
31% completarse.
0%

6. Influencia en el éxito de los proyectos
La inefectividad en el tratamiento de requisitos fue
la causa raíz principal, siendo los tres factores más
comunes en comprometer un proyecto los
siguientes:
1. Falta de feedback de usuario: 12,4%
2. Requisitos y especificaciones incompletas:
13,1%
3. Cambio de requisitos y especificaciones: 8,7%
Requisitos: pobremente organizados,
expresados, débilmente relacionados con los
interesados, cambiando excesivamente
rápido, o innecesarios; con expectativas
poco realistas.

7. Influencia en el éxito de los proyectos
Errores en los requisitos: Principal causa de incremento de costes por repetición de trabajos de
desarrollo. Entre el 70 y 80% de todos los costes de repetir trabajo son por causas de errores en los
requisitos.
Fte: Karl Wiegers ‘Business Value of Requirements Managament’ . Jamasoftware.com

8. Gestión de Requisitos e innovación
Innovar => Cambio
CAMBIO = NECESIDAD – RESISTENCIA
Eficiencia y Eficacia CAMBIO = f(Requisitos)
Calidad = f(Requisitos)

9. Análisis Empresarial
Requisitos de Negocio: Definen la naturaleza de
NEGOCIO la solución, justifican la inversión y constituyen
el punto de partida de un proyecto
Análisis Requisitos
STAKEHOLDERS
Requisitos de Stakeholders: Definen las
necesidades de los stakeholder.
Análisis Requisitos
SOLUCIÓN y TRANSICION
Requisitos de Solución: describen las
características de una solución, que
satisface los requerimientos de negocio y
de stakeholder.

10. Un requisito es:
1. Una condición o capacidad requerida por un stakeholder para
resolver un problema o alcanzar un objetivo.
2. Una condición o capacidad que debe ser cubierta o estar
contenida en una solución o componente de solución para
satisfacer un contrato, estándar, especificación, o cualquier otro
documento formal.
Dominio Soluciones Requisitos
Qué debe o no debe ser considerado en el requisito y cuáles son las
características necesarias del mismo…?

11. DEFINICIÓN
Declaración que identifica un producto o proceso operacional, funcional, o
característica de diseño o restricción, expresada sin ambigüedad, testeable o
medible, y necesaria para la aceptación de un producto o proceso (por el
cliente o directrices de garantía de calidad interna).
Fte: IEEE-STD-1220-1998 (IEEE 1998) -
Standard for Application and Management of
the Systems Engineering Process

12. Dinámicos.
Medibles (Plan aceptación)
Tienen que estar consensuados y priorizados.
Jerárquicos y Relacionados
Proceso de gestión de requisitos

13. Los requisitos definen la nueva CAPACIDAD.
• PRODUCTO CORRECTO: 'time to market' no es
suficiente, el verdadero reto es 'time to market
with the right product'
• EFECTIVO EN COSTE:
• MINIMO TIEMPO DE DESPLIEGUE

14. Los clientes….
NO ¿Saben lo que quieren?
SI
NO ¿Saben describirlo?
SI
NO ¿Están describiendo la solución en vez de la necesidad real?
SI
“Si no puedes describir lo que estás haciendo cómo un proceso, es que no
sabes lo que estás haciendo”
William Edwards Deming

15. Entorno….
Entorno
Negocio
Conflicto de intereses entre stakeholders. La voz del cliente no
es única.
Elicitación
Interesados
Entorno / Cultura
Condicionantes No Funcionales
Nuevo sistema Procesos

16. Los requisitos son la base de cada proyecto, definiendo lo que los
stakeholders necesitan del potencial nuevo sistema (propósito), lo que
debe hacer para satisfacer las necesidades de los interesados.
Propósito Construcción
Inicial Req Del Resultado OK?
(Gap)
NO
Sistema
¿Se entendió el
propósito inicial
SI del sistema?
¿El propósito es
el mismo?
“Experienced developers know that managing requirements is a
greater challenge than technical execution”
Agile Software Requirements (Dean Leffingwell)

17. Tiempo….
Tiempo: Entorno del negocio, tecnológico y de intereses de los
stakeholders cambia con el tiempo durante el plazo de
ejecución del proyecto.
Recomendación:
La aproximación de hacer una definición completa de requisitos, seguida
de un largo período antes de que las nuevas capacidades son liberadas,
no parece muy apropiado…
Fte: “Agile Software Requirements. Lean requirements Practices for Teams, Programs, and the Enterprise” Dean
Leffingwell

18. El triángulo de hierro….
Fijo Requisitos Coste Tiempo
Q?
Estimado Coste Tiempo Requisitos
Waterfall / Tradicional Ágil

19. Selección de proyectos por parte del sponsor
Facilitar la estimación
Permitir priorizar mejor
Facilita desarrollar diseños
Testear con efectividad
Facilita el seguimientos de estatus de proyecto
Acelera el desarrollo

20. El International Institute of Business Analysis es una
asociación profesional, independiente, sin ánimo de lucro y
de carácter mundial, dedicada al análisis de negocio. La
misión del IIBA® es desarrollar y mantener normas para la
práctica de análisis de negocio y administrar el proceso de
certificación de los profesionales del sector. El objetivo es
llegar a ser la primera organización mundial dedicada al
análisis de negocio.

21. Áreas de Conocimiento BABOK
Planeación y monitoreo de Análisis de Negocio Comprende cómo el AN determina qué actividades son necesarias con el fin de
completar un esfuerzo de Análisis de Negocio.
Elicitación Cómo los AN trabajan con los stakeholders para identificar y entender sus necesidades
y preocupaciones y comprenden el medio ambiente en el que trabajan.
Administración y Comunicación de Cómo los AN administran conflictos, problemas y cambios con el fin de asegurar que los
requerimientos stakeholders y el equipo mantienen el acuerdo del alcance de la solución.
Análisis Empresarial Describe cómo el AN identifica una necesidad de negocio, refina y clarifica la definición
de esa necesidad y define un alcance viable.
Análisis de Requerimientos Describe cómo el AN prioriza y progresivamente elabora los requerimientos de los
stakeholders y de la solución para posibilitar la implementación de la solución por parte
del equipo del proyecto.
Evaluación y validación de la Solución Describe cómo el AN evalúa las soluciones propuestas para determinar la mejor
Competencias Fundamentales Comportamientos, conocimientos y habilidades para la ejecución efectiva del Análisis
de Negocio.

22. Análisis de negocio
Define una nueva Determina el
necesidad de Evaluar el GAP Enfoque de la Define el alcance
negocio Solución
“Identifica y documenta los requerimientos de negocio y es a menudo el
punto de partida para el inicio de un nuevo proyecto o proyectos”

23. Define una nueva Determina el
necesidad de Evaluar el GAP Enfoque de la Define el alcance
negocio Solución
• Benchmarking • Análisis de • Benchmarking • Descomposición funcional
documentos
• Brainstorming • Brainstorming • Análisis de Interfaces
• Análisis DAFO
• Análisis de Reg. de Negocio • Análisis de decisiones • Modelado de alcance
• Focus Group • Estimación • Historias de Usuario
• Descomposición Funcional • DAFO • Declaración de problema o Visión
• Análisis Causa-Raiz

24. • Entrevistas con stakeholders ( o
Workshops de requisitos, Focus groups,
reuniones de sgto, talleres)
• Exploración de escenarios
• Estudios de mercado o de cualquier tipo
Fuentes de requisitos • Sistemas existentes
de stakeholders • Problemas y sugerencias de cambio de
sistemas existentes
• Sistemas análogos
• Prototyping, mock-ups, sketching
• Cuestionarios

25. Bases de organización de requisitos Seleccionar el modelo
Crear un conjunto de vistas/modelos para la - Escenarios de Uso
nueva solución de negocio , exhaustiva,
completa, consistente y entendida desde
todas las perspectivas de los stakeholders.
- Modelado de procesos
Son modelos no técnicos, entendibles por
los stakeholder.
- Historias de Usuario

26. Relación entre el ciclo de vida de los requisitos y del
proyecto.

27. Nivel Modelos
Requisitos de Sistema - Diagramas/descripción de arquitecuras o infraestructura tecnológica:
• Hardware
• Software
• Datos
Requisitos de - Diagramas UML
Susbsistema

28. Más información en http://www.evergreenpm.com/
E-mail: info@evergreenpm.com
Muchas Gracias, Javier Sánchez