Tema 1 Ingeniería de Requisitos

17,468 views

Published on

Introducción a la Ingeniería de Requisitos, Captura de requisitos, análisis de requisitos, validación y verificación de requsitos

Published in: Education
9 Comments
22 Likes
Statistics
Notes
No Downloads
Views
Total views
17,468
On SlideShare
0
From Embeds
0
Number of Embeds
2,036
Actions
Shares
0
Downloads
0
Comments
9
Likes
22
Embeds 0
No embeds

No notes for slide

Tema 1 Ingeniería de Requisitos

  1. 1. Análisis de Requisitos <ul><li>Curso 2008-09 Juan Carlos González Moreno </li></ul>
  2. 2. Introducción <ul><li>Ingeniería de Requisitos. </li></ul><ul><li>Modelos de Ciclo de Vida. </li></ul><ul><li>Proceso de desarrollo. </li></ul><ul><li>Metodologías de desarrollo. </li></ul><ul><li>Cliente y usuario. </li></ul>
  3. 3. Ingeniería de Requisitos <ul><li>Los requisitos del sistema definen lo que tiene que hacer el sistema y las circunstancias bajo las que debe operar . Tipos: </li></ul><ul><ul><li>Generales: Indican a “grosso modo” el objetivo del sistema. Ej: El sistema registra libros, periódicos, revistas y vídeos. </li></ul></ul><ul><ul><li>Funcionales: Definen parte de la funcionalidad del sistema. Ej: El sistema permitirá buscar un libro por título, autor o ISBN. </li></ul></ul><ul><ul><li>De Implementación: Indican como se construirá el sistema. Ej: La visualización se realizará utilizando el navegador Firefox. </li></ul></ul><ul><ul><li>De Rendimiento: Especifica atributos de espacio y/o tiempo. Ej: El sistema soportara un mínimo de 30 transacciones/segundo. </li></ul></ul><ul><ul><li>De Usabilidad: Indican el uso aceptable del sistema. Ej: Las utilidades se tienen que poder demostrar en < de 15 mn. </li></ul></ul>
  4. 4. Ingeniería de Requisitos <ul><li>La ingeniería de requisitos es el conjunto de actividades implicadas en descubrir, documentar y mantener un conjunto de requisitos . </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  5. 5. Ingeniería de Requisitos <ul><li>Observaciones: </li></ul><ul><ul><li>El coste de la fase de requisitos: 10-15 % del total </li></ul></ul><ul><ul><li>Corregir un requisito es 100 veces más caro que un error de programación </li></ul></ul><ul><ul><li>Los sistemas complejos conllevan miles de requisitos, por lo que es preciso un proceso y herramientas </li></ul></ul><ul><ul><li>Fallar en los requisitos es fallar en todo el proceso </li></ul></ul><ul><ul><li>Cuando se habla de requisitos no funcionales se está hablando de atributos de calidad del producto </li></ul></ul>
  6. 6. Documento de Requisitos
  7. 7. Proceso de Requisitos
  8. 8. Gestión de Requisitos
  9. 9. Captura de Requisitos <ul><li>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: </li></ul><ul><li>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. </li></ul><ul><li>Entrevistas: Existen diferentes tipos de entrevistas recomendadas, entre las que po demos mencionar: </li></ul><ul><ul><li>Entrevistas de Cuestionarios </li></ul></ul><ul><ul><li>Entrevistas de final abierto </li></ul></ul><ul><ul><li>Entrevistas en grupos de desarrollo </li></ul></ul><ul><ul><li>Discusiones </li></ul></ul>
  10. 10. Captura de Requisitos <ul><li>Entrevistas de Cuestionarios.- </li></ul><ul><li>Este tipo de entrevistas recomienda que se genere un cuestionario de preguntas , el cual será aplicado al cliente para comenzar la captura de requisitos. </li></ul><ul><li>Entrevistas de final abierto.- </li></ul><ul><li>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. </li></ul>
  11. 11. Captura de Requisitos <ul><li>Entrevistas en grupos de desarrollo.- </li></ul><ul><li>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. </li></ul><ul><li>Discusiones.- </li></ul><ul><li>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. </li></ul>
  12. 12. Captura de Requisitos <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  13. 13. Captura de Requisitos <ul><li>Una buena Especificación de Requisitos debe tener en cuenta las siguientes consideraciones: </li></ul><ul><ul><li>Naturaleza de la Especificación de Requisitos de Software.- Se deben especificar los siguientes aspectos: </li></ul></ul><ul><ul><ul><li>Funcionalidad </li></ul></ul></ul><ul><ul><ul><li>Interfaz Externa </li></ul></ul></ul><ul><ul><ul><li>Rendimiento </li></ul></ul></ul><ul><ul><ul><li>Atributos </li></ul></ul></ul><ul><ul><ul><li>Restricciones de diseño </li></ul></ul></ul><ul><ul><li>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. </li></ul></ul>
  14. 14. Captura de Requisitos <ul><li>Características de los Requisitos.- Los requisitos descritos deben ser: </li></ul><ul><ul><li>Completos </li></ul></ul><ul><ul><li>Implementación Independiente </li></ul></ul><ul><ul><li>Consistente y no Ambiguo </li></ul></ul><ul><ul><li>Preciso </li></ul></ul><ul><ul><li>Verificable </li></ul></ul><ul><ul><li>Que pueda ser leído </li></ul></ul><ul><ul><li>Modificable </li></ul></ul>
  15. 15. Captura de Requisitos <ul><li>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: </li></ul><ul><ul><li>Costo </li></ul></ul><ul><ul><li>Fecha de Entrega </li></ul></ul><ul><ul><li>Criterios de Validación y Verificación </li></ul></ul>
  16. 16. Captura de Requisitos <ul><li>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. </li></ul><ul><li>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. </li></ul>
  17. 17. Análisis de Requisitos <ul><li>El objetivo del análisis de requisitos es descubrir problemas en el borrador de requisitos generado durante su captura . </li></ul><ul><li>Tareas del análisis: </li></ul><ul><ul><li>Cuestionarse la necesidad de todos los requisitos </li></ul></ul><ul><ul><li>Investigar su consistencia y completitud </li></ul></ul><ul><ul><li>Asegurar su viabilidad: técnica, costes y planificación </li></ul></ul><ul><li>Procedimientos: </li></ul><ul><ul><li>Checklist </li></ul></ul><ul><ul><li>Matrices de interacción </li></ul></ul>
  18. 18. Negociación de Requisitos <ul><li>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 . </li></ul><ul><li>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 </li></ul><ul><ul><li>Tareas de la negociación: </li></ul></ul><ul><ul><ul><li>Discutir los requisitos conflictivos </li></ul></ul></ul><ul><ul><ul><li>Establecer prioridades en los requisitos </li></ul></ul></ul><ul><ul><ul><li>Compromiso final sobre el conjunto de requisitos </li></ul></ul></ul>
  19. 19. Validación de Requisitos <ul><li>La validación de requisitos consiste en comprobar que los requisitos son consistentes, completos y precisos . </li></ul><ul><li>Análisis vs. validación: </li></ul><ul><ul><li>En el análisis tenemos como entrada un conjunto incompleto de requisitos, en la validación un conjunto acordado de requisitos. </li></ul></ul><ul><ul><li>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? </li></ul></ul>
  20. 20. Validación de Requisitos <ul><li>El proceso puede ser visto como: </li></ul>
  21. 21. Validación de Requisitos <ul><li>Aproximaciones al proceso de validación: </li></ul><ul><ul><ul><li>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. </li></ul></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul>
  22. 22. Validación de Requisitos <ul><li>Aproximaciones al proceso de validación: </li></ul><ul><ul><ul><li>Prototipos.- Sólo tiene sentido si se desarrolla uno durante la fase de captura y se continua con él en el análisis. </li></ul></ul></ul>
  23. 23. Requisitos no funcionales
  24. 24. Problemas <ul><li>Los Problemas del proceso de análisis de requisitos </li></ul><ul><li>El primer problema que se presenta es la captura de los requisitos del usuario: </li></ul><ul><ul><li>De una manera sistemática y organizada. </li></ul></ul><ul><ul><li>Usando directrices o líneas guía. </li></ul></ul><ul><ul><li>Hacer los requisitos manejables y analizables. </li></ul></ul><ul><ul><ul><li>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é. </li></ul></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul>
  25. 25. Problemas <ul><li>Los Problemas del proceso de análisis de requisitos </li></ul><ul><li>El segundo problema es pasar a la fase de análisis, donde analizaremos los requisitos obtenidos para: </li></ul><ul><ul><li>comprenderlos , </li></ul></ul><ul><ul><li>desarrollar una especificación de la aplicación completa y consistente </li></ul></ul><ul><ul><li>expresarlos al menos semiformalmente . </li></ul></ul>
  26. 26. Problemas <ul><li>Los Problemas del proceso de análisis de requisitos </li></ul><ul><li>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 . </li></ul><ul><li>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é . </li></ul>
  27. 27. Problemas <ul><li>Los Problemas del proceso de análisis de requisitos </li></ul><ul><li>Durante el análisis y el diseño de la aplicación surgen nuevos problemas: </li></ul><ul><ul><li>La trazabilidad de los requisitos : cómo seguir un requisito de usuario por el análisis, el diseño y el código. </li></ul></ul><ul><ul><li>La mantenibilidad : cuando los requisitos evolucionen cómo podemos evolucionar el diseño y el código consistentemente con ello, y manteniendo la trazabilidad. </li></ul></ul>

×