Análisis e Ingeniería de Requisitos Tema 2

Transcripción

1 Análisis e Ingeniería de Requisitos Tema 2: Introducción a la Ingeniería de Requisitos Curso

2 Bibliografía Básica Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill, ª Ed. Ingeniería del Software. Ian Sommerville,Addison Wesley, 2004ª Ed. Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Piattini et al., RA-MA, AIR - 2

3 Índice de Transparencias Introducción Definiciones: conceptos fundamentales de la Ingeniería de Requisitos. Requisitos: Características, niveles y tipos Procesos de Desarrollo de Requisitos Identificación de Requisitos Análisis de Requisitos Especificación de Requisitos Validación de Requisitos AIR - 3

4 Introducción: Definiciones Requisito: Los requisitos describen los servicios que debe proporcionar el sistema y sus restricciones operativas. Propiedad que debe ser exhibida por un software para resolver un problema particular (SWEBOK). AIR - 4

5 Introducción: Definiciones Ingeniería de Requisitos: Es el proceso para descubrir, analizar, documentar y verificar los servicios que debe proporcionar el sistema y sus restricciones. Especificación de Requisitos: Es el documento que define, de forma completa, precisa y verificable, los requisitos del sistema. AIR - 5

6 Introducción: Definiciones Proceso de Ingeniería de Requisitos: Conjunto estructurado de actividades de cuya ejecución se obtiene, valida y mantiene el documento de requisitos del sistema Gestión de Requisitos: Actividad para gestionar los cambios en los requisitos de un sistema AIR - 6

7 Requisitos Los requisitos son una etapa clave en el ciclo de vida: Su coste es alrededor de 10-15% del coste total del proyecto. Un error en los requisitos puede ser hasta 100 veces más costoso que un error en el código. Una equivocación en la etapa de requisitos se arrastra en las demás fases del ciclo de vida. Los procesos/sistemas complejos implican miles de requisitos Necesidad de gestión y soporte automatizado AIR - 7

8 Requisitos Los requisitos de un software suelen ser una combinación compleja de los requisitos de diferentes personas en diferentes niveles de una organización y del entorno en el cual operará el software. Es fundamental que un requisito sea verificable, que tengan una prioridad, que esté identificado quien ha sido el que lo ha solicitado, etc. Los requisitos deben ser lo más claros y no ambiguos que se pueda, y cuantificables (si es posible). AIR - 8

9 Requisitos Pueden haber problemas con los requisitos: No reflejan las necesidades reales del cliente Son inconsistentes y/o incompletos Es costoso realizar cambios sobre los requisitos una vez que han sido acordados Puede haber malentendidos entre clientes, analistas, ingenieros software, etc. AIR - 9

10 Requisitos AIR - 10

11 Requisitos AIR - 11

12 Requisitos Niveles de Requisitos Los requisitos se pueden definir a distintos niveles de abstracción o detalle. Un requisito puede ser una simple declaración abstracta de alto nivel o bien una definición detallada y formal de una función del sistema. Es necesario hacer una separación entre niveles de descripción. AIR - 12

13 Requisitos AIR - 13

14 Requisitos Requisitos del Usuario: descripciones, en lenguaje natural o diagramas, de lo que se espera que el sistema proporcione y las restricciones bajo las cuales debe funcionar. Requisitos del Sistema: establecen con detalle las funciones, servicios y restricciones operativas del sistema. Deben ser precisos. Definir exactamente qué es lo que se va a implementar. Puede ser parte del contrato entre el comprador y el desarrollador. AIR - 14

15 Requisitos Lectores de los diferentes tipos de requisitos: Requisitos de usuario: Administradores clientes Usuarios finales del sistema Ingenieros clientes Administradores contratistas Arquitectos del sistema Requisitos del sistema (necesitan saber con más precisión qué hará el sistema): Usuarios finales del sistema Ingenieros clientes Arquitectos del sistema Desarrolladores del software AIR - 15

16 Tipos de Requisitos Tipos de Requisitos Requisitos del Usuario (descripción de alto nivel) Requisitos del Sistema (descripción detallada) Requisitos Funcionales Requisitos No Funcionales: Requisitos Del Producto Requisitos Organizacionales Requisitos Externos Requisitos De Dominio AIR - 16

17 Tipos de Requisitos Ejemplo: Requisitos de Usuario: 1. El sistema (LIBSYS) controlará todos los datos requeridos por las agencias que licencian los derechos de autor en el Reino Unido y en otra parte. Requisitos del sistema: 1.1 Al hacer una petición de un documento del LIBSYS, el solicitante se presentará con un formulario que registre los detalles del usuario y la petición hecha. 1.2 El formulario de petición del LIBSYS será almacenado en el sistema durante cinco años desde la fecha de petición. 1.3 Todos los formularios de petición del LIBSYS se deben indexar por usuario, por el nombre del material solicitado y por el proveedor de la petición. 1.4 El LIBSYS mantendrá un fichero en el que se registrarán todas las peticiones que se han hecho al sistema. 1.5 Para el material donde se aplican los derechos de préstamo del autor, los detalles del préstamos serán enviados mensualmente a las agencias que licencian los derechos de autor que se han registrado en el LIBSYS. AIR - 17

18 Tipos de Requisitos Requisitos de usuario: Los requisitos de usuario pueden responder a varios orígenes: Dominio del problema (Requisitos de Dominio) Intereses de la organización (Requisitos de Negocio u Organizacionales) Necesidades de los usuarios finales del software. AIR - 18

19 Tipos de Requisitos Requisitos del sistema: Requisitos Funcionales: Son declaraciones de los servicios que debe proporcionar el sistema. Especifica la manera en que éste debe reaccionar a determinadas entradas. Especifica cómo debe comportarse el sistema en situaciones particulares. Pueden declarar explícitamente lo que el sistema no debe hacer. AIR - 19

20 Tipos de Requisitos Ejemplo: Requisitos Funcionales 1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. 2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos. 3. A cada pedido se le deberá asignar un identificar único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento AIR - 20

21 Tipos de Requisitos Requisitos del sistema: Requisitos No Funcionales: No se refieren a funciones específicas que proporciona el sistema. Son restricciones de los servicios o funciones ofrecidas por el sistema (fiabilidad, tiempo de respuestas, capacidad de almacenamiento, etc.) Generalmente se aplican al sistema en su totalidad. Surgen de las necesidades del usuario debido a restricciones de presupuesto, políticas de la organización, necesidad de interoperatividad, etc. AIR - 21

22 Tipos de Requisitos Requisitos del sistema: Requisitos No Funcionales: A veces, no hay una distinción clara entre requisitos funcionales y no funcionales Expresar un requisito como funcional o no funcional depende del nivel de detalle requerido en el documento de requisitos. Ejemplo: El sistema asegurará que los datos son protegidos de accesos no autorizados Generalmente sería considerado como un requisito no funcional porque el requisito no se refiere a una funcionalidad específica del sistema El sistema incluirá un procedimiento de autorización de usuario en el que los usuarios se identifican mediante un nombre de usuario y una contraseña. Sólo los usuarios autorizados pueden acceder a los datos del sistema El requisito especifica con más detalle una función que debe ser incorporada en el sistema - > Requisito Funcional AIR - 22

23 Tipos de Requisitos Requisitos No Funcionales: Requisitos Del Producto: Especifican el comportamiento del producto. Ejemplos: rapidez de la ejecución, capacidad de memoria, fiabilidad, etc. Requisitos Organizacionales: Derivan de políticas y procedimientos existentes en la organización del cliente y del desarrollador. Ejemplos: Estándares de procesos, métodos de diseño, lenguajes de programación, métodos de entrega, etc. Requisitos Externos: Se derivan de factores externos al sistema y a su proceso de desarrollo. Ejemplos: Requisitos de interoperatividad, legislativos, éticos, etc. AIR - 23

24 Tipos de Requisitos Ejemplo: Requisitos No Funcionales Requerimiento del producto: 8.1 La interfaz de usuario del LIBSYS se implementará como HTML simple sin marcos o aplets Java. Requerimiento organizacional: El proceso de desarrollo del sistema y los documentos a entregar deberán ajustarse al proceso y a los productos a entregar definidos en XYZCo-SP-STAN-95 Requerimiento externo: 10.6 El sistema no deberá revelar al personal de la biblioteca que lo utilice ninguna información personal de los usuarios del sistema aparte de su nombre y número de referencia de biblioteca. AIR - 24

25 Tipos de Requisitos AIR - 25

26 Tipos de Requisitos Requisitos No Funcionales de Producto Especifican Restricciones en la Ejecución del Sistema Parte de estos requisitos se pueden formular de forma precisa, de forma que puedan ser fácilmente cuantificables: Rendimiento Capacidad Otros son más difíciles de cuantificar y por lo tanto se expresan generalmente de modo informal Usabilidad AIR - 26

27 Tipos de Requisitos Ejemplo: Requisitos No Funcionales de Producto Fiabilidad: El servicio A del Sistema debe tener una disponibilidad de 99 % Rendimiento: El Sistema Y procesará un mínimo de 8 transacciones por segundo Espacio: El código ejecutable del Sistema Z estará limitado a 512 Kb Portabilidad: El Sistema se desarrollará para las plataformas PC y Macintosh Seguridad: El Sistema encriptará todas las comunicaciones externas usando el algoritmo RSA AIR - 27

28 Tipos de Requisitos Requisitos No Funcionales Organizacionales Son restricciones en el proceso de desarrollo del Sistema. También llamados requisitos No Funcionales de Proceso. Ejemplos: Estándares y Métodos de Desarrollo Herramientas a usar Producción de Informes El proceso de desarrollo debe ser conforme con ISO El Sistema debe desarrollarse usando la Herramienta Visual Paradigm. Los informes de Gestión sobre el esfuerzo dedicado a cada componente se deben generar cada dos semanas. AIR - 28

29 Tipos de Requisitos Requisitos No Funcionales Externos Están relacionados con el entorno. Se pueden aplicar a Producto y Proceso Ejemplos: Sistema Médico: El responsable de la protección de datos de la organización debe certificar que todos los datos se mantienen de acuerdo a la legislación vigente Sistema Protección de Trenes: El tiempo requerido para detener completamente el tren se basa en la siguiente ecuación de deceleración: γtren = γcontrol + γgradiente AIR - 29

30 Tipos de Requisitos Los Requisitos No Funcionales son especialmente importantes en Sistemas Críticos Es decir, aquellos cuyos fallos causan un daño significativo de tipo económico, físico o humano a las organizaciones o personas. Ejemplos: Negocio: Sistema reserva aerolínea Misión: Sistema de control de órbita de un satélite Seguridad Física o Humana: Sistema de Control Central Nuclear Sistema médico de control de radiación para tratamiento de Cáncer Los principales RNF en estos sistemas son: Fiabilidad, Rendimiento, Seguridad, Usabilidad, Seguridad Física AIR - 30

31 Tipos de Requisitos Requisitos del sistema: Requisitos de Dominio: Provienen del dominio de aplicación del sistema. Reflejan características y restricciones del dominio de la aplicación. Pueden ser funcionales o no funcionales. AIR - 31

32 Tipos de Requisitos Ejemplo: Requisitos de Dominio 1. Deberá existir una interfaz de usuario estándar para todas las bases de datos que estará basada en el estándar Z Debido a las restricciones en los derechos de autor, algunos documentos deberán borrarse inmediatamente después de su llegada. Dependiendo de los requerimientos del usuario, estos documentos se imprimirán de forma local en el servidor del sistema para ser distribuidos de forma manual al usuario o se enviarán a la impresora. AIR - 32

33 Tipos de Requisitos Ejercicio 1: Un sistema automático de expedición de billetes vende billetes de tren. Los usuarios seleccionan su destino e introducen una tarjeta de crédito y un número de identificación personal. El billete de tren se expide y se carga a su cuenta de la tarjeta de crédito. Cuando el usuario presiona el botón de inicio, se activa un menú que muestra los posibles destinos, junto con un mensaje para el usuario que le indica que seleccione el destino. Una vez que se ha seleccionado el destino, se pide a los usuarios que introduzcan su tarjeta de crédito. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transacción de crédito se haya validado, se le expide el billete. 1. Redacte un conjunto de requisitos funcionales para el sistema expendedor de billetes. 2. Redacte un conjunto de requisitos no funcionales para el sistema expendedor de billetes. Indicando su tipo. 3. Redacte un conjunto de requisitos de dominio para el sistema expendedor de billetes. AIR - 33

34 Tipos de requisitos Otras clasificaciones de requisitos: De producto vs. De Proceso De Producto: Son los requisitos propiamente en el software a desarrollar. Ejemplo: El software verificará que un estudiante ha superado todos los pre-requisitos antes de dejarle matricularse en una asignatura. De Proceso Esencialmente son restricciones sobre la manera en que se desarrolla el software. Ejemplos: El software se escribirá en Ada, Se utilizará METRICA 3 como metodología. AIR - 34

35 Tipos de Requisitos Ejercicio 2: 1. Identificar los requisitos funcionales y especificar cada requisito con la siguiente estructura: Requisitos Funcionales: Requisito Funcional 1 Introducción Entradas Procesamiento Salidas Requisito Funcional 2 Requisito Funcional 3 AIR - 35

36 Tipos de Requisitos Ejercicio 3: 1. Identificar los requisitos funcionales y especificar cada requisito con la siguiente estructura: Requisitos Funcionales: Requisito Funcional 1 Introducción Entradas Procesamiento Salidas Requisito Funcional 2 Requisito Funcional 3 AIR - 36

37 Índice de Transparencias Introducción Definiciones: conceptos fundamentales de la Ingeniería de Requisitos. Requisitos: Características, niveles y tipos Procesos de Desarrollo de Requisitos Identificación de Requisitos Análisis de Requisitos Especificación de Requisitos Validación de Requisitos AIR - 37

38 Introducción: Definición de Ingeniería de Requisitos Qué es la Ingeniería de Requisitos? Es el proceso para descubrir, analizar, documentar y verificar los servicios que debe proporcionar el sistema y sus restricciones. Se define un proceso. Dicho proceso facilita la comprensión de lo que quiere el cliente, mediante la realización de ciertas actividades: Analizando sus necesidades Confirmando su viabilidad Negociando la solución Especificando la solución sin ambigüedad Validando y Gestionando requisitos para que el sistema pueda ser operativo. AIR - 38

39 Proceso de Desarrollo de Requisitos Objetivo: Crear y mantener un documento de requisitos del sistema (ERS). Define el conjunto estructurado de actividades de cuya ejecución se obtiene y mantiene la especificación de los requisitos. El proceso de desarrollo (ingeniería) de requisitos puede variar según la metodología seguida y el dominio de aplicación. En general, se distinguen las siguientes etapas: 1. Identificación, elicitación o captura de requisitos 2. Análisis (y negociación) de requisitos 3. Especificación o documentación de requisitos 4. Validación de requisitos 5. (Gestión de requisitos) AIR - 39

40 Proceso de Desarrollo de Requisitos Desarrollo de requisitos vs. Gestión de requisitos AIR - 40

41 Proceso de Desarrollo de Requisitos AIR - 41

42 Proceso de Desarrollo de Requisitos AIR - 42

43 Proceso de Desarrollo de Requisitos Actores del proceso: El proceso de ingeniería de requisitos está dominado por factores humanos, sociales y organizacionales Implican diferentes stakeholders de diferentes procedencias y perfiles, y con distintos objetivos. AIR - 43

44 Proceso de Desarrollo de Requisitos Actores del proceso: Stakeholders: persona o grupo que se verá afectado por el sistema, directa o indirectamente. Usuarios finales del sistema. Clientes Gerentes Expertos en el dominio Reguladores externos Representantes de trabajadores Encargados de mantenimiento de sistemas relacionados Ingenieros de software Etc. AIR - 44

45 Proceso de Desarrollo de Requisitos Ejemplo: Stakeholders del sistema para un cajero automático (ATM) de un banco 1. Los clientes actuales del banco quienes reciben los servicios del sistema. 2. Los representantes de otros bancos quienes tienen acuerdos recíprocos que les permiten utilizar otros ATMs. 3. Los directores de las sucursales bancarias quienes obtienen información del sistema. 4. El personal de ventanilla de las sucursales bancarias quienes están relacionados con el funcionamiento diario del sistema. 5. Los administradores de la base de datos quienes son responsables de integrar el sistema con la base de datos de clientes del banco. 6. Los administradores de seguridad del banco quienes deben asegurar que el sistema no suponga un riesgo de seguridad. 7. Las personas del departamento de marketing del banco quienes probablemente estén interesadas en utilizar el sistema como un medio para promocionar al banco. 8. Los ingenieros de mantenimiento de hardware y software quienes son responsables de mantener y actualizar el hardware y el software. 9. Los reguladores de la banca nacional quienes son los responsables de asegurar que el sistema se ajusta a las regulaciones de la banca. AIR - 45

46 Proceso de Desarrollo de Requisitos AIR - 46

47 Proceso de Desarrollo de Requisitos Identificación o captura de requisitos En esta etapa los ingenieros de software trabajan con los clientes y los usuarios finales del sistema. Determinar: el dominio de la aplicación qué servicios debe proporcionar el sistema rendimiento requerido del sistema restricciones de hardware etc. AIR - 47

48 Proceso de Desarrollo de Requisitos Análisis de requisitos: Una vez recopilados los requisitos: Se agrupan por categorías y se organizan Se estudia cada requisito en relación con el resto Se examina la consistencia, completitud y ambigüedad de los requisitos Se clasifican en base a las necesidades de los clientes/usuarios (negociación) Negociación de requisitos: Los clientes, usuarios y resto de los implicados deberán clasificar sus requisitos y discutir posibles conflictos Priorizar requisitos Compromiso final sobre el conjunto de requisitos a implementar AIR - 48

49 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos La captura y análisis de requisitos es un proceso complejo y de vital importancia. Implica: Comprender el dominio de la aplicación Comprender el problema en cuestión Comprender el contexto del negocio Comprender las necesidades y restricciones de los usuarios finales AIR - 49

50 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Problemas a la hora de hacer una captura de requisitos: Problemas de Alcance: Límites del sistema mal definidos Detalles técnicos innecesarios proporcionados por los clientes/usuarios No están claros los objetivos del sistema Problemas de Comprensión: Los clientes no están seguros de lo que necesitan Los clientes no entienden totalmente el dominio del problema Dificultades para comunicar las necesidades Omisión de información por considerar que es obvia Especificación de requisitos ambiguos, poco estables o contradictorios Problemas de volatilidad: Los requisitos que cambian con el tiempo AIR - 50

51 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Para la recopilación y análisis de requisitos se seguirán, en general, 5 pasos: Identificar las fuentes de información y planificar las actividades de investigación Realizar las preguntas apropiadas (comprender necesidades) Analizar la información (detectar puntos no claros) Confirmar con los usuarios (lo que parece haberse comprendido) Sintetizar los requisitos (especificación de requisitos) AIR - 51

52 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Fuentes de Información Los requisitos se originan a partir de: Objetivos (intereses de negocio, factores críticos de éxito): proveen la motivación para realizar el software, pero suelen ser ambiguos. Documentación existente: Permite al ingeniero conocer los datos e información con los que se trabaja en la organización. Conocimiento del Dominio: Permite al ingeniero inferir conocimiento tácito que los stakeholders no articulan. Interesados (stakeholders): El ingeniero necesita identificar, representar y gestionar los puntos de vista de los diferentes tipos de interesados. Entorno operacional: el entorno en el que se ejecutará el software. Ej. Otros sistemas que operan en la organización. Entorno organizacional: El ingeniero debe ser sensible a la estructura, cultura y políticas de la organización, así como a los procesos de negocio a los que dará soporte el software. Ej. Normas, procedimientos, etc. AIR - 52

53 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Principales técnicas de captura y análisis de requisitos: Entrevistas Desarrollo conjunto de aplicaciones (JAD) Prototipado Observación Estudio de documentación Cuestionarios Tormenta de ideas (Brainstorming) ETHIC AIR - 53

54 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Entrevistas: Cada tipo de entrevista requiere un comportamiento y una preparación distinta. Existen dos elementos principales: Entrevistador y Entrevistado AIR - 54

55 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos EL ENTREVISTADO PUEDE PRESENTAR: PASIVIDAD, INHIBICION NO ACEPTACION RECHAZO AGRESIVIDAD EL ENTREVISTADOR DEBE POSEER: CIERTAS CUALIDADES PERSONALES CONOCIMIENTO DE TECNICAS ACTITUD ADECUADA EXPERIENCIA PRACTICA No basta con hacer preguntas Es importante la forma en que se plantea la conversación y la relación que se establece relación asimétrica, dinámica y única AIR - 55

56 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Problemas de Comunicación: Discrepancia de objetivos Barreras de la comunicación Mantenimiento de la motivación AIR - 56

57 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Barreras de la Comunicación: OIR LO QUE QUEREMOS PASAR POR ALTO IDEAS CONTRARIAS DIFERENTE SIGNIFICADO DE LAS PALABRAS COMUNICACION NO VERBAL EMOCIONES RUIDO DISTANCIA Eliminación de Barreras: ADAPTARSE AL MUNDO DEL RECEPTOR UTILIZAR EL DIALOGO SERVIRSE DE LA COMUNICACION DIRECTA INSISTIR (VARIAS VECES) UTILIZAR LENGUAJE SENCILLO Y DIRECTO UTILIZAR VIAS DISTINTAS REDUCIR LAS DISTANCIAS AIR - 57

58 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Factores a Considerar: COMUNICACION NO VERBAL PROXIMIDAD FISICA ORIENTACION POSTURA ADEMANES CABEZA EXPRESION FACIAL OJOS APARIENCIA ASPECTOS DEL LENGUAJE ESCUCHAR Y RESPONDER VOCABULARIO EXPRESION VERBAL AIR - 58

59 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Cualidades del Entrevistador: Saber observar y escuchar (escucha activa) Poseer madurez Ser objetivo e imparcial No ser autoritario Capacidad de empatía Comprensión Ser cordial y accesible Respetar la intimidad Ser sincero, paciente, sereno Ser prudente AIR - 59

60 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Fases de la Entrevista: Preparación Realización y Conducción Análisis AIR - 60

61 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Preparación de la Entrevista: Investigar la situación Identificar los entrevistados Preparar el objetivo y el contenido Planificar lugar y hora AIR - 61

62 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Realización de la Entrevista: Etapas: Apertura (establecer un ambiente confortable) Desarrollo Técnicas Directivas: preguntas abiertas, preguntas directas, preguntas cerradas, sondeo. Técnicas No Directivas: pausa, asentir, reflejar ideas, resumir. Término (resumir, agradecer, establecer nuevas citas) AIR - 62

63 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Análisis de la Entrevista: Es la fase más descuidada Requiere: Pasar notas a limpio Reorganizar la información Contrastar la información con otras entrevistas o fuentes Evaluar cómo ha ido la entrevista. AIR - 63

64 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Desarrollo Conjunto de Aplicaciones (JAD): Es una técnica para promover la cooperación y el trabajo en equipo entre usuarios y analistas. Razones para realizar: Dinero gastado en preparación y realización de entrevistas. Todo el grupo puede actuar como revisor y detectar defectos. Propugna una participación más profunda de los usuarios en el proyecto. AIR - 64

65 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Fases de un JAD: Adaptación o preparación: Selección de los participantes Recabar una cierta información Organizar la reunión Sesión JAD Documentación AIR - 65

66 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Prototipado: Consiste en la elaboración de un modelo o maqueta del sistema. Se construye para evaluar mejor los requisitos que desea que cumpla. Es útil cuando: El área de aplicación no está bien definida. El coste de rechazo de la aplicación es muy alto. Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organización. AIR - 66

67 Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Tipos principales de prototipos: Prototipado de la interfaz de usuario Modelos de Rendimiento Prototipado funcional AIR - 67

68 Ejercicio 4: Proceso de Desarrollo de Requisitos: Captura, Análisis y Negociación de requisitos Dado el sistema de la DGT propuesto en el ejercicio 2, y habiendo visto ya distintos tipos de técnicas para la captura y análisis de requisitos, realice las siguientes tareas: 1. Identifique las fuentes de información para la captura de requisitos (documentación, stakeholders, entorno operacional y organizacional). 2. Planificar las actividades de investigación. Describir las actividades en términos de objetivos, contenido, personas y/o material involucrado, duración, etc. AIR - 68

69 Proceso de Desarrollo de Requisitos AIR - 69

70 Proceso de Desarrollo de Requisitos Especificación o documentación de requisitos Es un documento que define, de forma completa, precisa y verificable, los requisitos, el comportamiento u otras características de un sistema o componente de un sistema. Debe incluir información veraz Debe comunicar dicha información de forma eficaz Describir correctamente todos los requisitos del software No describir ningún detalle del diseño del software, de su verificación o de la dirección del proyecto que influyen en los requisitos. AIR - 70

71 Proceso de Desarrollo de Requisitos Validación de requisitos En esta etapa se intenta encontrar problemas con los requisitos Se realizan verificaciones sobre la especificación de requisitos: Verificaciones de validez. Verificaciones de consistencia. Verificaciones de completitud. Verificaciones de realismo (presupuesto, tiempos) Verificabilidad. Ejemplos: el sistema no se ajusta a estándares; se detectan nuevas inconsistencias o ambigüedades; etc. AIR - 71

72 Análisis e Ingeniería de Requisitos Tema 2: Introducción a la Ingeniería de Requisitos Curso