1 Especificación y Análisis de Requerimientos
2
3
4 Especificación y análisis de requerimientos
5
6 Qué es un Requerimiento?Es un aspecto del contenido o comportamiento del producto, requerido o deseado por el cliente. Requerimientos funcionales. (Debe hacer) Requerimientos no-funcionales.(Debe tener) Una restricción es un requerimiento que afecta a todo el producto.
7 Qué es un Concepto? Ciclo de vida “V” Concepto Why? Análisis What?Pruebas acept. Verificación y Validación Why? Análisis Pruebas integ. What? Diseño Pruebas unit. How? Código Do! Concepto : conocimiento general del proceso del negocio. entrega: diag. de contexto, diag. de Entidad-Relación, Casos de Uso
8 Modelo de Procesos “Volere”
9
10 Fases de la especificación y análisis de requerimientosBlastoff Recolección de requerimientos Prototipos Verificación y validación Revisiones Post-Mortem
11
12
13 Blastoff Preparación para el inicio del proyectoReunión entre los principales desarrolladores, clientes y usuarios Del Blastoff se obtienen: El contexto Propósito del proyecto Lista de principales riesgos Estimación inicial del esfuerzo Decisión de seguir adelante o no Identificación clara de los interesados Compromiso con el proyecto Formación de equipos
14 Recolección de RequerimientosEn esta etapa se deben Extraer los requerimientos de los usuarios Descubrir el mayor número posible de requerimientos Utilizar diferentes métodos para los requerimientos conscientes, inconscientes y los no-imaginados
15 Métodos para la recolección de requerimientosAprendiz Escenciales Entrevistas Herramientas Mind Maps Brainstorming Particionamiento del contexto Identificación de eventos y Casos de uso Uso de Video
16 Requerimientos escencialesDiferencia entre la implementación actual y el requerimiento escencial Estan presentes independientemente de la tecnología Buscar al contenido de información, no el medio.
17
18 Brainstorming El grupo de desarrolladores se reune para una lluvia de ideas Muchas ideas, ideas nuevas, toda idea es buena No deben evaluarse, debatir ni criticar No limitarse por lo posible Luego la lista de ideas es evaluada, ordenada (votación) -> 60 ideas locas pueden contener 5 ideas geniales.
19 Tipos de RequerimientosRestricciones globales Requerimientos Funcionales Requerimientos No-Funcionales
20 Restricciones globalesAfectan a todo el producto y son determinadas por el usuario y los que administran el proyecto/producto. 1. Propósito del sistema 2. El cliente 3. El usurio 4. Convenciones para la nomenclatura y las definiciones 5. Hechos relevantes 6. Restricciones del proyecto 7. Suposiciones
21 Requerimientos FuncionalesLo que el producto debe hacer 8. Alcance del sistema 9. Requerimientos Funcionales y de datos
22 Requerimientos FuncionalesDescribir una acción que debe realizar el producto No escribir soluciones Cada evento/caso de uso tiene muchos requerimientos funcionales Algunos son parte también de otros eventos Iniciar descomponiendo los casos de uso en pasos: serie de pasos para completar el trabajo de un caso de uso Acciones que puede reconocer el usuario Posiblemente una interacción entre usuario y máquina número limitado de pasos El uso del formato ayuda para determinar qué tan completa está la especificación de requerimientos.
23
24 Requerimientos No-FuncionalesApoyan a las funciones, son las propiedades que el producto debe tener. 10. Apariencia y sensación 11. Usabilidad 12. Performance 13. Operabilidad 14. Mantenibilidad 15. Seguridad 16. Requerimientos Políticas 17. Requerimientos legales
25 Requerimientos No-FuncionalesDescriben las propiedades o características que el producto debe tener. Cada requerimiento funcional tiene asociados requerimientos no-funcionales Algunos pueden afectar a nivel de eventos, otros a todo el producto. Requerimientos no-funcionales: Apariencia y sensación: (Bosquejos) Usabilidad: Depende de la definición de los usuarios, cuantificable por los criterios de evaluación. Performance: Requerimientos reales del performance, velocidad, presición, disponibilidad, seguridad, nivel de servicio, volúmenes de datos, etc. Operacional: Ambiente en el que el usuario operará el producto y productos con los que colabora.
26
27 Otros temas importantes:Puntos que salen eventualmente durante el proyecto 18.Discusiones abiertas 19. Soluciones comerciales 20. Problemas nuevos 21. Tareas 22. Cutover 23. Documentación del usuario 24. Sala de espera
28 Registro de los requerimientos:Para manejar los requerimientos, estos deben tener: Un número único de ID Tipo Lista de los eventos y casos de uso que lo contienen. Descripción: una frase que describe la intención del requerimiento. Propósito: Por qué se considera importante? Fuente: ¿Quién determinó este requerimiento
29 Registro de los requerimientos (cont.)Criterio de evaluación: Prueba no-ambigua que indica si una solución cumple este requerimiento Satisfacción del cliente: Grado de satisfacción si el criterio se cumple exitosamente (1=no importa mucho-5=muy satisfecho) Insatisfacción del cliente: Grado de insatisfacción si el criterio no se cumple (1=no importa mucho-5=muy molesto)
30 Verificación y Validación de RequerimientosPrevenir la infiltración de requerimientos: los que entran al producto depués del proceso de análisis de requerimientos. Prevenir la fuga de requerimientos: aquellos cuya fuente se desconoce Estos incrementan desmesuradamente el costo y el tamaño del producto. Se pueden usar métricas de función para controlar la infiltración de requerimientos. El número de function points puede ser una medida para limitar el tamaño del desarrollo.
31 Quality Gateway Evaluación de los requerimientosPara incluirlos en la especificación cada requerimiento debe pasar el umbral de calidad. Sirve para prevenir la infiltración y la fuga de requerimientos. Para pasar debe : Tener un criterio de evaluación Tener una identificación única y referencias a los eventos y casos de uso Ser relevante Ser viable Tener un valor para el cliente No ser adorno Estar completo Usar la tecnología correcta Los requerimientos rechazados se regresan al interesado Ser mantendrá una lista de requerimientos rechazados y la razón
32
33 Criterios de ValidaciónEs una meta numérica que la solución debe cumplir. No se puede diseñar una solución a un requerimiento sin una manera de saber si se ha logrado resolverlo o no. Para los requerimientos funcionales el criterio especifica cómo establecer si cumple sus objetivos. Para los requerimientos no-funcionales cuantifican el comportamiento resultante.
34 Métricas Tipo de requerimiento Escalas de evaluación10. Apariencia y sensación Cumple con el estándar? especificar quién/cómo probarlo 11. Usabilidad Tiempo requerido para aprender Tiempo de entrenamiento Realización de funciones en tiempo planteado 12. Performance Tiempo para completar la acción 13. Operabilidad Cuantificación del tiempo/facilidad de uso 14. Mantenibilidad Tiempo permitido Esfuerzo requerido para portarlo 15. Seguridad Cuantificar quién ha tenido acceso 16. Requerimientos Políticas Quién los acepta (no son cuantificables) 17. Requerimientos legales Opinión del abogado
35
36 Prueba de los criteriosCumple con los objetivos y la intención del producto? Provoca el comportamiento correcto? Puede ser probado? Las pruebas son eficientes (costo)? Es subjetivo el criterio? Esta definida la terminología? Es ambiguo?
37 Pruebas de Relevancia Se encuentra dentro del contexto del proyecto?Cumple con las restrucciones globales y el plan estratégico del producto? Es consistente con el producto?
38 Pruebas de viabilidad Los usuarios son capaces de usar el producto?Tenemos la habilidad tecnológica para construir el producto? Se tienen los medios y el tiempo para ello? Es aceptable a todos los intersados? Se puede hacer de manera eficiente? Cuáles son las consecuencias del requerimiento?
39 Prototipos y Modelado de SituacionesPor qué usar prototipos? Algunos requerimientos no son obvios o no están completos Algunos usuarios tienen dificultades para formular sus deseos Algunos desarrolladores tienen dificultades para entender los que se está pidiendo Darles a los usuarios la oportunidad de "usar" el requerimiento Determinar la factibilidad o necesidad del requerimiento Permite encontrar mas requerimientos escondidos.