INGENIERIA DE REQUISITOS INGENIERÍA DE SOFTWARE La comprensión de los requisitos de un software está entre las tareas más difíciles que encuentra un ingeniero de software. ¿Qué es? La ingeniería de requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajaran. ¿Porqué es importante ? El diseño y la construcción de un software elegante que resuelva el problema incorrecto no satisface las necesidades de nadie. ¿Cómo puedo estar seguro de que lo he hecho correctamente? El ingeniero de software revisa los productos de trabajo de la ingeniería de requisitos junto con el cliente y los usuarios finales para asegurarse que hayan entendido lo que en realidad pretendían decirle. Es necesario hacer una advertencia: aún después de que todas las partes están de acuerdo, las cosas cambian, y continuarán haciéndolo a través de la vida del proyecto. Determinación de Requerimientos Antes de que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a través de un proceso de obtención. Tareas de la Ingeniería de Requisitos “Por lo general, las semillas de los desastres más importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto” 1. Inicio En algunos casos, una conversación informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniería del software, pero en general, la mayoría de proyectos comienza cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. 2. Obtención La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. ¿Quién está detrás de la solicitud de este trabajo? ¿Cuál será el beneficio económico del éxito de una solución? ¿Hay alguna otra alternativa para la solución que necesita? ¿Quién utilizará solución? la Las siguientes preguntas permiten al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solución: ¿Cómo caracterizaría una buena salida generada para una buena solución? ¿A que tipo de problema(s) va dirigida esta solución? ¿Hay aspectos o restricciones especiales del rendimiento que afecten la manera de enfocar la solución? Las siguientes preguntas se concentran en la eficacia de la reunión: ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son oficiales? ¿Estoy preguntando demasiado? ¿Hay alguien más que pueda suministrar información adicional? ¿Hay algo más que debería preguntarle? Consejo Si un sistema o producto va a servir a muchos usuarios, los requisitos deberán ser obtenidos de un grupo representativo de dichos usuarios. Si sólo una persona define todos los requisitos, el riesgo de aceptación será alto. Todas estas preguntas ayudarán a romper el hielo e iniciar la comunicación tan esencial para el éxito del análisis. Técnicas para facilitar las especificaciones de una aplicación La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. Se establecen normas de preparación y de participación. Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero lo suficientemente informal como para animar el libre flujo de ideas. Un coordinador que controla la reunión. El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución en una atmósfera que permita alcanzar el objetivo. Consejo Evite el impulso de cortar la idea de un cliente por demasiado costosa o poco práctica. La idea es negociar algo que sea aceptable por todos. Es decir, debes tener una mente abierta. Despliegue de la Función de Calidad El DFC es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software. Identifica tres tipos de requisitos: Normales Esperados Innovadores 3. Elaboración La información conseguida con el cliente durante el inicio y la obtención se expande y se refina durante la elaboración. Esta actividad de la ingeniería de requisitos se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. 4. Negociación El ingeniero de requisitos debe conciliar los conflictos por medio de un proceso de negociación. Se identifican y se analizan los riesgos asociados con cada requisito. Se hacen estimaciones preliminares de esfuerzos requeridos para su desarrollo y después se analizan para saber su impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. 5. Especificación La especificación es el producto de trabajo final que genera la ingeniería de requisitos. Sirve como base para las actividades de ingeniería de software subsecuentes. 6. Validación La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecido de manera precisa; que se han detectado las inconsistencias, errores y omisiones, y que éstos han sido corregidos. 7. Gestión de requisitos Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a éstos en cualquier momento mientras se desarrolla el proyecto. Casos de Uso Una vez recopilados los requisitos, el analista puede crear un conjunto de escenarios que identifiquen una línea de utilización para el sistema que se ha de construir. Clave Un caso de uso es un escenario que describe cómo el software va a ser usado en una determinada situación. Casos de Uso (Cont.) Para crear un caso de uso, el analista debe primero identificar los diferentes tipos de personas (o dispositivos) que utiliza el sistema o producto (actores). Es importante indicar que un actor y un usuario no son la misma cosa. Ya que la obtención de requisitos es una actividad de evolución, no todos los actores se identifican en la primera interación. Muchas gracias