Análisis e Ingeniería de Requisitos - kybele.etsii.urjc.esAIR-2012-2013]Tema2.pdf · Análisis e Ingeniería de Requisitos – Tema 2 ... 4 . Análisis e ... de detalle requerido

Análisis e Ingeniería de Requisitos – Tema 2 www.kybele.urjc.es

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

Curso 2012-2013


Bibliografía Básica

Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill,

2002 5ª 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, 1996.

AIR - 2


Í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


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



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



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


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


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


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


Requisitos

AIR - 10


Requisitos

AIR - 11


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


Requisitos

AIR - 13


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


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


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


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


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


Tipos de Requisitos


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


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


Tipos de Requisitos


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


Tipos de Requisitos



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


Tipos de Requisitos


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


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:

9.3.2 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


Tipos de Requisitos

AIR - 25


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


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


Tipos de Requisitos

Requisitos No Funcionales Organizacionales

Son restricciones en el proceso de desarrollo del Sistema.

También llamados requisitos No Funcionales de Proceso. Estándares y Métodos de Desarrollo

Herramientas a usar

Producción de Informes

Ejemplos: • El proceso de desarrollo debe ser conforme con ISO 9003.

• 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


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


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


Tipos de Requisitos


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


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 Z39.50

2. 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


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


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


Tipos de Requisitos

Ejercicio 2:

1. Identificar los requisitos funcionales y especificar cada requisito con la siguiente estructura:


Requisito Funcional 1

Introducción

Entradas

Procesamiento

Salidas



AIR - 35


Tipos de Requisitos

Ejercicio 3:

1. Identificar los requisitos funcionales y especificar cada requisito con la siguiente estructura:



Introducción

Entradas

Procesamiento

Salidas



AIR - 36


Í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


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


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



Desarrollo de requisitos vs. Gestión de requisitos

AIR - 40



AIR - 41



AIR - 42



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



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



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



AIR - 46



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



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


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



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



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


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




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



Entrevistas:

Cada tipo de entrevista requiere un comportamiento y una preparación distinta.

Existen dos elementos principales: Entrevistador y Entrevistado

AIR - 54



EL ENTREVISTADO PUEDE PRESENTAR:

PASIVIDAD, INHIBICION

NO ACEPTACION

RECHAZO

AGRESIVIDAD

EL ENTREVISTADOR DEBE POSEER:

CIERTAS CUALIDADES PERSONALES

CONOCIMIENTO DE TECNICAS

ACTITUD ADECUADA

EXPERIENCIA PRACTICA

“relación asimétrica, dinámica y única”

Es importante la forma en que se

plantea la conversación y la relación que se

establece

No basta con hacer preguntas

AIR - 55



Problemas de Comunicación:

Discrepancia de objetivos

Barreras de la comunicación

Mantenimiento de la motivación

AIR - 56



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



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



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



Fases de la Entrevista: Preparación

Realización y Conducción

Análisis

AIR - 60



Preparación de la Entrevista:

Investigar la situación

Identificar los entrevistados

Preparar el objetivo y el contenido

Planificar lugar y hora

AIR - 61



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



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



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



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



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



Tipos principales de prototipos:

Prototipado de la interfaz de usuario

Modelos de Rendimiento

Prototipado funcional

AIR - 67



Ejercicio 4:

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



AIR - 69



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



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


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

Curso 2012-2013

Documents

Análisis e Ingeniería de Requisitos - kybele.etsii.urjc.esAIR-2012-2013]Tema2.pdf · Análisis e Ingeniería de Requisitos – Tema 2 ... 4 . Análisis e ... de detalle requerido