Clases Unidad II

INGENIERÍA DE REQUISITOS
DISCIPLINAS DE LA
CONTENIDO
• Disciplinas de la Ingeniería de Requisitos.

• Características del Proceso de Ingeniería de Requisitos
• Dimensiones de la Ingeniería de Requisitos
• La captura de requisitos
• El análisis de requisitos
Disciplinas de la Ingeniería de Requisitos
En general se consideran que son cuatro las disciplinas

que conforman la IR:
• Captura (elicitation) de requisitos
• Análisis de requisitos
• Especificación de requisitos
• Verificación de requisitos
CAPTURA (ELICITATION) DE REQUISITOS
El proceso a través del cual los clientes

(comprador y/o usuarios) y desarrollador
(contratista) de un sistema de software,
descubren, revisan, articulan y entienden las
necesidades del usuario y las restricciones en el
software
ANALISIS DE REQUISITOS
El proceso de analizar las necesidades de los

clientes y usuarios para establecer una
definición de los requisitos de software
ESPECIFICACIÓN DE REQUISITOS
El desarrollo de un documento que en forma clara

y precisa registra cada uno de los requisitos del
sistema de software
VERIFICACIÓN DE REQUISITOS
El proceso llevado a cabo para asegurar que la

especificación de requisitos de software están
en concordancia o satisfacen los requisitos del
sistema de software.

Hay quienes consideran que adicional a estas
cuatro disciplinas deben realizarse las
siguientes:
ESTUDIO DE FACTIBILIDAD
Para un nuevo sistema a desarrollar el proceso
de ingeniería de requisitos comienza con un
estudio de factibilidad.
El resultado del estudio es un informe que

recomienda si es conveniente llevar acabo la IR
y el proceso de desarrollo del sistema.
MANEJO DE REQUISITOS DE SOFTWARE
El control y seguimiento de las actividades de

captura, análisis, especificación y verificación
de requisitos.
Características del Proceso de Ingeniería de Requisitos
• La IR es un proceso iterativo, ya que al ser un

proceso de descubrimiento y comunicación,
difícilmente pueda realizarse en forma lineal
• Los requisitos no siempre son entregados en su

totalidad por los clientes y usuarios, así que los
ingenieros de requisitos también deben descubrirlos

requisitos informales
Captura de Análisis y negociación

requisitos de requisitos
documento de requisitos e requisitos negociados

Informe de validación
documento de
requisitos
Validación de requisitos
borrador documento de requisitos

• Los limites de las actividades de IR son difíciles

de establecer por la misma naturaleza del proceso.
• No hay claridad ni consenso en cuanto a los

productos que se deben tener al final de cada
actividad.
• Los requisitos pueden evolucionar tan

rápidamente que pueden cambiar antes de haber
concluido el desarrollo del proyecto.
Sistemas de
Información
existentes Documento de
especificación
Necesidades requisitos
de los clientes y Proceso de IR
usuarios (caja negra)
Estándares Modelos del

sistema
Cada organización
Regulaciones
tendrá su propio proceso
Información del
dominio
Problemas con el proceso de ingeniería de requisitos:
-No se tienen en cuenta a todos los stakeholders

-No se consideran las necesidades del negocio
-No existe una gestión explicita de requisitos
-Las responsabilidades de cada actividad no están
claramente establecidas (que persona)
- Problemas de comunicación entre los stakeholders
Dimensiones de la Ingeniería de Requisitos
Son tres las dimensiones que comprende la IR e ilustran el

avance del proceso desde especificaciones incompletas,
informales e individuales hacia unos requisitos
especificados de manera completa, formal y acordada
entre todos los participantes
Comprensión
formalismo acuerdo
• Grado de comprensión del conocimiento sobre el

sistema que se desea desarrollar: vaga, media,
Completa.
• Grado de formalismo de la representación de los
requisitos: informal, semi-formal, formal.
• Grado de acuerdo al cual llegan los

participantes
del proceso mediante algún tipo de negociación:
personal, grupal
CAPTURA DE REQUISITOS
“ Quien hace una pregunta parece ignorante durante cinco

minutos. Quien se le calla sigue siéndolo el resto de su vida “
Antiguo proverbio chino

Kotonya y Sommerville
La actividad de CAPTURA (ELICITATION) tiene

como propósito descubrir, articular y entender los
requisitos del sistema de software. Esto implica la
definición de todos los usuarios (Stakeholders) y el
análisis de la naturaleza de su participación
La captura de requisitos es un proceso difícil:
-Comprender el dominio de la aplicación (control de tránsito aéreo)

Libros, manuales y expertos del dominio
-Comprender el problema (reglas de vuelo visual)
la gente que lo conoce esta muy ocupada para explicarlo
-Comprende el contexto del negocio (gestión del aeropuerto)
reglas del negocio (políticas) o de organización
-Comprender las necesidades y restricciones de los usuarios
finales del sistema (interfaz de control de radar)
los usuarios no saben lo que puede hacer por ellos el
computador
!! La captura de los requisitos adecuados es de vital importancia.
Si no se hace, el cliente no estará satisfecho con el producto. !!
-Los requisitos cambian (incluso en la etapa de captura)

- cambian las condiciones del negocio
- cambian los usuarios finales
- cambian los interlocutores
-No se ha planificado tiempo suficiente para esta fase
-Los ingenieros de requisitos no han aprendido la jerga técnica
-Los usuarios finales no quieren un sistema nuevo

• Los usuarios/clientes a menudo no conocen

realmente lo que desean obtener del sistema,
solo en términos muy generales.
- les resulta difícil articular lo que quieren

del sistema
- hacen demandas irreales debido a que

no conocen el costo de sus peticiones
• Los usuarios del sistema expresan sus requisitos

con sus propios términos y con un conocimiento
implícito de su propio trabajo. Los ingenieros de
requisitos sin experiencia del dominio del cliente
deben comprender estos requisitos.
• Utilizan terminologías diferentes provocando

problemas de comunicación.
• Diferentes usuarios tienen requisitos distintos y

podrían expresarlos de varias formas. Los
ingenieros de requisitos tienen que descubrir todas
las fuentes potenciales de requisitos, así como las
partes comunes y los conflictos
• Emergen nuevos requisitos de nuevos usuarios
que no habían sido consultados y/o considerados
previamente
• No todos los requisitos del sistema son
formulados por los usuarios. Los ingenieros de
requisitos deben descubrirlos
• Tendencia a omitir la información que es

considerada como obvia por parte del clieente.
• Disponibilidad de los usuarios
 en general siempre están muy ocupados. Difícil

concertar reuniones.
 el ingeniero de requisitos no es su prioridad #1
 el ingeniero de requisitos es considerado una amenaza

para ellos. Automatización de procesos del negocio
entonces despido de personal.
U.C.V., Postgrado en Ciencias de la Computación – Curso Ingeniería de Requisitos – Resp. Alfredo Matteo Marzo - julio 2008
Stakeholders
• El termino de usuario dentro de la IR es

conceptualmente mas amplio al comúnmente referido
como un usuario del sistema.
• El término usuario (stakeholder) se utiliza para

referirse a cualquier persona que tiene influencia directa
o indirecta sobre los requisitos del sistema.
Stakeholders
Hay dos grupos principales de usuarios:
- clientes (usuarios y propietarios del

sistemas)
- desarrolladores (analistas, arquitecto
de software, programadores,…..)
Fuentes de información para la captura de requisitos
• clientes y usuarios del sistema

• sistemas existentes (manuales o automatizados)
• sistemas de la competencia
• expertos del dominio de aplicación
• documentos sobre el dominio de aplicación
• reglas del negocio (normativas, leyes)
Dimensiones de los requisitos
• Se identifican tres dimensiones en las cuales se pueden
clasificar los requisitos según diversos propósitos
características
ámbito audiencia
Dimensiones de los requisitos
• Ámbito: indica si el requisito debe cumplirse a nivel de
hardware, software o del sistema.
• Audiencia: indica el tipo de persona (capaz de entenderlo)

a la que está dirigido el requisito. Los tipos de audiencia
son los clientes/usuarios y los desarrolladores del sistema.
• Características: indica la naturaleza de la característica

deseada del sistema, de tipo funcional o no funcional
Resolución de conflictos
• Detectar las incoherencias entre las fuentes de información

• Analizar el origen de los conflictos:
- incomprensión
- objetivos divergentes
- prioridades diferentes
• Negociación, arbitrar, reunirse con la gerencia
TÉCNICAS • Entrevistas
• Sesiones JAD
Habituales
• Brainstorming
Añadir Producto
Cliente
Eliminar Producto
• Casos de uso
Modificar Cantidad Producto
Consultar Carro
Buscando
Información
• Reutilización de requisitos
(familias de sistemas)
Complementarias
• Estudio de documentación
• Inmersión en el negocio
• Prototipos
Entrevistas
• Es la técnica de elicitación más utilizada,
y de hecho son prácticamente inevitables
en cualquier desarrollo.
• Se pueden identificar tres fases:

Preparación, Realización y Análisis.
Entrevistas
Preparación Realización Análisis
• Estudiar el dominio del • Apertura • Leer notas

problema. • Reorganizar Inf.
• Desarrollo
• Seleccionar a las
• Terminación • Validar contenido
personas
• Determinar el objetivo y • Evaluar
contenido.
• Planificar las entrevistas
JAD
• Joint Application Development

(Desarrollo Conjunto de aplicaciones)
• Esta técnica desarrollada por IBM en
1977, es una alternativa a las entrevistas
individuales, que se desarrollan a lo largo
de un conjunto de reuniones en grupo
durante un periodo de 2 a 4 días.
JAD
Continuación
• Se basa en cuatro principios: dinámica de
grupos, el uso de ayudas visuales, mantener
un proceso organizado y racional y una
filosofía de documentación WYSIWG (lo que
se ve es lo que se obtiene).
• Tiene dos grandes pasos:

• JAD/Plan: cuyo objetivo es elicitar y especificar
requisitos.
• JAD/Desing: en el que se aborda el diseño del SW
JAD • Debido a las necesidades de organización que

Continuación
requiere y que no suele adaptarse bien a los horarios
de trabajo de los clientes y usuarios, esta técnica no
suele emplearse con frecuencia, aunque cuando se
aplica suele tener buenos resultados.
Ventajas
• Ahorra tiempo al evitar que las opiniones de los clientes se contrasten
por separado.
• Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la
documentación generada, no sólo los ingenieros de requisitos.
• Involucra más a los clientes y usuarios en el desarrollo.
Participantes del JAD

JAD Jefe de Jad: Es el responsable de todo el proceso y asume
Continuación
el control durante las reuniones
Analista: Es el responsable de la producción de los
documentos que se deben generar.
Patrocinador Es el que tiene la decisión final de que se lleve
ejecutivo: a cabo el desarrollo.
Representante Durante el JAD/Plan, suelen ser directivos con
de los una visión global del sistema. Para los
usuarios: JAD/Desing suelen incorporarse futuros
usuarios finales.
Representante Son personas expertos en SI que deben
s de Sistemas ayudar a los usuarios a comprender qué es o
de Inf.: no factible con la tecnología actual y el
esfuerzo que implica
Especialistas: Son personas que pueden proporcionar
información detallada sobre aspectos muy
concretos, tanto desde el punto de vista del
usuario, como desde el punto de vista de los
desarrolladores
JAD • Definir el proyecto a alto nivel

Continuación
Adaptación • Recabar Inf., sobre la Organización
• Seleccionar a los participantes
• Planificar las sesiones
• Presentación
• Definir Objetivos y Requisitos
Celebración de
• Delimitar el ámbito del sistema
Fases del JAD las Sesiones
• Documentar temas abiertos
• Concluir la sesión
• Completar la documentación
Conclusión • Revisar la documentación

• Validar la documentación
Fases del JAD – Fase: Adaptación

JAD
Continuación • Es responsabilidad del jefe del JAD, ayudado por uno
o dos analistas, adaptar la técnica del JAD para cada
proyecto.
• La adaptación debe comenzar por definir el proyecto a alto nivel, para lo cual
pueden ser necesarias entrevistas previas con algunos clientes y usuarios.
También suele ser necesario recabar información sobre la organización para
familiarizarse con el dominio del problema.
• Una vez obtenida una primera idea de los objetivos del proyecto, es necesario
seleccionar a los participantes, citarles para las reuniones y proporcionarles una
lista con los temas que se van a tratar en las reuniones para que las puedan
preparar.
• El jefe del JAD debe decidir la duración y el número de sesiones a celebrar,
definir el formato de la documentación sobre la que se trabajará y preparar
transparencias introductorias y todo el material audiovisual que considere
oportuno.
JAD
Continuación
Fases del JAD – Fase: Celebración de las sesiones
• Durante las sesiones, los participantes exponen sus ideas y se

discuten, analizan y refinan hasta alcanzar un acuerdo. Los pasos
que se recomienda seguir para este proceso son los siguientes:
presentación, definir objetivos y requisitos, delimitar el ámbito del
sistema, documentar temas abiertos, concluir la sesión.
JAD
Continuación
• Presentación: se presentan a todos los participantes por parte del

patrocinador ejecutivo y del jefe del JAD.
• El patrocinador ejecutivo expone brevemente las necesidades que

han llevado al desarrollo y los beneficios que se esperan obtener.
• El jefe del JAD explica la mecánica de las sesiones y la

planificación prevista.
JAD
Continuación
• Definir objetivos y requisitos: el jefe del JAD promueve la

discusión para elicitar los objetivos o requisitos de alto nivel
mediante preguntas como: "¿Por qué se construye el sistema?",
"¿Qué beneficios se esperan del nuevo sistema?", "¿Cómo puede
beneficiar a la organización en el futuro?", "¿Qué restricciones de
recursos disponibles, normas o leyes afectan al proyecto?", "¿Es
importante la seguridad de los datos?", . . .
JAD
Continuación
• Delimitar el ámbito del sistema: una vez obtenido un número

importante de requisitos, es necesario organizarlos y llegar a un
acuerdo sobré el ámbito del nuevo sistema. Se identifican a los
usuarios potenciales (actores) y determinar qué tareas les ayudará
a realizar (casos de uso).
• Documentar temas abiertos: aquellas cuestiones que hayan

surgido durante la sesión que no se han podido resolver, deben
documentarse para las siguientes sesiones y ser asignadas a una
persona responsable de su solución para una fecha determinada.
JAD
Continuación
• Concluir la sesión: el jefe del JAD concluye la sesión revisando

con los demás participantes la información elicitada y las
decisiones tomadas. Se da la oportunidad a todos los participantes
de expresar cualquier consideración adicional, fomentando por
parte del jefe del JAD el sentimiento de propiedad y compromiso
de todos los participantes sobre los requisitos elicitados.
Fases del JAD – Fase: Conclusión

JAD Una vez terminadas las sesiones es necesario transformar las
Continuación
transparencias, notas y demás documentación generada en
documentos formales. Se distinguen tres pasos: completar la
documentación, revisar la documentación, validar la
documentación.
• Completar la documentación: los analistas recopilan la documentación

generada durante las sesiones en documentos conformes a las normas o
estándares vigentes en la organización para la que se desarrolla el proyecto.
• Revisar la documentación: la documentación generada se envía a todos los

participantes para que la comenten. Si los comentarios son lo suficientemente
importantes, se convoca otra reunión para discutirlos.
• Validar la documentación: una vez revisados todos los comentarios, el jefe

del JAD envía el documento al patrocinador ejecutivo para su aprobación. Una
vez aprobado el documento se envían copias definitivas a cada uno de los
participantes.
Brainstorming
El brainstorming o tormenta de ideas es una

técnica de reuniones en grupo cuyo objetivo es la
generación de ideas en un ambiente libre de
críticas o juicios.
• Las sesiones de brainstorming suelen estar formadas por un

número de cuatro a diez participantes, uno de los cuales es el
jefe de la sesión, encargado más de comenzar la sesión que
de controlarla.
Brainstorming
• Como técnica de elicitación de requisitos, el
brainstorming puede ayudar a generar una gran
variedad de vistas del problema y a formularlo de
diferentes formas, sobre todo al comienzo del
proceso de elicitación, cuando los requisitos son
todavía muy difusos.
• Frente al JAD, el brainstorming tiene la ventaja de que es muy
fácil de aprender y requiere poca organización, de hecho, hay
propuestas de realización de brainstorming por vídeo–conferencia
a través de Internet
• Por otro lado, al ser un proceso poco estructurado, puede no

producir resultados con la misma calidad o nivel de detalle que
otras técnicas.
Fases del Brainstorming

• Seleccionar a los participantes
Preparación • Seleccionar al Jefe de la sesión

• Los participantes son Stakeholders
• Plantear el problema a tratar (semilla)

• Se generan ideas
Generación • Se cierra la fase.
• Se deben Observar reglas.
• Revisar ideas
Consolidación • Descartar ideas
• Priorizar ideas
• Ideas Priorizadas
Documentación
• Comentarios de la Consolidación
Casos de uso
Añadir Producto
Los casos de uso son una técnica para la
Eliminar Producto
especificación de requisitos funcionales propuesta
Cliente

inicialmente en el método OOSE y que actualmente
forma parte de la propuesta de UML.
Consultar Carro
Un caso de uso es la descripción de una secuencia de

interacciones entre el sistema y uno o más actores en la que se
considera al sistema como una caja negra y en la que la que los
actores obtienen resultados observables.
Casos de uso
Añadir Producto
Los actores son personas u otros sistemas que

Eliminar Producto
interactúan con el sistema cuyos requisitos se
están describiendo.
Cliente
Consultar Carro
Los casos de uso presentan ciertas ventajas sobre la descripción

meramente textual de los requisitos funcionales, ya que facilitan la
elicitación de requisitos y son fácilmente comprensibles por los
clientes y usuarios.
Además, pueden servir de base a las pruebas del sistema y a la
documentación para los usuarios.
Casos de uso
Añadir Producto
Para la descripción concreta de los casos de uso

Eliminar Producto
se proponen plantillas, en las que las interacciones
Cliente
Modificar Cantidad Producto se numeran siguiendo las propuestas de

Consultar Carro
[Cockburn 1997], [Scheneider y Winters 1998] y
[Coleman 1998] y se describen usando lenguaje
natural en forma de patrones lingüísticos.
Prototipo
• Versión inicial del sistema generada al principio del desarrollo
• Para capturar y validar requisitos
• Toma en cuenta requisitos funcionales
• Dos tipos de desarrollo de prototipos:

• evolutivos: incremento de la funcionalidad (parecido a
extreme programming) (para los requisitos mejor comprendidos)
• “de usar y tirar” (los requisitos peor comprendidos)
Prototipo
Ventajas:
• revela requisitos incompletos o inconsistentes
• desarrollo de interfaces de usuario
Desventajas:
• costos de entrenamiento en técnicas de prototipaje

• incremento en el costo del desarrollo
• aumenta el tiempo de entrega del producto
ANÁLISIS DE REQUISITOS
• El análisis de requisitos es la disciplina de transición

entre entendimiento del problema y la especificación
de la solución.
• En la práctica no existe una frontera bien delimitada

entre la captura y el análisis de requisitos.
captura
análisis
especificación
verificación
Análisis versus Captura
• La Captura trata de encontrar los requisitos (informal).
• El Análisis trata de encontrar las características de los

requisitos (formal)
Como entrada al análisis de requisitos se tiene:
- un pleno entendimiento del problema:

los objetivos
el alcance,
los stakeholders
- un conjunto inicial de requisitos

El proceso de análisis de requisitos
Compresión del dominio: Los analistas deben

comprender el dominio de la aplicación.
Clasificación: Recolectar el conjunto no estructurado de

Requisitos (conjunto inicial de requisitos) y agruparlos
en agrupaciones coherentes.
Resolución de conflictos: Resolver los conflictos que

pudieran producirse entre los requisitos de los
stakeholders
El proceso de análisis de requisitos
Priorización: Interacción con los stakeholders para

identificar los requisitos mas importantes
Comprobación de requisitos: Comprobar si los requisitos

son completos, correctos, factibles, no ambiguos,..
Análisis de los requisitos iniciales
• Como cada uno de los requisitos se relacionan con los otros ?

• Son los requisitos factibles ?
• Son los requisitos no ambiguos ?
• Son los requisitos correctos ?
• Son los requisitos completos ?
• Son los requisitos verificables ?
Dependencias entre requisitos
R2 depende de R1
Si R1 es descartado entonces R2 queda también descartado
Requisitos incompatibles
Si se satisface R1 entonces se presenta una

incompatibilidad con que R2 se satisfaga y viciversa.
Matriz de interacción
0: requisito independiente
requisitos
R1 R2 R3 R4 1: con conflicto
1000: solapado
R1
R2
R3
R4
• Son los requisitos factibles ?
Es técnicamente factible ?
Es económicamente factible ?
Es operacionalmente factible?
• Son los requisitos no ambiguos ?
El requisito posee una única interpretación

• Son los requisitos correctos ?
Cuando satisfacen las necesidades del cliente

• Son los requisitos completos ?
Cuando se cubren todos los requisitos posibles
• Son los requisitos verificables ?

Cuando se pueden establecer casos de prueba
El análisis de requisitos es un proceso iterativo e incremental
captura
análisis
El propósito global del análisis de requisitos es construir

una baseline de requisitos
Baseline de requisitos
Los requisitos pertenecientes a la baseline de requisitos satisfacen:
• son mutuamente compatibles

• son factibles
• son correctos
• son completos
• son no ambiguos
• son verificables
En la situación ideal, la captura de requisitos

será lo suficientemente.......
de forma que estos sean compatibles,
factibles, correctos,......
para permitir derivar una baseline razonable
En la práctica esto no es así
Como se logra la obtención de una baseline de

requisitos?
Derivando nuevos requisitos

Construyendo modelos
Clasificando los requisitos
Como se logra la obtención de una baseline de requisitos?
Derivación de nuevos requisitos
R1 R2 R3
R4 R5 R6 R7 R8 R9 R10 R11
R12 R13 R14


Ejemplo:
en la captura de requisitos a través del enfoque de
casos de uso, estos pueden ser visto como los
requisitos del top-level. Al especificar y
documentar los casos de uso y desarrollar los
diagramas de secuencias se pueden descubrir
requisitos derivados.

La derivación de requisitos no siempre forma un árbol
A B
D
Construcción de Modelos
Los modelos se utilizan en ingeniería para entender
mejor lo que se quiere construir. En particular, en la IS
se utilizan :
• modelos de datos (para la información que transforma

el software)
• modelos de procesos (para los procesos que
transforman la información)
• modelos de control (para definir el comportamiento
del sistema)
El problema deriva en cuales modelos escoger y el nivel
de detalle.
Ejemplo: Diagramas de flujos de datos (DFD)
• La descomposición funcional usando DFD es muy

apropiado para la derivación de requisitos.
• DFD son adecuados para modelar requisitos

funcionales, pero no capturan otros aspectos del
sistema: interacción, estructura de datos, el estado del
sistema, etc.
Ejemplo: Modelos del enfoque orientado a objetos
Se modelan aspectos estáticos a través del modelo

de clases (se captura la estructura del dominio del
problema) y aspectos dinámicos a través de
diagramas de secuencias o diagramas de estados.

Clases Unidad II

Cargado por

Copyright:

Formatos disponibles

También podría gustarte

Clases Unidad II

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clases Unidad II

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA DE REQUISITOS

• Disciplinas de la Ingeniería de Requisitos.

Disciplinas de la Ingeniería de Requisitos

En general se consideran que son cuatro las disciplinas

Disciplinas de la Ingeniería de Requisitos

CAPTURA (ELICITATION) DE REQUISITOS

El proceso a través del cual los clientes

Disciplinas de la Ingeniería de Requisitos

El proceso de analizar las necesidades de los

Disciplinas de la Ingeniería de Requisitos

El desarrollo de un documento que en forma clara

Disciplinas de la Ingeniería de Requisitos

El proceso llevado a cabo para asegurar que la

Disciplinas de la Ingeniería de Requisitos

El resultado del estudio es un informe que

Disciplinas de la Ingeniería de Requisitos

MANEJO DE REQUISITOS DE SOFTWARE

El control y seguimiento de las actividades de

Características del Proceso de Ingeniería de Requisitos

• La IR es un proceso iterativo, ya que al ser un

• Los requisitos no siempre son entregados en su

Características del Proceso de Ingeniería de Requisitos

Captura de Análisis y negociación

documento de requisitos e requisitos negociados

borrador documento de requisitos

Características del Proceso de Ingeniería de Requisitos

• Los limites de las actividades de IR son difíciles

• No hay claridad ni consenso en cuanto a los

• Los requisitos pueden evolucionar tan

Características del Proceso de Ingeniería de Requisitos

Estándares Modelos del

Características del Proceso de Ingeniería de Requisitos

Problemas con el proceso de ingeniería de requisitos:

-No se tienen en cuenta a todos los stakeholders

Dimensiones de la Ingeniería de Requisitos

Son tres las dimensiones que comprende la IR e ilustran el

Dimensiones de la Ingeniería de Requisitos

Dimensiones de la Ingeniería de Requisitos

• Grado de comprensión del conocimiento sobre el

• Grado de acuerdo al cual llegan los

“ Quien hace una pregunta parece ignorante durante cinco

Antiguo proverbio chino

La actividad de CAPTURA (ELICITATION) tiene

-Comprender el dominio de la aplicación (control de tránsito aéreo)

-Los requisitos cambian (incluso en la etapa de captura)

-Los ingenieros de requisitos no han aprendido la jerga técnica

-Los usuarios finales no quieren un sistema nuevo

• Los usuarios/clientes a menudo no conocen

- les resulta difícil articular lo que quieren

- hacen demandas irreales debido a que

• Los usuarios del sistema expresan sus requisitos

• Utilizan terminologías diferentes provocando

• Diferentes usuarios tienen requisitos distintos y

• Tendencia a omitir la información que es

• Disponibilidad de los usuarios

 en general siempre están muy ocupados. Difícil

 el ingeniero de requisitos no es su prioridad #1

 el ingeniero de requisitos es considerado una amenaza

• El termino de usuario dentro de la IR es