El documento aborda el análisis y la ingeniería de requisitos en el desarrollo de software, explicando tipos de requisitos, procesos de captura, análisis, negociación y validación. Se hace hincapié en la importancia de especificaciones claras y en la gestión de cambios para asegurar la calidad del sistema. Además, se discuten problemas comunes en el proceso de análisis y la necesidad de trazabilidad y mantenibilidad de los requisitos.

1. Análisis de Requisitos Curso 2008-09 Juan Carlos González Moreno

2. Introducción Ingeniería de Requisitos. Modelos de Ciclo de Vida. Proceso de desarrollo. Metodologías de desarrollo. Cliente y usuario.

3. Ingeniería de Requisitos Los requisitos del sistema definen lo que tiene que hacer el sistema y las circunstancias bajo las que debe operar . Tipos: Generales: Indican a “grosso modo” el objetivo del sistema. Ej: El sistema registra libros, periódicos, revistas y vídeos. Funcionales: Definen parte de la funcionalidad del sistema. Ej: El sistema permitirá buscar un libro por título, autor o ISBN. De Implementación: Indican como se construirá el sistema. Ej: La visualización se realizará utilizando el navegador Firefox. De Rendimiento: Especifica atributos de espacio y/o tiempo. Ej: El sistema soportara un mínimo de 30 transacciones/segundo. De Usabilidad: Indican el uso aceptable del sistema. Ej: Las utilidades se tienen que poder demostrar en < de 15 mn.

4. Ingeniería de Requisitos La ingeniería de requisitos es el conjunto de actividades implicadas en descubrir, documentar y mantener un conjunto de requisitos . Un proceso de ingeniería de requisitos es un conjunto estructurado de actividades de cuya ejecución se obtiene, valida y mantiene el documento de requisitos del sistema. El proceso define las actividades a realizar, su secuencia, entradas y salidas de cada actividad, etc. La gestión de requisitos es una actividad encargada de gestionar los cambios en los requisitos del sistema . La gestión implica el control de cambios y el impacto de los mismos.

5. Ingeniería de Requisitos Observaciones: El coste de la fase de requisitos: 10-15 % del total Corregir un requisito es 100 veces más caro que un error de programación Los sistemas complejos conllevan miles de requisitos, por lo que es preciso un proceso y herramientas Fallar en los requisitos es fallar en todo el proceso Cuando se habla de requisitos no funcionales se está hablando de atributos de calidad del producto

6. Documento de Requisitos

7. Proceso de Requisitos

8. Gestión de Requisitos

9. Captura de Requisitos Es un proceso en el cual los datos son extraídos de las personas pudiendo variar, dependiendo de la persona consultada . La Ingeniería de Requisitos ha trabajado arduamente para tratar de desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y segura: Introspección: Esta técnica recomienda que el ingeniero de requisitos se ponga en el lugar del cliente y trate de imaginar como desearía él el Sistema. Entrevistas: Existen diferentes tipos de entrevistas recomendadas, entre las que po demos mencionar: Entrevistas de Cuestionarios Entrevistas de final abierto Entrevistas en grupos de desarrollo Discusiones

10. Captura de Requisitos Entrevistas de Cuestionarios.- Este tipo de entrevistas recomienda que se genere un cuestionario de preguntas , el cual será aplicado al cliente para comenzar la captura de requisitos. Entrevistas de final abierto.- Este tipo de entrevistas son del tipo que realizan los psicólogos. La idea es que el ingeniero de requisitos permita que el Cliente le vaya narrando su problemática y el ingeniero de Software lo guíe a través de la narración para ir determinando los requisitos del sistema.

11. Captura de Requisitos Entrevistas en grupos de desarrollo.- Este tipo de entrevistas recomienda formar grupos específicos con el personal del cliente . Estos grupos tendrán en común algún área de trabajo o especialidad. El objetivo es poder contar con los expertos en cierta área de la empresa para poder llegar en conjunto a la especificación de requisitos. Discusiones.- Este tipo de entrevistas pretende que el Ingeniero de Requisitos sostenga una discusión con el Cliente sobre su problemática para tratar de determinar en conjunto los requisitos del sistema.

12. Captura de Requisitos Análisis de Protocolo: Esta técnica parte de la idea de que el cliente cuenta con un modelo mental preexistente del sistema deseado. Se enfrenta al “experto “ con un caso real y se observa como lo resuelve (establecimiento del protocolo), preguntando y anotando las dudas. Casos de Uso: Es una técnica bastante utilizada que &quot; captura cada una de las funciones del sistema &quot; y en base a cada una de ellas especifica sus requisitos. VORD: Esta técnica es utilizada para capturar requisitos en base a puntos de vista . Es utilizado en sistemas que van a ser desarrollados con el paradigma de programación orientados a objetos.

13. Captura de Requisitos Una buena Especificación de Requisitos debe tener en cuenta las siguientes consideraciones: Naturaleza de la Especificación de Requisitos de Software.- Se deben especificar los siguientes aspectos: Funcionalidad Interfaz Externa Rendimiento Atributos Restricciones de diseño Ambiente de la Especificación de Requisitos.- Debe de estar descrita de tal manera que no describa aspectos del área de diseño o de implementación.

14. Captura de Requisitos Características de los Requisitos.- Los requisitos descritos deben ser: Completos Implementación Independiente Consistente y no Ambiguo Preciso Verificable Que pueda ser leído Modificable

15. Captura de Requisitos Aprobación del Cliente o patrocinador.- Todos los requisitos descritos deben contar con ella. Un punto importante a tener en cuenta es la &quot;evolución&quot; de los mismos y proveer mecanismos que permitan la Evolución de la Especificación de Requisitos, e incluir requisitos del Proyecto en la Especificación de Requisitos. Requisitos tales como: Costo Fecha de Entrega Criterios de Validación y Verificación

16. Captura de Requisitos En general las fases de captura y análisis de requisitos de usuario han recibido poca atención por parte de las metodologías de desarrollo de software. La transición a las fases de diseño, cuando se utilizan metodologías de orientación a objetos, así como la trazabilidad de los requisitos a lo largo de éste proceso, son también aspectos poco soportados por éstas.

17. Análisis de Requisitos El objetivo del análisis de requisitos es descubrir problemas en el borrador de requisitos generado durante su captura . Tareas del análisis: Cuestionarse la necesidad de todos los requisitos Investigar su consistencia y completitud Asegurar su viabilidad: técnica, costes y planificación Procedimientos: Checklist Matrices de interacción

18. Negociación de Requisitos La negociación de requisitos es el proceso de discutir los conflictos encontrados y llegar a algún compromiso que satisfaga a todos los usuarios . Ej: En el desarrollo de cierta aplicación para una empresa el departamento de ventas quiere tener acceso total a los recursos almacenados y a la lista de clientes, mientras que el de seguridad quiere controlar dichos recursos y permitir sólo un acceso restringido Tareas de la negociación: Discutir los requisitos conflictivos Establecer prioridades en los requisitos Compromiso final sobre el conjunto de requisitos

19. Validación de Requisitos La validación de requisitos consiste en comprobar que los requisitos son consistentes, completos y precisos . Análisis vs. validación: En el análisis tenemos como entrada un conjunto incompleto de requisitos, en la validación un conjunto acordado de requisitos. En el análisis nos preguntamos si ¿los requisitos satisfacen las necesidades del cliente? o ¿tengo los requisitos adecuados? en la validación sin embargo las preguntas más frecuentes son ¿están bien descritos los requisitos? o ¿el documento de requisitos representa claramente el sistema?

20. Validación de Requisitos El proceso puede ser visto como:

21. Validación de Requisitos Aproximaciones al proceso de validación: Revisión de requisitos.- Un grupo de personas lee, analiza y discute el documento de requisitos. Se sigue un procedimiento similar al de inspección de código. Test de requisitos.- Es deseable diseñar pruebas sobre cada requisito individual. Dificultades a la hora de diseñar casos de test para un requisito puede implicar ambigüedad del mismo o falta de información.

22. Validación de Requisitos Aproximaciones al proceso de validación: Prototipos.- Sólo tiene sentido si se desarrolla uno durante la fase de captura y se continua con él en el análisis.

23. Requisitos no funcionales

24. Problemas Los Problemas del proceso de análisis de requisitos El primer problema que se presenta es la captura de los requisitos del usuario: De una manera sistemática y organizada. Usando directrices o líneas guía. Hacer los requisitos manejables y analizables. Una vez conseguidos los requisitos, pasamos a la fase de análisis. En ella, lo que haremos es analizar los requisitos obtenidos de los usuarios con el fin de comprenderlos, y a partir de ellos desarrollar una especificación de la aplicación, que deberá ser completa y consistente, y deberá estar expresada de una manera al menos semiformal, no simplemente textual. En este proceso, encontraremos habitualmente gran cantidad de problemas en los requisitos, areas no especificadas, requisitos contradictorios, y afirmaciones (aparentemente) vagas e irrelevantes. Eso nos llevará de vuelta a los usuarios con el fin de mejorar la calidad de los requisitos: pero debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y el por qué. Después de obtener una buena lista de requisitos, comenzamos con el análisis y el diseño de la aplicación, y entonces nos surgen nuevos problemas: el primero es la trazabilidad de los requisitos: cómo seguir un requisito de usuario por el análisis, el diseño y el código, que nos permita comprobar que el requisito ha sido tenido en cuenta y cómo lo ha sido. Y esto enlaza directamente con el problema de la mantenibilidad: cuando los requisitos comienzan a evolucionar -como sin duda lo harán-, cómo podemos ir evolucionando el diseño y el código consistentemente con ello, y cómo seguir manteniendo la trazabilidad.

25. Problemas Los Problemas del proceso de análisis de requisitos El segundo problema es pasar a la fase de análisis, donde analizaremos los requisitos obtenidos para: comprenderlos , desarrollar una especificación de la aplicación completa y consistente expresarlos al menos semiformalmente .

26. Problemas Los Problemas del proceso de análisis de requisitos Además en este proceso, encontraremos habitualmente gran cantidad de fallos en los requisitos: áreas no especificadas, requisitos contradictorios, y afirmaciones (aparéntemente) vagas e irrelevantes . Eso nos llevará de vuelta a los usuarios a los que debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y por qué .

27. Problemas Los Problemas del proceso de análisis de requisitos Durante el análisis y el diseño de la aplicación surgen nuevos problemas: La trazabilidad de los requisitos : cómo seguir un requisito de usuario por el análisis, el diseño y el código. La mantenibilidad : cuando los requisitos evolucionen cómo podemos evolucionar el diseño y el código consistentemente con ello, y manteniendo la trazabilidad.