Análisis e Ingeniería de Requisitos Tema 2

(1)

Análisis e Ingeniería de Requisitos

Tema 2: Introducción a la Ingeniería de Requisitos

(2)

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.

(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

(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).

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

(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

(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

(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).

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

(10)

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

(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

(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

(16)

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

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

(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)

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

(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

(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

(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

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

(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:

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.

(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

(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:

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



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.

(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 “

(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:

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

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

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

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

(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

(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

(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

(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

(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

(40)

Proceso de Desarrollo de Requisitos

(41)

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

(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

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

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

(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

(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

(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:

(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)

(52)

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.

Proceso de Desarrollo de Requisitos:

(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



(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:

(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

“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

(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

(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

(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

(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

(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

(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

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

(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

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

(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

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

(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

(68)

Proceso de Desarrollo de Requisitos:

Captura, Análisis y Negociación de requisitos

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