Free Tema5

Tema5.
pdf
Anónimo
Ingeniería de Requisitos
3º Grado en Ingeniería Informática
Escuela Politécnica Superior de Córdoba

Universidad de Córdoba
Reservados todos los derechos.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Tema 5: Técnicas de educción de requisitos
1. Entrevista no estructurada
Las entrevistas son la técnica de elicitación más utilizada y son inevitables en
cualquier desarrollo.
La Entrevista no Estructurada es aquella en la que las preguntas no están bien

de nidas o si lo están pueden suscitarse cambios en la forma de adquisición de
conocimientos. Se utilizan cuando una investigación está comenzando o es de gran
interés obtener la información de forma inmediata.

Se recomienda el uso de esta técnica cuando el Ingeniero de Requisitos tiene
formación Alta.
2. Entrevista estructurada
Se identi can 3 fases:
1. Preparación de entrevistas:
• Estudiar el dominio del problema: Conocer la terminología básica del

dominio del problema.
• Seleccionar a las personas a las que se va a entrevistar: Enfoque top-down,

empezando por los directivos y terminando por los futuros usuarios.
• Determinar el objetivo y contenido de las entrevistas.
• Plani car las entrevistas: Fecha, hora, lugar y duración.
2. Realización de entrevistas. Se distinguen tres etapas:
• Apertura: El entrevistador debe presentarse e informar al entrevistado de la

razón de la entrevista, qué se espera conseguir, cómo se utilizará la
información, etc.
• Desarrollo: No debería durar más de dos horas, siendo un 20% del tiempo
para el entrevistador y un 80% para el entrevistado. Debe contemplarse la
posibilidad de una tercera persona que tome notas o grabe la entrevista. 
• Terminación: Recapitulación sobre la entrevista para con rmar que no ha

habido confusiones en la información recogida. Dejar abierta la posibilidad
de volver a contactar para aclarar dudas.
1
fi
fi
fi
fi
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-4283477
3. Análisis de las entrevistas.
Entrevista estructurada Entrevista no estructurada
Pros • Asegura la elaboración • El entrevistador tiene mayor

uniforme de las preguntas exibilidad al realizar las
para todos los que van a preguntas adecuadas a quien
responder.
responde.
• Fácil de administrar y • El entrevistador puede

evaluar.
explotar áreas que surgen
espontáneamente durante la
• Evaluación más objetiva de
entrevista.
quienes responden y de las

respuestas.
• Puede producir información
sobre área que se minimizaron
• Se necesita un limitado
o en las que no se pensó que
entrenamiento del
fueran importantes.
entrevistador.

• Resulta en entrevistas más
pequeñas.
Contras • Alto costo de preparación.

• Puede utilizarse
negativamente el tiempo.
• Los que responden pueden

no aceptar un alto nivel en la • Los entrevistadores pueden
estructura y carácter introducir sus sesgos en las
mecánico de las preguntas.
preguntas o al informar de
resultados.
• Un alto nivel en la estructura

puede no ser adecuado para • Puede recopilarse información
todas las situaciones.
extraña.
• El alto nivel en las • El análisis y la interpretación

estructuras reduce de los resultados pueden ser
responder de forma largos.
espontánea y la habilidad
• Toma tiempo extra recolectar
del entrevistador para
los hechos esenciales.
continuar con comentarios
hacia el entrevistado.
2
fl
Llévate 1 año de WUOLAH PRO con BBVA. ¿Cómo? ¡+Info aquí!
3. Observación de tareas habituales
El ingeniero de requisitos interviene pasivamente en el entorno donde se ejecuta la
función o se desempeñan los informantes.
Fases:
1. Tipos de observación:
• Observar a una persona o actitud sin que el observado se de cuenta y su
interacción por parte del analista.
• Observar una operación sin intervenir, pero estando la persona observada

consciente de la observación.
• Observar y a la vez estar en contacto con las personas observadas.
2. Preparación para la observación:
• Determinar y de nir aquella que va a observarse.
Estimar el tiempo necesario de observación.

•
• Obtener la autorización de la gerencia para llevar a cabo la observación.
• Explicar a las personas observadas qué se va a hacer y por qué.
3. Conducción de la observación:
• Familiarizarse con los componentes físicos del área inmediata de

observación.
• Mientras se observa, medir el tiempo en forma periódica.
• Anotar lo observado lo más especí camente posible.
• Abstenerse de realizar comentarios cualitativos o de juicio de valores.
• Observar las reglas de cortesía y seguridad.
4. Secuela de la observación.
• Documentar y organizar formalmente las notas.
• Revisar los resultados y conclusiones junto con la persona observada, el

supervisor inmediato y posiblemente otro de sistemas.
Se recomienda su uso en casos en que se ha tenido algo de formación.
3
fi
fi
4. Veinte preguntas
El Ingeniero de Requisitos presenta un caso al usuario y este realiza veinte
preguntas para dar solución al problema.
Permite conocer la información relevante a manejar en el caso presentado.

Requiere tener un conocimiento inicial de los procesos involucrados.
5. Incidentes críticos
Es una mezcla de entrevista estructurada y análisis de protocolos. El Ingeniero de
Requisitos debe identi carse eventos o situaciones ocasionales o críticas.
EL objetivo es obtener una completa cuenta de solución del caso en cuestión,

describiendo los factores que in uyen en él. Se pide a los usuarios que describan
casos particularmente interesantes o difíciles.
Es preferible que el Ingeniero de Requisitos tenga alguna formación en la técnica,

pero no es estrictamente necesario.

6. Clasi cación de conceptos/Laddering
Estas técnicas están relacionadas y se aplican conjuntamente. El ingeniero de
requisitos debe interactuar con el informante a través de un juego de cartas que
representan conceptos. Debe conducir la sesión con certeza, sabiendo qué pedir
en cada momento y variar las preguntas según los objetivos perseguidos.
La técnica sólo se aplicará si el ingeniero de requisitos tiene formación en ella.
7. Cuestionarios
El ingeniero de requisitos debe conocer cómo crear un cuestionario adecuado. Si el
cuestionario es distribuido a muchos usuarios (clientes) se llama survey.
Son útiles en dominios donde se requiere recolectar un gran número de enfoques

de una situación o para contrastar opiniones.
Una variante al cuestionario es la compleción de oraciones.
8. Análisis de tareas
Es descomponer tareas en subtareas o pasos y analizarlos para capturar la
información y destreza requerida para ejecutarlas. Consiste en llegar a la
4
fi
fi
fl
clasi cación de los factores implicados en la solución del problema y la
identi cación de las tareas atómicas necesarias. Es necesario identi car las
acciones y conceptos de forma taxonómico.
9. Análisis de protocolos
Es similar a la observación de tareas habituales.
Es particularmente útil cuando los casos se han seleccionado previamente y revela

una gran cantidad de detalles interesantes. También es útil para extraer información
sobre heurísticas que los usuarios utilizan en la solución de problemas que no
pueden explicar.

La técnica consiste en grabar en un protocolo el comportamiento de los usuarios
mientras trabaja en la solución del problema. Ese protocolo se transcribe y analiza
para convertirlo en un conjunto de razonamientos que llevan a la solución del
problema.
El protocolo puede ser: copia literal, copia del contenido semántico (parafraseado),
generación de una verbalización a partir de la información utilizable (inferencia) y la
recuperación de la información previamente considerada (recuerdo).
Se recomienda su uso sólo cuando el ingeniero de requisitos tiene una formación

alta en la técnica.
10. Emparrillado
Es una técnica donde el informante es interpelado por el ingeniero de requisitos
para establecer una valoración de un conjunto de elementos y características.
Se utilizan métodos no simples para establecer relaciones entre los datos.
Tanto los procedimientos de la sesión como los del análisis requieren el

conocimiento teórico y una ejercitación mínima respecto de su aplicación práctica.
Se recomienda su uso en casos de alta formación del ingeniero de requisitos.
11. Tormenta de ideas

Es una técnica donde un conjunto de personas interactúan para generar ideas
respecto a algún aspecto del proyecto de desarrollo. El ingeniero de requisitos
actúa como moderador.
El equipo está formado por:
5
fi
fi
fi
• Director: Figura principal y encargado de dirigir la sesión. Es un experto en
pensamiento creador. Su función es formular claramente el problema y que
todos se familiaricen con él. Al nal, clasi cará las ideas de la lista
proporcionada por el secretario.
• Secretario: Registra por escrito las ideas según surgen. Las enumera,
reproduce elmente, redacta y se asegura de que todos están de acuerdo
con lo escrito. Realiza una lista de tareas.
• Participantes: Su función es producir ideas.
Fases de aplicación
• Descubrir hechos: Al menos un día antes, el director comunica los temas a
tratar. En la sesión se determina el problema, delimitándolo, precisándolo y
clasi cándolo. Se plantea el problema, recogiendo las experiencias que se
poseen o consultando documentación.
• Producir ideas: Se busca producir una gran cantidad de ideas. Al día

siguiente se pedirá a los participantes una lista de ideas que puedan haber
surgido.
• Descubrir soluciones: Se elabora una lista de nitiva de ideas para seleccionar

las más interesantes. Se establecen criterios de conveniencia para cada idea.
Si el ingeniero de requisitos no tiene conocimiento de la técnica puede aplicarse

igualmente.
12. Técnica nominal de grupo

Es una forma de estructurar reuniones de pequeños grupos que permiten combinar
juicios individuales y usarlos en situaciones de incertidumbre o desacuerdo. Es útil
en identi car problemas, explorar soluciones y establecer prioridades.
Tiene cuatro pasos:
1. Generación por escrito de ideas: Los miembros se reúnen y se les presenta

un problema. Cada uno escribe sus ideas.
2. Round Robin: Cada miembro tiene la oportunidad de presentar su idea al

grupo por turnos. Todas son registradas.
3. Discusión secuencial de la lista de ideas: El grupo discute las ideas para

aclararlas y las evalúa.
6
fi
fi
fi
fi
fi
fi
4. Votación: Cada miembro cali ca las ideas. La decisión nal es la idea con la
cali cación más alta.
13. Entrevista de grupo

Tiene 3 etapas:
1. Establecer la relación con el grupo, estructurar las reglas de interacción del
grupo y el conjunto de objetivos.
2. Intentar provocar discusiones intensas y acaloradas en áreas relevantes.
3. Intentar sumar las respuestas del grupo para determinar la amplitud del
acuerdo.
El proceso de iteración produce ventajas:
• Bola de nieve: Cada individuo es capaz de ampliar y re nar sus opiniones en

la interacción con los otros miembros del grupo.

• Estimulación: Una entrevista en grupo ofrece más estimulación que una
estándar.
• Seguridad: La seguridad de estar entre una multitud anima a los miembros a

expresar opiniones y conocimientos.
• Libertad: Los individuos no están sometidos a presión que pueda condicionar

sus respuestas.
• Votación: Enfatiza el encontrar una solución de compromiso a un problema.
14. Encuestas
Recogen información de una porción de la población de interés. La información se
recoge de manera que a cada individuo se le hacen las mismas preguntas de la
misma manera.
Todos los resultados de la encuesta deben presentar en resúmenes anónimos.
• Tamaño de la muestra: Una muestra de tamaño moderado es su ciente

estadística y operacionalmente. Las encuestas más comunes son por correo,
teléfono y en persona.
• Preocupaciones potenciales: La calidad de una encuesta es determinada por

su propósito y por la forma en que es conducida. Deben llevarse a cabo para
obtener información estadística sobre algún tema. 
7
fi
fi
fi
fi
fi
15. Método Delphi
Es una técnica de predicción cualitativa cuya losofía se basa en el establecimiento
de previsiones de futuro basadas en las opiniones subjetivas procedentes de un
grupo de expertos.
Logra una convergencia de las respuestas sobre la importancia y ocurrencia de una

serie de sucesos. Es caracterizada por el anonimato de las respuestas.
Su procedimiento es:
1. Se de ne el tema.
2. Se elabora el cuestionario.
3. De ne el panel de expertos.
4. Se envía el cuestionario a todos los individuos elegidos, a los que se le pide

que validen y respondan las cuestiones y agreguen otras.
5. Una vez recogidos los cuestionarios, se tabulan las respuestas para obtener

los resultados representativos del grupo.
6. En una segunda ronda, se vuelve a enviar el cuestionario con la contestación

del grupo, representada por la media y la dispersión de opinión mediante el
primer y tercer cuartil.
16. Observación participativa

El ingeniero de requisitos participa en las funciones del dominio intentando
aprender in situ la información base necesaria a los requisitos. Además de observar,
puede ejecutar las funciones interactuando con los informantes e inquiriéndoles
sobre cómo ejecutarlas.
Es recomendable para todos los valores de experiencia del ingeniero de requisitos.
17. Prototipo rápido

Se inicia con la de nición de los objetivos globales para el software, luego se
identi can los requisitos conocidos y las áreas del esquema en donde se necesita
más de nición. Se utiliza para dar al usuario una vista preliminar de parte del
software.
El prototipo nos asegura que nuestro software sea de mejor calidad y que su
interfaz sea de agrado para el usuario.
8
fi
fi
fi
fi
fi
fi
Etapas
• Recolección y re namiento de requisitos que establezcan los objetivos del
prototipo.
• Modelado, diseño rápido y de nición de las funcionalidades.
• Construcción del prototipo.
• Desarrollo y evaluación del prototipo por el cliente.
• Re namiento del prototipo.
• Producto de Ingeniería. 

Cómo se lleva a cabo
Se comienza elaborando un prototipo del producto nal.
Una maqueta es una versión simpli cada del sistema software deseado.
Representa la interfaz del sistema y las conexiones entre pantallas. Se pueden
codi car partes del sistema, llamado “prototipo funcional”.
Ventajas
• No modi ca el ujo del ciclo de vida.
• Reduce coste, esfuerzo y aumenta la probabilidad de éxito.
• Exige disponer de las herramientas adecuadas.
• Es útil cuando el cliente conoce los objetivos generales para el software, pero
no identi ca los requisitos detallados de entrada, procesamiento o salida.
• Mejora la usabilidad.
• Ofrece un mejor enfoque cuando el responsable del desarrollo de software

está inseguro de la e cacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debería tomar la interacción humano-
máquina. 
Para que sea efectivo

• Debe ser un sistema con el que se pueda experimentar.
• Debe ser comparativamente barato.
• Debe desarrollarse rápidamente.
• Énfasis en la interfaz de usuario.
9
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
• Equipo de desarrollo reducido.
• Herramientas y lenguajes adecuados. 
Desventajas
• El usuario ve que el prototipo funciona y piensa que es el producto
terminado.
• El desarrollador puede querer ampliar el prototipo para construir el sistema
nal sin considerar los compromisos de calidad y mantenimiento que tiene
con el cliente. 
Tipos de Modelo de Prototipos

• Modelo de Prototipos rápido: Metodología de diseño que desarrolla
rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el
próximo diseño es desarrollado con un nuevo prototipo.
• Modelo de Prototipos reutilizable: Sus partes o el conjunto pueden ser

utilizados para construir el producto real.
• Modelo de Prototipos Modular: Se añaden nuevos elementos sobre el

prototipo a medida que el ciclo de diseño progresa.
• Modelo de Prototipos Horizontal: Cubre un amplio número de aspectos y

funciones pero la mayoría no son operativas. Útil para evaluar el alcance del
producto.
• Modelo de Prototipos Vertical: Cubre un pequeño número de funciones

operativas. Útil para evaluar el uso real sobre una pequeña parte del
producto.
• Modelo de Prototipos de Baja- delidad: Se implementa con papel y lápiz,

emulando la función del producto real sin mostrar el aspecto real del mismo.
• Modelo de Prototipos de Alta- delidad: Se implementa de la forma más

cercana posible al diseño real en términos de aspecto, impresiones,
interacción y tiempo. 
Tipos de prototipos
• Desechable: Sirve para eliminar dudas de lo que quiere el cliente y para
desarrollar la interfaz que más le convenga.
10
fi
fi
fi
• Evolucionario: Modelo parcialmente construido que puede pasar de ser
prototipo a ser software, pero no tiene una buena documentación y calidad. 
Información obtenido con el uso del Prototipo

• Reacciones iniciales del usuario: El profesional de sistema obtendrá cómo
reaccionan los usuarios al trabajar con el prototipo y qué tan conveniente es
el acoplamiento entre las necesidades y las características modeladas en el
sistema.
• Sugerencias: Fruto de la relación de los usuarios con el prototipo. Indican al

profesional por qué caminos dirigirse para re nar el prototipo de forma que
satisfaga mejor las necesidades de los usuarios.
• Innovaciones; Características nuevas del sistema que no fueron

contempladas previamente a la interacción con el prototipo.
• Prioridades. 

Estrategias para el desarrollo de prototipos
• Prototipos por Pantallas: La interfaz entre el sistema y el usuario es la pantalla
de visualización. Su creación conduce a:
• Qué debe presentarse como información sobre la pantalla principal.
• Cuál pertenece a una pantalla de detalle.
• Prototipos para Procedimientos de Procesamientos: Las funciones de

procesamiento incluyen entradas, cálculos, recuperar información y
actividades de salidas. La aplicación se diseña para asegurar la detección de
errores. El objetivo es determinar si los procedimientos de aplicación fueron
desarrollados adecuadamente.
• Prototipos de funciones básicas: Solo es necesario desarrollar los módulos

básicos del sistema, los que forman el núcleo de la aplicación.
Otra variante de prototipo es el Storyboarding. Son dibujos o pantallas que

muestran secuencias típicas o interacciones con el sistema deseado.
La inexperiencia de un ingeniero de requisitos podría dar lugar a incertidumbre en

los resultados.
11
fi
18. Focus Group
Son reuniones grupales donde se anima a la discusión abierta de los individuos en
presencia del Ingeniero de Requisitos, que actúa como moderador pasivo.
Esta técnica puede:
• Facilitar la captura de propuestas de diseño.
• Facilitar consenso sobre conceptos del producto.
• Apoyar a usuarios en el análisis de su propio problema e identi car la

necesidad de cambio.
• Apoyar el desarrollo de un signi cado compartido del sistema que está

siendo especi cado.
19. Joint/Rapid Application Design (JAD/RAD)

Es un método donde los que tienen algún interés en el sistema trabajan juntos en

una sesión grupal dirigida por un facilitador, para especi car y realizar un desarrollo
preliminar de un sistema.
Sus roles son: líder de la sesión, usuarios representativos, especialistas, analistas,

representante de desarrollo y directivos.
Dura cinco días y el facilitador guía a los participantes de la sesión a través de

tareas: orientación, de nir requisitos de alto nivel, delimitar alcance del sistema,
identi car y estimar diseño, conclusiones y documentar resultados.
Se realizan las siguientes actividades:
• Inicio: Se de ne el ámbito y la estructura del proyecto.
• Desarrollo: Se identi can las salidas del proyecto y se debe conseguir el

consenso entre los participantes de modo que se materialice en los modelos.
• Finalización: Se valida la información de la sesión y se generan los productos

de la metodología propuesta. Si fuera necesario, se integran los productos de
salida.
Hay dos tipos de productos:
• De preparación: Historia y contexto del proyecto, los objetivos y límites, las

actividades del entorno del negocio que pueden afectar al éxito del proyecto
y los bene cios.
12
fi
fi
fi
fi
fi
fi
fi
fi
fi
De resultado de las sesiones de trabajo: Se establecen con anterioridad al
•
inicio de las reuniones.
El ingeniero de requisitos debería tener una notable experiencia en educción.
20. Escenarios/Casos de Uso

Es una descripción de un conjunto de posibles escenarios con un propósito común.
Ayuda a conocer la frontera del sistema y alcance de los requisitos.
Se debe identi car los actores externos al entorno del sistema que interactúan con
él. Para cada actor se identi can posibles casos de uso, se describen algunos
escenarios concretos para ilustran los casos de uso y se agrupan escenarios

similares en uno si son variaciones sobre un tema.
13
fi
fi

Free Tema5

Cargado por

Información del documento

Título original

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

Free Tema5

Cargado por

Copyright:

Formatos disponibles

Tema5.

3º Grado en Ingeniería Informática

Escuela Politécnica Superior de Córdoba

Reservados todos los derechos.

La Entrevista no Estructurada es aquella en la que las preguntas no están bien

Reservados todos los derechos.

• Estudiar el dominio del problema: Conocer la terminología básica del

• Seleccionar a las personas a las que se va a entrevistar: Enfoque top-down,

• Determinar el objetivo y contenido de las entrevistas.

• Plani car las entrevistas: Fecha, hora, lugar y duración.

2. Realización de entrevistas. Se distinguen tres etapas:

• Apertura: El entrevistador debe presentarse e informar al entrevistado de la

• Terminación: Recapitulación sobre la entrevista para con rmar que no ha

Entrevista estructurada Entrevista no estructurada

Pros • Asegura la elaboración • El entrevistador tiene mayor

• Fácil de administrar y • El entrevistador puede

quienes responden y de las

Reservados todos los derechos.

Contras • Alto costo de preparación.

• Los que responden pueden

• Un alto nivel en la estructura

• El alto nivel en las • El análisis y la interpretación

• Observar una operación sin intervenir, pero estando la persona observada

• Observar y a la vez estar en contacto con las personas observadas.

2. Preparación para la observación:

• Determinar y de nir aquella que va a observarse.

Estimar el tiempo necesario de observación.

Reservados todos los derechos.

• Obtener la autorización de la gerencia para llevar a cabo la observación.

• Explicar a las personas observadas qué se va a hacer y por qué.

• Familiarizarse con los componentes físicos del área inmediata de

• Mientras se observa, medir el tiempo en forma periódica.

• Anotar lo observado lo más especí camente posible.

• Abstenerse de realizar comentarios cualitativos o de juicio de valores.

• Observar las reglas de cortesía y seguridad.

• Documentar y organizar formalmente las notas.

• Revisar los resultados y conclusiones junto con la persona observada, el

Se recomienda su uso en casos en que se ha tenido algo de formación.

Permite conocer la información relevante a manejar en el caso presentado.

EL objetivo es obtener una completa cuenta de solución del caso en cuestión,

Es preferible que el Ingeniero de Requisitos tenga alguna formación en la técnica,

Reservados todos los derechos.

La técnica sólo se aplicará si el ingeniero de requisitos tiene formación en ella.

Son útiles en dominios donde se requiere recolectar un gran número de enfoques

Una variante al cuestionario es la compleción de oraciones.

Es particularmente útil cuando los casos se han seleccionado previamente y revela

Reservados todos los derechos.

Se recomienda su uso sólo cuando el ingeniero de requisitos tiene una formación

Se utilizan métodos no simples para establecer relaciones entre los datos.

Tanto los procedimientos de la sesión como los del análisis requieren el

11. Tormenta de ideas

El equipo está formado por:

• Producir ideas: Se busca producir una gran cantidad de ideas. Al día

Reservados todos los derechos.

• Descubrir soluciones: Se elabora una lista de nitiva de ideas para seleccionar

Si el ingeniero de requisitos no tiene conocimiento de la técnica puede aplicarse

12. Técnica nominal de grupo

Tiene cuatro pasos:

1. Generación por escrito de ideas: Los miembros se reúnen y se les presenta

2. Round Robin: Cada miembro tiene la oportunidad de presentar su idea al

3. Discusión secuencial de la lista de ideas: El grupo discute las ideas para

13. Entrevista de grupo

2. Intentar provocar discusiones intensas y acaloradas en áreas relevantes.

• Herramientas y lenguajes adecuados. 