Universidad Tecnológica Nacional Facultad Regional Córdoba Cátedra de Análisis de Sistemas

1. Universidad Tecnológica Nacional Facultad Regional Córdoba Cátedra de Análisis de Sistemas Seminario de Actualización Docente Tema: Ingeniería de Requerimientos Disertante: Ing. Judith Meles Abril de 2001

2. El Problema de los Requerimientos 1) Lo que el usuario necesita 2) Lo que el usuario cree necesitar 3) Lo que le transmitió al profesional

3. El Problema de los Requerimientos 4) Lo que el profesional entendió 5) Lo que se entregó al principio 6) Lo que al final resultó

4. Introducción La efectividad y flexibilidad de un sistema está extrechamente relacionada a la correcta comprensión de las necesidades de los clientes y/o usuarios del sistema, hay un componente clave en todo proceso de desarrollo , que juega un papel central, llamado.... ESPECIFICACIÓN DE REQUERIMIENTOS

5. ¿ Qué es un Requerimiento?(Definición IEEE-Std-610 - 1990) • Condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. • Condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto. • Representación documentada de una condición o capacidad como las expresadas anteriormente.

6. Requerimientos: Categorías • En general, caen en dos grandes categorías: • orientado al mercado • específico para un cliente

7. RequerimientosOrientados al Mercado • Bocetados e informales • Técnicas más de manufactura que de Ingeniería de Software • Especificación en forma de presentación comercial • “Cliente” no fácilmente identificable • Se basan en Consultores para aspectos deseables • Enfoque poco estructurado.

8. Requerimientos Específicos para un cliente • Voluminosos y más “formales” • Uso de técnicas de Ingeniería de Software • Largas especificaciones • Uso del conocimiento del dominio • Proyectos basados en personal propio • Método estructurado siguiendo un enfoque particular

9. Requerimientos: Una Perspectiva Organizacional • La contribución de los SI a las organizaciones • Automatizar reduciendo costos de proceso • Informar a los tomadores de decisiones • Transformar la organización • Prerequisitos • Visión del negocio y la organización • Alineación de los SI con la estrategia corporativa • El desarrollo de los SI tiene que ver con: • Necesidades de los involucrados • Requerimientos del usuario y estrategia de negocios

10. De la automatización de la rutina a los procesos críticos • La especificación de requerimientos debe atender a: • mejorar la gestión del cambio • integrar visiones dentro de la empresa • vincular la estrategia empresaria con los SI • ER como camino para gerenciar el cambio: • comprensión conceptual del status actual • definición del cambio • implementación del cambio • integración de esta nueva implementación

11. Requerimientos: Una Perspectiva del Software • Los errores en la definición de requerimientos resulta en un mantenimiento costo de los sistemas de software. • Surge la Ingeniería de Requerimientos como un sub-campo de la Ingeniería de Software

12. Importancia de los requerimientos • Premisa • Hacer un mejor trabajo definiendo y especificando software no sólo vale la pena sino que tambien es posible y ventajoso en costo • Soporte: • Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta repararlo • Muchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron • Los errores de requerimientos son comúnmente: hechos, incorrectos, omisiones, inconsistencias y ambigüedades • Los errores en los requerimientos pueden detectarse

13. PROBLEMA REAL especificación correcta especificación incorrecta Especificación deRequerimientos diseño basado en especificación incorrecta diseño correcto diseño incorrecto Diseño correcto Diseño programas basados en diseño incorrecto programas basados especificación incorrecta programas correctos errores de programación Implementación funciones correctas errores corregibles errores no corregibles errores ocultos Testing Errores corregibles Catarata de Errores de Mizuno

14. Impacto de los errores en la etapa de requerimientos • El software resultante puede no satisfacer a los usuarios • Las interpretaciones múltiples de los requerimientos pueden causar desacuerdos entre clientes y desarrolladores • Es imposible que a través del testeo el software satisfaga sus requerimientos • Puede gastarse tiempo y dinero construyendo el sistema erróneo

15. Evolución de Requerimientos Comprensión inicial del problema Cambios en la comprensión del problema Requerimientos Cambiados Requerimientos iniciales Tiempo

16. Clases de Requerimientos • Requerimientos Durables: son relativamente estables, derivan de las actividades centrales del negocio, los cuales se relacionan directamente con el dominio del sistema. • Requerimientos Volátiles: son aquellos que tienen probabilidad de cambiar durante el desarrollo del sistema o después que el sistema se haya puesto en producción.

17. Clasificación de Requerimientos Volátiles • Mutables: los requerimientos cambian debido al entorno en el cual la organización opera. • Emergentes:surgen con la comprensión de los clientes del sistema, durante su desarrollo. El diseño puede relevar nuevos requerimientos. • Consecuentes: resultan de la introducción del sistema de computación, cambiando los procesos del negocio y abriendo nuevas formas de trabajo que generan nuevos requerimientos • De Compatibilidad: dependen de un sistema o proceso en particular dentro del negocio, si cambian, los requerimientos relacionados deberán cambiar.

18. Especificación de Requerimientos • La documentación de Requerimientos para la construcción de Software es la actividad que tradicionalmente se ha llamado Especificación de Requerimientos. • La Especificación de Requerimientos representa ambos: un modelo de lo que se necesita y una definición del problema bajo consideración.

19. Especificación de Requerimientos Razones para esforzarse en su desarrollo.... • Focaliza el proceso comunicacional en la comprensión a cerca del dominio, el negocio y el sistema propuesto. • Puede ser parte de un arreglo contractual. • Puede usarse para la evaluación del producto final, y tener unrol crucial en las pruebas de aceptación del sistema.

20. Especificación de Requerimientos Una nueva visión para su desarrollo... Requerimientos Empresariales Especificación de Requerimientos Requerimientos No Funcionales Requerimientos Funcionales Evaluación

21. Requerimientos Funcionales • Relacionados con la descripción del comportamiento fundamental de los componentes del software. • Las funciones son especificacdas en términos de entradas, procesos y salidas. • Una vista dinámica podría considerar aspectos como el con trol, el tiempo de las funciones (de comienzo a fin) y su comportamiento en situaciones excepcionales.

22. Requerimientos No Funcionales • Juegan un papel crucial en el diseño y desarrollo del sistema de información. • Pueden definirse como consideraciones o restricciones asociadas a un servicio del sistema. • Sueles llamerse también requerimientos de calidad o no comportamentales en contraste con los comportamentales. • Pueden ser tan críticos con los funcionales.

23. Dificultades asociadas a los Requerimientos No Funcionales • No hay reglas ni lineamientos para determinar cuando se obtuvo una soluciónóptima. • Tiene buenas y malas soluciones, no soluciones correctas e incorrectas • Problemas relacionados con requerimientos no funcionales pueden ser síntomas de problemasmayores. • Hay dos atributos que deben poseer: deben ser objetivos y testeables.

24. Requerimientos No Funcionales: Tipos Requerimientos No Funcionales Requerimientos del Producto Requerimientos Organizacionales Requerimientos Externos Requerimientos de Eficiencia Requerimientos de Confiabilidad Requerimientos de Portabilidad Requerimientos Interoperatibidad Requerimientos Eticos Requerimientos de Usabilidad Requerimientos de Entrega Requerimientos de Entrega Requerimientos de Estándares Requerimientos Legales Requerimientos De Performance Requerimientos De Espacio Requerimientos de Privacidad Requerimientos de Seguridad

25. Ingeniería de Requerimientos “Es el proceso sistemático de desarrollar requerimientos a través de un proceso cooperativo e iterativo de analizar el problema, documentar las observaciones resultantes en una variedad de formatos de representación y chequear la precisión de la comprensión obtenida”

26. Representación, aspecto social y aspecto cognitivo De una formulación informal a una especificación formal Proceso no determinístico y no lineal Elicitar, especificar y validar requerimientos, no son actividades predominantemente técnicas Típica actividad de resolución de problemas. Características del proceso

27. Aspectos principales de la Ingeniería de Requerimientos Comprender el problema Describir el problema Acordar sobre la naturaleza del problema

28. Validación Especificación Elicitación Propuesta de laIngeniería de Requerimientos RASTREABILIDAD HACIA DELANTE Y HACIA ATRAS

29. Usuario Feedback del usuario Modelos a validar por el usuario Requerimientos del usuario Especificación de Requerimientos Elicitación Modelos de Requerimientos Conocimiento Validación Especificación Necesidad de más conocimiento Resultados de la validación Conocimiento del dominio Conocimiento del dominio Dominio del Problema Interacción entre Procesos de laIngeniería de Requerimientos

30. Productos entregables Modelos ... Del dominio del problema De los requerimientos funcionales De los requerimientos no funcionales

31. Elicitación: Propósito Ganar conocimiento relevante del problema, para producir una especificación rigurosa del software necesario para resolver el problema. Al final del proceso el analista podría ser un “experto” en el dominio del problema.

32. Elicitación: Entradas • Fuentes del conocimiento del dominio: • Expertos del dominio • Literatura sobre el dominio • Software existente en el dominio • Software similar en otros dominios • Standards nacionales e internacionales • Otros “involucrados”

33. Elicitación: Actividades • Tareas a encarar por el analista: • Identificar fuentes de conocimiento • Adquirir el conocimiento • Decidir sobre la relevancia de un conocimiento • Comprender la significación del conocimiento y su impacto

34. Elicitación: Actividades • Técnicas más usadas : • Entrevistas • Torbellino de Ideas • Escenarios • Reuso de conocimiento • Análisis de Documentación • Observación • Análisis de Objetivo / Meta

35. Elicitación: Productos • Es un proceso de creación de modelos • El analista comienza con modelos mentales con conocimiento dependiente del domino • Al avanzar, los modelos son más orientados al software • No se produce ningún modelo formal • Sucesión de modelos mentales del dominio del problema

36. Especificación: Propósito Acuerdo usuarios-desarrolladores sobre el problema a resolver Pauta para el desarrollo de un sistema de software

37. Especificación: Entradas Conocimiento sobre el dominio del problema Lo provee el proceso de elicitación

38. Especificación: Actividades Análisisy asimilación del conocimiento de los requerimientos Síntesis y organización del conocimiento en un modelo de requerimientos coherente y lógico

39. Especificación: Productos • Se producen una variedad de modelos: • modelos orientados al usuario, que especifican comportamiento, características no funcionales, etc. • modelos orientados al desarrollador, que especifican propiedades funcionales y no funcionales del software y restricciones

40. El Problema... A partir del Modelo de requerimientos se puede establecer que no contiene definiciones contradictorias, pero... Un modelo correcto de requerimientos no es necesariamente el modelo de requerimientoscorrecto. No existen los REQUERIMIENTOS de los requerimientos El peligro está en hacer el esfuerzo de analizar el problema erróneo.

41. Causas de los errores Dificultades en la elicitación de los requerimientos del usuario. Dificultad en establecer un esquema de comprensión común entre analista y usuario.

42. Validación: Propósito Certifica la consistencia del modelo (de requerimientos) con las intensiones de clientes y usuarios Ayuda a hacer el artefacto correcto La necesidad aparece cuando se modifica el modelo actual Se aplica también a los modelos intermedios

43. Validación: Entradas Todo modelo está sujeto a validación, por lo tanto cada modelo es input El conocimiento sobre el dominio del problema debe ser validado Algunas partes del modelo formal

44. Validación: Actividades • Interacción entre analistas, clientes del sistema y usuarios en el dominio del problema. • Similar a formular una nueva teoría científica y posteriormente testearla • Caracterizada por: • preparación del experimento • ejecución del experimento y análisis de los resultados

45. Validación: Técnicas Prototipos Animación Enfoque de Sistemas Expertos

46. Proceso de construcción y evaluación de modelos de trabajo de un sistema para aprender de ciertos aspectos del sistema requerido y/o su solución potencial. Técnica común de la ingeniería. En Ingeniería de Software: es el paradigma de producir software tan rápido y económicamente como sea posible en alguna etapa del desarrollo. Un modelo es considerado un prototipo si: es posible obtener información sobre el comportamiento y performance del sistema que se “prototipea” construir el prototipo debería ser un proceso rápido Prototipos

47. Prototipo de comportamiento, es un modelo en caja negra del sistema que muestra como responde a los estímulos. En un modelo funcional Prototipo estructural, muestra como el sistema “prototipeado” cumplirá con este comportamiento. Es un modelo de caja de cristal que muestra la estructura interna y la organización del sistema. Modela los requerimientos no funcionales Tipos de prototipos

48. Visión gráfica múltiple de un proceso en acción. Se representan gráficamente los principales objetos y se interactúa con ellos (tiempo real) En el contexto de desarrollo de IS es un enfoque que provee un ambiente visual para validar y ejecutar simbólicamente especificaciones conceptuales (en términos de modelos de entidades, reglas y procesos) de un IS. “En el contexto de especificaciones conceptuales, visualización involucra la animación del comportamiento de un sistema y una interfase visual que refleja los resultados de eventos bajo la componente gráfica -cuando es apropiado la textual- de la especificación” Animación

49. Ventaja sobre prototipos: no impone decisiones de diseño muy tempranas Provee una indicación de la dinámica del sistema mediante una recorrida Permite determinar relaciones causales escondidas en la especificación Animación: Características

50. Algunas herramientas CASE reciben el calificativo de sistemas expertos por el conocimientos de algunos aspectos del proceso que ellos corporizan. Este puede ser: conocimiento del método, conocimiento de cómo aplicar un método de RE conocimiento del dominio, conocimiento sobre el dominio el cual se supone se modeló Enfoque de sistemas expertos