IngenieriaRequisitos 1

Ingenier
Ingenieríía de Requisitos
Ingeniería
Ingeniería del Software de Gestión
Ingeniería de Requisitos
Ingeniería de Requisitos: definición
¿Qué es la Ingeniería de Requisitos?

Es el proceso de descubrir, analizar,
documentar y verificar los servicios que debe
proporcionar el sistema y sus restricciones
Define un proceso
Facilita la comprensión de lo que quiere el cliente:
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.
2
1
Proceso de Desarrollo de Requisitos

Objetivo: Crear y mantener un documento de
requisitos del sistema
Define el conjunto estructurado de actividades
para obtener y mantener la especificación de
los requisitos
El proceso de desarrollo (ingeniería) de
requisitos comprende (en general) 4 etapas:
1. Identificacióno captura de requisitos
2. Análisis (y negociación) de requisitos
3. Especificación o documentación de requisitos
4. Validación de requisitos
3

Necesidades del Usuario
Información del dominio
Sistemas de Información previos
Regulaciones
Estándares
Estudio de la Captura
Viabilidad y Análisis
Informe
Modelos Especificación
del
de
Sistema
Viabilidad
Requisitos
de Usuario Validación
y de Sistema
Documento de
Requisitos
Gestión de Requisitos
4
2

Requirements
specification
System requirements
specification and
modeling
User requirements
specification
Business requirements
specification
System
Feasibility
requirements User
elicitation study
requirements
elicitation
Prototyping
Requirements
elicitation
Reviews Requirements
validation
System requirements
document
5
Estudio de la Viabilidad
El estudio de viabilidad decide si vale la
pena desarrollar el sistema
¿Contribuye a los objetivos de la
organización?
¿Es factible con la tecnología actual en coste
y tiempo?
¿Puede integrarse con otros sistemas de la
organización?
Viabilidad Análisis Especificación Validación Gestión
6
3
Captura y Análisis
El equipo técnico trabaja con los usuarios
finales para determinar:
El dominio de la aplicación
Los servicios a ofrecer
Rendimiento esperado
Restricciones …
Puede implicar a varias personas o
stakeholders
Análisis Especificación Validación Gestión
7
Captura y Análisis: stakeholders

Persona o grupo de personas que se verá
afectado por el sistema, directa o indirectamente
No saben lo que quieren en realidad

Expresan los requisitos en sus propios
términos
Sus requisitos pueden entrar en conflicto
Factores políticos pueden influir en los
requisitos declarados
Pueden aparecer nuevos stakeholders
nuevos requisitos
8
4
Captura y Análisis: stakeholders
Ejemplo: cajero automático (ATM) de un banco

Clientes del Banco
Representantes de otros bancos
Directores de Sucursal
Personal de Ventanilla
DBAs
Directores de Seguridad
Departamento de Marketing
Ingenieros de Mantenimiento
Reguladores de la banca nacional
9
Captura y Análisis: actividades

Descubrimiento de Requisitos
Clasificación y Organización
Ordenación por prioridades y negociación
Documentación de Requisitos
10
5
Captura y Análisis: resumen
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
11
Captura y Análisis: problemas típicos
Problemas a la hora de hacer una captura de requisitos:

Problemas de Ámbito:
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
12
6
Captura y Análisis: pasos

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)
13
Captura y Análisis: técnicas

Principales técnicas de captura y análisis de
requisitos
Entrevistas
Desarrollo conjunto de aplicaciones (JAD)
Prototipado Necesidades del Usuario
Información del dominio
Sistemas de Información previos
Regulaciones
Observación
Estándares
Estudio de la Captura
Viabilidad y Análisis
Modelos Especificación
Informe
del
de
Sistema
Viabilidad
Requisitos
Validación
Estudio de documentación
de Usuario
y de Sistema
Documento de
Requisitos
Cuestionarios
Tormenta de ideas (Brainstorming)
ETHIC
14
7
Captura y Análisis: técnicas de recolección de información
Principales técnicas de captura y análisis de

requisitos
Entrevistas
Workshops colaborativos
Prototipado
Observación
Estudio de documentación
Cuestionarios
Tormenta de ideas (Brainstorming)
ETHIC Análisis Especificación Validación Gestión
15
Técnicas de recolección de información: cuestionario
Cuestionario: Medio de recogida de información de manera

directa o de preparación para una entrevista
PUESTO: vendedor de mostrador
1. ¿Qué pasos sigue para gestionar el cobro de una venta

2. ¿Existen distintos procedimientos en función del artículo, tipo de
cliente, forma de pago, etc.?
3. ¿Qué datos se requieren habitualmente para realizar la gestión del
cobro?
4. ¿Se necesitan datos adicionales? ¿Bajo que circunstancias?
5. Ventas Semanales. Picos y Valles en las ventas
6. ¿Existen problemas en el proceso? Identificar posibles cuellos de
botella
7. Describa los casos especiales que conozca para excepciones al
proceso habitual
16
8
Técnicas de recolección de información

Entrevistas
Intento sistemático de recoger información de otra persona a través
de una comunicación interpersonal que se lleva a cabo
por medio de una conversación estructurada
Flaaten et al. (1989)
Cada tipo de entrevista requiere un

comportamiento y una preparación
distinta: selección, disciplina, rendimiento
Existen dos elementos principales:
Entrevistador y Entrevistado
17
Técnicas de recolección de información: entrevistas
EL ENTREVISTADO PUEDE PRESENTAR: EL ENTREVISTADOR DEBE POSEER:
PASIVIDAD, INHIBICION ☺ CIERTAS CUALIDADES PERSONALES

NO ACEPTACION ☺ CONOCIMIENTO DE TECNICAS
RECHAZO ☺ ACTITUD ADECUADA
AGRESIVIDAD ☺ EXPERIENCIA PRACTICA
Es importante la
No basta con forma en que se
hacer preguntas plantea la
conversación y la
relación que se
establece
“relación asimétrica, dinámica y única”

18
9
Problemas de Comunicación
DISCREPANCIA DE OBJETIVOS
BARRERAS DE COMUNICACION
MANTENIMIENTO DE LA MOTIVACION
19

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
20
10
Factores a Considerar
COMUNICACION NO VERBAL
PROXIMIDAD FISICA CABEZA

ORIENTACION EXPRESION FACIAL
POSTURA OJOS
ADEMANES APARIENCIA
ASPECTOS DEL LENGUAJE
ESCUCHAR Y RESPONDER
VOCABULARIO
EXPRESION VERBAL
21
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
22
11
Fases de la Entrevista
Preparación
Realización y Conducción
Análisis
23
Preparación de la Entrevista
Investigar la situación
Ejemplo: TAE, Interés Nominal …
Identificar los entrevistados: top-down
Minimizar nº personas
Entrevista de Cortesía
Preparar el objetivo y el contenido
Planificar lugar y hora
Terreno neutral Material Auxiliar
Agenda del entrevistado
ENTREVISTA
Preparación Realización Análisis
24
12
Realización y conducción de la Entrevista

Etapas:
Apertura
Introducción
establecer un ambiente confortable
Desarrollo
Técnicas: preguntas abiertas, pausas, asentir y dar
muestras de escucha, reflejar ideas, resumir.
20%/80%
Aplicar psicología para mantener el control de la entrevista
Término
Recapitular, agradecer, establecer nuevas citas
Acabar bien: es el principio de la relación
ENTREVISTA
25
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
Aspectos a mejorar
ENTREVISTA
26
13
Técnicas de Recolección de Información: Workshops colaborativos
Técnica de extracción de en la que se promueve

la cooperación entre usuarios y analistas en las
que se aprovechan las ventajas de la dinámica
de grupos
Características
Desarrollo mediante un trabajo sistemático y
organizado (reglas de la reunión, tipo de partipación,
mantener el alcance, tiempos de discusión, tamaño
del equipo, etc.)
Varias reuniones en intervalos de 2 a 4 días
Uso de ayudas visuales de comunicación
27
Justificación
Esfuerzo dedicado a la preparación, realización
y análisis de entrevistas
Contrastar opiniones encontradas ↑t
Todo el grupo puede actuar como revisor y
detectar defectos
Propugna una participación más profunda de
los usuarios en el proyecto
“ … el sistema que hemos construido …”
28
14
Fases
Adaptación o preparación:
Selección de los participantes
Recabar una cierta información
Organizar la reunión
Sesión
Elaboración del ERS (CASE)
Debe existir un responsable
Documentación
Refinar el resultado
Ejemplos
Joints Requirement Planning (JRP), Joints Application
Development (JAD), Sesiones de Trabajo
29
Técnicas de recolección de información: prototipado
Prototipado
Consiste en la elaboración de un modelo
o maqueta del sistema
Versiones reducidas, demos o conjuntos de pantallas

(no totalmente operativos)
Se construye para evaluar mejor los requisitos que
desea que cumpla
Aplicación
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
30
15
Técnicas de recolección de información: prototipado
Tipos principales de prototipos:

Prototipado de la interfaz de usuario
Storyboard .ppt prototipo evolutivo
Modelos de Rendimiento
De carácter técnico (no aplicables en RE)
Prototipado funcional
Primera versión del sistema con
funcionalidad limitada
“No sé exactamente lo que quiero, pero lo sabré cuando lo vea”
31
Captura y Análisis de Requisitos: Ejercicio 1
Ejercicio 1
Elaborar un cuestionario para el análisis

de requisitos de una red de
concesionarios de venta de automóviles
32
16
Captura y Análisis de Requisitos: Ejercicio 2

Elaborar un prototipo en papel que refleje el sistema
informático de la gestión de un acuario
Datos de cada pez:

Nombre científico: Corydoras Paleatus
Nombre común: Coridora punteado
Origen: Sur de Brasil, norte de Argentina
Tamaño: 7cm
Comportamiento Social: muy bueno
Temperatura: 18 a 28 ºC
Alimentación: omnívoro
Datos adicionales
Proveedores
Histórico de Compra/Venta mensual y anual
Especies “bien avenidas”
33
Especificación de requisitos
El objetivo de la Especificación de
Requisitos es obtener un documento de
especificación de requisitos (ERS)
Documento que define, de forma
completa, precisa y verificable los
requisitos que debe cumplir el sistema
tanto funcionales como no funcionales así
como las restricciones aplicables al diseño
(software y hardware)
[IEEE, 1990]
34
17
Características fundamentales
Debe incluir información veraz
Debe comunicar dicha información de
forma eficaz
Describir correctamente todos los
requisitos necesarios 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
El QUÉ y no el CÓMO
35
Características deseable en una BUENA
especificación de requisitos
1. No ambigua.
2. Completa.
3. Fácil de verificar.
4. Consistente (coherente).
5. Clasificada por importancia o estabilidad.
6. Fácil de modificar.
7. Fácil identificación del origen y de las
consecuencias de cada requisito.
8. De fácil utilización durante la fase de explotación
y de mantenimiento.
36
18
NO AMBIGUA
Un requisito ambiguo se presta a diferentes interpretaciones
Una ERS es no ambigua si y solo si cada requisito tiene una
única interpretación
Es necesario definir términos, siglas o abreviaturas, cuando, en
función del contexto, pueden tener otros significados
(interpretaciones) en un glosario de términos
Requisitos especificados en lenguaje natural. Hay que prestar
atención a la redacción de los requisitos
Ejemplo: “Todos los registros de un fichero serán controlados
mediante un bloque de control de registro”
Un bloque controla todos los registros de un fichero
Cada registro tiene su propio bloque
Se controla cada registro mediante un bloque pero un bloque puede
controlar más de un registro
37
COMPLETA
Incluye no solo los requisitos funcionales sino
también los no funcionales (seguridad, rendimiento,
operacion, documentación, fiabilidad,
disponibilidad...etc.) así como restricciones de diseño
y construcción (software y hardware)
Define la respuesta del software tanto para entradas
válidas como no válidas
Es conforme con estándares y procedimientos
definidos y aprobados en la organización
Requisitos incompletos definición de las causas,
descripción de acciones para cambiar su estado y
seguimiento (TBD)
38
19
CONCISA
Una ERS no debe incluir información adicional
que no proporcione valor en la comprensión de
un requisito
Prestar especial cuidado en la redacción de los
requisitos
Evitar repetir información que existe en otros
documentos
Incluir referencias a otros documentos
39
FACIL DE VERIFICAR
Una ERS es fácil de verificar sii para cada requisito
existe un procedimiento finito y efectivo en coste para
que una persona o máquina compruebe que el software
satisface dicho requisito
Ejemplo de requisito no verificable:

“El programa no debe entrar nunca en un bucle infinito”
Hay que eliminar de la ERS los requisitos no verificables

o reescribir posteriormente el requisito de forma que sea
verificable
40
20
CONSISTENTE
Una ERS es consistente sii ningún conjunto de
requisitos son contradictorios o entran en conflicto
Tipos de conflicto:
1. Dos o más requisitos describen el mismo objeto real pero
utilizan términos distintos para designarlo
2. Conflicto en las características especificadas sobre los objetos
reales (p.e. un requisito establece que todas las luces han de
ser azules y otro verdes)
3. Conflicto lógico o temporal entre dos acciones determinadas
(p.e. un requisito establece la suma de dos entradas y otro la
multiplicación)
41
FACIL DE MODIFICAR
Una ERS es fácilmente modificable si su
estructura y estilo permiten que cualquier
cambio se pueda realiza fácil, completa, y
consistentemente
Debe ser mínimamente redundante. Cada
requisito debe aparecer sólo en un lugar
Es posible la redundancia con objeto de facilitar la
compresión de los requisitos, pero supone
problemas de consistencia al modificar
Mejor crear referencias cruzadas entre los
requisitos
42
21
FACILMENTE TRAZABLE
Una ERS facilita las referencias con otros
productos del ciclo de vida si:
Establece un origen claro para cada uno de los
requisitos (hay referencias hacia atrás)
Posibilita la referencia de estos requisitos con
productos de trabajo futuros dentro del ciclo de vida
(hay referencias hacia adelante)
Cada requisito debe tener un número de
referencia único que lo identifique sobre los
demás
43
PRIORIZADA
Todos los requisitos de la especificación
deberían tener un nivel de prioridad establecido
No todos los requisitos tienen la misma
importancia
Por ejemplo clasificar la prioridad de los requisitos
como M (obligatorio), D (deseable) y O (optativo),
o de asingnandoles una prioridad de 0 a 10
La priorización de los requisitos es conveniente
para planificar correctamente el alcance de los
proyectos en cada fase o iteración de su
desarrollo
44
22
FACILIDAD DE USO
El personal de mantenimiento y explotación no
participa en el desarrollo
Para soportar los cambios, incluir registro
Criticidad de cada componente
Origen
45
Especificación de requisitos: estructuración

Organizar los requisitos ayuda a los
lectores a comprender el sistema y a los
analistas a reubicar funciones
Organización por subsistemas, grupos
funcionales, funciones y subfunciones.
Por clase de usuario
Por clase de estímulo
Por clase de objeto
Por clase de requisito
Apoyarse en estándares actuales para la
estructuración de los requisitos
(p.e. IEEE Std. 830)
46
23

Ejemplo de Estructura de ERS
IEEE Std. 830 (I)
1. Introducción
1.1 Objetivo
1.2 Ambito
1.3 Definiciones, Siglas y Abreviaturas
1.4 Referencias
1.5 Visión global
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Limitaciones generales
2.5 Supuestos y dependencias
3. Requisitos específicos
Apéndices
Índice
47

3. Requisitos específicos
3.1 Requisitos funcionales
Ejemplo de 3.1.1 Requisito funcional 1

3.1.1.1 Introducción
Estructura de ERS 3.1.1.2 Entradas

3.1.1.3 Procesamiento
IEEE Std. 830 (y II) 3.1.1.4 Salidas

3.1.2 Requisito funcional 2
....................
3.1.n Requisito funcional n
3.2 Requisitos de interfaz externo
3.2.1 Interfaces de usuario
3.2.2 Interfaces hardware
3.2.3 Interfaces software
3.2.4 Interfaces de comunicaciones
3.3 Requisitos de ejecución
3.4 Restricciones de diseño
3.4.1 Seguimiento de estándares
3.4.2 Limitaciones hardware
.....
3.5 Atributos de calidad
3.5.1 Seguridad
3.5.2 Mantenimiento
.....
3.6 Otros requisitos
3.6.1 Base de datos
3.6.2 Operaciones
3.6.3 Documentación
.....
48
24
Especificación de requisitos: clasificación

Clasificación de Técnicas de Especificación:
Según la forma de Representación:
Gráficas
Textuales
Marcos (o plantillas (“templates”))
Matriciales
Según el enfoque de modelización:
Dimensión de la función
Dimensión de la información
Dimensión del tiempo
49
Validación de Requisitos
Mostrar que los requisitos definen el

sistema que el cliente desea
Coste de un error en los requisitos
Bola de Nieve
En el análisis
Entrada conjunto incompleto de requisitos
En la validación
Entrada conjunto acordado de requisitos
50
25
Validación de Requisitos
Especificación
VERIFICACIÓN DE
REQUISITOS
Comprobar que la ERS se

CLIENTE/ ANALISTAS OTROS
construye de acuerdo a los IMPLICADOS
USUARIOS
criterios y estándares
establecidos
REVISIÓN
ERS Verificada
ERS
VALIDACIÓN DE
y Validada
REQUISITOS &Técnicas de Revisión
(Formales, informales)
Comprobar que la ERS se &Uso de Listas de
ajusta a las necesidades del comprobación
cliente/usuario y otros &Acciones correctivas
interlocutores para eliminar defectos
51
Proceso de Gestión de Requisitos: evolución
Los requisitos para sistemas software son

siempre cambiantes
A veces el problema no puede definirse
completamente
Durante el proceso de desarrollo, evoluciona
la comprensión del problema
Una vez que el sistema se ha instalado
surgen nuevo requisitos
52
26

Cuando los usuarios experimentan con el
sistema descubren nuevas necesidades y
prioridades
Cambiar la ayuda solicitada a diferentes
usuarios
El cliente no suele ser el usuario
Adaptación a los usuarios
Cambios en el entorno de negocio y técnico
HW/SW, prioridades negocio, legislación
La gestión de requisitos es el proceso de
comprender y controlar los cambios en los
requisitos del sistema
53

La evolución de los requisitos es inevitable
Comprensión Cambios en la
Inicial comprensión del
del Problema problema
Requisitos Requisitos
Inciales Cambiados
Tiempo
Especificar y desarrollar un sistema grande puede

llevar varios años:
Cambios en el entorno del sistema
Cambios en los objetivos del negocio
… los requisitos deben evolucionar
54
27
Bajo el punto de vista evolutivo, los

requisitos se dividen en dos clases:
Requisitos duraderos: se derivan de la actividad
principal de la organización y están relacionados con
el dominio del problema. (Ej. En un hospital,
requisitos referidos a pacientes, médicos,
enfermeras, etc.)
Requisitos Volátiles: Requisitos que probablemente
cambien durante el proceso de desarrollo del sistema
o después de estar en funcionamiento. (Ej. requisitos
de políticas gubernamentales del sanidad)
55

Requisitos Volátiles
Cambiantes
Cambio en el pago de cuidados hospitalarios
Emergentes
Surgen al incrementarse la comprensión por parte
del cliente
Consecuentes
Resultado de la puesta en funcionamiento del
sistema
De Compatibilidad
Dependientes de sistemas particulares o procesos
de negocio de la organización
56
28
Proceso de Gestión de Requisitos

Planificación de la gestión de requisitos:
Esta etapa establece el nivel de detalle
necesario en la gestión de requisitos
Durante la etapa de gestión de
requisitos, habrá que decidir sobre:
1. La identificación de requisitos
2. Un proceso de gestión del cambio
3. Políticas de rastreo/trazabilidad
4. Ayuda de herramientas CASE
57
Proceso de Gestión de Requisitos: trazabilidad

Relaciones entre Requisitos y Requisitos – Diseño
Cuando se proponen cambios, se debe rastrear el
impacto de estos cambios
La trazabilidad es una propiedad de la especificación
de requisitos que refleja la facilidad de encontrar
requisitos relacionados.
Tres tipos de información de trazabilidad que pueden
ser mantenidos:
1. La información de rastreo de la fuente
2. La información de rastreo de los requisitos
3. La información de rastreo del diseño
58
29
Proceso de Gestión de Requisitos: trazabilidad
Matrices y Árboles de Trazabilidad
59

Gestión de Cambios de los requisitos:
La gestión del cambio se debe aplicar a
todos los cambios propuestos
Ventajas de utilizar un proceso formal de
gestión de cambios:
Todos los cambios propuestos son tratados de
forma consistente
Todos los cambios en el documento de requisitos
se hacen de forma controlada.
60
30
Proceso de Gestión de Requisitos: fases
Etapas principales en un proceso de

gestión de cambio
Problema Requisitos
Identificado Análisis del Problema Análisis del Cambio Implementación Revisados
y Especificación y del
del Cambio Cálculo de Costes Cambio
61

En cambios urgentes
Tentación de hacer ese cambio al sistema y
documento de requisitos
Esto conduce a un desfase entre a que la
especificación de requisitos y la implementación
del sistema
En procesos de programación extrema
No se realiza un proceso formal de gestión de
cambios
Los cambios de alta prioridad se realizan en la
próxima iteración
62
31
Proceso de Gestión de Requisitos: conceptos
Línea Base
Conjunto de requisitos funcionales y no-
funcionales que el equipo del proyecto se ha
comprometido a implementar en una release
específica
Una versión aprobada de la especificación de
requisitos del software
63
Proceso de Gestión de Requisitos: buenas prácticas
Definir un Proceso de Control de Cambios

Establecer un Grupo (o comité) de Control de
cambios (GCC)
Realizar análisis de Impacto sobre los cambios
Crear líneas Base y controlar las versiones de
los requisitos
Mantener la historia de los cambios
Seguir el estado de los requisitos
Medir la volatilidad de los requisitos
Usar herramientas de gestión de requisitos
Crear matrices de trazabilidad de los requisitos
64
32
Proceso de Gestión de Requisitos: Posibles Roles
GCC: Grupo de Control de Cambios, grupo de personas

que deciden aprobar o rechazar las peticiones de
cambios para un proyecto específico
Promotor del cambio: Persona autorizada que solicita
la petición de cambio de requisitos
Evaluador: Analiza el impacto de la petición de cambio
(puedes ser técnico, martketing, cliente o combinación)
Modificador: El que realiza el cambio como
consecuencia de un petición de cambio aprobada
Verificador: Persona que determina si el cambio se ha
realiado correctamente.
Validador: Persona del cliente que valida la
implementación del cambio realizado
65

Posibles estados de una Petición de Cambio
SOLICITUD DE CAMBIO DEL PROMOTOR
ENVIADA
EVALUADOR REALIZA ANÁLISIS DE IMPACTO
EVALUADA RECHAZADA
GCC APRUEBA PETICIÓN
CAMBIO CANCELADO
APROBADA
FALLADA
VERIFIC.
MODIFICADOR REALIZA CAMBIO Y PETICIÓN DE VERIF.
CAMBIO CANCELADO
CAMBIADA CANCELADA
LOS PRODUCTOS
HA INSTALADO
MODIFICADOR
VERIFICADOR HA CONFIRMADO EL CAMBIO

REQUERIDA Y
NO VERIFIC.
VERIFICADA
CAMBIO CANCELADO
GCC CIERRA LA PETICIÓN
CERRADA
66
33
Resumen – Puntos Clave

Proceso de Ingeniería de requisitos
Estudio de la Viabilidad
Análisis
Especificación
Validación
Gestión
Proceso para gestionar y controlar cambios
en los requisitos SW de un sistema
67
34

IngenieriaRequisitos 1

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

IngenieriaRequisitos 1

Cargado por

Copyright:

Formatos disponibles

Ingenier

Ingeniería del Software de Gestión

Ingeniería de Requisitos: definición

¿Qué es la Ingeniería de Requisitos?

Proceso de Desarrollo de Requisitos

3. Especificación o documentación de requisitos

Proceso de Desarrollo de Requisitos

Proceso de Desarrollo de Requisitos

Viabilidad Análisis Especificación Validación Gestión

Análisis Especificación Validación Gestión

Captura y Análisis: stakeholders

No saben lo que quieren en realidad

Captura y Análisis: stakeholders

Ejemplo: cajero automático (ATM) de un banco

Captura y Análisis: actividades

Captura y Análisis: resumen

La captura y análisis de requisitos es un

Captura y Análisis: problemas típicos

Problemas a la hora de hacer una captura de requisitos:

Captura y Análisis: pasos

Captura y Análisis: técnicas

Captura y Análisis: técnicas de recolección de información

Principales técnicas de captura y análisis de

Técnicas de recolección de información: cuestionario

Cuestionario: Medio de recogida de información de manera

PUESTO: vendedor de mostrador

1. ¿Qué pasos sigue para gestionar el cobro de una venta

Técnicas de recolección de información

Cada tipo de entrevista requiere un

Técnicas de recolección de información: entrevistas

EL ENTREVISTADO PUEDE PRESENTAR: EL ENTREVISTADOR DEBE POSEER:

PASIVIDAD, INHIBICION ☺ CIERTAS CUALIDADES PERSONALES

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

Técnicas de recolección de información: entrevistas

Técnicas de recolección de información: entrevistas

Técnicas de recolección de información: entrevistas

PROXIMIDAD FISICA CABEZA

Técnicas de recolección de información: entrevistas

Cualidades del Entrevistador

Técnicas de recolección de información: entrevistas

Técnicas de recolección de información: entrevistas

Técnicas de recolección de información: entrevistas

Realización y conducción de la Entrevista

Técnicas de recolección de información: entrevistas

Técnicas de Recolección de Información: Workshops colaborativos

Técnica de extracción de en la que se promueve

Análisis Especificación Validación Gestión

Técnicas de Recolección de Información: Workshops colaborativos

Técnicas de Recolección de Información: Workshops colaborativos

Técnicas de recolección de información: prototipado

Versiones reducidas, demos o conjuntos de pantallas

Técnicas de recolección de información: prototipado

Tipos principales de prototipos:

“No sé exactamente lo que quiero, pero lo sabré cuando lo vea”

Captura y Análisis de Requisitos: Ejercicio 1

Elaborar un cuestionario para el análisis

Análisis Especificación Validación Gestión

Captura y Análisis de Requisitos: Ejercicio 2

Datos de cada pez:

Análisis Especificación Validación Gestión

Ejemplo de requisito no verificable:

Hay que eliminar de la ERS los requisitos no verificables

Especificación de requisitos: estructuración

Especificación de requisitos: estructuración