Comprensión de los requerimientos

1. 6.Comprensión de los
Requerimientos
Prof. Ramiro Estigarribia
Link a la presentación

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 Ing. 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?
➔ ¿Existe un solo evento que motiva la creación,
o la necesidad evoluciona en el tiempo?
★ No hay respuestas definitivas a estas preguntas.
1. En ciertos casos, una conversación casual es todo lo que se
necesita para desencadenar un trabajo grande de ingeniería de
software.
2. La mayor parte de proyectos comienzan cuando se identifica
una necesidad del negocio o se descubre un nuevo mercado o
servicio potencial.

5. ¿Qué es la Indagación?
Parece una tarea muy simple:
Preguntar al cliente cuáles son los objetivos para el sistema,
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 que identifique distintos aspectos de la función
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 de escenarios
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. ¿Qué es 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: Proyecto

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 en la Validación.
➔ A medida que se crea cada elemento, 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. Identificación de los participantes
➔ 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.

13. 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 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 ingenieros de 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 o desarrollador) controla la reunión.
5. Se utiliza un 'mecanismo de definición' (que pueden ser hojas,
etiquetas adhesivas, pizarrón, o foro virtual).

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, representa el sistema (producto) desde la
perspectiva de los actores.

17. Ejemplo Diagrama Casos de Uso

18. Ejemplo Diagrama Casos de Uso

19. 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 principales que
debe presentar el sistema para cumplir sus objetivos.

20. 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.