HABLEMOS SOBRE REQUISITOSJordi Borja – jborja@visuresolutions.comDirector de Desarrollo de Negocio y Estrategia de Solución
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
Visure Solutions, The Requirements Company•   Compañía española especializada en Ingeniería de Requisitos•   Experiencia d...
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
La inversión en Requisitos no puede esperar• Síntomas   •   Usuarios no satisfechos   •   Alto nivel de retrabajo   •   Pl...
Muchas empresas ya han decidido mejorar sus Requisitos con                                                    Visure      ...
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
1.- Sí: los proyectos fallan por culpa de los RequisitosTiempo                       }              Sorpresa!             ...
1.- Sí: los proyectos fallan por culpa de los Requisitos             Causas de los defectos                               ...
1.- Sí: los proyectos fallan por culpa de los Requisitos     Requisitos incompletos                                       ...
1.- Sí: los proyectos fallan por culpa de los RequisitosFuente: Keil, Cule, Lyytinen, Schmidt   .                         ...
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                                                  15
2.- Los Requisitos defectuosos impactan en el negocio                                                  16
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
3.- Invertir en Requisitos proporciona grandes beneficios                                                                 ...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
4.- El retorno de la inversión es inmediato                              Investments - Year OneSoftware / Hardware   Licen...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
5.- No es suficiente con tener una metodología de desarrollo.• Adoptar metodologías de desarrollo ágiles o basadas en  pro...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
6.- No es suficiente con tener buenos Analistas• Un buen analista requiere además:   •   Un proceso maduro e institucional...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
7.- ¿Somos maduros en Requisitos?Contexto                                  ProcessActual y legislativo                    ...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
8.- ¿Qué técnicas debemos de utilizar?•   La clave del éxito en la Ingeniería de Requisitos es usar técnicas:     –   Madu...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
9.- Capacitación de las personas: el mejor activo de la organización• Las personas involucradas en la Ingeniería de Requis...
Agenda• 10 aspectos a considerar cuando hablamos de Requisitos   1. Sí: los proyectos fallan por culpa de los Requisitos  ...
10 .- Seleccionar la herramienta adecuada no es sencillo                                                                  ...
Tener un proceso no es suficiente                               33
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
Release Management / Priorización / Estimación• Problemáticas comunes   – Se solicitan funcionalidades que realmente no so...
Release Management, priorización y estimación•   ¿En base a qué criterios podemos decidir qué requisitos forman parte    d...
Priorización de Requisitos• No todo puede estar en el “top” de las prioridades: MoSCoW  (Must have, Should have, Could hav...
¿Es un problema simple? Cientos de elementos (demandas, cambios, requisitos) caracterizados  por:    ‒   Prioridad    ‒  ...
Técnicas de Priorización•   Clásica     –   Realizado por los stakeholders según su visión.     –   Suele terminar en casi...
Estimando el valor relativo para el cliente para cada requisito• Se puede definir una priorización basada en tres componen...
Estimando la prioridad para cada requisito              Procedente de la                     Procedente de la             ...
Ejemplo matriz de priorización                                                                              State Office  ...
Priorización – Representación gráfica de la priorización (IRQA)Release Content Management     –         Graphical and text...
Priorización – Representación textual de la priorización (IRQA)                                                           ...
¿Cuándo estimar?• Etapas preliminares:    – Para cotizar para un contrato    – Para realizar estudios de viabilidad•   Dur...
Métodos de estimación•   Opinión de experto     – En base a experiencia personal.     – ¿Son confiables?•   Analogía:     ...
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
Métodos de especificación de Requisitos                                                                            El méto...
¿Por qué se especifican mal los requisitos?•   La mayoría de los requisitos se especifican en lenguaje natural.•   Puesto ...
Reglas para especificar RequisitosUn requisito debe ser:1.    Claro                     El conjunto de Requisitos debe ser...
Algunos ejemplos… (reales)•   La información sobre los metadatos de los usuarios debería    almacenarse en memoria dentro ...
Algunos ejemplos … (reales)En cuanto a rangos de morosidad, debe permitir variar losrangos de mora como 0 - 30 días, 31 - ...
Validación de la calidad (IRQA)                             53
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
Requisitos sin cambios: ¿es posible?•   ¿Cuántos de sus proyectos mantienen sus requisitos invariables en el    tiempo?   ...
Características de los Requisitos•   Características de los requisitos     –   Volátiles: inconstantes     –   Mutantes: p...
Requisitos sin cambios: ¿es posible?¿Por qué cambian los requisitos?   – Porque las necesidades de los usuarios varían en ...
El talón de Aquiles de la Ingeniería de Requisitos             ¡Controlar los Cambios!•   No controlar los cambios causa p...
Controlar los cambios•   ¿Cómo controlar los cambios?    –   Establecer líneas base de requisitos.    –   Definir un proce...
Línea Base•   Línea Base    – Es el conjunto de requisitos funcionales y no-funcionales que se van a      implementar en u...
Controlar los cambios•   Definir un Proceso de Control de Cambios     –   Propósito, revisión, aprobación e incorporación ...
Trazabilidad¡La trazabilidad es  imprescindible!                         62
Trazabilidad•   El objetivo es mantener la traza bidireccional entre los requisitos y cada nivel de    descomposición del ...
Trazabilidad                    Requisitos         de Usuario                        Requisitos                        de...
Lista de comprobación• Objetivos:                              • Notación:                                              R....
Lista de comprobación (IRQA)                          66
Matriz de asociación1. Objetivos:                                 •Notación:    – Representar       las    relaciones     ...
Matriz de asociación (IRQA)      B1    B2    ...          COMPONENTES/SERVICIOS…                              BmA1    C11 ...
Análisis de Impacto1. Evaluar el Impacto del cambio en términos de:   –   Coste   –   Funcionalidades del sistema afectada...
Análisis de Impacto4. Determinar los componentes del sistema que se ven afectados:    –   Otros requisitos    –   Diseños,...
MétricasLas métricas proporcionan una visión objetiva acerca de qué está pasando …       …y nos ayudan para poder analizar...
Agenda•   Visure Solutions, the Requirements Company•   La inversión en Requisitos no puede esperar•   10 aspectos a consi...
5 consejos finales…1.   Nunca creas que negocio “no sabe lo que quiere”.                                                  ...
1.- Nunca creas que negocio no sabe lo que quiere•   Negocio SÍ sabe lo que quiere. Quizá no sepa explicarlo.     – Es nue...
1.- Nunca creas que negocio no sabe lo que quiere•   La comunicación usuario / analista es clave.     –   Disponemos de té...
5 consejos finales…1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca esperes que el usuario te de un buen re...
2.- Nunca esperes que el Usuario te de un buen requisito• Los usuarios tienen que explicarnos cuál es el problema que  nec...
5 consejos finales…1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca esperes que el usuario te de un buen re...
3.- Nunca gestiones documentos. Gestiona requisitos.• Los documentos hacen difícil…   –   Acceso concurrente a diferentes ...
5 consejos finales…1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca esperes que el usuario te de un buen re...
4.- Nunca hagas dos veces el mismo trabajo.•   Define un proceso para crear catálogos de requisitos reutilizables.     –  ...
5 consejos finales…1.   Nunca creas que negocio “no sabe lo que quiere”.2.   Nunca esperes que el usuario te de un buen re...
5.- Nunca compres una herramienta si no tienes proceso. Ni al revés!                                                      ...
Y por último….                 84
Nunca creas que un mundo mejor no es posible…                                           85
Jordi Borja – Director de Desarrollo de Negocio y Estrategia de Solución – jborja@visuresolutions.com – 2012              ...
Próxima SlideShare
Cargando en…5
×

Hablemos sobre requisitos - Jordi Borja - Visures Solutions

729 visualizaciones

Publicado el

Hablemos sobre requisitos - Jordi Borja - Visures Solutions

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
729
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Hablemos sobre requisitos - Jordi Borja - Visures Solutions

  1. 1. HABLEMOS SOBRE REQUISITOSJordi Borja – jborja@visuresolutions.comDirector de Desarrollo de Negocio y Estrategia de Solución
  2. 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. 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. 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. 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. 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. 7. Muchas empresas ya han decidido mejorar sus Requisitos con Visure 7
  8. 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. 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. 10. 1.- Sí: los proyectos fallan por culpa de los RequisitosTiempo } Sorpresa! 1010
  11. 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 costFuentes: James Martin, Barry Boehm 11
  12. 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. 13. 1.- Sí: los proyectos fallan por culpa de los RequisitosFuente: Keil, Cule, Lyytinen, Schmidt . 13
  14. 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. 15. 2.- Los Requisitos defectuosos impactan en el negocio 15
  16. 16. 2.- Los Requisitos defectuosos impactan en el negocio 16
  17. 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. 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. 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. 20. 4.- El retorno de la inversión es inmediato Investments - Year OneSoftware / Hardware Licenses (IRQA + IRQA Web) $ 25.500 Maintenance - Year One $0 Hardware $0Services Training $ 4.000 Consulting $ 8.000People Labor Related Investment $ 10.400Grand 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 260Net Labor Hours Recovered - Year One 1.698 2.553 Cost Per Engineering Hour: $40Total Annual Labor Dollars $ 67.900 $ 102.100Recovered In Year One Return on Investment Low HighInvestment Payback Period (Months) 7,3 5,1NPV (over 2 years, discounted at 7%) $ 41.834 $ 220.712First Year ROI 63% 135% 20
  21. 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. 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. 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. 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. 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. 26. 7.- ¿Somos maduros en Requisitos?Contexto ProcessActual y legislativo Asset LibraryModelosMadurez 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 4RequirementsCapability Adecuación Solución TecnológicaModel (3.2)Evaluaciones Technical Visure Asset University Library 26
  27. 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. 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. 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. 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. 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. 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 Xproyectos y mantenimiento Manejo de atributos de los requisitos X(captura, modelado, Consulta y búsqueda de requisitos Xdocumentación y validación de Firma digital Xrequisitos) 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 XLectura de requisitos Lectura y seguimiento de los requisitos XCreación de prototipos y Creación de Prototipos Xsimulaciones Creación de Simulaciones XConsulta de prototipos ysimulaciones Consulta de prototipos y simulaciones XAdministración de requisitos Gestión de flujos de trabajo para el seguimiento y administración de los requisitos X(Administración de laconfiguración, diseño de plantillas Generación de informes y dashboards Xde reutilización, diseño deplantillas de informes y dashbord, Administración de perfiles y permisos Xdefinición de reglas de calidad delrequerimiento, seguimiento de Seguimiento de los requisitos Xlos 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 XDefinición y administración de Seguimiento de los escenarios de pruebas Xescenarios de pruebas Creación y seguimiento de los criterios de aceptación de los requisitos XConsulta de informes y dashboard Consulta de los informes y dashboards X X 32
  33. 33. Tener un proceso no es suficiente 33
  34. 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. 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. 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. 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. 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. 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. 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. 41. Estimando la prioridad para cada requisito Procedente de la Procedente de la planificación gestión de riesgosRequisito 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. 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,5Conservation 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,79Payment 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,02Field 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,51eFOTG Coordinator 1 7 8 4 5 8 7 6,5 7,0 13,5 7,2 3 3,8 2 2,7 1,38Case 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,36Watershed 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,41Farm 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,78Economic 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,54Economic Tools Development 13 4 2 5 2 7 2 5,0 2,0 7,0 3,7 3 3,8 4 5,3 0,57Economic 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,70Non-Economic Committees 14 6 6 2 1 2 1 4,0 3,5 7,5 4,0 3 3,8 5 6,7 0,55Employee Personnal Development 2 7 7 3 3 3 3 5,0 5,0 10,0 5,3 3 3,8 2 2,7 1,02Other 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,74RC&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,50Emergency 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,57Field 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,82Outreach 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,59Social Science Coordinator 10 3 3 2 2 2 2 2,5 2,5 5,0 2,7 2 2,6 2 2,7 0,68Farm 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,92Other 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. 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. 44. Priorización – Representación textual de la priorización (IRQA) 44
  45. 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. 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. 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. 48. Métodos de especificación de Requisitos El método más utilizado es el lenguaje naturalFuente: Jonathan Babcock, “Good requirements are more than just accurate” 48
  49. 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. 50. Reglas para especificar RequisitosUn requisito debe ser:1. Claro El conjunto de Requisitos debe ser:2. Atómico • Completo3. No ambiguo • Consistente4. Verificable • Modificable5. Necesario • Priorizado6. Independiente de Diseño7. Factible8. Completo9. Consistente10. Correcto11. Trazable12. Caracterizado con atributos 50
  51. 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. 52. Algunos ejemplos … (reales)En cuanto a rangos de morosidad, debe permitir variar losrangos 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 a35, 50 a 63 etc.El sistema, además de incluir todos los cambios exigidos por lasfranquicias; deberá tener la capacidad para adaptarse de manerarápida y eficaz a los cambios futuros obligatorios y no obligatoriosque el Banco acepte integrar a su sistema. Dentro de estos cambiosmandatarios se incluyen las certificaciones periódicas que lasfranquicias solicitan regularmente. Esto de acuerdo a lo solicitadoen el punto del Mantenimiento. 52
  53. 53. Validación de la calidad (IRQA) 53
  54. 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. 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. 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. 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. 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. 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. 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. 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. 62. Trazabilidad¡La trazabilidad es imprescindible! 62
  63. 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. 64. Trazabilidad  Requisitos de Usuario Requisitos de Sistema Componentes Componente Diseñado Componente Desarrollado Pruebas ImplicadosLa trazabilidad permite la visibilidad de las relaciones entre productos 64
  65. 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. 66. Lista de comprobación (IRQA) 66
  67. 67. Matriz de asociación1. 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. 68. Matriz de asociación (IRQA) B1 B2 ... COMPONENTES/SERVICIOS… BmA1 C11 C12 ... C1mA2 C21 C22 ... C2m REQUISITOS... ... ... ... ...An Cn1 Cn2 ... Cnm 68
  69. 69. Análisis de Impacto1. Evaluar el Impacto del cambio en términos de: – Coste – Funcionalidades del sistema afectadas – Impacto para el cliente y stakeholders externos2. 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. 70. Análisis de Impacto4. 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, recursos6. Identificar las tareas necesarias, estimar el esfuerzo, coste y calendario 70
  71. 71. MétricasLas 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. ChangesNumber 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. 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. 73. 5 consejos finales…1. Nunca creas que negocio “no sabe lo que quiere”. 73
  74. 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. 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. 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. 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. 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. 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. 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. 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. 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. 83. 5.- Nunca compres una herramienta si no tienes proceso. Ni al revés! 83
  84. 84. Y por último…. 84
  85. 85. Nunca creas que un mundo mejor no es posible… 85
  86. 86. Jordi Borja – Director de Desarrollo de Negocio y Estrategia de Solución – jborja@visuresolutions.com – 2012 86

×