Comprension de los requerimientos
0 recomendaciones1,229 vistas
Este documento describe los conceptos clave de la ingeniería de requerimientos. Explica que entender los requerimientos de un proyecto es una de las tareas más difíciles para los ingenieros de software. Detalla los pasos del proceso de ingeniería de requerimientos, incluyendo la indagación, elaboración, negociación y especificación de requerimientos. También destaca la importancia de identificar a los participantes y considerar múltiples puntos de vista para desarrollar requerimientos completos y consistentes.
Comprension de los requerimientos
- 2. Requerimientos de un Problema ➔ No parece tan difícil entender requerimientos: ★ ¿Acaso no sabe el cliente lo que se necesita? ★ ¿No deberían conocer los usuarios finales las características que le darán beneficio? ➔ Entender los requerimientos es una de las tareas más difíciles que enfrenta el ingeniero de software.
- 3. ¿Qué es la Ingeniería de Requerimientos? ➔ Es el espectro amplio de tareas y técnicas que llevan a entender los requerimientos de un proyecto. ➔ Es una de las acciones importantes de la I.S. que comienza durante la actividad de comunicación y continúa en la de modelado. ➔ Debe adaptarse a las necesidades del proyecto, del producto y de las personas participantes. ➔ La ingeniería de requerimientos tiende un puente para el diseño y la construcción.
- 4. ¿Cómo se inicia un proyecto? ➔ La mayor parte de proyectos comienzan cuando se identifica una necesidad del negocio o se descubre un nuevo mercado o servicio potencial. ➔ En ciertos casos, una conversación casual es todo lo que se necesita para desencadenar un trabajo grande de ingeniería de software.
- 5. ¿Qué es la Indagación? Parece una tarea muy simple: Consiste en preguntar al cliente y a los usuarios: Cuáles son los objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el producto en las operaciones cotidianas. Pero no es simple: es muy difícil.
- 6. Indagación - Problemas 1. Problemas de alcance: La frontera de los sistemas está mal definida o los clientes especifican detalles técnicos innecesarios que confunden, más que clarifican. 2. Problemas de entendimiento: Los clientes no están seguros de lo que se necesita, tienen problemas para comunicar las necesidades al ingeniero de sistemas, omiten información que creen que es “obvia”. 3. Problemas de volatilidad: Los requerimientos cambian con el tiempo.
- 7. ¿Qué es la etapa de Elaboración? ➔ Se centra en desarrollar un modelo refinado de los requerimientos del software y su comportamiento. ➔ La información obtenida del cliente durante la concepción e indagación se expande y refina durante la etapa de elaboración. ➔ La elaboración está motivada por la creación y mejora de escenarios de usuario que describen cómo interactuará el usuario final.
- 8. Negociación ➔ No es raro que los clientes pidan más de lo que puede lograrse con recursos limitados de negocio. ➔ También es común que clientes propongan requerimientos conflictivos con el argumento de que es “vital para sus necesidades”. ➔ Estos conflictos deben reconciliarse por medio de un proceso de negociación. ➔ Se pide a clientes que ordenen sus requerimientos según su prioridad y que después analicen los conflictos.
- 9. ¿En qué consiste la Especificación? ➔ Tiene diferentes formas: Puede ser un documento escrito, un conjunto de modelos gráficos, un prototipo, o una combinación. 1. Para sistemas grandes, el mejor enfoque puede ser un documento escrito que combine descripciones en un lenguaje natural con modelos gráficos. 2. Para productos pequeños quizá todo lo que se requiera sea diagramas de casos de uso. Ejemplo: http://www.processimpact.com/process_assets/srs_preview. pdf
- 10. Validación de Requerimientos ➔ La calidad de los productos de la ingeniería de los requerimientos se evalúa durante la validación. 1. Analiza la especificación a fin de garantizar que no tenga ambigüedades. 2. Garantiza que se detectaron y corrigieron los errores y omisiones. 3. Garantiza que que los productos del trabajo se presentan conforme a los estándares establecidos para el proyecto.
- 11. Preguntas a Realizar ➔ A medida que se crea, se estudia para detectar inconsistencias, omisiones y ambigüedades. La revisión aborda las preguntas siguientes: 1. ¿Es coherente con los objetivos del sistema? 2. ¿Se han especificado todos los requerimientos en el nivel apropiado de abstracción? 3. El requerimiento, ¿es realmente necesario o representa una característica no esencial? 4. ¿Cada requerimiento está claro y no es ambiguo? 5. ¿Hay requerimientos en conflicto con otros?
- 12. ➔ Sommerville y Sawyer definen participante a: “cualquier persona que se beneficie en forma directa o indirecta del sistema en desarrollo”. ➔ Cada participante tiene un punto de vista diferente respecto del sistema, obtiene beneficios cuando éste se desarrolla con éxito y corre riesgos si fracasa el esfuerzo de construcción. Identificación de los participantes
- 13. Reconocer múltiples puntos de vista ➔ Debido a que existen muchos participantes, los requerimientos del sistema se explorarán desde muchos puntos de vista diferentes. ➔ Cada uno de estos, aportará información al proceso de ingeniería de los requerimientos. ➔ A medida que se recaba información procedente de múltiples puntos de vista, los requerimientos tal vez sean inconsistentes o estén en conflicto. ➔ Debe clasificarse toda la información de los participantes (incluso los conflictivos) para elegir la mejor combinación.
- 14. Colaboración ➔ En los primeros capítulos se mencionó que, para obtener un sistema exitoso, los clientes (y otros participantes) debían colaborar entre sí. Pero, ¿cómo se llega a esta colaboración? ➔ El trabajo del ingeniero de requerimientos es identificar las áreas de interés común y las de conflicto (por ejemplo, requerimientos que desea un participante, pero que están en conflicto con las necesidades de otro).
- 15. Enfoques para recabar requerimientos 1. Tanto expertos en software como otros participantes intervienen en las reuniones. 2. Se establecen reglas para la participación. 3. Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos, pero con la suficiente informalidad para estimular el libre flujo de ideas. 4. Un “facilitador” (cliente, desarrollador o participante) controla la reunión. 5. Se utiliza un “mecanismo de definición” (que pueden ser hojas, pizarrón, aplicación ,etc).
- 16. Casos de Uso ➔ A medida que se reúnen los requerimientos, comienza a materializarse la visión general del sistema. ➔ Sin embargo, es difícil avanzar hasta no entender cómo emplean los usuarios finales dichas funciones. ➔ Para lograr esto, se crean un conjunto de escenarios que identifican la naturaleza de los usos para el sistema que se va a construir. ★ Los casos de uso, proporcionan la descripción de la manera en la que se utilizará el sistema.
- 17. Resumen y Conclusiones ➔ Las tareas de la ingeniería de requerimientos se realizan para establecer un fundamento sólido para el diseño y la construcción. ➔ La ingeniería de requerimientos ocurre durante las actividades de comunicación y modelado que se hayan definido para el proceso general del software. ➔ Los participantes establecen los requerimientos básicos, definen las restricciones, así como las características y funciones principales que debe presentar el sistema para cumplir sus objetivos.
- 18. Resumen y Conclusiones ➔ Conforme se identifican los requerimientos y se crea su modelo, el equipo de software y otros participantes negocian la prioridad, la disponibilidad y el costo de cada requerimiento. ➔ Además, se valida cada requerimiento y su modelo como un todo comparado con las necesidades del cliente a fin de garantizar que va a construirse el sistema correcto.