Este documento presenta una introducción a la ingeniería de requisitos. Explica que los requisitos definen lo que el sistema debe hacer y las condiciones en que debe operar. Describe el proceso de ingeniería de requisitos, el cual incluye la identificación, análisis, especificación y validación de requisitos. También presenta varias técnicas como entrevistas, brainstorming y casos de uso para la recolección y modelado de requisitos.

1. Ingeniería de Requisitos MSc(c): Pablo Ruiz Fundación Universitaria de Popayán Septiembre 2011

2. Agenda Los requisitos de software Ingeniería de requisitos Técnicas de ingeniería de requisitos

4. ¿Qué son los requisitos? Un requisito es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo [IEEE] Una condición o capacidad que debe ser atendida por el sistema [RUP]. Algo que el sistema debe hacer o una cualidad que el sistema debe poseer [Robertson – Robertson].

5. Problemas Los usuarios no saben lo que quieren. Un sistema tiene muchos usuarios y ninguno tiene una visión de conjunto. No saben cómo hacer más eficiente la operación en su conjunto No saben qué partes de su trabajo pueden transformarse en software. No saben detallar lo que saben de forma precisa.

6. Solución tradicional: analistas Labores obtener una lista de requisitos de cada usuario adquirir una visión de conjunto componer una especificación completa, correcta y estable Desventajas listas de requisitos son difíciles de comprender y de hacer bien difíciles de transformar en especificaciones de diseño e implementación

7. Objetivos generales Enumerar los requisitos candidatos Comprender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales

8. Requisitos funcionales Definen lo que el sistema tiene que hacer, los servicios que debe proporcionar al usuario Describen la funcionalidad del sistema

9. Requisitos no funcionales Delimitan las condiciones en que el sistema presta servicios a los usuarios Velocidad de respuesta Ancho de banda requerido Espacio en memoria o en disco ....

10. Características de un Requisito Especificado por escrito: como todo contrato o acuerdo entre dos partes. Posible de probar y verificar. Si un requerimiento no se pude comprobar . Entontes ¿ Cómo se sabe que si se cumplió con él o no? Conciso: un requisito es conciso si es fácil de leer y entender. Su redacción debe ser simple para las personas que lo vayan a consultar en el futuro.

11. Completo: Un requisito es completo si no necesita ampliar detalles en su redacción, es decir se proporciona la información suficiente para su comprensión Consistente: Un requisito es consistente si no es contradictorio con otro requisito No ambiguo: Un requisito no es ambiguo cuando tienen una sola interpretación . El lenguaje usado en su definición no debe causar confusión al lector. Características de un Requisito

12. Agenda Los requisitos de software Ingeniería de requisitos Técnicas de ingeniería de requisitos

13. Ingeniería de Requisitos Ingeniería de Requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el clientequiere y cómo interactuarán los usuarios finales con el software. [Pressman]

14. Ingeniería de Requisitos Es el proceso mediante el cual se intercambian diferentes puntos de vistapara recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos. [Leite89] Definición de lo que se desea hacer o producir

15. Importancia de la ingeniería de Requisitos Permite gestionar las necesidades del proyecto en forma estructurada. Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultados. Disminuye los costos y retrasos del proyecto Mejora la calidad del software Mejora la comunicación entre equipos Evita rechazos de los usuarios finales

16. Ingeniería de Requisitos El proceso de ingeniería de requisitos puede ser descrito en 4 :

17. Identificación de Requisitos, I Elicitación de los requisitos El propósito de la elicitación de requisitos es ganar conocimientos relevantes del problema. En esta actividad es donde los analistas de requisitos deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver. Debe existir una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades Se debe descubrir los diferentes servicios que el sistema debe prestar y las restricciones .

18. Análisis Se trabaja sobre la base de la anterior actividad. Actividad la cual se enfoca a descubrir problemas con los requisitos del sistema identificados hasta el momento. Por lo general se hace un análisis luego de haber producido un bosquejo inicial del documento de requisitos. Se conceptúan los requisitos, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones

19. Especificación Se documentan los requisitos acordados con el cliente en un nivel apropiado de detalle. En la práctica esta actividad se va realizando conjuntamente con el análisis. Se pude decir que la especificación es el “pasar en limpio ” el análisis realizado previamente aplicando técnicas o estándares de documentación como UML.

20. Validación La validación es la actividad que certifica que el modelo de los requisitos es consistente con las intenciones de los clientes y los usuarios. Se verifica que los requisitos sean consistentes y que estén completos

21. Agenda Los requisitos de software Ingeniería de requisitos Técnicas de ingeniería de requisitos

22. Técnicas de ingeniería de Requisitos El análisis de requisitos siempre comienza con una comunicación entre dos o más partes. Un cliente tiene un problema al que puede encontrar una solución basada en computadora. El desarrollador responde a la petición del cliente. La comunicación ha comenzado. Pero,el camino entre la comunicación y el entendimiento está lleno de baches.

23. Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es fundamental conocer el dominio del problema. Mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades. Para conocer el dominio del problema se puede obtener información de fuentes externas al negocio del cliente Técnicas de ingeniería de Requisitos

24. Normalmente clientes y analistas se enfrascan en el proyecto de forma unilateral y no en equipo. Cada parte define su propio “territorio” Este enfoque no es muy efectivo, abundan los malentendidos, se pierde información importante y nunca se establece una relación de trabajo satisfactoria. Técnicas de ingeniería de Requisitos

25. Con los anteriores problemas, se han desarrollado numerosas técnicas para tratar de superarlos Cada técnica puede aplicarse en una o más actividades de la ingeniería de requerimientos; en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose. Técnicas de ingeniería de Requisitos

26. Entrevistas Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo. En las entrevistas se pueden identificar claramente tres fases [Piattini]: preparación, realización y análisis

27. Preparación de entrevistas: Las entrevistas no deben improvisarse, por lo que conviene realizar las siguiente tareas previas: Estudiar el dominio del problema Seleccionar a las personas a las que se va a entrevistar(top–down) Determinar el objetivo y contenido de las entrevistas Planificar las entrevistas Entrevistas

28. Realización de entrevistas: se distinguen tres etapas [Piattini]: Apertura Desarrollo Terminación Análisis de las entrevistas Reorganizar la información, contrastarla con otras entrevistas o fuentes de información. Validar con el entrevistado para confirmar los contenidos. Entrevistas

29. Brainstorming El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios [Raghavan]. Las sesiones de brainstormingformadas de cuatro a diez participantes, uno de los cuales es el jefe de la sesión.

30. Fases del brainstorming Preparación Selección de participantes Preparación logística Generación Jefe de proyecto expone un enunciado general del problema , que hace de semilla para que se generen ideas. Los participantes generan nuevas ideas de forma aleatoria Reglas Se prohíbe la critica de ideas Se fomentan las ideas más avanzadas y se estimula a los participantes a generar nuevas ideas Se debe generar un gran número de ideas, Se debe alentar a los participantes a combinar o completar las ideas de otros participantes

31. Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos: Revisar ideas: se revisan para clarificarlas Descartar ideas. Priorizar ideas. Documentación: el jefe produce la documentación oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidación. Fases del brainstorming

33. Los Casos de Uso facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. Sirven de base a las pruebas del sistema y a la documentación para los usuarios. Los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema Se escriben, generalmente, en lenguaje natural No hay descripción interna del sistema, solo la interacción con el mismo Casos de Uso

34. Casos de Uso Ventajas y desventajas Caracterización detallada de todas las posibles interacciones con el sistema Ayuda en el dibujo de los límites del sistema, y con el alcance de los requerimientos Los casos de uso no captura en dominio del conocimiento Un caso de uso no es especificación precisa, solo es la representación de un problema puntual

36. Identificar los actores fuera de los límites del sistema que interactúan con él

37. Para cada actor

38. Identificar los posibles casos de uso

39. Establecer escenarios concretos para ilustrar cada caso de uso

41. Escribirlo

42. Especificar reglas para elección del mismo y para interactuar con él

43. Considerar alternativas

44. Ver posibles superposiciones de casos de usoTemplate de caso de uso: Nombre:Resumen:Actores:Precondiciones:Descripciones:Excepciones:Postcondiciones:

46. Precondición: un usuario válido está conectado al sistema

48. En el paso 9, si hay información incorrecta, el sistema le preguntará al cliente que quiso poner

49. Postcondiciones:

51. Los Casos de Uso y UML La notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML y fue avalada por las principales empresas que desarrollan software en el mundo. La mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno