Elicitación de Requisitos

Transcripción

1 Departamento de Lenguajes escuela técnica superior de ingeniería informática Grupo de Ingeniería a del Software Marzo de 2006 Versión original: Amador Durán Toro (septiembre 2004) Última revisión: Amador Durán Toro (marzo 2006); cambio en el modelo de tareas. Tiempo: 1h 30m 1. Objetivos 2. Problemas Objetivos Conocer el dominio del problema para poder comunicarse con clientes y usuarios y entender sus necesidades. Conocer el sistema actual (manual o informatizado) y sus aspectos positivos y negativos. Identificar las necesidades, tanto explícitas como implícitas, de clientes y usuarios y sus expectativas sobre el sistema a desarrollar. Grupo de Ingeniería del Software 1 1

2 1. Objetivos 2. Problemas Objetivos Nunca debe perderse de de vista porqué se se desarrolla el el software: para satisfacer necesidades reales, para resolver problemas reales. La La única forma de de resolver las las necesidades reales es es comunicarse con con aquellos que que tienen dichas necesidades. El El cliente o usuario es es la la persona más importante involucrada en en el el proyecto. Alan Davis Grupo de Ingeniería del Software 2 1. Objetivos 2. Problemas Problemas La de requisitos es una actividad principalmente de carácter social, mucho más que tecnológico. Los problemas que se plantean son por tanto de naturaleza psicológica y social, más que técnicos. Grupo de Ingeniería del Software 3 2

3 1. Objetivos 2. Problemas Problemas de articulación Dificultad para expresar claramente las necesidades. No ser conscientes de sus propias necesidades. No entender como la tecnología puede ayudar. Miedo a parecer incompetentes por ignorancia tecnológica. No tomar decisiones por no poder prever las consecuencias, no entender las alternativas o no tener una visión global. No escuchar adecuadamente a los clientes y usuarios. Problemas de comunicación Cultura y vocabulario diferentes. Intereses distintos en el sistema a desarrollar. Medios de comunicación inadecuados (p.e. diagramas que no entienden los clientes y usuarios). Conflictos personales o políticos. Grupo de Ingeniería del Software 4 1. Objetivos 2. Problemas Limitaciones cognitivas No conocer el dominio del problema. Hacer suposiciones sobre el dominio del problema. Hacer suposiciones sobre aspectos tecnológicos. Hacer simplificaciones excesivas. Conducta humana Conflictos y ambigüedades en los roles de los participantes. Pasividad de clientes, usuarios o ingenieros de requisitos. Temor a que el nuevo sistema lo deje sin trabajo. Técnicos Complejidad del dominio del problema. Complejidad de los requisitos. Cambios en los requisitos (cuanto más se ve, más se necesita). Cambios en hardware y software, reduciendo el coste. Múltiples fuentes de requisitos. Fuentes de información poco claras. Grupo de Ingeniería del Software 5 3

4 1. Objetivos 2. Problemas Tareas b Glosario de Términos Información sobre Necesidades Estudiar Estudiar el el Dominio Dominio del del Problema Problema Identificar Identificar Necesidades Necesidades Estudiar Estudiar la la Situación Situación Actual Actual Modelo del Negocio Actual Modelo del Negocio a implantar Documentación Adicional Actas de reuniones Documentos Proyectos similares etc. Priorizar Priorizar Necesidades Necesidades Información sobre prioridades Grupo de Ingeniería del Software 6 1. Objetivos 2. Problemas Observación in situ Observación pasiva en el lugar de trabajo del usuario. Puntualmente se pueden hacer preguntas, pero sin interrumpir el trabajo del usuario. Se debe evitar que el usuario se sienta observado. Inmersión/aprendizaje n/aprendizaje Observación activa en el lugar de trabajo del usuario. Se trabaja con el usuario como si se fuera un nuevo empleado. Es muy costoso en tiempo. Estudio documentación Estudio de normas internas, documentos comerciales (facturas, albaranes, ), documentos internos, etc. Encuestas Envío de formularios a un número elevado de usuarios. La tasa de respuesta suele ser baja (<10%). El desarrollo de formularios eficaces es complejo. Grupo de Ingeniería del Software 7 4

5 1. Objetivos 2. Problemas Glosarios de t Un glosario es un pequeño diccionario que contiene relativos al dominio del problema. Cada término tiene un nombre (quizás algunos sinónimos también) y una definición. Es una técnica muy sencilla que permite registrar el conocimiento que se va adquiriendo sobre el dominio del problema y compartirlo con todos los participantes en el proyecto, estableciendo un vocabulario común. Principio de Circularidad [Leite] Un glosario debe ser tan autocontenido como sea posible. Ayuda a que los estén relacionados y que no se deje conocimiento fuera del glosario. Principio de Mínimo M Vocabulario [Leite] Los requisitos deben expresarse usando principalmente elementos del glosario. Ayuda a que sea más comprensible y menos ambiguo. Grupo de Ingeniería del Software 8 1. Objetivos 2. Problemas Modelado del actual o a implantar Describe el funcionamiento del actual o a implantar del cliente, es decir, sus procesos de. Es fundamental para entender el contexto en el que se usará el sistema a desarrollar. El nivel de detalle es menor que en los modelos del sistema a desarrollar. Permite mejorar los procesos de al tener una visión más general de los mismos. Técnicas habituales Diagrama de actividades Técnica de UML similar a los diagramas de estado. * Casos de uso de Similar a los casos de uso del sistema a desarrollar, pero con ámbito diferente. * *Los diagramas de actividades y los casos de uso del sistema se verán n en los siguientes temas. Grupo de Ingeniería del Software 9 5

6 1. Objetivos 2. Problemas Preparación n de entrevistas Conocer el vocabulario del dominio del problema. Imprescindible para poder entender al entrevistado. Seleccionar las personas a entrevistar Se debe minimizar el número de entrevistas. Los directivos suelen proporcionar una visión general, mientras que los futuros usuarios una más detallada. Determinar objetivos y contenidos s entrevistas Se debe minimizar el tiempo entrevista. Los entrevistados deben conocer con antelación el objetivo entrevista y las preguntas que se le van a hacer. Planificar las entrevistas Establecer fecha, hora, lugar y duración de cada entrevista de acuerdo con el entrevistado. Grupo de Ingeniería del Software Objetivos 2. Problemas Realización n de entrevistas Apertura (5-15 min.) Presentarse al entrevistado y recordarle el objetivo de la entrevista, como se usará la información, etc. Explicar notaciones que el entrevistado no conozca. Causar buena impresión. Desarrollo ( 2 horas, 20%/80%) Evitar monólogos y mantener el control, contemplando la posibilidad de una tercera persona tomando notas o la grabación entrevista. Comenzar con preguntas abiertas (no pueden responderse con un sí o un no) y terminar con preguntas más concretas. No anticipar respuestas a las preguntas. Usar el vocabulario del dominio del problema. Grupo de Ingeniería del Software 11 6

7 1. Objetivos 2. Problemas Realización n de entrevistas (continuación) n) Terminación (5-10 min.) Recapitular para evitar confusiones. Agradecer la colaboración. Citar para otra entrevista si fuera necesario y dejar abierta la posibilidad de futuros contactos. Análisis de entrevistas Redactar el acta entrevista pasando a limpio las notas tomadas y reorganizando la información. Contrastar los resultados con los de otras entrevistas. Enviar el acta al entrevistado para su confirmación. Grupo de Ingeniería del Software Objetivos 2. Problemas Ventajas reuniones/entrevistas Ahorran tiempo al contactar con varias personas a la vez. Permiten contrastar las opiniones de los participantes directamente en lugar de hacerlo por separado. Suelen generar una mayor implicación de clientes y usuarios. Inconvenientes reuniones/entrevistas Un grupo de personas es mucho más difícil de controlar que una sola persona. El detalle información obtenida suele ser menor que en las entrevistas. La planificación es más compleja, al implicar a varias personas. Grupo de Ingeniería del Software 13 7

8 1. Objetivos 2. Problemas Joint Application Development (JAD) Conjunto de reuniones durante 2 a 4 días. Cuatro principios: dinámica de grupo, uso de técnicas audiovisuales, organización y documentación WYSIWYG. Se adapta mal a los horarios de clientes y usuarios y es compleja de organizar. Roles en JAD Jefe del JAD: responsable general, controla las reuniones. Analista: responsable documentación generada. Patrocinador ejecutivo: decide si el proyecto se lleva a cabo o no. Representantes de los usuarios: directivos o futuros usuarios finales. Representantes de sistemas de información: asesoran sobre las posibilidades tecnología y su coste. Especialistas: asesoran en aspectos técnicos o del dominio del problema. Grupo de Ingeniería del Software Objetivos 2. Problemas Fases del JAD Adaptación El jefe del JAD debe adaptar el JAD al proyecto, seleccionar los participantes, definir el formato documentación, planificar las reuniones y preparar material audiovisual introductorio. Celebración s reuniones Presentación Definir objetivos y requisitos Delimitar el ámbito del sistema Documentar temas abiertos Concluir la sesión Conclusión Completar la documentación Revisar la documentación Validar la documentación Grupo de Ingeniería del Software 15 8

9 1. Objetivos 2. Problemas Brainstorming (tormenta de ideas) Objetivo: generar ideas en un ambiente libre de críticas o juicios. Grupos de 4 a 10 personas, una de ellas es el jefe sesión. Requiere poca organización y es fácil de aprender. Puede generar diferentes vistas del problema, aunque no con una gran calidad de detalles. Fases del brainstorming Preparación Seleccionar participantes, citarlos y preparar el lugar. Generación El jefe propone un problema semilla, se proponen ideas sin ningún tipo de críticas, se fomentan las ideas más avanzadas para estimular y se alienta a completar las ideas de otros. Consolidación Se revisan las ideas, se descartan las que no son factibles y se priorizan las restantes. Documentación El jefe sesión redacta el acta reunión. Grupo de Ingeniería del Software 16 9