Ingeniería de Requerimientos

1. Ingeniería de Requerimientos Análisis

2. Adquisición Desarrollo Análisis Especificación Validación Control de Cambios Administración Control de Versiones Seguimiento Ingeniería de Requerimientos

3. Análisis • El objetivo del análisis es descubrir problemas, inconsistencias y faltantes en los requerimientos adquiridos. Esto sirve de retroalimentación para las personas interesadas, de manera que se puedan resolver mediante un proceso de negociación

4. Temas • Priorizar • Identificar problemas • Identificar oportunidades • Negociar

5. Priorizar • Los proyectos de software tienen recursos limitados • Es importante priorizar los requerimientos • Ayuda a resolver conflictos • Permite planificar las entregas • Facilita el uso adecuado de los recursos • Balancear beneficios y costos

6. Priorizar • Es un trabajo realizado entre usuarios/clientes y desarrolladores • Usuarios/clientes definen las funciones con mayores beneficios • Desarrolladores definen costos, riegos técnicos, y dificultad de cada función • Todos los requerimientos pactados se implementarán, pero algunos no son tan esenciales

7. Priorizar • Escalas • Pocos valores • Puede ser subjetiva • Todos deben estar de acuerdo en el significado • Tres valores • Alta – Media – Baja • Esencial – Condicional – Opcional • Crítica – Importante - Útil

8. 1 2 3 Priorizar • Alta – Esencial • Requerimiento de misión crítica • El software no es aceptable sin él

9. Priorizar • Media – Condicional • Operaciones de soporte del sistema • Amplía la funcionalidad del software, pero se puede aceptar sin él al comienzo • Baja – Opcional • Interesante tener esta funcionalidad o cualidad, si los recursos lo permiten • Funciones que no son muy valiosas

10. Priorizar • La prioridad de cada requerimiento debe ir en la especificación de los casos de uso o en la especificación de los requerimientos • En un caso de uso con varias alternativas, algunas pueden tener mayor prioridad que otras

11. Priorizar • Identificar • Regulaciones externas • Funciones núcleo del negocio y/o diferenciadoras • Las demás características • Priorizar basados en costos, beneficios y riesgos

12. Priorizar • RUP • Priorizar basado en: • Beneficios (para el negocio) • Crítico, importante, útil • Impacto en la arquitectura • Ninguno, extiende, modifica • Riesgos • Tienen más alta prioridad los más críticos, con mayor impacto y riesgo

13. Priorizar • Pasos (1) • Hacer una lista con los casos de uso y los requerimientos del sistema que no están en los casos de uso • Para cada caso de uso/requerimiento se califican de 0 a 3 los siguientes aspectos: • Significativo para la arquitectura • Riesgo • Naturaleza crítica (beneficio)

14. Priorizar • Pasos (2) • Se determina el peso que se dará a cada aspecto, en un rango de 1 a 3 • Se calcula la prioridad de cada caso de uso/requerimiento, sumando los valores de cada aspecto (multiplicados previamente por su respectivo peso) • Los valores más altos corresponden a las mayores prioridades

15. Priorizar • Ejemplo: Pesos: Arq: 1, Riesgo: 2, Beneficio: 3

16. Priorizar • XP • PlanningGame • Priorizar basado en: • Importancia para el negocio • Esfuerzo (costo) • Riesgo

17. Priorizar • XP • Los usuarios/clientes definen el valor para el negocio (crítico – significante - útil) • Los desarrolladores definen el riesgo (bajo, medio, alto) y estiman el esfuerzo • Se negocian las prioridades y se selecciona la historia de usuario que se implementará

18. Priorizar • Karl Wiegers • Priorizar basado en: • Valor del requerimiento • Beneficio, costo de no tenerlo • Costo y riesgo • Implementación, elementos técnicos • La prioridad está directamente relacionada con el valor e inversamente relacionada con el costo y el riesgo

19. Priorizar • Pasos (1) • Listar los requerimientos, características o casos de uso que se desean priorizar • Estimar el beneficio relativo (1 muy bajo, 9 el máximo) • Basado en los objetivos del negocio • Determinado principalmente por los clientes

20. Priorizar • Pasos (2) • Estimar el costo de no tener la función (1 bajo, 9 alto) • Valor = Suma del beneficio y el costo • Se puede dar un peso a cada uno • Estimar el costo de implementar la función (1 bajo, 9 alto) • Complejidad, Interfaz de usuario, … • Determinado por los desarrolladores

21. Priorizar • Pasos (3) • Estimar el riesgo asociado (1 bajo, 9 alto) • Falta de experiencia, tecnología nueva, … • Calcular la prioridad, así: • Prioridad = % Valor / (% Costo + % Riesgo) • Se puede dar pesos al costo y al riesgo • El porcentaje es con respecto al total de todas las funciones evaluadas

22. Priorizar • Pasos (4) • Ordenar de forma descendente • Los primeros elementos, por tener un balance favorable en costo/beneficio, son candidatos a tener alta prioridad

23. Priorizar • Ejemplo Pesos: Beneficio: 2, Costo no tener: 1, Costo: 1, Riesgo: 0.5

24. Priorizar • Tablas: • Son una herramienta de gran ayuda, que incluye elementos numéricos en una valoración que generalmente es subjetiva • Los resultados obtenidos deben ser revisados, pues sirven de guía pero no son absolutos

25. Priorizar • Otros aspectos que se pueden considerar • Volatilidad de los requerimientos • Competidores • Recursos • …

26. Ejercicio • Elabore una plantilla para calcular las prioridades de los requerimientos

27. Priorizar • Otras técnicas • Voto acumulativo (100-Dollar Test) • Distribuir 100 unidades (pesos, horas) entre los requerimientos • Puntuación (Ranking) • Dar un puntaje de 1 a N (para N requerimientos), donde 1 es el menos importante • Diez primeros (Top Ten)

28. Temas • Priorizar • Identificar problemas • Identificar oportunidades • Negociar

29. Identificar problemas • Determinar • Los requerimientos son factibles • Técnicamente • Económicamente • Operacionalmente • No hay contradicciones/inconsistencias

30. Identificar problemas • Algunas técnicas • Lista de preguntas • Revisar casos de uso • Matriz de requerimientos • Matriz CRUD

31. Identificar problemas • Ejemplo Lista de preguntas • ¿Los requerimientos son consistentes con los objetivos propuestos? • ¿Hay requerimientos “cosméticos”, es decir, que no son realmente necesarios? • ¿Se requiere tecnología con la que no se cuenta actualmente? • ¿Algún requerimiento se puede dividir en otros requerimientos?

32. Identificar problemas • Revisar casos de uso (1) • El diagrama de casos de uso presenta claramente el comportamiento del sistema • No hay cadenas de relaciones “include” y/o “extends” • Hay pocas dependencias entre casos de uso • Todas las relaciones entre los casos de uso están justificadas

33. Identificar problemas • Revisar casos de uso (2) • Se han identificado todos los casos de uso • No hay casos de uso innecesarios • Si el modelo es muy grande o las responsabilidades están distribuidas, se han utilizado paquetes • Los paquetes hacen el modelo más fácil de entender

34. Identificar problemas • Matriz de requerimientos • Filas y columnas con los requerimientos • Cero (0) si son independientes • Uno (1) si presentan algún conflicto • Dos (2) si tienen elementos comunes, es decir, se solapan

35. Identificar problemas • Ejemplo - Matriz de requerimientos

36. Identificar problemas • Matriz CRUD • Permite encontrar requerimientos faltantes • Filas  Casos de uso • Columnas Entidades - Conceptos • Celdas: • C: Crear • R: Leer - Consultar • U: Actualizar • D: Borrar

37. Identificar problemas • Ejemplo – Matriz CRUD

38. Identificar problemas • Entidades que no tengan alguna de las acciones • ¿Falta un caso de uso? • ¿Algún caso de uso está incompleto? • ¿El objeto no es necesario? • ¿Falta determinar alguna regla del negocio?

39. Ejercicio • Elabore la matriz CRUD para los casos de uso y entidades en el ejemplo • Determine posibles requerimientos faltantes

40. Temas • Priorizar • Identificar problemas • Identificar oportunidades • Negociar

41. ¿Cómo va a ser el resultado? ¿Cómo va a ser la entrada? Restricciones de datos Restricciones de tiempo de ejecución Identificar oportunidades • Refinar los requerimientos Requerimiento

42. Identificar oportunidades • Requerimientos explícitos • Se declaran y establecen • Requerimientos implícitos • Se asume que se deben cumplir • Requerimientos innovadores • Van más allá de las expectativas del cliente

43. Identificar oportunidades • Mejorar “usabilidad” (facilidad de uso) del sistema • Ayudas o guías para el usuario • No son triviales, impactan positivamente • Promedio de uso de cada acción • Acciones más frecuentes tienen mayor prioridad y facilidad de acceso

44. Temas • Priorizar • Identificar problemas • Identificar oportunidades • Negociar

45. Negociar • Consiste en llegar a un acuerdo en los requerimientos, con las personas interesadas en el proyecto • Se realiza • Cuando hay conflictos • Diferentes objetivos y perspectivas de las personas interesadas

46. Negociar • Se deben identificar los conflictos • Elementos en conflicto • Autores, Fuentes • Participarán en la negociación • Descripción del conflicto • Posibles alternativas • Importancia / Urgencia

47. Negociar • Plantilla propuesta

48. Negociar • Se deben evitar los conflictos emocionales • Contar con un buen facilitar • Además de los conflictos y las alternativas, se deben hace explícitas las argumentaciones • Apoyan la solución seleccionada

49. Negociar • Pasos (1) • Definir el problema • Definir los interesados • Identificar los objetivos de cada interesado • Analizar los objetivos • Inconsistencias • Riesgos • Supuestos

50. Negociar • Pasos (2) • Determinar los criterios/reglas para evaluar las alternativas • Negociación, basada en: • Realizar propuestas y definir qué aspectos se está dispuesto a cambiar • Buscar alternativas para los puntos en conflicto • Establecer beneficios y compromisos de cada una de las partes