Hablemos sobre requisitos - Jordi Borja - Visures Solutions

1. HABLEMOS SOBRE REQUISITOS
Jordi Borja – jborja@visuresolutions.com
Director de Desarrollo de Negocio y Estrategia de Solución

2. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
2

3. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
3

4. Visure Solutions, The Requirements Company
• Compañía española especializada en Ingeniería de Requisitos
• Experiencia de más de 10 años en proyectos de Gestión y Definición de
Requisitos
• Fabricante y distribuidor de la herramienta IRQA, solución líder en Europa
con más de 200 clientes en 20 países.
• Oficinas en España, Suecia, Alemania y USA.
4

5. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
5

6. La inversión en Requisitos no puede esperar
• Síntomas
• Usuarios no satisfechos
• Alto nivel de retrabajo
• Planificaciones no predecibles y sobrecostes
• Incumplimiento de normativas y Requisitos no funcionales
• Falta de visibilidad y control.
• Dificultad para administrar el cambio
• El papel clave del CIO
• Identificar problemáticas de negocio asociadas a los requisitos.
• Diagnosticar si el proceso de Requisitos es maduro o no.
• Asumir el reto de mejorar la Gestión y Definición de Requisitos
• “Vender” internamente la importancia de los Requisitos
‒ A Tecnología y a Negocio.
– Asignar los recursos necesarios para la mejora
– Asignar el presupuesto para la mejora.
6

7. Muchas empresas ya han decidido mejorar sus Requisitos con
Visure
7

8. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
8

9. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
9

10. 1.- Sí: los proyectos fallan por culpa de los Requisitos
Tiempo
} Sorpresa!
1010

11. 1.- Sí: los proyectos fallan por culpa de los Requisitos
Causas de los defectos Esfuerzo dedicado a corregir los defectos
Requirements
Errors Design Errors
(82%) (13%)
Other Errors (4%) Coding Errors (1%)
Coste relativo de solucionar un defecto La importancia de los Requisitos
200 Project Analyzed
180
0- 5% invested in Req.
160 Management results in 80-200%
% Overcost
140 overcost
8-14% invested in Req.
120
Management results in 0-60%
100 overcost
80
60
40
20
0
0 5 10 15 20 25
% Requirements Management Cost compared to total project cost
Fuentes: James Martin, Barry Boehm
11

12. 1.- Sí: los proyectos fallan por culpa de los Requisitos
Requisitos incompletos 13, 1%
Usuarios no involucrados 12.4%
Falta de recursos 10,6%
Expectativas no realistas 9,9%
Falta de soporte ejecutivo 9,6%
Cambios en la especificación 8,7%
Fallos de planificación 8,1%
No hay necesidad futura 7,5%
Fuentes: IT Toolbox y Standish Group
12

13. 1.- Sí: los proyectos fallan por culpa de los Requisitos
Fuente: Keil, Cule, Lyytinen, Schmidt .
13

14. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
14

15. 2.- Los Requisitos defectuosos impactan en el negocio
15

16. 2.- Los Requisitos defectuosos impactan en el negocio
16

17. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
17

18. 3.- Invertir en Requisitos proporciona grandes beneficios
Nivel 1 Nivel 4
Coste estimado por proyecto $ 250.000,00 $ 250.000,00
Sobrecoste medio (preproducción) $ 72.000,00 $ 4.200,00
Coste medio post-producción $ 34.400,00 $ 2.800,00
Coste Total Proyecto $ 356.400,00 $ 257.000,00
Sobre coste total por proyecto $ 106.400,00 $ 7.000,00
• 32,4% en aumento de productividad de los Analistas
• >30% reducción tiempo requerido por Stakeholders
18

19. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
19

20. 4.- El retorno de la inversión es inmediato
Investments - Year One
Software / Hardware
Licenses (IRQA + IRQA Web) $ 25.500
Maintenance - Year One $0
Hardware $0
Services
Training $ 4.000
Consulting $ 8.000
People
Labor Related Investment $ 10.400
Grand Total: Year One Investments $ 47.900
Labor Savings
Low High
Total Project Staff Headcount 20 20
Total Labor Hours Saved - Year One 1.958 2.813
Less - Startup Labor Hours Invested 260 260
Net Labor Hours Recovered - Year One 1.698 2.553
Cost Per Engineering Hour: $40
Total Annual Labor Dollars
$ 67.900 $ 102.100
Recovered In Year One
Return on Investment
Low High
Investment Payback Period (Months) 7,3 5,1
NPV (over 2 years, discounted at 7%) $ 41.834 $ 220.712
First Year ROI 63% 135%
20

21. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
21

22. 5.- No es suficiente con tener una metodología de desarrollo.
• Adoptar metodologías de desarrollo ágiles o basadas en
prototipado y simulación no es garantía de éxito.
22

23. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
23

24. 6.- No es suficiente con tener buenos Analistas
• Un buen analista requiere además:
• Un proceso maduro e institucionalizado en la organización
• Un conjunto de técnicas bien definidas.
• Una capacitación especializada
• Una herramienta que de soporte al proceso y a las técnicas
3 Analistas en
organizaciones de Nivel 2
2 Analistas en
organizaciones de Nivel 3
24

25. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
25

26. 7.- ¿Somos maduros en Requisitos?
Contexto
Process
Actual y legislativo
Asset
Library
Modelos
Madurez Adecuación de procesos
(3.1)
Diagnóstico Plan de Implantación
Mejora
Inicial Mejora Desarrollo de la solución de la
Continua
Fase 1 Fase 2 Fase 3 Solución
Fase 5
Fase 4
Requirements
Capability Adecuación Solución
Tecnológica
Model
(3.2)
Evaluaciones Technical Visure
Asset University
Library
26

27. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
27

28. 8.- ¿Qué técnicas debemos de utilizar?
• La clave del éxito en la Ingeniería de Requisitos es usar técnicas:
– Maduras
– Probadas Creativas
– Que se ajusten a la realidad de la organización Brainstorming
Walt Disney
– En base a la tipología de proyectos. Other people’s view (OPV)
Observación
• Elegir las técnicas adecuadas no es sencillo Field Observation
Aprendizaje
– Captura de Requisitos Entrevistas
Entrevistas
– Priorización / Release Management / Planificación Cuestionarios
Osborn checklist
– Escritura de Requisitos Orientadas a Históricos
Arqueología
– Modelado de Requisitos Reutilización
Otras
– Derivación de pruebas Prototipos, simulaciones, story
boards.
– Administración del cambio Ordenamiento de Cartas
– Análisis de impacto Priorización
– Gestión de configuraciones y líneas base MoSCoW
Kano
– Taxonomías de requisitos. Matrices de Wieger
Planning Game
– Identificación de stakeholders Release Management
Velocidad del equipo
– … Story Points
Maximización / Minimizaciión
Planificación y Estimación
Simulaciones de Montecarlo
COCOMO
Puntos función
28

29. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
29

30. 9.- Capacitación de las personas: el mejor activo de la organización
• Las personas involucradas en la Ingeniería de Requisitos
necesitan una formación especializada
30

31. Agenda
• 10 aspectos a considerar cuando hablamos de Requisitos
1. Sí: los proyectos fallan por culpa de los Requisitos
2. Los Requisitos defectuosos impactan en el negocio
3. Invertir en Requisitos proporciona grandes beneficios
4. El retorno de la inversión es inmediato
5. No es suficiente con tener una metodología de desarrollo
6. No es suficiente con tener buenos analistas.
7. ¿Somos maduros en Requisitos?
8. ¿Qué técnicas debemos utilizar?
9. Capacitación de las personas: el mejor activo.
10. ¿Estamos usando las herramientas adecuadas?
31

32. 10 .- Seleccionar la herramienta adecuada no es sencillo
IRQA IRQA IRQA
IRQA Sólo Report Quality IRQA Prototyper
Actividad SubActividad IRQA lectura Manager Analyzer Prototyper Server
Técnicas de Captura y Análisis de Requisitos X X X
Modelado de requisitos X
Especificación y documentación de requisitos X
Manejo de líneas base de requisitos X
Manejo de la trazabilidad de los requisitos X
Control de versiones de los requisitos individuales y grupales X
Ingeniería de requisitos en Taxonomía de requisitos X
proyectos y mantenimiento Manejo de atributos de los requisitos X
(captura, modelado, Consulta y búsqueda de requisitos X
documentación y validación de Firma digital X
requisitos) Reutilización de requisitos, escenarios de prueba y casos de uso X
Trabajo distribuido y fuiera de linea X
Integración con herramientas de ofimática X
Actividades de revisión de la calidad del requerimiento X
Gestión de solicitudes de cambio para mantenimiento X
Gestión de reglas de negocio X
Integración con otras actividades y herramienta para el
desarrollo de los requisitos X
Lectura de requisitos Lectura y seguimiento de los requisitos X
Creación de prototipos y Creación de Prototipos X
simulaciones Creación de Simulaciones X
Consulta de prototipos y
simulaciones
Consulta de prototipos y simulaciones X
Administración de requisitos Gestión de flujos de trabajo para el seguimiento y
administración de los requisitos X
(Administración de la
configuración, diseño de plantillas Generación de informes y dashboards X
de reutilización, diseño de
plantillas de informes y dashbord, Administración de perfiles y permisos X
definición de reglas de calidad del
requerimiento, seguimiento de Seguimiento de los requisitos X
los requisitos)
Administración de plantillas de reutilización X
Definición de reglas para la revisión de la calidad de los
requisitos
X
Creación de escenarios de pruebas X
Definición y administración de Seguimiento de los escenarios de pruebas X
escenarios de pruebas
Creación y seguimiento de los criterios de aceptación de los
requisitos X
Consulta de informes y dashboard
Consulta de los informes y dashboards X X
32

33. Tener un proceso no es suficiente
33

34. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
34

35. Release Management / Priorización / Estimación
• Problemáticas comunes
– Se solicitan funcionalidades que realmente no son necesarias.
– No se especifica la prioridad de cada uno de los Requisitos, en base a la
estrategia de negocio
– No es posible agrupar las necesidades en fases, causando un scope creep
que imposibilita el comienzo del desarrollo.
– No se sabe cómo estimar el coste, esfuerzo y recursos necesarios para
implementar los requisitos.
– Etc.
35

36. Release Management, priorización y estimación
• ¿En base a qué criterios podemos decidir qué requisitos forman parte
de una release y qué hacer cuando estos criterios cambian?
– Es preciso disponer de criterios de priorización que, de una forma objetiva, nos
ayuden a diferenciar unos requisitos de otros, así como poder diferenciar entre
urgencia, criticidad e importancia.
• ¿Cómo podemos estimar el coste, los recursos y el esfuerzo que
vamos a necesitar para realizar una release?
– Es preciso disponer de criterios de estimación que, en función de unas
variables, nos ayuden a establecer el esfuerzo, recursos y costes necesarios
para llevar a cabo las tareas requeridas.
36

37. Priorización de Requisitos
• No todo puede estar en el “top” de las prioridades: MoSCoW
(Must have, Should have, Could have, Won’t have)
• Debemos diferenciar entre diferentes criterios de priorización:
– Urgente: Relativo al tiempo
– Importante: Relativo a la funcionalidad del sistema
– Crítico: Relativo al funcionamiento del negocio
– …
• Clasificación de Kano: Básico, Adicional, Excitante
• Hay que definir los posibles valores, ponderación y
significados para cada criterio de priorización.
37

38. ¿Es un problema simple?
 Cientos de elementos (demandas, cambios, requisitos) caracterizados
por:
‒ Prioridad
‒ Origen
‒ Coste
‒ Fechas
‒ Valor para la organización (beneficio)
‒ Recursos necesarios
‒ Estimación (h)
 Alcance de la siguiente versión, con restricciones del tipo:
‒ Fecha de lanzamiento
‒ Recursos disponibles
‒ Funcionalidades obligatorias a incluir
 …y distintos objetivos
‒ Maximizar el número de elementos a incluir en una versión
‒ Maximizar el número de elementos con máxima prioridad
‒ Maximizar el número de elementos de un origen específico
‒ Minimizar el consumo de recursos
‒ Minimizar el tiempo necesario
‒ Maximizar el beneficio para la organización
38

39. Técnicas de Priorización
• Clásica
– Realizado por los stakeholders según su visión.
– Suele terminar en casi todos los requisitos y/o cambios con prioridad muy alta.
– Se definen otras prioridades como “super alta” o “crítica”
– Bueno para análisis iniciales, pero no para definir el alcance de una release.
– Una buena técnica es volver a clasificar sólo los requisitos o cambios de “extrema prioridad” en
3 grupos.
• Exhaustiva
– Analizando diferentes perspectivas de priorización, ponderando cada uno de ellos
– Por ejemplo: por usuario, peticionario, competencia, análisis de mercado, regulaciones, …
• Basada en valor
• Basada en valor relativo
39

40. Estimando el valor relativo para el cliente para cada requisito
• Se puede definir una priorización basada en tres componentes:
 Valor relativo para el cliente
 Coste
 Riesgo
Requisito Beneficio si está Penalización si Total (Beneficio + Valor %
presente no está (1-9) Penalización)
(1-9)
1
2
3
40

41. Estimando la prioridad para cada requisito
Procedente de la Procedente de la
planificación gestión de riesgos
Requisito Valor % Coste % Riesgo % Prioridad
1 A L X A/(L+X)
2 B M Y B/(M+Y)
3 C N Z C/(N+Z)
-- 100% 100% 100% --
41

42. Ejemplo matriz de priorización
State Office Area Office Field Office
Relative Relative Relative Relative Relative Relative Relative Total Total Total Relative Relative
Work Item Ranking Benefit Penalty Benefit Penalty Benefit Penalty Benefit Penalty Value Value % Cost Cost % Risk Risk % Priority
Relative Weights: 2,0 1,0 1,0 1,0 1,0 1,0 0,5
Conservation Planning Technology Assistance 6 7 6 8 7 9 8 7,8 6,8 14,5 7,7 6 7,7 3 4,0 0,79
Payment Schedules, Cost Data Development 3 8 8 5 5 6 7 6,8 7,0 13,8 7,3 4 5,1 3 4,0 1,02
Field Office/Landowner Assistance (time in the field) 16 7 5 8 6 8 6 7,5 5,5 13,0 6,9 8 10,3 5 6,7 0,51
eFOTG Coordinator 1 7 8 4 5 8 7 6,5 7,0 13,5 7,2 3 3,8 2 2,7 1,38
Case Studies Promoting New Conservation Technology 20 5 2 4 2 8 2 5,5 2,0 7,5 4,0 6 7,7 5 6,7 0,36
Watershed Planning Economic Assistance 19 7 6 2 2 2 2 4,5 4,0 8,5 4,5 6 7,7 5 6,7 0,41
Farm Bill Technical Assistance 7 6 7 5 5 5 5 5,5 6,0 11,5 6,1 4 5,1 4 5,3 0,78
Economic Training/Workshops (own state) 15 6 3 6 3 7 3 6,3 3,0 9,3 4,9 5 6,4 4 5,3 0,54
Economic Tools Development 13 4 2 5 2 7 2 5,0 2,0 7,0 3,7 3 3,8 4 5,3 0,57
Economic Training/Workshops (NEDC) 9 5 5 1 1 1 1 3,0 3,0 6,0 3,2 2 2,6 3 4,0 0,70
Non-Economic Committees 14 6 6 2 1 2 1 4,0 3,5 7,5 4,0 3 3,8 5 6,7 0,55
Employee Personnal Development 2 7 7 3 3 3 3 5,0 5,0 10,0 5,3 3 3,8 2 2,7 1,02
Other Program Support / Economic Analysis 8 5 5 5 5 5 5 5,0 5,0 10,0 5,3 3 3,8 5 6,7 0,74
RC&D Economic Techincal Assistance 17 5 2 2 2 2 2 3,5 2,0 5,5 2,9 3 3,8 3 4,0 0,50
Emergency Watershed Program Support 12 7 6 2 2 2 2 4,5 4,0 8,5 4,5 3 3,8 6 8,0 0,57
Field Office Quality Assurance Reviews 5 7 7 5 5 7 7 6,5 6,5 13,0 6,9 4 5,1 5 6,7 0,82
Outreach to Conservation Partners (University, Extension, Etc) 11 6 3 2 2 2 2 4,0 2,5 6,5 3,4 3 3,8 3 4,0 0,59
Social Science Coordinator 10 3 3 2 2 2 2 2,5 2,5 5,0 2,7 2 2,6 2 2,7 0,68
Farm Bill Program Manager/Coordinator Support 4 7 8 6 6 6 6 6,5 7,0 13,5 7,2 4 5,1 4 5,3 0,92
Other Duties as Assigned 18 3 2 2 2 2 2 2,5 2,0 4,5 2,4 3 3,8 2 2,7 0,46
Totals: 118 101 79 68 94 75 102,25 86,25 188,5 100 78 100 75 100
42

43. Priorización – Representación gráfica de la priorización (IRQA)
Release Content Management
– Graphical and textual representation of the results of the sorting of the priorization. The weight of each attribute is represented with a different colour (positive or
negative).
The diagram represents from left to right the order of priority based on the calculation of the different attributes
43

44. Priorización – Representación textual de la priorización (IRQA)
44

45. ¿Cuándo estimar?
• Etapas preliminares:
– Para cotizar para un contrato
– Para realizar estudios de viabilidad
• Durante el proyecto:
– Un patrón contra el cuál medir, ajustar el desempeño, y
anticiparse a los riesgos
• Al final del proyecto:
– Extrapolar resultados a otros proyectos
45

46. Métodos de estimación
• Opinión de experto
– En base a experiencia personal.
– ¿Son confiables?
• Analogía:
– Comparación con proyectos similares.
– ¿Como determinar qué es igual y qué es distinto?
• Descomposición:
– Subdividir y estimar los componentes; top-down o bottom-up; traslada el
problema a estimar las partes
• Modelos matemáticos
– En base a fórmulas matemáticas y estadísticas
– Calculan estimaciones en base a medidas objetivas y/o subjetivas
– Esos valores pueden no tenerse en etapas tempranas (p. e. COCOMO y
Puntos Función)
– El avance de la tecnología los pone a prueba permanentemente
– Falta de datos históricos sobre productividad
• Story Points (desarrollos ágiles)
46

47. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
47

48. Métodos de especificación de Requisitos
El método más utilizado
es el lenguaje natural
Fuente: Jonathan Babcock, “Good requirements are more than just accurate”
48

49. ¿Por qué se especifican mal los requisitos?
• La mayoría de los requisitos se especifican en lenguaje natural.
• Puesto que los expertos del dominio, los analistas, los
desarrolladores, los usuarios, etc. saben leer y escribir, se asume que
también saben especificar requisitos.
¿Es eso cierto?
49

50. Reglas para especificar Requisitos
Un requisito debe ser:
1. Claro El conjunto de Requisitos debe ser:
2. Atómico • Completo
3. No ambiguo • Consistente
4. Verificable • Modificable
5. Necesario • Priorizado
6. Independiente de Diseño
7. Factible
8. Completo
9. Consistente
10. Correcto
11. Trazable
12. Caracterizado con atributos
50

51. Algunos ejemplos… (reales)
• La información sobre los metadatos de los usuarios debería
almacenarse en memoria dentro de una tabla hash, o bien en una tabla
de base de datos, con una clave ajena a la tabla de Usuarios.
• El administrador deberá ser capaz de insertar, borrar, mostrar y
actualizar la información sobre los usuarios. Opcionalmente, deberá
también ser capaz de generar un informe y enviarlo por e-mail al cliente
• El sistema debe ser capaz de importar ficheros ABC. El proceso debe ser
amigable y rápido para el usuario
• El administrador deberá ser capaz de crear facturas asociadas con las
diferentes compañías que estén dadas de alta en el sistema y éste
también deberá estar al tanto de facturas impagadas para que puedan
generar un mail y enviárselos a ellos.
• En mi opinión, ningún cliente debería poder nunca enviar órdenes al
equipo de empaquetado. Ya lo hicimos así en un proyecto hace tres años
y el resultado fue nefasto
• Generalmente, el sistema debe ser capaz de terminar el proceso de
rastreo sin sobrecargar excesivamente el servidor
51

52. Algunos ejemplos … (reales)
En cuanto a rangos de morosidad, debe permitir variar los
rangos de mora como 0 - 30 días, 31 - 60, 61- 90, 91 a 120, 121-
150, 151- 180, etc.; a otros rangos como 0 a 10 días, 25 a
35, 50 a 63 etc.
El sistema, además de incluir todos los cambios exigidos por las
franquicias; deberá tener la capacidad para adaptarse de manera
rápida y eficaz a los cambios futuros obligatorios y no obligatorios
que el Banco acepte integrar a su sistema. Dentro de estos cambios
mandatarios se incluyen las certificaciones periódicas que las
franquicias solicitan regularmente. Esto de acuerdo a lo solicitado
en el punto del Mantenimiento.
52

53. Validación de la calidad (IRQA)
53

54. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
54

55. Requisitos sin cambios: ¿es posible?
• ¿Cuántos de sus proyectos mantienen sus requisitos invariables en el
tiempo?
– La respuesta más común es pocos, muy pocos o incluso ninguno...
• ¿Podemos tener requisitos sin cambios?
– Los requisitos inevitablemente van a evolucionar y cambiar.
Prepárese para los cambios … porque sin duda, ¡van a aparecer!
55

56. Características de los Requisitos
• Características de los requisitos
– Volátiles: inconstantes
– Mutantes: presentan alteraciones que se transmiten a otros requisitos
– Emergentes: surgen al ir analizando el sistema en profundidad.
– Colaterales: surgen como efecto de la inclusión de otros requisitos.
– Compatibles: se añaden para adaptar el sistema a su entorno, debido a que el
entorno cambia. Este entorno puede ser físico u organizacional (cambian las
políticas, se producen cambios en las reglas y en los procesos de negocio)
• La propia existencia del sistema va a generar nuevos requisitos por
parte de los usuarios.
56

57. Requisitos sin cambios: ¿es posible?
¿Por qué cambian los requisitos?
– Porque las necesidades de los usuarios varían en el transcurso del proyecto.
– Porque se producen cambios tecnológicos.
– Porque las restricciones del Sistema cambian.
– Porque el entorno y reglas de negocio evolucionan.
– Porque al analizar el problema, no se hacen las preguntas correctas a las
personas correctas.
– Porque no se comunican adecuadamente las necesidades.
– Porque cambia el problema que se está resolviendo.
– Porque cambia el mercado en el cual se desenvuelve el negocio.
57

58. El talón de Aquiles de la Ingeniería de Requisitos
¡Controlar los Cambios!
• No controlar los cambios causa problemas
– Retrabajo, baja calidad, calendarios impredecibles, aumento de costes, etc.
– Especificaciones no satisfechas
– Requisitos Mutantes
58

59. Controlar los cambios
• ¿Cómo controlar los cambios?
– Establecer líneas base de requisitos.
– Definir un proceso formal para la solicitud y gestión de los cambios.
– Trazar los requisitos a través del diseño, código y pruebas.
– Realizar un análisis de impacto ante los cambios.
– Disponer de métricas de control de cambios.
– Disponer de herramientas.
59

60. Línea Base
• Línea Base
– Es el conjunto de requisitos funcionales y no-funcionales que se van a
implementar en una release específica.
– Es una versión aprobada de la especificación de requisitos del
software.
• Los requisitos antes de entrar en la Línea Base deben ser
sometidos a un procedimiento de revisión formal.
• Una vez incluido el requisito en la línea base cualquier cambio
debe someterse al procedimiento de control de cambios.
60

61. Controlar los cambios
• Definir un Proceso de Control de Cambios
– Propósito, revisión, aprobación e incorporación de los cambios
– Definir un modelo de estados, de forma que se tengan identificados la situación
de los cambios en todo momento.
– Incluir el análisis de impacto
– Soportar el proceso con una herramienta, ¡ojo! ¡una herramienta no es un
proceso!
• Todas las peticiones de cambio deben seguir el proceso descrito y
pasar por los controles definidos, p. e. Comité de Control de
Cambios.
• Los cambios en los requisitos pueden requerir una renegociación de
los compromisos del proyecto.
61

62. Trazabilidad
¡La trazabilidad es
imprescindible!
62

63. Trazabilidad
• El objetivo es mantener la traza bidireccional entre los requisitos y cada nivel de
descomposición del producto en componentes.
• La traza bidireccional ayuda a determinar todas las fuentes de requisitos y cubren las
relaciones entre otros componentes durante el ciclo de vida
(diseño, código, pruebas, cambios, planes, interfaces, etc. )
• La trazabilidad es imprescindible para realizar una adecuada gestión de cambios.
• Posibles tipos de trazabilidad:
– Trazabilidad de afectados: Conjunto de trazas que permite identificar a los afectados por cada
requisito del proyecto.
– Trazabilidad entre requisitos: Conjunto de trazas que permite identificar, para cada requisito
de usuario, el conjunto de requisitos de sistema que lo resuelven dentro de un proyecto.
– Trazabilidad de planificación: Conjunto de trazas que permite identificar el estado de
desarrollo de cada requisito del proyecto.
• La trazabilidad entre los requisitos de un proyecto y los diferentes productos
generados puede ser:
– Directa: Cuando la relación entre un requisito y un componente es inmediata.
– Indirecta: Si la relación se define entre componentes de trazabilidad no relacionados
directamente entre sí
63

64. Trazabilidad

Requisitos
de Usuario
Requisitos
de Sistema
Componentes
Componente
Diseñado
Componente
Desarrollado
Pruebas
Implicados
La trazabilidad permite la visibilidad de las relaciones entre productos
64

65. Lista de comprobación
• Objetivos: • Notación:
R.1 R1
– Representar los requisitos. R1.1 R1.1
R 1.1.1 R1.1.1
– Anota el producto o servicio en el que CU 1
CU 2
está soportado el requisito.
.
.
– Comprueba que todo requisito está R 1.1.n R1.1.n
soportado en algún producto o .
servicio. .
.
R 1.n R1.n
– Realizar la traza con los requisitos .
especificados por el usuario. .
R.N Rn
65

66. Lista de comprobación (IRQA)
66

67. Matriz de asociación
1. Objetivos: •Notación:
– Representar las relaciones
COMPONENTES/SERVICIOS…
existentes entre los requisitos y los
productos o servicios objeto del B1 B2 ... Bm
proyecto.
A1 C11 C12 ... C1m
REQUISITOS
– Analizar la consistencia entre los
requisitos y los productos o A2 C21 C22 ... C2m
servicios objeto del proyecto.
... ... ... ... ...
– Realizar la traza con los requisitos
especificados por el usuario. An Cn1 Cn2 ... Cnm
67

68. Matriz de asociación (IRQA)
B1 B2 ... COMPONENTES/SERVICIOS…
Bm
A1 C11 C12 ... C1m
A2 C21 C22 ... C2m
REQUISITOS
... ... ... ... ...
An Cn1 Cn2 ... Cnm
68

69. Análisis de Impacto
1. Evaluar el Impacto del cambio en términos de:
– Coste
– Funcionalidades del sistema afectadas
– Impacto para el cliente y stakeholders externos
2. Especificar los QUIÉNES:
– QUIÉN es el que tiene una necesidad concreta.
– QUIÉN ha aprobado que se implemente una necesidad.
– QUIÉN va a verse impactado por el cambio.
3. Especificar los CÓMOS:
– CÓMO cambia el calendario y presupuesto del proyecto.
– CÓMO cambian los riesgos del proyecto.
– CÓMO cambian otros elementos del proyecto (requisitos, elementos de
diseño, pruebas, etc.)
69

70. Análisis de Impacto
4. Determinar los componentes del sistema que se ven afectados:
– Otros requisitos
– Diseños, código, pruebas, documentación de usuario, pantallas, etc.
– Planes (calendarios, presupuestos, riesgos, etc.), hardware, otros sistemas…
5. Entender todas las implicaciones del cambio
– Conflictos con otros requisitos
– Viabilidad, coste, recursos
6. Identificar las tareas necesarias, estimar el esfuerzo, coste y calendario
70

71. Métricas
Las métricas proporcionan una visión objetiva acerca de qué está pasando …
…y nos ayudan para poder analizar el por qué de los cambios
16
30
14
Number of Req. Changes
Number of Req. Changes
12 25
10 Marketing
20
Management
8
15 Customer
6 SW Group
4 10 Other Eng.
2 5 Testing
0
0
0 5 10 15 20 Source
Weeks After SRS was Baselined
71

72. Agenda
• Visure Solutions, the Requirements Company
• La inversión en Requisitos no puede esperar
• 10 aspectos a considerar cuando hablamos de Requisitos
• Problemáticas de negocio asociadas a los requisitos
– Release Management / Priorización / Planificación de Requisitos
– Cómo escribir requisitos de calidad
– Requisitos mutantes. La gestión del cambio
• 5 consejos finales
72

73. 5 consejos finales…
1. Nunca creas que negocio “no sabe lo que quiere”.
73

74. 1.- Nunca creas que negocio no sabe lo que quiere
• Negocio SÍ sabe lo que quiere. Quizá no sepa explicarlo.
– Es nuestra responsabilidad…
‒ Conocer el negocio y sus procesos.
‒ Crear el “clima” conveniente para entender sus necesidades.
‒ Identificar correctamente a todos los involucrados
‒ Aplicar técnicas para ser capaces de “entender” lo que quiere negocio.
‒ “Hablar el mismo idioma” que ellos. Validar los requisitos.
‒ No tratar de convencerles de cuáles son sus problemáticas reales.
‒ Proporcionar soluciones factibles y certificadas a sus problemáticas.
‒ Aceptar cambios en los requisitos a medida que cambien las necesidades de negocio.
‒ Proporcionar estimaciones realista.
‒ Definir un proceso maduro de Gestión y Definición de Requisitos.
• Pero negocio también debe conocer sus responsabilidades.
– Facilitarnos el conocimiento del negocio.
– Seguir estrictamente el proceso de requisitos definido.
– Ser precisos cuando proporcionen información... y proporcionarla a tiempo.
– Priorizar de forma objetiva.
– Estar disponibles y ser participativos durante el ciclo de vida de requisitos.
– Revisar y proporcionar feedback.
• 4 factores clave: CULTURA, PROCESO, TÉCNICAS Y HABILIDADES
74

75. 1.- Nunca creas que negocio no sabe lo que quiere
• La comunicación usuario / analista es clave.
– Disponemos de técnicas para poder mejorar esa comunicación.
– Pero son necesarias también habilidades sociales para resolver los problemas de
comunicación, como…:
‒ Falta de motivación
‒ Falta de tiempo
‒ Tensiones y opiniones enfrentadas
‒ Generalización
‒ Selección
‒ Distorsión
‒ Falta de Liderazgo o Liderazgo imperante.
‒ Falta de confianza
‒ Sobrevaloración del conocimiento
‒ Alcance de acuerdos. Moderación.
‒ Falta de pensamiento analítico
‒ Comunicación oral y escrita
– Algunas de estas habilidades sociales incluyen:
‒ Escucha activa
‒ Asertividad
‒ Persuasión y negociación
‒ Motivación
‒ Empatía , credibilidad y obtención de la confianza.
‒ Colaboración
‒ Compromiso
‒ Comunicación
75

76. 5 consejos finales…
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca esperes que el usuario te de un buen requisito.
76

77. 2.- Nunca esperes que el Usuario te de un buen requisito
• Los usuarios tienen que explicarnos cuál es el problema que
necesitan resolver… pero no son expertos en requisitos!
• ¿Qué debemos hacer?
– Conseguir la implicación del usuario.
– Aplicar técnicas para capturar el máximo de información.
– Mantener al usuario en el ámbito del problema.
– Diferenciar los que es necesario y opcional.
– Asegurarnos de que lo que se pide se puede probar y hay un criterio de
aceptación claro.
– Capturar las necesidades de todos los stakeholders.
– Verificar que no hay conflictos y en su caso, resolverlos.
– Validar constantemente con el usuario que la solución que proponemos
resuelve su problema.
77

78. 5 consejos finales…
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca esperes que el usuario te de un buen requisito.
3. Nunca gestiones documentos. Gestiona requisitos.
78

79. 3.- Nunca gestiones documentos. Gestiona requisitos.
• Los documentos hacen difícil…
– Acceso concurrente a diferentes partes del mismo.
– Versionado individual de los requisitos.
– Acceder siempre a la última versión de la específicación
– Filtrado, reordenación, clasificación.
– Trazabilidad. Análisis de impacto y de cobertura.
– Control de acceso.
– Discusiones individuales sobre requisitos.
– Uso de atributos
– Workflows individuales de los requisitos.
– Obtención de métricas e indicadores.
– Reutilización
– …
• Además, incentivan…
– Requisitos no atómicos.
– Sobre especificación.
79

80. 5 consejos finales…
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca esperes que el usuario te de un buen requisito.
3. Nunca gestiones documentos. Gestiona requisitos.
4. Nunca hagas dos veces el mismo trabajo.
80

81. 4.- Nunca hagas dos veces el mismo trabajo.
• Define un proceso para crear catálogos de requisitos reutilizables.
– Los requisitos no funcionales pueden ser un buen comienzo.
– Los requisitos funcionales pueden reutilizarse en…
‒ Componentes reutilizables.
‒ Familias de producto y variantes.
• Mantén trazadas al catálogo de requisitos las pruebas asociadas.
– Los procesos de certificación se basan en ello!
• Reutiliza GRUPOS de requisitos, no requisitos individuales.
– El copy/paste o la referencia no son suficientes
81

82. 5 consejos finales…
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca esperes que el usuario te de un buen requisito.
3. Nunca gestiones documentos. Gestiona requisitos.
4. Nunca hagas dos veces el mismo trabajo.
5. Nunca compres una herramienta si no tienes proceso. Ni al revés!
82

83. 5.- Nunca compres una herramienta si no tienes proceso. Ni al revés!
83

84. Y por último….
84

85. Nunca creas que un mundo mejor no es posible…
85

86. Jordi Borja – Director de Desarrollo de Negocio y Estrategia de Solución – jborja@visuresolutions.com – 2012
86