Elicitación de requerimientos

Elicitación de Requisitos
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Junio, 2021
Loja, Ecuador

3
1. Introducción
2. Proceso
3. Técnicas de recolección
4. Entrevista
5. Brainstorming
6. JAD
7. Prototipo
8. Escenarios
9. Card Sorting
Agenda

4
Introducción
Elicitación de requerimientos
Se descubren los requerimientos por medio de consultas con los stakeholders
(involucrados/interesados, ejem: clientes, usuarios, programadores)
Ingeniería de
requisitos
Concepción
de Requisitos
Desarrollo de
requisitos
Elicitación
Análisis
Especificación
Verificación
Mantenimiento
de requisitos

5
Introducción
Inmersión del negocio
• No podemos analizar o diseñar lo que no conocemos
• El primer paso es buscar pasos de entendimiento del producto / negocio /
servicios
• Estudiar el contexto de la empresa / problema / dominio
¿Dónde conseguimos esa información?
Debemos conocer a nuestro cliente, su negocio, y como funciona, cuál es su
contexto en el que se desenvuelve y hacia donde quiere llegar

6
Introducción
• Se debe comprender el
funcionamiento del sistema
dentro de la organización y
como interactúan con otros
sistemas ya existentes
• Se debe entender las
funciones de todos los
involucrados, así como los
rol de cada uno en el
sistema
• Se deberán entender los
detalles del problema donde
se utilice el sistema. Ej.
Entender la organización
particular de una biblioteca
• Adquirir conocimiento o
comprender el funcionamiento
de términos relacionados con
el sistemas. Ej. Sistema de
biblioteca deberán entender
algunos términos como índices
de clasificación de libros
Dominio de
la aplicación
Problema a
resolver
Contexto de
la
organización
Necesidades
y
restricciones
de
stakeholder

7
Introducción
¿Cuál es el propósito de la obtención de requisitos?
El Ing de Requisito va a recopilar / reunir / obtener todos los requisitos
para el programa / proyecto / sistema / en cuestión
Los pasos:
1. Definir el alcance del sistema
2. Obtener conocimiento de dominio
3. Decidir sobre las técnicas de obtención para usar
4. Obtenga los requisitos
5. Realizar análisis de brechas
6. Completar los requisitos

8
Introducción
Fuente de requisitos

9
Introducción
La adquisición efectiva de lo requisitos es muy importante
Si no se descubren lo requisitos reales del usuario, nunca estará satisfecho con
el producto final
El descubrimiento de requisitos es el proceso de recopilación de información sobre el
sistema requerido y los sistemas existentes, así como de separar, a partir de esta
información, los requisitos del usuario y del sistema
Las fuentes de información durante la fase de descubrimiento de requisitos incluyen
documentación, participantes del sistema y especificaciones de sistemas similares

10
Introducción
 Existen varios proceso para llevar a cabo la adquisición y análisis de requisitos
 Un proceso general puede incluir las siguientes etapas

11
Introducción
 Determinación de objetivos
 Los objetivos organizacionales deben establecerse, incluyendo las metas generales de
la organización, una descripción del problema a resolver, la justificación y necesidad
del sistema, las restricciones del sistema
 Conocimiento de antecedentes
 Espaparse de información sobre el sistema, incluyendo conocer la organización
dónde se instalará el sistema, el dominio de aplicación y los sistema existentes

12
Introducción
 Organización del conocimiento
 Las etapas anteriores generan una gran cantidad de conocimiento el cual debe ser
filtrado y organizado. Esto incluye identificar a los stakeholders, sus roles en la
organización, priorización de metas y descartar conocimiento que no contruye a los
requisitos del sistema
 Recolección de requisitos
 Se consultan a los stakeholders del sistema para recolectar requisitos, utilizando
una técnica adecuada

15
Proceso
La identificación de los distintos stakeholders
se puede realizar, por ejemplo, mediante la
caracterización de los roles o puestos que
existen en la organización
Hay varias formas de identificar quienes son
las partes interesadas. Se puede, por ejemplo,
preguntar al cliente, examinar el organigrama
comparar con productos similares o analizar el
contexto del sistema
Debemos ver todo como un sistema, que áreas
están relacionadas con el proyecto.
Identificación de los stakeholders

16
Proceso
Identificación de los stakeholders
 Experto
 Un desarrollador
 Un inspector: This category
includes safety inspectors,
auditors, firemen, policemen, and
state agencies inspectors
 A negative stakeholder

18
Técnicas
Las Técnicas de Captura para Requisitos sirven para
 Conseguir que los interesados humanos articulen sus requisitos, y
 Recopilar el conocimiento sobre los requisitos del sistema
Este conocimiento debe estar estructurado:
 Partición → Agregando conocimiento relacionado
 Abstracción → Reconociendo generalidades
 Proyección → Organizándolo de acuerdo a una perspectiva

19
Técnicas
Categoría principal Componentes
Técnicas tradicionales Cuestionarios; Surveys; Entrevistas (de comienzo y final
abierto, estructuradas); Análisis de documentos (formularios,
organigramas, modelos, estándares, manuales, normas, etc.).
Técnicas grupales Brainstorming; Focus Groups; RAD/JAD
Prototipos Solo o combinado con otras técnicas
Técnicas orientadas por
modelos
Métodos basados en objetivos; métodos basados en escenarios,
Story Card
Técnicas cognitivas Laddering; Card Sorting; Repertory Grids
Técnicas contextuales Métodos etnográficos (observación del participante);
Etnometodología; Análisis de conversación (estudio de
conversación e interacción)
Tabla: Taxonomía de técnicas de elicitación de Nuseibeh y Easterbrook

21
Técnicas
Empatizar con el usuario es fundamentalmente, entenderlo, descubrir el problema
que hay que solucionar y detectar esas verdades ocultas que nos sirvan como
detonador de una gran idea

22
Técnicas
Las principales Técnicas de Captura para Requisitos son:
 Entrevista
 Escenarios
 Observación
 Reutilización de requisitos
 Prototipo

24
Entrevista
¿Qué es una entrevista?
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. Es parte de
las técnicas tradicionales
Es una forma de diálogo formal o
informal entre dos o más personas
 El entrevistador busca respuesta a un
conjunto de preguntas planteadas
 El entrevistado se ve como una
fuente de información

25
Entrevista
El entrevistado puede presentar:
 Pasividad, inhibición
 No aceptación
 Rechazo
 Agresividad
El entrevistador debe poseer:
 Ciertas cualidades personales
 Conocimiento de técnicas
 Actitud adecuada
 Experiencia práctica

26
Entrevista
Cualidades o Habilidades
Ser buen
oyente
Busque
Hechos y
opiniones
Elimine
prejuicios
Ser
Observador y
escuchador
Ser
objetivo e
imparcial
Capacidad
empatía
Comprensión
Ser cordial
y accesible
Paciente
Prudente
sincero
Cordial y
accesible

27
Entrevista
Errores comunes
Arrogancia
Criticar
Falta de cortesía
Falta de interés
Interrumpir

28
Entrevista
Errores comunes
https://www.youtube.com/watch?v=MlWiPuH4m2E
Entrevista correcta
https://www.youtube.com/watch?v=zucejhrDPy8

30
Entrevista
Problemas
Discrepancia de objetivos
Barreras de comunicación
 Oir lo que queremos
 Pasar por alto las ideas contrarias
 Prejuicios sobre el emisor
 Diferente significado de las palabras
 Comunicación no verbal
 Emociones
 Ruido
 Distancia
Cómo eliminar las barreras
 Adaptarse al mundo del receptor
 Utilizar el diálogo
 Sirvase de la comunicación directa
 Insistir varias veces
 Utilizar lenguje sencilo y directo
 Reducir las distancias

31
Entrevista
Factores a considerar para detectar problemas durante las entrevistas:
Comunicación verbal
 Contacto corporal
 Proximidad física, orientación, postura
 Ademanes, cabeza, expresión facial, ojos
 Apariencia
 Aspectos del lenguaje
“Escuchar y responder”
Vocabulario
Expresión verbal

32
Entrevista
Entrevistas Cerradas
Los stakeholders responden a un
conjunto predefinidos de preguntas
Entrevistas Abiertas
No hay un programa predefinido. Se
evaluán una serie de cuestiones que se
discuten de una forma no muy
estructurada
En la práctica se debe hacer una mezcla de las dos

33
Entrevista
Ventajas
 Brinda mayor comodidad y es más
interesante para el entrevistado
 Respuestas más detalladas
 Permite mayor espontaniedad
 Permite al entrevistado adaptarse al
vocabulario del entrevistado
Desventajas
 Se pueden obtener detalles
innecesarios
 Se puede perder de vista el control
de la entrevista
 Consume más tiempo
Preguntas abiertas

34
Entrevista
Ventajas
 Permite ahorrar tiempo
 Facilita la comparación de
respuestas
 Permite al entrevistador mantener el
control de la entrevista
Desventajas
 Puede ser molestoso para el
entrevistado
 Perdida de detalles en las respuestas
Preguntas cerradas

35
Entrevista
Definir el propósito
Puntos claves
Identificar posibles
entrevistados
Evite preguntas largas o
complejas
Use preguntas abiertas y
cerradas
Vocabulario del negocio

36
Entrevista
Fases de una entrevista
 Preparación
 Conducción / Realización
 Análisis
Preparación
 Investigar la situación
 Identificar las personas a entrevistar
 Preparación del objetivo y contenido
 Planificar lugar y hora
Conducción / Realización
 Apertura
 Desarrollo
 Métodos directos:
 Preguntas abiertas, directas, cerradas, si/no
 Sondeo
 Métodos indirectos
 Utilizar palabra y frases apropiadas
 Asentir y dar muestras de escuchar
 Repetir las respuestas dadas, resumir
 Reflejar ideas, sentimientos
 Pausas
 Terminación

37
Entrevista
 Datos de las personas: usuarios, interesados, etc.
 ¿Qué trabajo realizan? ¿Para quién?
 ¿Qué interfiere con su trabajo?
 ¿Qué cosas hacen su trabajo más fácil o más difícil?
 Datos: de entrada y salidas clave, datos ya existentes
 Lista de entradas y salidas
 ¿Cuá es el problema? ¿Cómo se resuelve ahora? ¿Cómo le gustaría que se
resolviera?
 Procesos: propósito, objetivo y metas
 ¿Quién necesita la aplicación?
 ¿Cuántos usuarios la van a usar y de qué tipo?

38
Entrevista
 Ubicaciones: lugares involucrados, contexto de los usuarios
 Entorno de los usuarios, computadoras, plataformas
 Aplicaciones relevantes existentes
 Experiencias de los usuarios con este tipo de aplicación, expectativas de tiempo de
entrenamiento
 Otros
 ¿Existen requisitos legales, regulatorios u otros estándares que deban ser tenidos en
cuenta?

39
Entrevista
Análisis
 Pasar a limpio las notas
 Reorganizar la información y contrastarla
 Evaluar la entrevista → mejora de aspecto
 Conclusiones
 Fracaso
 Entrevista deficiente
 Mala relación
 Acusaciones
 Éxito
 Planificación
 Flexibilidad
 Personalidad
 “No existe la entrevista ideal”

40
Entrevista
Fecha: Hora:
Entrevistado:
Empresa:
Rol:
Entrevistador:
Problema:
Objetivo:
Preguntas
Formato de la entrevista

41
Entrevista
Formato de la entrevista

42
Entrevista
El diálogo con el señor Páez gerente de la empresa TRANS&TURIS.
• Gracias por recibirme señor Páez, disculpe que tome algo de su tiempo
• No se preocupe, dígame ¿en qué puedo servirle?
• Estoy a cargo del desarrollo del sistema de venta de boletos y control de reservaciones de la empresa, y, debido a su posición
como gerente me interesaría tener su perspectiva acerca de la situación actual, es importante que usted como el encargado de
la organización pueda brindarme sus criterios
• Escucho pues, tiene algo en particular que le interese
• Pues si, puede informarme como esta marchando el proceso?
• Mire, actualmente el proceso de venta de boletos se ha hecho demasiado tedioso, la cantidad de destinos que cubrimos y los
varios turnos que se tienen hacia esos destinos ha hecho que el control manual de las ventas y reservaciones sea mucho más
complejo que antes. Desde mi punto de vista esto es un inconveniente para la empresa ya que la imagen que se presenta hacia
los usuarios de nuestros servicios se esta perdiendo por esta clase de errores
• ¿Y en que aspectos cree que el sistema podría ayudarle a mejorar esto?
• Me parece que a través del uso de ordenadores, las tareas de venta de boletos podrían mejorar la organización y el exceso de
papeleo existente en la actualidad, mire que en la actualidad son tres listados que deben actualizarse por la venta de un boleto,
esto lleva demasiado tiempo y tienen a cometer muchos errores. Por ejemplo, el listado de pasajero de un turno para un viaje
no siempre se actualiza por errores manuales, vendiendo hasta dos o tres veces el mismo asiento, lo cual causa incomodidad
en los pasajeros, he tenido un sinnúmero de quejas por este motivo
• Bla, bla, bla
Ejemplo

43
Entrevista
Redacción de los requisitos funcionales del analista
• El sistema debería registrar los pasajes vendidos en la lista de pasajeros de cada turno
• El sistema debe imprimir el boleto entregado a cada pasajero
• Debe evitar la venta duplicada de asientos en un mismo turno
• El sistema debe permitir reservaciones de pasaje para cada turno especifico
• El sistema deberá controlar la capacidad máxima de cupos de cada bus de la empresa
• Etc., etc., etc.
Ejemplo

44
Entrevista
Otra parte del diálogo con el señor Páez …..
• … dígame, cuantas personas hacen la venta de boletos
• Actualmente se tienen tres personas en la boletería de las oficina y dos en las oficinal de la terminar terrestre.
• Todos ellos venden boletos a cualquier parte?
• Inicialmente fue así, pero ahora para evitar las confusiones los hemos dividido por destinos aunque eso no sean tan
convenientes, nos gustaría que en cualquier boletería pueda venderse boletos para cualquier destino
• Ya veo, y los empleado de boletería tiene conocimiento o les parecen familiares los computadores?
• No, ninguno de ellos lo tienen, no son expertos en nada de eso
Ejemplo
Atributos del Sistema
• El sistema debe ser multiusuario
• El sistema debe ser de fácil uso

45
Entrevista
Ejemplo
Glosario de Términos
Término Definición
Bus Vehículo terrestre para transporte masivo
Viaje Documento de pago entregado al usuario para que lo presente al controlador durante el viaje
Turno
Ruta
Asiento

46
Encuesta
• Es un instrumento que consiste en un conjunto de preguntas u otros tipos de
indicaciones con el objetivo de recopilar información de un encuestado
• Éstas son típicamente una mezcla de preguntas cerradas y abiertas
Tipos de preguntas
• Abiertas: ayudan a recopilar datos cualitativos en el que el encuestado puede
responder de forma gratuita con pocas o ninguna restricción
• Dicotómicas: son pregunta cerrada de “sí/no”
• Opción múltiple: son un tipo de pregunta cerrada en la que el encuestado tiene
que seleccionar una sola o muchas preguntas de selección múltiple de una lista
dada de opciones

47
Encuesta
Ventajas:
● Es una forma fácil y rápida de recopilar
información necesaria
● Son prácticos. Puedes seleccionar las
preguntas, así como el formato
● Funciona bien para grandes poblaciones
de usuarios distribuidos en una gran
extensión geográfica
● Se pueden abordar asuntos relacionados
con características del software a
desarrollar
● Útil para conocer la opinión de los
usuarios sobre desarrollo del sistema
Desventajas:
● Falta de sinceridad
● Algunas preguntas son difíciles de
analizar
● Preguntas omitidas
● Diferencias en la comprensión e
interpretación

48
Encuesta – Proceso o Preparación
Decide qué tipo de información
deseas recolectar al administrar tu
cuestionario
• Se debe pensar en qué datos se
requieren y cómo se utilizarán
• Crear preguntas útiles, así como a
saber en qué orden colocarlas
• Idealmente, el cuestionario debe ser
corto
Piensa en preguntas que te ayudarán a
conseguir la información que necesitas
• Empieza con un rango amplio de
preguntas
• Luego reduce el número hasta que, de una
u otra manera, cada una de ellas se
relacione con tus metas
• Una buena idea utilizar preguntas abiertas
o cerradas, o una mezcla de ambas

49
Encuesta – Proceso o Preparación
Utiliza preguntas cerradas para
obtener respuestas específicas
• Las preguntas cerradas tienen un
rango específico de opciones para los
encuestados
• Las preguntas pueden requerir
respuestas como sí, no, verdadero,
falso, o pueden preguntarle al
encuestado si está de acuerdo o no con
una frase
Utiliza preguntas abiertas para
solicitar opiniones
• Las preguntas abiertas son una
oportunidad para que los encuestados
comuniquen sus experiencias o
expectativas específicas
Realiza tus preguntas de tal modo que
evites la confusión y el sesgo
• Evita las preguntas sugestivas
• Este tipo de preguntas indican que el
encuestador busca una respuesta
determinada y que limitará las
respuestas de los encuestados

51
Estudio de documentos – análisis de documentos
Técnica de investigación que consiste en realizar la lectura y el análisis de
la documentación (referente al dominio del problema) que existe dentro de
la empresa con el objetivo de recolectar la información necesaria para el
proceso de desarrollo, y realizar un resumen en un documento

52
Ventajas:
● Información confiable
● Técnica no intrusiva
● Bajo coste
● Puede indicar el comportamiento de la
entidad
● Enriquece el proceso de Requisitos.
● Aprovecha el material existente para
validar requisitos
● Complementa o ayuda a planear
actividades de elicitación con otras
técnicas
Desventajas:
• Escritos no homogéneos
• Disposición limitada de los documentos
• Puede ser difícil encontrar la información
importante
• Existen Retrasos en la entrega de
Información
• Hay duplicación innecesaria de la
información
• Tediosa y Poco Efectiva
• Puede haber información inválida o
desactualizada

53
Proceso
1. Selección del material
2. Revisión del material
3. Organización
4. Análisis de datos
5. Conclusiones
1. Preparación
Elaborar preguntas que deben ser respondidas por el
análisis.
2. Aplicación
Estudiar la documentación buscando responder las
preguntas formuladas inicialmente y documentando los
aspectos relevantes.
3. Finalización
Las respuestas tomadas por las preguntas iniciales deben
ser documentadas por una memoria de levantamiento que
debe ser validada por algún interesado con autoridad.

54
¿A quién se aplica?
No se necesita de una persona en sí, sino que se debe tener acceso a los documentos
para poder analizarlos
¿Cuándo se aplica?
• Cuando el cliente no está disponible para una entrevista, encuesta o similar.
• Cuando es necesario conocer el funcionamiento de la empresa más a fondo.
• Cuando se va a desarrollar un sistema muy grande, ya que puede facilitar la
comprensión del problema.
• En el caso de que se necesite acceder a información más precisa o datos
históricos
¿Quiénes participan?
• Cliente, que autoriza el acceso a los documentos
• Analista o equipo de analistas de documentación

55
¿De donde obtenemos la información?
• Documentación impresa: libros, proyectos
previos, archivos estadísticos, históricos, etc.
• Documentación electrónica: documentos
en formato digital
• Documentación gráfica: Gráficos de barras,
gráficos lineales, planos, fotografías, etc.
• Documentación audiovisual: videos y
audios que contienen información de
entrevistas, presentaciones, conferencias, etc.
• ¿Que le hacemos a esta información?
Separar el proceso antes mencionado en más partes
específicas:
• Selección del material: Recolección del
material útil
• Revisión del material: Clasificación del
material y separación de muy importantes y
poco importantes
• Análisis de datos: Analizar la información y
elaborar un documento con la interpretación
realizada
• Conclusiones: Cerrar el tema especificando
los puntos que clave y la información
fundamental

56

57

58
Estudio de documentos – Herramienta
Huddle: https://www.huddle.com
Espacios de trabajo Reportes ordenados de los documentos Trabajo colaborativo

59
• Read the Docs: https://readthedocs.org
• Swagger: https://swagger.io
• MAXQDA: https://es.maxqda.com/software-analisis-textos#
• ATLAS.ti: https://atlasti.com/es/
• Winmax: https://www.winmaxcorp.com/
• NUD*IST: https://nud-ist.waxoo.com/

60
Ejemplo

61
Observación
• Los sistemas de software no existen aislados
• Se usan en un contexto social y organizacional,
• Dicho escenario podría derivar o restringir los requerimientos del sistema de software
• A menudo satisfacer dichos requerimientos sociales y organizacionales es crítico para el éxito del
sistema
• Una razón por la que muchos sistemas de software se entregan, y nunca se utilizan, es que sus
requerimientos no consideran de manera adecuada cómo afectaría el contexto social y organizacional
la operación práctica del sistema
• La etnografía es una técnica de observación que se usa para entender los procesos operacionales y
ayudar a derivar requerimientos de apoyo para dichos procesos
• Un analista se adentra en el ambiente laboral donde se usará el sistema
• Observa el trabajo diario y toma notas acerca de las tareas existentes en que intervienen los
participantes
• Los factores sociales y organizacionales que afectan el trabajo, que no son evidentes para los
individuos, sólo se vuelven claros cuando los percibe un observador sin prejuicios

62
Observación
Es la técnica más conocida, también conocida como Etnografía
Entender como funcional el negocio
Ganar conocimiento sobre lo que ocurre en realidad; que no necesariamente es lo que está
documentado o dicho
Mejor opción para identificar requisitos de Usabilidad RNF
Hay dos tipos de realizar esta técnica: la pasiva y activa
 Pasiva: El observador no hace preguntas, se limita a tomar notas y no interferir en el
desempeño normal de las operaciones, no tiene contacto directo con el personal de la
empresa
 Activa: El observador puede conversar y efectuar tareas con el usuario

63
Observación
Observación
Usuarios de
acceso
difícil
Usuarios que no
saben expresar
su necesidad o
deseo
Usuarios que no
saben lo que
quieren o necesitan
Clientes que
no dominan
el negocio

Observación
Observación
Entrevista
Reuniones
Cuestionarios
Cómo complemento de otras técnicas

65
Observación
Algunos riesgos de la observación Algunas sugerencias
Desconocimiento de la perspectiva, representaciones y
posiciones de los sujetos observados Distanciamiento necesario
Efecto “novedad”, las primeras impresiones del
observador pueden tener un efecto distorsionador en los
recortes y en los juicios que se emitan con posterioridad.
La observación nunca es ingenua
Plantearse siempre hipótesis provisorias para ser
transformadas o ajustadas a partir de los datos relevados
Desconocimiento de la propia influencia en la situación Explicitar o pedir que se expliciten, siempre que sea
posible, los propósitos de la observación, las estrategias,
el uso que se le dará a la información y todo aquello que
se considere necesario.
Recomendaciones para iniciar una observación (i)

66
Observación
Algunos riesgos de la observación Algunas sugerencias
Focalización excesiva: derivada del desconocimiento
del contexto y la desconsideración de la simultaneidad
de variables
El recorte de la situación por observar y analizar no
puede ser ni excesivamente amplio, que no permita la
definición de problemas claros y precisos, ni
excesivamente estrecho, que conduzca a errores en el
análisis por desconocimiento de las variables que
intervienen.
Confianza desmedida en la propia memoria: La
fuerza de la vivencia lleva a presuponer que se
recordarán los hechos y su secuencia. Cuando éstos se
van superponiendo y complejizando las situaciones, se
torna difícil rememorarlos.
No desestimar nunca la posibilidad de registrar
acontecimientos significativos. Si las situaciones
implican personalmente al observador de modo que
dificultan la toma de registro, conviene dejar alguna
“huella” de lo vivido (una o dos palabras clave, por
ejemplo)
Recomendaciones para iniciar una observación (ii)

67
Observación
La etnografía es muy efectiva para descubrir dos tipos de requerimientos:
Requerimientos que se derivan de la forma en que realmente trabaja la gente, en vez de la
forma en la cual las definiciones del proceso indican que debería trabajar
Por ejemplo:
los controladores de tráfico aéreo pueden desactivar un sistema de alerta de
conflicto que detecte una aeronave con trayectoria de vuelo que se cruza, aun
cuando los procedimientos de control normales especifiquen que es obligatorio
usar tal sistema. Ellos deliberadamente dejan a la aeronave sobre la ruta de
conflicto durante breves momentos, para ayudarse a dirigir el espacio aéreo. Su
estrategia de control está diseñada para garantizar que dichas aeronaves se
desvíen antes de que haya problemas, y consideran que la alarma de alerta de
conflicto los distrae de su trabajo

68
Observación
La etnografía es muy efectiva para descubrir dos tipos de requerimientos:
Requerimientos que se derivan de la cooperación y el conocimiento de las actividades de
otras personas
Por ejemplo:
Los controladores de tráfico aéreo pueden usar el conocimiento del trabajo de
otros controladores para predecir el número de aeronaves que entrarán a su
sector de control. Entonces, modifican sus estrategias de control dependiendo de
dicha carga de trabajo prevista. Por lo tanto, un sistema ATC automatizado
debería permitir a los controladores en un sector tener cierta visibilidad del
trabajo en sectores adyacentes

69
Observación
• La etnografía puede combinarse con la creación de prototipos
• La etnografía informa del desarrollo del prototipo, de modo que se requieren menos
ciclos de refinamiento del prototipo
La etnografía no es un enfoque completo para la adquisición por sí misma, y debe usarse
para complementar otros enfoques, como el análisis de casos de uso

71
Observación
Ventajas:
 Información de primera mano
 Se obtienen requisitos difíciles de transmitir
 Ilustran el porqué de que muchos usuarios
no pueden describir fácilmente sus
requisitos: sus tareas y procesos de negocio
son demasiado complejos y sutiles.
 Incremente del vocabulario del analista
Desventajas:
 Coste relativamente alto
 Mayor toma de decisiones
 Puede requerir de alto enfoque en los entornos
ruidosos

74
Observación - Formato
Ejemplo

75
Análisis de Sistemas Existentes
Analizar un sistema que ya existe y que se encuentra operando, esto nos permite
identificar varios problemas o a su vez poder añadir o adaptar otras funcionalidades, con el
objetivo de comprender, mejorar, ajustar y/o predecir su comportamiento.

76
Ventajas:
● Una ventaja de analizar sistemas
ya existentes sería que la mayor
parte de la información la tenemos
ya disponible
● Ya se sabe dónde centrar el
análisis de estudio para rectificar
dicho sistema
● Mejoramiento del sistema
Desventajas:
● Un mal análisis podría hacer que el
sistema sea menos eficiente
● Al existir sistemas con poca
documentación tardaría más tiempo en
realizar un análisis.
● Costos adicionales

77
Proceso o preparación
Requisitos existentes:
• Se debe buscar los requisitos del sistema existente, esto proporcionará una cantidad de
información sobre lo que se debe considerar
• Recordar que el sistema fue elaborado en un tiempo diferente, con tecnología diferente
• Lo más importante es que deberá asegurarse de que todos los requisitos sigan siendo válidos
• Modifica, elimina y agregan nuevos requisitos

78
Proceso o preparación
Documentos de interfaz existentes: Límites pueden cambiar con el nuevo
sistema. (Vistas)
Documentos de diseño: Se centran en la implementación Por ejemplo: que
elementos de datos se almacenan y manipulan, es decir, la estructura de datos , la
arquitectura, etc.
Manuales: Estos describen cómo se debe realizar el sistema y son muy detallados
Clasificatorios: Son aquellos que indican los pasos exactos que se deben seguir al
usar el sistema

79
Conducción
• Se usa la información que se recopiló
para establecer un nuevo alcance y
objetivo con el fin de crear un sistema
superior al anterior
• Recopilar salidas
• Puntos de control
• Estudio de flujo
• Examinar factibilidad
Análisis
• En la fase de análisis es donde se
• especificará lo que se debe lograr
• Diagramas
• Discusión
• Lista de resultados
• Análisis de requisitos

80
Grupo de Reuniones
 Facilitated sessions
 Workshops
 Focus groups
 Brainstorming sessions
 Requirements workshops
 Joint application development (JAD)

81
Grupo de Reuniones - Brainstorming
 Objetivo: generar ideas en un ambiente libre de críticas o juicios
 Grupos de 4 a 10 personas, una de ellas es el jefe de la sesión
 Requiere poca organización y es fácil de aprender
 Puede generar diferentes vistas del problema, aunque no con una gran calidad de
detalles
Definición: el brainstorming también conocido como lluvia de ideas o tormenta de ideas es
una técnica creativa grupal cuyo objetivo es la generación de nuevas ideas, sobre un tema o
problema concreto en un ambiente relajado

82
Fases del Fases del brainstorming
 Preparación
 Seleccionar participantes, citarlos y preparar el lugar.
 Generación
 El jefe propone un problema semilla, se proponen ideas sin ningún tipo de
críticas, se fomentan las ideas más avanzadas para estimular y se alienta a
completar las ideas de otros
 Consolidación
 Se revisan las ideas, se descartan las que no son factibles y se priorizan las
restantes
 Documentación
 El jefe de la sesión redacta el acta de la reunión

83

84
Problemas comunes
• No definir de forma clara los objetivos de la sesión
• Perder el foco del objetivo principal. El moderador debe reconducir la sesión
• Elegir mal al moderador de la sesión. Si este no dirige bien, la sesión no saldrá bien
• Elegir integrantes especializados en la materia a tratar. Esto solo generará
perspectiva ya creadas
• Un grupo muy grande de participantes fomenta que muchos usuarios no hablen y se
pierdan opiniones valiosas
• Escoger las primeras ideas como las mejores. Esto influye en la dirección que
toman el resto de ideas

85
Preparación de la tormenta de ideas
► Reglas básicas
Suspender el juicio
Durante el proceso de generación de ideas, no hay que realizar ninguna valoración o
crítica sobre estas
Solo se apuntan las ideas, la evaluación se realiza después
Esta regla es muy importante y, quizás, sea la que más cuesta a las personas seguir,
ya que estamos entrenados para ser analíticos y prácticos

86
► Reglas básicas
Pensar libremente
Las ideas más prácticas muchas veces nacen de otras ideas que, en su mayoría,
son inviables
Es muy importante para una sesión de Brainstorming efectiva, los usuarios piensen
libremente y tengan ideas imposibles
De esta forma, se consigue salir de las ideas lógicas y habituales, fomentando así la
creación de nuevas soluciones
Es más fácil perfeccionar una idea, que crear una nueva.

87
► Reglas básicas
La cantidad es importante
Al hacer un Brainstorming se busca generar una gran cantidad de ideas, para luego
escoger la mejor de todas ellas. Esto es así por dos motivos:
1.Al principio suelen aparecer en la mente las ideas más obvias y habituales, por lo
que estas ideas no son innovadoras.
2.Cuantas más ideas se generen en la sesión, más se pueden elegir, combinar y
adaptar para resolver el problema planteado al principio.

88
► Reglas básicas
Efecto multiplicador
Los participantes en las tormentas de ideas, no solo contribuyen con sus
pensamientos, sino que también puede sugerir mejoras o combinar las ideas que
tienen los demás
Así, las ideas que tienen unos usuarios sirven de estímulo para los otros
participantes

89
Figuras Principales
Moderador
Secretario
Participantes

90
Para que una sesión de Brainstorming sea efectiva,
primero debe estar bien organizada

91
Elección del espacio
El espacio es un factor importante. Lo recomendable es hacerlo en una sala grande,
con luz natural y pizarras para escribir en ellas.
En ocasiones, muchas, no se dispone de este espacio idílico. Factores, para que la
lluvia de ideas sea eficaz:
1.El lugar debe ser amplio. Así, se mejora la fluidez y la creatividad de los participantes
2.El mobiliario de la sala debe ser lo más cómodo
3.Se debe contar con una pizarra, ordenador o cuadernos donde apuntar las ideas que
generan los participantes
4.La disposición de los participantes, debe fomentar que estén unos en frente de los otros,
para fomentar la comunicación y la generación de ideas.
5.Fuente de hidratación con agua y bebidas ricas en azúcar y cafeína. de esta forma se
mantienen las neuronas despiertas

92
Herramientas
Idea Boardz https://ideaboardz.com/

93
Herramientas
Miro https://miro.com/

94
Herramientas
 FreePlane https://freeplane.sourceforge.io/wiki/index.php/Home
 Coggle https://coggle.it/
 WiseMapping http://www.wisemapping.com/
 Lucidchar https://www.lucidchart.com/pages/es/ejemplos/software-de-lluvia-de-
ideas

95
Ejemplo
https://ideaboardz.com/for/TransTuris/4543033
Ideas para implementar el Sistema de boletos, cliente y evitar errores en las ventas de boletos

96
Grupo de Reuniones - JAD
Joint Application Development, Desarrollo Conjunto de Aplicaciones
 Es una alternativa a las entrevistas individuales
 Se desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo
de 2 a 4 días
 En estas reuniones se ayuda a los clientes y usuarios a formular problemas y
explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes
del desarrollo

97
 Esta técnica se base en cuatro principios:
 Dinámica de grupo
 el uso de ayudas visuales para mejorar la comunicación (diagramas,
transparencias, multimedia, herramientas CASE, etc.),
 mantener un proceso organizado y racional
 y una filosofía de documentación, por la que durante las reuniones se trabaja
directamente sobre los documentos a generar.

98
El JAD tiene dos grandes
pasos:
1)JAD/Plan cuyo objetivo es
elicitar y especificar
requisitos
2)JAD/Design, en el que se
aborda el diseño del
software

99

100

101
En comparación con las entrevistas individuales, presenta las siguientes 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
 Implica más a los clientes y usuarios en el desarrollo

102

103

104

105
Jefe del JAD:
 Responsable de todo el proceso y asume el control durante las reuniones
 Debe tener dotes de comunicación y liderazgo
 Algunas habilidades importantes que debe tener son:
 entender y promover la dinámica de grupo,
 iniciar y centrar discusiones,
 reconocer cuándo la reunión se está desviando del tema y reconducirla,
 manejar las distintas personalidades y formas de ser de los participantes,
 evitar que decaiga la reunión aunque sea larga y difícil, etc.

106
Analista
 Responsable de la producción de los documentos que se deben generar
durante las sesiones JAD. Debe tener la habilidad de organizar bien las ideas y
expresarlas claramente por escrito
 En el caso de que se utilizan herramientas software durante las sesiones, debe
ser capaz de manejarlas eficientemente.

107
Patrocinador Ejecutivo:
 Tiene la decisión final de que se lleve a cabo el desarrollo. Debe
proporcionar a los demás participantes información sobre la necesidad del
nuevo sistema y los beneficios que se espera obtener de él
Representantes de los usuarios
 durante el JAD/Plan, suelen ser directivos con una visión global del
sistema. Durante el JAD/Design suelen incorporarse futuros usuarios
finales

108
Representantes de sistemas de información
 personas expertos en sistemas de información que deben ayudar a los usuarios
a comprender qué es o 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 del punto de vista de los usuarios porque conocen muy
bien el funcionamiento de una parte de la organización, como desde el punto
de vista de los desarrolladores porque conocen perfectamente ciertos aspectos
técnicos de la instalación hardware de la organización

109
Jad Plan preparation
 Interview Executive Sponsor
 Read Existing documentation
 Complete Draft of 1 – Page Project summary
 Interview Stakeholders
 Establish JAD Team
 Customize Application Baseline Document Template
 Create JAD Plan Sessión Agenda
 Prepare Materials
 Set up room
 Review with Executive Sponsor

110
Jad Plan Session Steps
 Executive sponsor: Kicks-Off Session
 Review Expectiations / Procedures
 Define Applications Scope
 Define JAD Design Session Plans
 Plans
 Parallel or Serial
 Resources Needed
 Estimates
 Schedules
 Standars
 Screens
 Reports
 Interface
 Complete Application Baseline Document
 Conclude JAD Plan Sesion

111
• Microsoft Project
• OpenProj
• PRIMAVERA https://www.oracle.com/industries/construction-engineering/
JIRA SOFTWARE
Es una aplicación web para el seguimiento de errores, de incidentes y para la gestión operativa
de proyectos.
La herramienta fue desarrollada por la empresa australiana Atlassian. Tiene diversos tipos de
licencia según el uso que se vaya a realizar, incluyendo una licencia gratuita para
organizaciones sin ánimo de lucro

112
Focus Group
• Es un medio para obtener ideas y actitudes sobre un producto, servicio específico u
oportunidad en un entorno de grupo
• El grupo está integrado de 6 a 12 personas
• Los participantes comparten sus impresiones, preferencias y necesidades, guiados por
un moderador
• El objetivo es recolectar información
para resolver las preguntas de
investigación
• Recopilar comentarios sobre necesidades,
oportunidades y problemas para
identificar los requisitos, o puede
recopilar comentarios para validar y
refinar los requisitos ya obtenidos

113
Focus Group
La técnica Focus Group consiste en unir a un grupo de personas
de un mismo sector (con diferentes ámbitos de trabajo e
inquietudes), con el objetivo de crear debate alrededor de una
temática, bajo la dirección de un moderador que presenta las
líneas maestras de estudio

114
Focus Group
Ventajas:
● Flexible
● Resultados inmediatos
● Anima y estimula a las personas
para competir ideas más
abiertamente
● Los datos pueden ser combinados
cuantitativos para presentar un
cuadro mejor del tema
● Reduce el esfuerzo con respecto a
entrevistas individuales
Desventajas:
● Dificultades para reclutar
participantes ocupados
● Se necesita realizar por lo menos 2 a 3
grupos focales
● Dificultad para presentar comparar
resultados
● Los miembros pueden dar respuestas
poco sinceras
● El moderador puede alterar los
resultados con sus opiniones

115
Focus Group - Preparación
Reclutar participantes:
● Suele tener de 6 a 12 asistentes
● Puede ser necesario invitar a más individuos con el fin de permitir que aquellos que
no asistan a la sesión debido a conflictos no programados, emergencias o por otros
motivos
● Si muchas personas necesitan participar, puede ser necesario ejecutar más de un
focus group
● El tema del focus group influirá en quién debe ser reclutado. Si el tema es un nuevo
producto, es probable que deban incluirse los usuarios existentes (expertos y novatos)

116
Asignar el moderador y el registrador
● El moderador debe tener experiencia en la facilitación de grupos. Las habilidades
típicas incluyen habilidad para:
● Promover la discusión
● Hacer preguntas abiertas (que promuevan una respuesta extendida)
● Facilitar la interacción entre los miembros del grupo
● Involucrar a todos los miembros
● Mantener la sesión enfocada
● Permanecer neutral
● Ser adaptable y flexible

117
Crear guía de discusión
● La guía de discusión incluye metas / objetivos de la sesión y de cinco a seis preguntas
Reserva de sitio y servicios
• Se selecciona la ubicación para la sesión
• Organizar soporte técnico para transcribir la sesión
• y, si se usa, equipo de grabación de audio / video

118
Focus Group – Ejecutar, Producir Informe
Ejecutar la sesión de focus group
El moderador guía la discusión del grupo, sigue un guión planificado de antemano con
problemas específicos y asegura que se cumplan los objetivos. Sin embargo, la discusión
grupal debería aparecer fluida y relativamente desestructurada para los participantes. Una
sesión suele ser de 1 o 2 horas de duración. Se debe usar una herramienta para capturar
los comentarios del grupo
Analizar la sesión de focus group
El moderador analiza y documenta los acuerdos y desacuerdos de los participantes y los
sintetiza en un informe por temas

119
Focus Group – Ejecutar, Producir Informe
Tipos de focus group
Single Focus Group
Two-way Focus Group
Dual Moderator Focus Group
Mini Focus Group
Online Focus Group

120
Focus Group – Herramientas
Herramientas de videoconferencias
• Zoom,
• GoToMeeting,
• Teams,
• WebEx,
• Hangouts
Herramientas de Encuesta
• Surveymonkey
• Google Forms
Herramientas de votación online
• Pollev,
• Mentimeter
Herramientas de colaboración
Son herramientas para apoyar focus
groups remotos, reemplazan la pizarra
convencional
Whimsical,
• Miro
• Mural

122
Prototipos
Los prototipos son una herramienta para clarificar requisitos poco
claros
Existen un amplio rango de técnicas de prototipado para requisitos:
• Desde diseños de plantillas dibujadas en papel,
• Hasta versiones beta de prueba de productos software
complejos
A la vez que para elicitar-clarificar requisitos, sirven también en su
validación

123
Prototipos
“No sé exactamente que quiero, pero lo sabré cuando lo vea”
Situaciones de Utilidad
• Área de aplicación no definida
• Coste alto de rechazo de la aplicación
• Necesidad de evaluación del impacto del sistema
Razones para emplearlo
• Prototipado de la interfaz de usuario
• Modelos de rendimiento
• Prototipado evolutivo
Cualidad del prototipo: Ser construido más rápidamente que la aplicación

124
Prototipos
Ventajas
• Permiten el desarrollo de un sistema a partir de
requisitos poco claros o cambiantes
• Son más fáciles de abordar con los usuarios
finales
• El usuario participa más activamente en la
construcción del producto de software ya que “lo
puede ver” y, dependiendo del tipo de
prototipo, “utilizar” desde el primer momento
• Se reduce el riesgo o la incertidumbre sobre la
implementación del software
• Su uso redunda en una mayor satisfacción del
usuario con el producto final, ya que él o ella han
participado activamente de su diseño
• Permite a todos los involucrados entender bien y
mejor el problema antes de la implementación
final
Desventajas
• El usuario quiere empezar a trabajar desde el
primer momento con el prototipo para solucionar
su problema particular, cuando el prototipo es solo
un modelo de lo que será el producto
• Requiere participación activa del usuario, al
menos, para evaluar el prototipo. Y mucho más
involucramiento si queremos que participe en su
creación
• Falta de experiencia que tienen muchos Analistas
Funcionales en programación y en actividades de
diseño de interfaces de usuario

126
Prototipos
Herramientas de Pencil
https://pencil-project.uptodown.com/windows

127
Prototipos
Herramientas de prototipo
https://www.adobe.com/la/products/xd.html

128
Prototipos
Herramientas de prototipo
• https://www.mockplus.com/
• https://www.justinmind.com/
• https://www.axure.com/
• Visio - the interaction designer's nail gun (3rd edition)
http://www.guuui.com/issues/02_07.html
• Picodo https://pidoco.com/en
• Cacoo https://cacoo.com/es/
• MockupTiger https://www.mockuptiger.com/
• OmniGraffle https://www.omnigroup.com/omnigraffle/
• Gomockingbird https://gomockingbird.com/mockingbird/
• Visual Paradim https://www.visual-paradigm.com/

129
Escenarios
• Técnicas orientadas por modelos
• Método de análisis del entorno, permite analizar y comparar diferentes factores
estratégicos, situarse en un contexto futuro específico y estudiar su posible
impacto en la empresa
• Son ejemplos de la vida real donde se especifica como el sistema debe ser
usado
• Los escenarios son particularmente útiles para detallar un bosquejo de
descripción de requerimientos

130
Escenarios
Escenarios
Particulares
Son aquellos que
describen un momento
específico de la
aplicación
Generales
Son aquellos que
representan las funciones
fundamentales de la
aplicación

131
Escenarios
Proceso:
● Definir horizontes temporales, alcance negocios incluidos y variables claves de
decisión
● Identificar grupos de interés(Stakeholders)
● Identificar tendencias actuales y factores claves del entorno que pueden influir
● Identificar factores de incertidumbre que afectan a las variables implicadas
● Construir dos o tres escenarios alternativo.
● Valorar las consistencia interna y la verosimilitud de estos escenarios
● Analizar la dinámica de los escenarios anticipando las acciones de los agentes
● Formular alternativas estratégicas

133
Escenarios
Ventajas:
● Permiten ver fácilmente la
interacción del sistema con los
demás actores (usuarios u otros
sistemas)
● Muy útiles cuando la
implementación se va a hacer
UML
● Las descripciones pueden ser
creadas antes de que el sistema sea
construido y permiten, por tanto,
«sentir» el impacto resultante
Desventajas:
• No son demasiado útiles para describir
sistemas sin usuarios y/o con pocas
interfaces
• No modelan bien requisitos no
funcionales y restricciones de diseño.
• Exigen una alta participación del
interesado en su elaboración y
necesitan que él realice una concepción
completa de la solución informática,
que sólo sería posible al final del
proceso de obtención de requisitos

135
Escenarios - Ejemplo
Un escenario comienza con un bosquejo de la interacción. Durante el proceso de
adquisición, se suman detalles a éste para crear una representación completa de dicha
interacción. En su forma más general, un escenario puede incluir:
1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario.
2. Una descripción en el escenario del flujo normal de los eventos
3. Una descripción de qué puede salir mal y cómo se manejaría
4. Información de otras actividades que estén en marcha al mismo tiempo
5. Una descripción del estado del sistema cuando termina el escenario

136
Escenario para recabar
historia médica en
MHC-PMS

137
Como ejemplo de un simple escenario de texto, considere
cómo usaría el MHC-PMS para ingresar datos de un
nuevo paciente (figura 4.14). Cuando un nuevo paciente
asiste a una clínica, un auxiliar médico crea un nuevo
registro y agrega información personal (nombre, edad,
etcétera). Después, una enfermera entrevista al paciente
y recaba su historia médica. Luego, el paciente tiene una
consulta inicial con un médico que lo diagnostica y, si es
adecuado, recomienda un tratamiento. El escenario
muestra lo que sucede cuando se recaba la historia
médica.

139
Casos de Uso
• Los casos de uso son una técnica de descubrimiento de requerimientos que se
introdujo por primera vez en el método Objectory (Jacobson et al., 1993)
• Identifica a los actores implicados en una interacción, y nombra el tipo de
interacción
• Se complementa con información adicional, puede ser una descripción textual o
modelo gráficos como una secuencia UML o un gráfico de estado
• No hay distinción tajante y rápida entre escenarios y casos de uso
• Algunas personas consideran que cada UC es un solo escenario; otras, como sugieren
Stevens y Pooley (2006), encapsulan un conjunto de escenarios en un solo caso de
uso.
• Cada escenario es un solo hilo a través del caso de uso. Por lo tanto, habría un
escenario para la interacción normal, más escenarios para cada posible excepción
• En la práctica, es posible usarlos en cualquier forma

140
Casos de Uso
Ejemplo:
El establecimiento de consulta permite que dos o más médicos, que trabajan en diferentes
consultorios, vean el mismo registro simultáneamente. Un médico inicia la consulta al elegir al
individuo involucrado de un menú desplegable de médicos que estén en línea. Entonces el
registro del paciente se despliega en sus pantallas, pero sólo el médico que inicia puede editar el
registro. Además, se crea una ventana de chat de texto para ayudar a coordinar las acciones. Se
supone que, de manera separada, se establecerá una conferencia telefónica para comunicación
por voz

141
Casos de Uso
Casos de uso para el MHC-PMS

142
Casos de Uso
Casos de uso para el MHC-PMS

143
Story Board
Es una secuencia de imágenes o ilustraciones que hacen de guía al argumento de
una historia y que permiten previsualizar un resultado

144
Story Board
Ventajas:
● Genera una descripción completa
● Facilita la transmisión del mensaje
● No necesita programación
● Puede descubrir funcionalidad,
interacción y presentación de
manera simultanea
Desventajas:
• Todos tienen que trabajar en el mismo
fichero
• Sacrifica la flexibilidad y el control por
una fácil sensación de uso

147
Card Sorting
Es una técnica de elicitación
cognitiva
La clasificación de tarjetas es una
técnica en el diseño de la experiencia
de usuario en la que una persona
prueba a un grupo de expertos en la
materia o usuarios para generar un
dendrograma
Es una técnica usada tempranamente
en el diseño de experiencia de usuario
que sirve para definir la estructura de
un sitio o aplicación

148
Card Sorting - Abierto
Este tipo de card sorting dispone sólo de las tarjetas que los usuarios deben organizar,
no existen categorías predeterminadas. De modo que los usuarios pueden crear tantas
categorías como deseen y denominarlas como ellos entiendan más conveniente

149
Card Sorting - Cerrado
En este caso si que creamos una serie de categorías en las que los usuarios deben
organizar las tarjetas. De modo que los usuarios sólo pueden ordenar los contenidos
en esos grupos predefinidos

150
Card Sorting - Híbrido
El card sorting híbrido es una mezcla de dos casos anteriores. Es decir, establecemos una
serie de categorías en las que los usuarios deben ordenar los contenidos, pero también les
ofrecemos la posibilidad de crear otras categorías que tenga sentido para ellos

151
Card Sorting
Ventajas:
● Más pruebas en menos tiempo
● Más participantes
● Reducir costos
● Más rápido análisis de datos
Desventajas:
● No considera las tareas del usuario
● Los resultados pueden ser muy
variados
● Poca comunicación entre el usuario y
evaluador

152
Card Sorting - Proceso
● Se seleccionan al menos 15 personas
● Cada tarjeta contiene mapas en los que contiene los títulos de los menús
individuales o nombres de categorías
● Cada probador individual tiene la tarea de poner el elemento del menú en un
orden que tenga sentido
● La clasificación de las tarjetas se la puede llevar una o varias veces
● El método también se puede utilizar para una sola parte del menú
● Se discuten y seleccionan las propuestas individuales

153
Card Sorting - Ejemplo
● enlace

154
Card Sorting - Herramientas

155
Clasificación de Técnica de Elicitación
Actividades IR Tarea de la actividad Técnica
Elicitación de requisitos Identificar fuentes de los requisitos Reunión JAD
Seleccionar técnicas para desarrollar proceso de
comunicación
Observación Assessment workshop
Aplicar técnicas para elicitar los requisitos Reunión JAD
Análisis de requisitos Clasificar requisitos en: requisitos de
almacenamiento, funcionales y no funcionales
Focus Group Análisis de formularios
Realizar modelado conceptual Brainstorming Assessment workshop
Delphi
Asignar requisitos y diseño arquitectónico Paper Prototyping
Negociar requisitos Reunión JAD

156
Actividades IR Tarea de la actividad Técnica
Especificación de
requisitos
Crear documento de definición del sistema Paper Prototyping
Crear documento de especificación de requisitos
del sistema
Cuestionarios
Crear documento de especificación de requisitos
del software
Paper Prototyping
Validación de requisitos Revisar requisitos Role Playing
Desarrollar prototipos para elicitación y para
validación
Paper Prototyping
Validar los requisitos obtenidos con los clientes y
usuarios
Simulación
Delphi
Elaborar pruebas de aceptación Role Playing

157

158

159
Procedimiento de Elicitación

160

161
Diagrama de procedimiento

162
Artefacto de Procedimiento
Acta de reunión

163
Artefacto de Procedimiento
Glosario de términos

164
Cŕeditos
• Transparencias basadas por:
• Toni Granollers, Requisitos http://ocw.udl.cat/enginyeria-i-arquitectura/interaccio-
persona-ordinador/4.-requisitos
• Francisco José García, Ingeniería de Requisitos
• George Koelsch, Requirements Writing for System Engineering
• Guía metodológica para la gestión de requerimientos de software del GAD-I:
http://repositorio.utn.edu.ec/bitstream/123456789/7688/7/PG%20581%20Anexo%
208.pdf

Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
165
Gracias

Elicitación de requerimientos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Elicitación de requerimientos

Similar a Elicitación de requerimientos (20)

Más de Rene Guaman-Quinche

Más de Rene Guaman-Quinche (20)

Último

Último (6)

Elicitación de requerimientos