IDR Unidad 2: Elicitación de requerimientos

Ingeniería de requerimientos Carrera de Software
Ph.D. Franklin Parrales 1
13/05/2021
Elicitación de
requerimientos
Unidad 2
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Ingeniería de Requerimientos

13/05/2021
Objetivo general de la Unidad 2
Conocer el dominio del problema para poder
comunicarse con clientes y usuarios para entender
sus necesidades, tanto explícitas como implícitas
y sus expectativas sobre el sistema a desarrollar.

13/05/2021
Lección 1
Elicitación de requerimientos -
Definición – Objetivos –
Problemas - Tareas
Unidad 2

13/05/2021
Contenido
• Definición de elicitación
• Objetivos de la elicitación
• Problemas de elicitación
• Tareas básicas de la elicitación
• Técnicas de elicitación
– ¿Qué técnica utilizar?

13/05/2021
Proceso de Requisitos
Artefactos
Análisis Especificación Validación
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Planificación Obtención Verificación
Documento
de
Visión

13/05/2021
Proceso espiral de IR
Validación
de requerimientos
Adquisición
de requerimientos
Adquisición
de requerimientos
del usuario
Prototipos
Revisiones
Documento
de requerimientos
del sistema
Inicio
Adquisición de
requerimientos
del sistema
Estudio
de factibilidad
Especificación de
requerimientos
Especificación y modelado
de requerimientos
del sistema
Especificación
de requerimientos del usuario
Especificación de
requerimientos
de la empresa

13/05/2021
Elicitación de Requisitos
• To elicit: Descubrir, tornar explícito,
obtener el máximo de información para el
conocimiento del objeto en cuestión, en
este caso los requisitos.
• Etapa muy relacionada con resto etapas
(Ej. Técnicas elicitación usada guiada por el
esquema de modelización y viceversa)

13/05/2021
La elicitación de requisitos
• Uno de los aspectos más cruciales y
desafiantes en el desarrollo de proyectos de
software es la captura de los requisitos para
la aplicación propuesta.
• La elicitación consiste en identificar las
fuentes de obtención de requisitos y luego
utilizando técnicas evocar esas fuentes.
• La captura de requisitos es una actividad
humana intensa que se basa en la
participación de los stakeholders, como
fuente principal de obtención de requisitos.

13/05/2021
La elicitación de requisitos
Adquisición (elicitación) y análisis de requerimientos se refieren a un conjunto de
actividades realizadas para descubrir los requerimientos.
Se realiza después del estudio de factibilidad o viabilidad
No consiste solamente en preguntar a los usuarios lo que quieren !
Requiere un
minucioso
análisis
la
de
organización, el
de aplicación,
procesos que el
utilizará
dominio
y los
sistema

13/05/2021
Responsable de la elicitación de
requisitos
• La captura de los requisitos
es responsabilidad del
analista…
– pero puede estar implicado
otro personal técnico que
desee beneficiarse de un
conocimiento mucho más
profundo de las necesidades
de los interesados.

13/05/2021
Contenido

13/05/2021
Objetivos de la elicitación
• Capturar las necesidades del cliente, usuario,
otros interesados
– Generar modelos del dominio
• Revisar la situación actual
– Organización actual y sistemas
– Versión actual del sistema
– Desarrolladores de versión anterior
– Documentos existentes (antecedentes)
– Sistemas análogos ya existentes (antecedentes)
Se trabaja en conjunto con los usuarios y
clientes

13/05/2021
El proceso de adquisición y análisis
de requerimientos
1. Descubrimiento
de requerimientos
2. Clasificación y
organización de
requerimientos
3. Priorización y
negociación de
requerimientos
4. Especificación
de requerimientos

13/05/2021
Contenido

13/05/2021
Dificultades de la elicitación
• Los clientes y usuarios generalmente no
entienden como diseñar y desarrollar el
software.
– Por ello, no estarán en capacidad de especificar
sus necesidades de software de tal forma que
entiendan los desarrolladores.
• Por su parte, los desarrolladores a menudo
no entienden los problemas y necesidades
de los clientes y usuarios, como para
especificar las necesidades.

13/05/2021
• Entre las dificultades típicas, tenemos:
– Necesidades diferentes y a veces conflictivas de los
diferentes tipos de usuarios.
– Requisitos no declarados o asumidos por parte de los
stakeholders.
– Identificar a los stakeholders clave.
– Incapacidad para imaginar nuevas o diferentes formas de
usar el software.
– Incertidumbre para adaptarse a las necesidades
cambiantes del negocio.
– Contar con un gran número de requerimientos sumamente
relacionados.
– Tiempo limitado para obtener los requisitos. Stakeholders
ocupados – importantes.
– Superar la resistencia al cambio.

13/05/2021
• Información esparcida en diversas fuentes con
posibilidad de conflictos entre ellas.
• Conocimiento tácito
• Observabilidad limitada
– un observador puede cambiar el problema
– clientes ocupados
• Desviación
– persona puede no sentirse libre para decir lo que el
ingeniero necesita saber
– persona puede no querer decir lo que el ingeniero
necesita saber
– Motivacional, observacional, cognitiva, notacional

13/05/2021
Problemas de elicitación
• Problemas comunes:
– No saben lo que quieren del sistema, sólo en
términos generales, no conocen el costo de sus
peticiones
– Los requisitos están en sus términos y con
conocimiento implícito de su propio trabajo
– Distintos usuarios tienen distintos requisitos, se
deben encontrar todas las fuentes
– Influyen factores políticos
– La prioridad que se da a los requisitos varía con
el tiempo
– Aparecen nuevos requisitos

13/05/2021
Otros problemas de elicitación
• De articulación
– Dificultad para expresar claramente las
necesidades.
– No ser conscientes de sus propias
necesidades.
– No entender como la tecnología puede
ayudar.
– Miedo a parecer incompetentes por
ignorancia tecnológica.

13/05/2021
• De comunicación
– No escuchar adecuadamente a los clientes y
usuarios
– Cultura y vocabularios diferentes.
– Intereses distintos en el sistema a desarrollar.
– Medios de comunicación inadecuados (por
ejemplo: diagramas que no son entendidos
por clientes y usuarios).
– Conflictos personales o políticos.

13/05/2021
• Limitaciones cognitivas
– No conocer el dominio del problema.
– Hacer suposiciones sobre el dominio del
problema.
– Hacer suposiciones sobre aspectos
tecnológicos.
– Hacer simplificaciones excesivas.
– No tomar decisiones por no poder prever las
consecuencias, no entender las alternativas o
no tener una visión global.

13/05/2021
• Conducta humana
– Conflictos y ambigüedades en los roles de los
participantes.
– Pasividad de clientes, usuarios o ingenieros de
requerimientos.
– Persona puede no sentirse libre para decir lo que
el ingeniero necesita saber
– Persona puede no querer decir lo que el
ingeniero necesita saber
– Temor a que el nuevo sistema los deje sin
trabajo.

13/05/2021
• Técnicos
– Complejidad del dominio del problema.
– Complejidad de los requisitos.
– Cambios en los requisitos (cuanto más se ve,
más se necesita).
– Cambios en hardware y software para reducir
el coste.
– Múltiples fuentes de requisitos.
– Fuentes de información poco claras.

13/05/2021
Superando las dificultades…
• Se debe fomentar un ambiente de cooperación y
comunicación entre los desarrolladores, clientes y
usuarios, para asegurar que se elicitan los
requerimientos apropiados.
• Para obtener los requisitos de forma eficaz, será
necesario:
1. Elegir y planificar las técnicas de elicitación de
requerimientos.
2. Establecer metas y expectativas
3. Elicitar los requerimientos
4. Verificar y corregir los hallazgos
5. Repetir los pasos 1-4 para profundizar el
entendimiento de los requerimientos por parte del
equipo.

13/05/2021
Contenido

13/05/2021
Tareas en la adquisición de Requerimientos
La adquisición de requerimientos debe cubrir cuatro dominios
Dominio
de
aplicación
Problema a
resolver
Necesidades y
restricciones
de
stakeholders
Contexto de la
organización
1.- Entender el dominio de
aplicación → Se refiere adquirir
conocimiento o comprender el
funcionamiento de términos
relacionados con la aplicación del
sistema. Ejemplo: Para realizar el
sistema de biblioteca deberán
entenderse algunos términos
como índices de clasificación de
libros, etc.
2.- Entender el problema → Se
deben entender los detalles del
problema donde se utilizara el
sistema. Ejemplo: Entender la
organización particular de una
biblioteca
3.- Conocimiento de la
organización → Se debe
comprender el funcionamiento del
sistema dentro de la organización
y como interactúa con otros
sistemas ya existentes.
4.- Necesidades y restricciones
de stakeholders→ Se debe
comprender las funciones de
todos los involucrados, así como
el rol de cada uno en el sistema.

13/05/2021
• Comprender el problema que se va a resolver, para lo cual es
necesario estudiar el dominio o entorno en el que el sistema va a operar.
• Buscar y recolectar información acerca del sistema a desarrollar, de
manuales de operación y mantenimiento, de manuales organizacionales
y políticas de operación.
• Definir los límites y restricciones del sistema para determinar con
precisión que es lo que el sistema va a hacer y también especificar lo que
no va a hacer.
• Identificar a las personas o usuarios interesados en el sistema, ya
que ellos conocen el medio ambiente en que operará el sistema y pueden
ayudar describiendo sus necesidades.
• Recolectar y clasificar requerimientos, los desarrolladores pueden
iniciar definiendo un bosquejo general del sistema, su funcionamiento
básico y estableciendo su alcance.

13/05/2021
Actividades
1- Identificación de fuentes de información:
stakeholders, documentos escritos, libros o manuales,
sistemas de software existentes. Establecer límites
2- Recolectar la información
se utilizan diferentes técnicas para obtener la
información
3- Comunicación
Se presentan los resultados de determinadas maneras,
las cuales pueden ayudar o entorpecer al entendimiento.
Debe haber una retroalimentación. Asociada con la
etapa de documentación y modelización.

13/05/2021
Existen varios procesos para llevar a cabo la adquisición y análisis de requerimientos. Un
proceso general puede incluir las siguientes etapas:
Establish objectives Understand background Organise knowledge C
Establecer objetivos Conocer antecedentes Organizar el conocimiento Recolectar requerimientos
La adquisición de requerimientos abarca entonces cuatro etapas básicas.
1.- Determinación de objetivos
2.- Conocimiento de antecedentes.
3.- Organización de conocimiento
4.- Recolectar requerimientos
Objetivos de
la empresa
Problema a
resolver
Restricciones
del sistema
Estructura
organizacional
Dominio de
aplicación
Sistemas
existentes
Identificación
de
stakeholders
Priorización
de metas
Filtrado del
conocimiento
del dominio
Requisitos de los
stakeholders
Requisitos del
dominio
Requisitos
organizacionales
Muchos piensan que
solo esto es obtención
de requerimientos.
[enfoque limitado]

13/05/2021
Tareas básicas de la elicitación
• Es fundamental conocer qué es lo que se
preguntará, analizará o estudiará.
• Además se debe identificar a los actores clave
que pueden aportar al desarrollo del proyecto.
• Por ello es importante realizar estas actividades
preliminares:
Cuando necesite: Entonces crear:
Definir la visión del producto Visionamiento
Aclarar términos Un glosario
Identificar los riesgos de los
requerimientos
Una estrategia para mitigar los
riesgos de los requerimientos

13/05/2021
Visionamiento
Material docente compilado por el profesor Ph.D. Franklin Parrales

13/05/2021
Artefactos
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Documento
de
Visión

13/05/2021
Blastoff
Preparación para el inicio del proyecto
• Reunión entre los principales
desarrolladores, clientes y usuarios
• Del Blastoff se obtienen:
– El contexto
– Propósito del proyecto
– Lista de principales riesgos
– Estimación inicial del esfuerzo
– Decisión de seguir adelante o no
– Identificación clara de los interesados
– Compromiso con el proyecto
– Formación de equipos

13/05/2021
Blastoff (continuación)
• Determinar el propósito del producto:
– 1. Escribir el una frase el objetivo/propósito
del producto
– 2. Cuál es la ventaja/solución que ofrece?
– 3. Definir cómo medir el éxito.
– Además:
– 4. Es realista / factible?
– 5. Lo desean todos los interesados
(stakeholder)?

13/05/2021
Visionamiento
• Es una declaración concisa que resume el propósito a
largo plazo y la intensión del nuevo producto.
• Esta declaración podría reflejar una vista equilibrada
que satisface las necesidades de diversos
stakeholders.
• Desde un punto de vista general puede verse como
algo idealista, pero debe basarse en realidades
propias de la organización en la cual se va a
desarrollar el producto.
• Este visionamiento puede ser parte de otros
documentos como por ejemplo en el documento de
inicio del proyecto, en alguna carta del proyecto, pero
principalmente en el documento de visión del
proyecto.

13/05/2021
Visionamiento
• Como resultado del visionamiento tenemos:
– Asegura que las definiciones y problemática del
producto se alinea con las metas y objetivos del
negocio.
– Identificar los stakeholders del producto en forma
general.
– Descripción del estado del negocio y cómo los
usuarios se beneficiarán cuando el proyecto
termine.
– Facilita a los miembros del equipo dar una
descripción sencilla del proyecto.

13/05/2021
Preguntas que debe responder el
visionamiento
• ¿Quién comprará o usará este producto?
• ¿Qué hará el producto para sus
Stakeholders?
• ¿Cuáles son las razones para comprar o
utilizar este producto.
• ¿Cuál será el estado del entorno
operacional o de negocios cuando el
producto esté disponible?
• ¿Cómo se distinguirá en el mercado?

13/05/2021
Pasos para lograr el visionamiento de la solución
1. Definir lo siguiente:
– Cliente Objetivo (Target customer): Describe las personas que
usarán o comprarán el software.
– Declaración de necesidad u oportunidad: Describe lo que hace el
cliente (Target customer) y explica como este producto le podría
ayudar.
– Nombre del producto: Proporciona el nombre del producto que se
creará.
– Categoría del producto: Describe el tipo de producto que construirá.
Las categorías del producto podrían incluir: aplicaciones de software de
gestión interna, software integrado, software de juegos, dispositivos de
hardware, o sistemas complejos.
– Los principales beneficios o las razones convincentes para
comprar: Describe qué podría hacer el producto para el cliente o la
justificación para haber comprado el producto.
– Principal alternativa competitiva, sistema actual, o proceso manual
actual: Describir los principales productos disponibles que compiten, o
el sistema, o el proceso que el producto reemplazará.
– Declaración de la diferencia de los productos primarios: Explicar
las diferencias entre el producto que se construirá y la competencia.

13/05/2021
2. Crear la declaración de la visión mediante la introducción de
los términos definidos en la siguiente plantilla.
– Para <Cliente objetivo> quien <declaración de la
necesidad u oportunidad>, el <nombre del producto> es
un <categoría del producto> que <principales beneficios o
razones convincentes para comprar>.
– A diferencia de <principal alternativa competitiva, sistema
actual, o proceso manual actual>, nuestro producto
<declaración de las diferencias del producto primario>.
3. Revisar la declaración de la visión y verificar que se alinea
con las metas y objetivos de la organización.
– Contar con un sponsor para asegurar que la visión se
ajusta con los objetivos organizacionales y
departamentales.
– Contar con un equipo de trabajo, idealmente en
colaboración con el sponsor del proyecto, con la finalidad
de revisar la declaración de la visión como sea necesario.

13/05/2021
4. Hacer la declaración del problema, esta consiste en
una descripción del problema actual que la empresa
está experimentando y aclara lo que una solución
exitosa podría ser.
– Esto es útil cuando la solución incluye la ampliación de
un software existente o cuando la implementación del
producto crea una necesidad para un proceso de cambio
del negocio.
– Use la siguiente plantilla para hacer una declaración del
problema.
• El problema de <Insertar el planteamiento del problema>
afecta <nombre de las personas afectadas, organización, o
grupo de clientes>. El impacto de esto es <nombre del
impacto (por ejemplo, malas decisiones, los sobrecostos,
información o procesos erróneos, tiempo de respuesta lento a
los clientes, etc)>. Una solución exitosa sería <describir la
solución>.

13/05/2021
Ejemplo: Sistema de autotrámites
1. Definir lo siguiente:
• Cliente: Personal administrativo y estudiantes de la Universidad de
Guayaquil.
• Necesidad u oportunidad: Registran y resuelven los trámites que
se generan en cada centro asociado mediante un proceso definido
para cada trámite.
• Nombre del producto: Sistema de automatización de trámites.
• Categoría del producto: Aplicación Web.
• Beneficios o razones convincentes:
– Registra las solicitudes de trámites directamente en el sistema desde
cualquier centro.
– Define un flujo de documentación desde los centros asociados a la
sede central.
– Notifica a las personas involucradas en el trámite sobre las tareas que
debe realizar.
– Permite conocer sobre el estado de un trámite en cualquier momento.

13/05/2021
• Principal alternativa competitiva, sistema actual, o proceso
manual actual:
– Los trámites existentes tienen que enviarse de forma física a la
universidad.
– No existe un flujo de actividades debidamente controlado para cada
trámite.
– Tanto el estudiante como los involucrados en el trámite no conocen a
ciencia cierta sobre el estado del mismo.
• Declaración de la diferencia de los productos primarios:
Permitirá:
– Que las solicitudes de trámites académico/contable se registren en el
sistema.
– Que se notifique a los involucrados (personal UG-Estudiantes) del
inicio, gestión y finalización de un trámite.
– Que se identifique a la persona que está atendiendo un trámite.
– Que se pueda obtener información académico/contable..
– Que se puedan ejecutar las solicitudes de forma automática de acuerdo
al trámite solicitado.

13/05/2021
2. Defina el visionamiento:
• Para personal administrativo y estudiantes de la Universidad
de Guayaquil, quienes registran y resuelven los trámites que
se generan en cada centro asociado el sistema de
automatización de trámites es una aplicación Web que
registra las solicitudes de trámites directamente en el sistema
desde cualquier centro, define un flujo de documentación
desde los centros asociados a la sede central, notifica a las
personas involucradas en el trámite sobre las tareas que
debe realizar y permite conocer sobre el estado de un trámite
en cualquier momento.
• A diferencia del proceso actual que requiere que los trámites
existentes tengan que enviarse de forma física a la
universidad, no existe un flujo de actividades debidamente
controlado para cada trámite y tanto el estudiante como los
involucrados en el trámite no conocen a ciencia cierta sobre
el estado del mismo.

13/05/2021
3. Definición del problema
• El problema de la atención de trámites académicos y
contables que generan los estudiantes no tengan una
adecuada atención, lo que genera excesiva demora
en la resolución de los mismos debido a que no existe
un flujo definido para el envío-recepción y a la falta de
políticas para su ejecución.
• Afecta a: Estudiantes, Rector, Director Administrativo
Financiero, Coordinación Académica UG, Decanos,
Talento humano, Finanzas, Gestión de Procesos,
Atención al Estudiante y Secretarías.
• Cuyo impacto es: …

13/05/2021
• Cuyo impacto es:
– El promedio de tiempo para resolver un trámite es
alto.
– El estudiante requiere mucha gestión para obtener el
resultado de su trámite, causando malestar e
insatisfacción.
– Se desperdicia tiempo, en tareas relacionadas a
tratar de ubicar un trámite y conseguir su estado.
– Algunos trámites causan congestión en el proceso de
matriculación pues, al no poderse resolver ágilmente,
los estudiantes deben regresar al centro universitario
varias veces entorpeciendo procesos de trabajo
importantes (Matrículas).

13/05/2021
• Una solución satisfactoria permitirá:
– Que la atención de los casos se realice mediante un sistema de
fácil uso, de tal forma de que se de solución a todos los trámites.
– Que las solicitudes de trámites sean registradas directamente en
un sistema.
– Que las solicitudes de trámites fluyan electrónicamente hacia a
las diferentes personas que deban revisarlo antes de su
resolución.
– Que la documentación relacionada al trámite esté asociada a
éste de forma digital de manera que pueda ser visualizada
directamente en el sistema.
– Que se pueda conocer el estado en que se encuentra un
trámite.
– Que se pueda disponer de estadísticas que permitan tomar
decisiones para optimizar los procesos relacionados.
– Que exista seguimiento adecuado de los trámites, estableciendo
tiempos de respuesta.

13/05/2021
Glosario

13/05/2021
Artefactos
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Documento
de
Visión

13/05/2021
Glosario
• Se lo considera como un diccionario de términos
comúnmente relevantes con respecto al producto
que se construye, se mejora o se compra.
• Los términos del glosario se utilizan a lo largo de
todo el proyecto.
• Su uso es necesario pues establece un
vocabulario común para los términos clave que
ayuda a los miembros del equipo a entender estos
términos.
– Diferentes stakeholders pueden usar el mismo
término para explicar diferentes cosas
(ambigüedad), o pueden usar diferentes términos
para expresar la misma cosa, causando confusión y
gasto de energía a la hora de comunicar los
requerimientos.

13/05/2021
Beneficios del glosario
• Como resultado de construir un glosario se tiene:
– Proveer un conocimiento compartido del dominio del
problema.
– Permitir a los dueños del negocio informen al
personal técnico acerca de importantes conceptos del
negocio.
– Provee los fundamentos para definir modelos de
requerimientos tales como reglas de negocio,
modelos de datos y casos de uso.
– Ahorra tiempo y esfuerzo durante el desarrollo de
requerimientos, eliminando malos entendidos de lo
que realmente significan los conceptos del negocios.

13/05/2021
Pasos para construir un glosario
Para lograr los beneficios mencionados se debe hacer lo
siguiente:
1. Determinar quien en el proyecto puede identificar
una lista inicial de términos.
– Incluir expertos en la materia.
– Incluir los analistas de datos de la organización de desarrollo
de software (que a menudo son los expertos en la definición
de términos del negocio).
2. Identificar términos importantes que sean
relevantes para el dominio del negocio.
– Examine los nombres en los documentos existentes del
proyecto (por ejemplo, en la carta del proyecto, en la
declaración de la visión, y declaración del problema).
– Incluya términos relacionados con la tabla que se indica.

13/05/2021
Término Ejemplo
Negocio, o partes del
negocio
clientes, compradores, clientes potenciales,
vendedores, proveedores, distribuidores y
proveedores de servicios
Lugares y ubicaciones direcciones y sitios
Eventos puestos de trabajo, órdenes de trabajo,
solicitudes, envíos y producción
Acuerdos contratos, estimaciones, y descuentos
Cuentas cuentas de clientes, registros financieros, y
balances
Productos y servicios servicios a los empleados, materiales y bienes
Mercados y prospectos partes de negocio, proveedores,
contratistas, clientes, vendedores, y distribuidores
Recursos
edificios, bienes, máquinas, dispositivos,
contratistas, empleados y sus definiciones
Términos clave y relevantes que se pueden utilizar para construir
el glosario

13/05/2021
3. Elabore el borrador de definiciones de los términos
– Oriente cada definición a lectores quienes no tienen experiencia en
el negocio o conocimiento acerca de los términos.
– Incluya “Alias” o nombres alternativos cuando múltiples términos
tienen el mismo significado.
– Incluya acrónimos (siglas) después de cada término donde se
utilice.
– Añada ejemplos para clarificar su utilidad. Por ejemplo use
calificadores (como es: “cliente potencial” en lugar de “cliente”) en
términos que ayuden a clarificar.
– Pedir a una persona bosquejar una definición para cada término.
4. Identificar múltiples stakeholders para revisar las
definiciones y revisar los términos como sea necesario para
llegar a un acuerdo común para cada término.
– Reunirse con los de stakeholders para socializar, definir, revisar y
aprobar los términos del glosario.

13/05/2021
Para tomar en cuenta…
• El glosario del proyecto puede ser creado por
secciones de acuerdo a los términos del proyecto,
como, por ejemplo:
– roles del proyecto, nombres de organización,
métodos de software, herramientas, etc.
• Además un glosario evoluciona a medida que se
van estableciendo los requisitos.
– Alguien deberá mantener el glosario al día de manera
que se use en todos los modelos de requisitos y en
las discusiones de requerimientos.
– Idealmente esto lo podría realizar alguna persona del
negocio, sin embargo un analista es un buen
candidato para realizar esta tarea.

13/05/2021
Ejemplo de un glosario
Término Definición Alias Ejemplos
Registro de
notas
Proceso que permite que los profesores ingresen las notas de los
estudiantes. Se puedenpresentarlossiguientescasos:
• Nota no ingresada en el sistema
• Nota registrada en el sistema difiere de la nota de la hoja de resumen
de notas.
• Nota de la evaluación difiere de la hoja de
resumende notas.
Registrode
notas
Registrodebeca
El registro extemporáneo de becas se da cuando en el Departamento de
becas no se ha ingresado la beca de un estudiante, a pesar de que este ha
cumplido con todos los requisitos que se necesita para aplicar a una beca. Asignación
de beca
Anulación
académica
La anulación académica se presenta cuando el estudiante presenta
repeticiones en determinadas asignaturas (3 en adelante); en esta caso
se realiza una autorización para hacer la anulación del periodo
académico en el que el estudiante reprobó la asignatura solicitada para
anulación. Se debe tener presente que en esta anulación no existe
devolución económica
Anular
asignatura
Digitalización
Proceso por el cual se capturan los datos de un formato físico y se lo
expresa datos en forma digital.
Documento
digital
Cliente
Una persona o organización, interna o externa, quienes tienen la
responsabilidad financiera del sistema. El cliente es el receptor de los
productos desarrollados y sus entregables. Ver también stakeholder Estudiante
Defecto
Una anormalidad dentro de un producto. Ejemplos como: omisión e
imperfecciones encontradas durante fases tempranas del ciclo de vida.
Un defecto puede ser cualquier tipo de novedad que se requiera registrar
y resolverla. Ver también Requerimiento de cambios. Error

13/05/2021
Mitigar el riesgo en los
requerimientos

13/05/2021
Artefactos
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Documento
de
Visión

13/05/2021
Primer análisis de riesgos
• Identificar los riesgos más probables para
el proyecto
• Estimar el costo / impacto si el riesgo se
vuelve un problema
• Identificar las señales que indiquen que el
riesgo se está volviendo un problema
• La intención es balancear los beneficios
con sus riesgos
• Un riesgo no forzosamente es algo malo.

13/05/2021
Evaluación y toma de decisión de
seguir adelante
• En base a lo anterior se analiza si:
– Los objetivos son viables y medibles?
– Son factibles?
– Son los riesgos demasiado altos?
– Es el costo de los objetivos razonable?
– Las personas implicadas están de acuerdo y
dispuestas?
– Se justifica el proyecto?
Hay razones para cancelarlo?

13/05/2021
Mitigar el riesgo en los requerimientos
• Los riesgos en los requerimientos son sucesos o
condiciones que ponen en peligro el desarrollo
satisfactorio del producto.
• Los riesgos deben ser evaluados, rastreados y
controlados a lo largo del proyecto, esto ocasiona
que se pueda tener un gran impacto de éxito en el
proyecto.
• Es necesario establecer estrategias que permitan
evaluar los requerimientos relacionados con el
riesgo e identificar acciones para evitar o
minimizar estos riesgos.

13/05/2021
Estrategia para mitigar el riesgo en los
requerimientos
• La estrategia para mitigar el riesgo en los
requerimientos, permite:
– Identificar los riesgos que podrían impedir el
desarrollo efectivo y la gestión de requisitos.
– Involucrar múltiples stakeholders que categorizan
el riesgo de cada requerimiento de acuerdo a su
grado de ocurrencia y a su impacto.
– Al equipo comunicar honestamente acerca de los
potenciales obstáculos.
– Identificar alternativas para administrar los
riesgos por parte del equipo.

13/05/2021
Identificación de los riesgos
1. Reunir los stakeholders para revisar y adaptar una lista
de potenciales riesgos de requerimientos
• Para esto es necesario usar una lista inicial de riesgos
comunes, como por ejemplo:
– Falta de involucramiento del usuario.
– Expectativa del cliente poco realista.
– Los desarrolladores añaden funcionalidades innecesarias.
– Constante cambio de requerimientos.
– Pobre análisis del impacto cuando las necesidades cambian y
evolucionan.
– Uso de nuevas técnicas o herramientas de requerimientos.
– Requisitos poco claros, ambiguos.
– Requisitos contradictorios (conflictivos).
– Falta de requisitos.
– Lluvia de ideas para identificar riesgos adicionales en base a la
experiencia del equipo, como de la cultura de la empresa y su
medio ambiente

13/05/2021
2. Clasificar los riesgos
• Analizar cada riesgo de acuerdo a su probabilidad y su impacto.
• La probabilidad. Riesgo estimado para causar un problema. Usar
una escala o rango como es:
a) Bajo: Remota posibilidad que el riesgo se realizará. Entre 0% - 25%.
b) Medio: Probabilidad moderada que ocurra el riesgo. Entre 26% -
74%.
c) Alto: Gran probabilidad o certeza de que el riesgo ocurra. Entre 75% -
-- 100%
• El impacto es el grado en que el riesgo afectan negativamente al
proceso de requisitos.
a) Bajo: Puede presentar algún impacto, insignificante.
b) Medio: Impacto manejable o marginal.
c) Alto: Impacto critico o catastrófico. Principales problemas que
necesitan ser analizados.
• Clasificar cada riesgo de acuerdo a cada dimensión (probabilidad e
impacto)

13/05/2021
3. Representar gráficamente las clasificaciones y
ponerse de acuerdo en los riesgos que se
abordarán.
• Una forma de representar la clasificación final podría
ser:
Relación entre la
probabilidad e
impacto de los
riesgos

13/05/2021
4. Determinar las formas de controlar, evitar o
mitigar los posibles riesgos críticos
– Asignar cada riesgo crítico a un miembro del equipo quien
tendrá la responsabilidad de monitorear el riesgo.
Identificar las acciones que él o ella tendrá, los recursos
necesarios para llevar acabo las acciones, y la manera
que él o ella comunicará las acciones al equipo.
– Asegurar que el sponsor y el líder del equipo estén de
acuerdo con las acciones.
– Asegurarse que los miembros del equipo entienden como
sus acciones afectan sus requerimientos.
– Monitorear los riesgos a lo largo del desarrollo y gestión
de requisitos.
– Analizar y adicionar nuevos riesgos a los requerimientos
como ocurran, y actualizar la estrategia de mitigación de
riesgo como sea necesario.

13/05/2021
Algunos riesgos y estrategias que comúnmente ocurren
en los proyectos de desarrollo
Riesgos comunes en los
requerimientos
Estrategias de mitigación
Falta de participación del usuario
• Identificar a los interesados del producto.
• Crear un plan de participación de interesados.
• Usar técnicas de elicitación que atraigan a los usuarios en el
proceso
Expectativaspocorealistas de los
clientes.
• Crear la visión del producto.
• Desarrollar modelos de alcance del proyecto.
• Validar requerimientos con prototipos operacionales.
Desarrolladores agregan
funcionalidades innecesarias .
• Crear la visión del producto.
• Priorizar requerimientos.
Constante cambio de
requerimientos.
• Desarrollarmodelos dealcance.
• Crear una línea base para requerimientos y establecer
mecanismos de control de cambios.
Pobre análisis del impacto cuando las
necesidadescambiany evolucionan.
• Crear una línea base y seguimiento de requerimientos.
• Formalizar documentos de requerimientos.
Uso de nuevas técnicas o herramientas de
requerimientos.
• Adaptar los procesos de requerimientos para el
proyecto.
• Conducir una retrospectiva de los requerimientos.
Requisitospococlaros,ambiguos.
• Desarrollar la visión del producto.
• Desarrollar múltiples modelos de requerimientos.
• Validar los requerimientos.
Requisitos contradictorios
(conflictivos).
• Formalizar el documento de visión.
• Validar los requerimientos con el modelo de validación.
Falta de requisitos
• Desarrollar múltiples modelos de requerimientos.
• Verificar la falta de requerimientos con el modelo de
validación.

13/05/2021
Para tomar en cuenta…
• Muchas de las acciones de mitigación de riesgos
involucra el establecimiento y seguimiento de las
buenas prácticas de gestión de requerimientos.
• En proyectos pequeños, se puede gestionar los
riesgos de manera informal siempre y cuando el
equipo revise los riesgos de forma periódica.
• Para tener un control efectivo de los riesgos es
necesario poner en práctica las técnicas de
mitigación y seguimiento de riesgos, revisando
periódicamente para verificar si se están tomando
las acciones correctas y si los nuevos riesgos
están siendo considerados.

13/05/2021
Ejemplo: catálogo de riesgos y estrategias de mitigación
Factor de riesgo Probabilidad Impacto
Estrategia de mitigación
Responsable
Falta de
disponibilidad del
rector para aclarar el
alcance
Media Alto Llevar a cabo un taller de
visionamiento con el actual
rector y crear modelos de
alcance en el taller.
Juan Peralta
(Gerente proyecto)
No involucramiento
del contratista
Media Alto Llevar a cabo una visita (por
ejemplo en el lugar de trabajo
hacer el seguimiento por un
medio día).
Llevar a cabo una entrevista con
el contratista cada cierto periodo
de tiempo.
María Piguave
(Analista).
Poco interés de las
secretarias de los
centros
Media Bajo Realizar un taller para indicar
las bondades de un sistema
automatizado.
Juan Peralta
(Gerente proyecto)
Poco interés de las
secretarias de
escuela
Alto Alto Realizar reuniones informativas
sobre el nuevo proceso
automatizado para resolver los
trámites de los estudiantes.
Juan Peralta
(Gerente proyecto) y
el sponsor del
proyecto.

13/05/2021
Definición de los stakeholders

13/05/2021
Artefactos
Actividades
Especificación
de Requisitos
Documento
de
Requisitos
Modelo del
Sistema
Documento
de
Visión

13/05/2021
Estrategias y herramientas para elicitar
requerimientos
Identificar fuentes
Una lista de fuentes de
requerimientos
Identificar stakeholders del producto Categorías de los stakeholders
Describir necesidades y criterios de
éxito de los stakeholders
Perfiles de stakeholders
Revisar técnicas de elicitación
Identificar combinaciones de
técnicas de elicitación:
entrevistas, prototipos
exploratorios, talleres
facilitadores,
focus groups, análisis de tareas
de usuario, estudio de
documentación existente
Plan de elicitación
Plan de elicitación de
stakeholders

13/05/2021
Identificación de Fuentes de
Información
• Stakeholders: clientes, usuarios, expertos del
dominio, otros actores, Grupos (formales /
informales)
• Documentos del Universo de discurso
(formularios, políticas de organización,
manuales, actas de reuniones, ...)
• Documentos externos al Universo de
discurso (manuales de otros software, libros
sobre temas relacionados, …)
• Software interno / externo

13/05/2021
Listar las fuentes de requerimientos
• El listado de fuentes es un inventario de personas,
documentos específicos, y fuentes de información
externa de donde se elicitarán los requerimientos.
• Se realiza para:
– identificar fuentes potenciales de documentación de
requerimientos, y
– permitir a los analistas: elicitar, revisar, documentar, y
verificar información de requerimientos con los
stakeholders.
• Para ello, se deberá:
– identificar las fuentes de información, y
– facilitar la planificación para una eficiente participación de
los stakeholders.

13/05/2021
Identificando fuentes
• Para realizar un proceso
apropiado de elicitación se
requiere:
1. Identificar los stakeholders
relevantes que proporcionarán
los requerimientos.
2. Identificar la documentación
que se pueda usar como
fuente de información para los
requerimientos.
3. Identificar fuentes externas de
información.

13/05/2021
1. Identificar los stakeholders relevantes que
proporcionarán los requerimientos
• Asegúrese de considerar a todos los stakeholders
del proyecto. Incluya a:
– los clientes quienes auspician y dirigen el desarrollo
de software
– los usuarios que interactuaran directamente con el
software, y otros quienes tienen conocimiento o
apuestan por el proyecto
• Desarrolle un plan de elicitación para cada
stakeholder.
– Tener en cuenta que los stakeholders están a
menudo ocupados y necesitan de un aviso previo
para participar en el levantamiento de requerimientos.

13/05/2021
2. Identificar la documentación que se pueda usar
como fuente de información de requerimientos
• Documentación de interfaces del sistema
existentes.
• Requerimientos de cambio, listas de defectos
de software, registro de quejas de clientes,
lista de inconvenientes.
• Guías de usuario, materiales de
entrenamiento, guías y procedimientos de
trabajo.
• Documentación help desk.
• Código fuente de sistemas existentes.

13/05/2021
3. Identificar fuentes externas de
información
• Departamentos o compañías que proveen
servicios de estudios de mercado y análisis
de la industria.
• Análisis de productos de software del
mercado
• Materiales de ventas, marketing y
comunicaciones
• Regulaciones, guías y leyes provenientes de
agencias gubernamentales o cuerpos
regulatorios.

13/05/2021
requerimientos
Identificar fuentes
requerimientos
facilitadores,
stakeholders

13/05/2021
Categorías de los stakeholders
• Las categorías de stakeholders son grupos o
individuos que están interesados en el producto de
software que se está desarrollando.
• Es necesario definir las categorías de los stakeholders
para entender:
– Quienes están interesados o influencian en el proyecto,
– Quienes utilizarán el producto y sus salidas;
– y a quien de alguna manera afectaría el producto.
• Por lo tanto, estos grupos e individuos necesitarán
estar informados acerca del progreso, conflictos,
cambios y prioridades del proceso de desarrollo del
producto.

13/05/2021
Estar informados acerca del progreso,
conflictos, cambios y prioridades
• Esto se hace:
– Especificando los tipos de personas quienes
tienen requerimientos y necesidades a las
que se denominan como involucrado o
stakeholders.
– Distinguiendo a los clientes de los usuarios
del producto.
– Clarificando que personas y agencias
externas se deben consultar.

13/05/2021
Tenga presente que…
• Si no logra una comprensión completa por
parte de los stakeholders puede ocurrir la
falta de requisitos o erróneos o el desarrollo
de la solución de forma incorrecta.
– Por tanto, es necesario que se asegure de que:
• todos los interesados comprenden su rol/categoría,
además de que…
• se incluyen a todos los interesados antes de proceder
con el desarrollo del software
– Esta actividad permite responder a las siguientes
preguntas:
• ¿Quién afecta o es afectado por el sistema?
• ¿Quién o qué interactúa con el sistema?
• ¿Quién tiene los conocimientos relevantes de los
requerimientos?

13/05/2021
¿Cuáles son las categorías de los
stakeholders?
Hay tres categorías de actores: clientes, usuarios y otras partes
interesadas
Stakeholders
Clientes
Patrocinador
(Sponsor)
Product
Champions
Usuarios
Usuarios
Directos
Usuarios
Indirectos
Otros
Consejeros Proveedores

13/05/2021
Clientes
• Son responsables de aceptar y pagar por el producto de
software.
• Sponsor
– Es quien autoriza o legitima el desarrollo del producto contratando
o pagando el proyecto.
– La influencia del sponsor es a veces necesaria para lograr el
involucramiento de los stakeholders.
– Asegúrese de revisar la lista de stakeholders con el patrocinador
para mantenerlo informado acerca de los stakeholders pertinentes.
• Product champions
– Es quien asegura que el software cumple con las necesidades de
múltiples comunidades de usuarios.
– Identifica quienes (usuarios) deben participar en el desarrollo de
requerimientos para asegurar que los requerimientos correctos son
obtenidos.
– Pueden ser los usuarios finales del producto.
– El producto puede tener múltiples champions si se tienes múltiples
tipos de usuarios directos.

13/05/2021
Usuarios
• Son aquellos que están en contacto con el producto de
software o son afectados por este de alguna manera.
• Usuarios directos
– Son las partes (por ejemplo: gente, organizaciones,
componentes del sistema o dispositivos que directamente
interactúan con el software) que directamente se involucran con
el software (por ejemplo: una persona que solicita la información
del sistema a través de una interfaz de usuario, un sistema que
envía o recibe archivos de datos, o un dispositivo que envía o
recibe señales o mensajes).
• Usuarios indirectos
– Quienes no interactúan directamente con el software pero
pueden entrar en contacto con los productos generados por el
sistema (reportes, facturas, bases de datos, etc.).
– También puede incluir a personas quienes pueden ser afectadas
por las decisiones o acciones realizadas como resultado de las
salidas del sistema.

13/05/2021
Otros stakeholders
• Poseen conocimiento acerca del producto o un interés
en su desarrollo o mantenimiento.
• Consejeros
– Tienen información relevante acerca del software.
– Puede incluir a expertos.
– A menudo conocen las reglas de negocio vitales que
deben ser incorporadas dentro del software, aun sino
interactúan con el producto de software.
– Asegúrese de identificar a los consejeros e involucrarlos
en le proceso de elicitación de requerimientos.
• Proveedores
– Quienes diseñan y producen el software transformando
los requerimientos en el producto final
– Incluye a los miembros del equipo (analistas, diseñadores,
desarrolladores, finanzas, ventas y departamentos de
soporte), proveedores de software y subcontratistas.

13/05/2021
¿Como categorizar los stakeholders?
Para realizar la categorización de los stakeholders, es necesario
realizar lo siguiente:
1. Identificar stakeholders, ya sean clientes, usuarios u otros
stakeholders.
– Registrar los stakeholders como roles en cada una de las
categorías, más que como personas especificas. Recuerde que
el mismo rol puede aparecer en varias categorías.
– Recordar que el mismo rol puede aparecer en múltiples
categorías.
2. Revisar el registro de categorías de stakeholders con los
stakeholders del proyecto para asegurar que la misma está
completa y precisa.
3. Revisar la lista como sea necesario y compartir la misma
con el equipo entero.

13/05/2021
Ejemplo: categorización de stakeholders
Clientes Usuarios Otros Stakeholders
Sponsor Product
Champion
Usuarios Directos Usuarios
Indirectos
Consejeros Proveedores
Rector Director de
procesos
• Secretaria
general
• Secretaria de la
carrera
• Director de
escuela
• Profesor
• Coordinación
académica
• Contabilidad
• Centro de
evaluaciones
• Estudiante
• Atención al
estudiante
• Call Center
• SRI
• Senescyt
• Auditor
externo
• Consultor
• Gerente del
proyecto.
• Analistas
• Desarrolladores
• Administrador
de base de
datos

13/05/2021
requerimientos
Identificar fuentes
requerimientos
facilitadores,
stakeholders

13/05/2021
• Es una descripción que caracteriza a cada
stakeholder y explica su relación con el proyecto.
• Es necesario definir el perfil para:
– entender los intereses, preocupaciones y criterios de éxito
del producto para cada stakeholder
– descubrir las posibles fuentes de conflicto entre las partes
interesadas de los requisitos, y
– poner de relieve temas relacionados con los requisitos que
pueden requerir más tiempo y atención.
• Los perfiles también pueden revelar los posibles
obstáculos para la implementación exitosa del
producto y le ayudará a definir la cantidad de
participación que cada stakeholder debe tener en el
levantamiento de requerimientos.

13/05/2021
• Los perfiles de los stakeholders permiten:
– Educar al equipo acerca de las expectativas del
cliente.
– Proveer al equipo un alto nivel de entendimiento
de las necesidades del usuario.
– Destacar potenciales obstáculos en el proceso de
aceptación del producto de software por parte de
los stakeholders.

13/05/2021
Perfiles de stakeholders: preguntas claves
• ¿Cuáles son las responsabilidades de los Stakeholders clave
en relación con el sistema en desarrollo o los cambios
implementados?
• ¿Qué motivaciones, deseos y esperanzas tienen los
stakeholders para el producto de software?
• ¿Qué características o capacidades de software deben estar
presentes para cada uno de los stakeholders para ver el
producto como un éxito?
• ¿Qué obstáculos, limitaciones, o los factores que limitan cada
actor se prevee para él mismo o para otros que puedan
amenazar la implementación exitosa?
• ¿Qué nivel de confort tienen los stakeholders con la
tecnología?
• ¿Hay algún trabajo especial o condiciones ambientales que
podrían afectar la capacidad de los stakeholders en utilizar
eficazmente el sistema?

13/05/2021
Perfiles de stakeholders: especificación
1. Escribir un breve perfil de cada actor.
Describa su:
– Rol: Lista la categoría de stakeholder (por ejemplo, el
sponsor (patrocinador), Product Champion, usuario directo,
usuario indirecto, asesor o proveedor) al que pertenece.
– Responsabilidades: Describa brevemente el rol de cada
stakeholder en relación con el proyecto.
– Intereses: Liste las necesidades de los stakeholders,
deseos y expectativas para el producto (por ejemplo, los
intereses de un patrocinador puede incluir aumento de los
ingresos, reducción de costos, mejora de los servicios y el
cumplimiento de las normas reglamentarias).
– Los criterios de éxito: Describir las características o
capacidades que el producto debe tener para ser
considerado como exitoso.

13/05/2021
Perfiles de stakeholders: especificación
– Preocupaciones: Lista de todos los obstáculos,
limitaciones, o los factores limitantes que puedan impedir
o inhibir al stakeholder a aceptar el producto.
– Capacidad técnica: Describir al usuario directo el grado
de familiaridad con la tecnología.
– Características del entorno de trabajo y limitaciones:
Describir las condiciones de trabajo relevante que pueda
afectar el uso del sistema (por ejemplo, un entorno de
trabajo ruidoso o el uso del móvil o al aire libre).
2. Incluir los perfiles de los stakeholders en el
documento de requerimientos de usuario (si se
utiliza) y el documento de especificaciones de
requisitos de software.
– Si los perfiles contienen gran cantidad de información,
documente un perfil por cada stakeholder en una tabla o
sección en el documento de requisitos correspondientes.

13/05/2021
Perfiles de stakeholders: combinación
• La combinación de las
categorías de stakeholders
puede considerarse en
proyectos pequeños o de
menor complejidad.
• Se puede crear una versión
más corta de los perfiles de
los stakeholders mediante la
combinación de los
intereses y los criterios de
éxito.

13/05/2021
Ejemplo: perfiles de stakeholders para un
sistema de trámites
Stakeholder Rol Responsa-
bilidad
Intereses Criterios de
éxito Preocupación
Competencia
s técnicas/
Relación de
ambiente de
trabajo
Rector -Sponsor
-Usuario
indirecto
Aprobar
(proyecto)
Construya un
sistema de
acuerdo a las
normas de la
universidad
Satisfacer las
necesidades
de los
estudiantes
Tiempo de
construcción de la
aplicación
N/A
Coordinación
Académica
-Usuario
directo
-Product
champion
Aprobar
proceso
Perfeccionar y
validar los
procesos
-Trámites
registrados en
cada centro.
-Cada actor
realiza las
actividades.
-Satisfacción
de los
estudiantes
-Involucramien-to
de los actores que
intervienen en el
proceso.
-No se registre de
forma apropiada
la información
Liberación del
producto.

13/05/2021
Lección 2
Elicitación de requerimientos -
Técnicas
Unidad 2

13/05/2021
Contenido

13/05/2021
requerimientos
Identificar fuentes
requerimientos
facilitadores,
stakeholders

13/05/2021
requerimientos
El descubrimiento de requerimientos incluye recabar información sobre:
• El dominio de la aplicación
• El problema especifico
• La organización o proceso
• Necesidades de stakeholders.
Se requiere diferentes técnicas para descubrir toda esta información.
Cada técnica puede cubrir uno o varios dominios diferentes.

13/05/2021
Guías básicas de recolección de datos
• Enfocarse en identificar las necesidades de los
stakeholders estudiando su comportamiento y sus
herramientas de apoyo.
• Involucrar a todos los grupos de stakeholders
• Involucrar solo a un representante de cada grupo de
stakeholders no es suficiente, especialmente si es un
grupo grande ya que cada uno tendrá su propia
perspectiva de la situación, la tarea, su trabajo y como
otros trabajan con ellos.
• Usar una combinación de técnicas de levantamiento de
datos. Cada técnica involucra cierta clase de
información desde una cierta perspectiva.
• Completar las sesiones de levantamiento de datos con
cosas específicas tales como la descripción de tareas y
prototipos, si están disponibles.

13/05/2021
Guías básicas de recolección de datos
• Organizar una sesión piloto, para asegurar que la sesión
de levantamiento de datos esta yendo como se la
planeo. Cualquier dato recolectado durante la sesión
piloto no puede ser tratado igual que los otros datos.
Después de realizar la sesión piloto es probable que
algunos cambios sean necesarios antes de organizar la
sesión real.
• El levantamiento de datos es una actividad muy cara y
que consume mucho tiempo y que usualmente se
restringe por los recursos disponibles.
• Como se registra los datos durante la sesión de
levantamiento de datos cara a cara es tan importante
como la técnica que se usa. Grabación de video, audio y
toma de notas son las principales opciones.

13/05/2021
Técnicas de elicitación
• Técnicas básicas
– Observación in situ
– Inmersión/aprendizaje
– Estudio de la documentación
– Encuestas
• Glosario de términos
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Observación in situ
• La observación in situ consiste en la observación
directa de las prácticas profesionales que se
realizan habitualmente en la organización para la
que se va a desarrollar el software.
• Antes de celebrar una sesión de observación in
situ, se deben escoger un conjunto de prácticas
representativas del resto, que se lleven a cabo
con una frecuencia relativamente alta o que
presenten cierta complejidad de comprensión.
• Además, se debe intentar que los resultados de la
práctica profesional sean observables en el
entorno real de trabajo.

13/05/2021
Observación in situ
• Poco utilizado…
• Antes de usarlo
– Determinar información necesaria
– Comunicar a los involucrados
– Considerar períodos normales y atípicos
– Planificar las anotaciones
▪ Ventajas
▪ Confiable
▪ Muy rico
▪ Desarrolla empatía
▪ Desventajas
▪ Efecto Hawthorne
▪ Cuidado con generalizar
demasiado (sesgo
particular/local)
Efecto Hawthorne: Teoría que proviene de la psicología experimental, que
mantiene que una persona modificará su actitud si se siente observada,
intentando comportarse de la forma que supone que el observador espera.

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Inmersión/aprendizaje
• Existen algunas variantes de la
observación in situ como son:
– la inmersión dentro de la organización para la
que se va a desarrollar el software
– la realización de periodos de aprendizaje por
parte de los ingenieros de requisitos, en las
que:
• la observación pasiva se cambia por una
participación activa en los procesos a
observar como si fuera un miembro más del
personal de la organización bajo estudio.

13/05/2021
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
• Motivación: Las personas con frecuencia encuentran
muy difícil articular los detalles de su trabajo, porque es
una segunda forma de vida para ellas
– Entienden su trabajo, pero tal vez no su relación con otras
funciones en la organización.
– 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

13/05/2021
Etnografía
La etnografía es muy efectiva
para descubrir dos tipos de
requerimientos:
1. 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.
2. Requerimientos que se
derivan de la cooperación y el
conocimiento de las
actividades de otras personas

13/05/2021
Etnografía
• 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.
• Más aún, la creación de prototipos se enfoca en la etnografía
al identificar problemas y preguntas que entonces pueden
discutirse con el etnógrafo.
• Siendo así, éste debe buscar las respuestas a dichas
preguntas durante la siguiente fase de estudio del sistema
(Sommerville et al., 1993).
Análisis
etnográfico
Reuniones
de interrogatorio
Etnografía
enfocada
Evaluación
de prototipos
Desarrollo
del sistema genérico
Prototipo
del sistema

13/05/2021
Etnografía
• Los estudios etnográficos pueden revelar detalles
críticos de procesos, que con frecuencia se
pierden con otras técnicas de adquisición de
requerimientos.
• Sin embargo, debido a su enfoque en el usuario
final, no siempre es adecuado para descubrir
requerimientos de la organización o de dominio.
– No en todos los casos se identifican nuevas
características que deben agregarse a un sistema.
• En consecuencia, 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.

13/05/2021
Enfoque antropológico (Técnicas de etnografía)
Se integra con el
medio ambiente, el
analista se
convierte en el
cliente.
▪ Ventajas
▪ Visión de dentro para afuera
▪ Visión muy contextualizada
▪ Desventajas
▪ Efecto Hawthorne
▪ Consume mucho tiempo
▪ Poca sistematización

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Investigar antecedentes - Documentación
Lectura de información
• Abarca la lectura de todos los
documentos disponibles en la
organización, intenta identificar
estructuras, hechos y vocabulario
similares.
• Tipo de lectura: diagramas
organizacionales, estándares,
modelos de procesos o manuales
de sistemas existentes.
• Fácil de obtener si hay
documentación, permite manejar
gran volumen.
• Provee información muy dispersa.
Gran trabajo para procesarlo.

13/05/2021
• Procedimientos y reglas son a menudo escritas
en manuales.
• Es una buena fuente de datos acerca de los
pasos envueltos en una actividad y regulaciones
que rigen una tarea.
• No debe ser usado como única fuente.
• Es bueno para entender la legislación, y para
obtener información en el trabajo.
• Este no envuelve el tiempo de los stakeholders,
el cual es un factor limitante en otras técnicas

13/05/2021
• Estudio, muestreo, visitas,…
• Buena forma de comenzar un proyecto
• Interna: estructura de la organización, políticas y
procedimientos, formularios e informes,
documentación de sistemas
• Externa: publicaciones de la industria y comercio,
Encuentros profesionales, visitas, literatura y
presentaciones de vendedores
▪ Ventajas
▪ Ahorra tiempo de otros
▪ Prepara para otros enfoques
▪ Puede llevarse a cabo fuera
de la organización
▪ Desventajas
▪ Perspectiva limitada
▪ Desactualizado
▪ Demasiado genérico

13/05/2021
• Ingeniería reversa
– Requiere que exista un sistema existente con
documentación (o código) disponible.
– Desventajas: no refleja la actualización de la
información, información muy detallada (a un bajo
nivel)
• Reuso
– Debe haber componentes reutilizables disponibles,
se debe definir lo que se va a reutilizar, necesita de
mecanismos de recuperación.
– Análisis de dominio
– Si bien favorece la calidad y la productividad, no
siempre es fácil de lograr en la realidad.

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Encuestas (cuestionario)
• Secuencia de preguntas que
exige un conocimiento mínimo.
• Facilitan la estructuración de
preguntas y un tratamiento
estadístico.
• Limita el tipo de respuestas
• Tienen poca participación e
interacción

13/05/2021
Encuestas (cuestionario)
• Consta de una serie de preguntas diseñadas para
obtener información específica.
• Las preguntas pueden requerir diferentes tipos de
respuestas como son:
– SI / NO
– Opción múltiple
– Largas o comentarios.
• Usualmente los cuestionarios son usados en conjunto
con otras técnicas.
• Pueden dar datos cualitativos o cuantitativos.
• Bueno para contestar preguntas especificas de un grupo
grande de personas o dispersado.

13/05/2021
Encuesta / Cuestionario
• No substituye la entrevista
• Antes de usar el enfoque:
– Determinar la información que se precisa
– Determinar el enfoque más adecuado:
• Abierto, cerrado, combinado
• Múltiple opción, valor en escala, orden relativo
– Desarrollar cuestionario
– Probarlo con perfil típico
– Analizar resultado de las pruebas
• Su principal uso es para validar asunciones y obtener
datos estadísticos sobre preferencias
▪ Ventajas
▪ Economía de escala
▪ Conveniente para quien contesta
▪ Respuestas anónimas
▪ Desventajas
▪ Menos rico
▪ Problemas por no-respuesta
▪ Esfuerzo de desarrollo

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Recordando… Glosario
• Se lo considera como un diccionario de términos
comúnmente relevantes con respecto al producto
que se construye, se mejora o se compra.
• Los términos del glosario se utilizan a lo largo de
todo el proyecto.
• Su uso es necesario pues establece un
vocabulario común para los términos clave que
ayuda a los miembros del equipo a entender estos
términos.
– Diferentes Stakeholders pueden usar el mismo
término para explicar diferentes cosas
(ambigüedad), o pueden usar diferentes términos
para expresar la misma cosa, causando confusión y
gasto de energía a la hora de comunicar los
requerimientos.

13/05/2021
Beneficios del glosario
• Como resultado de construir un glosario se tiene:
– Proveer un conocimiento compartido del dominio del
problema.
– Permitir a los dueños del negocio informen al
personal técnico acerca de importantes conceptos del
negocio.
– Provee los fundamentos para definir modelos de
requerimientos tales como reglas de negocio,
modelos de datos y casos de uso.
– Ahorra tiempo y esfuerzo durante el desarrollo de
requerimientos, eliminando malos entendidos de lo
que realmente significan los conceptos del negocios.

13/05/2021
Ejemplo de un glosario
Término Definición Alias Ejemplos
Registro de
notas
Proceso que permite que los profesores ingresen las notas de los
estudiantes. Se puedenpresentarlossiguientescasos:
-Nota no ingresada en el sistema
-Nota registrada en el sistema difiere de la nota de la hoja de
resumen de notas.
-Nota de la evaluación difiere de la hoja de resumende notas.
Registrode
notas
Registrodebeca
El registro extemporáneo de becas se da cuando en el Departamento de
becas no se ha ingresado la beca de un estudiante, a pesar de que este ha
cumplido con todos los requisitos que se necesita para aplicar a una beca. Asignación
de beca
Anulación
académica
La anulación académica se presenta cuando el estudiante presenta
repeticiones en determinadas asignaturas (3 en adelante); en esta caso
se realiza una autorización para hacer la anulación del periodo
académico en el que el estudiante reprobó la asignatura solicitada para
anulación. Se debe tener presente que en esta anulación no existe
devolución económica
Anular
asignatura
Digitalización
Proceso por el cual se capturan los datos de un formato físico y se lo
expresa datos en forma digital.
Documento
digital
Cliente
Una persona o organización, interna o externa, quienes tienen la
responsabilidad financiera del sistema. El cliente es el receptor de los
productos desarrollados y sus entregables. Ver también stakeholder Estudiante
Defecto
Una anormalidad dentro de un producto. Ejemplos como: omisión e
imperfecciones encontradas durante fases tempranas del ciclo de vida.
Un defecto puede ser cualquier tipo de novedad que se requiera registrar
y resolverla. Ver también Requerimiento de cambios. Error

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Entrevista Individual / Grupal
• Usar para:
– Entender el problema
de negocio
– Entender el ambiente
de operación
– Evitar omisión de
requisitos
– Mejorar las relaciones
con el cliente
• Pasos para las Entrevistas
– Seleccionar participantes
• Aprender tanto como sea
posible de antemano
– Preparar la entrevista
• Utilizar un patrón de
estructura
– Conducirla
• Apertura, desarrollo,
conclusión
– Enviar un memo con resultado
– Seguimiento
▪ Ventajas
▪ Orientado a las personas
▪ Interactivo/flexible
▪ Rico
▪ Desventajas
▪ Costoso
▪ Depende de las habilidades
interpersonales

13/05/2021
Entrevista – Patrón para conducirla
• Datos de las Personas: usuarios, interesados, disparador del
proyecto
– ¿Qué trabajo realizan? ¿Para quién?
– ¿Qué interfiere con su trabajo?
– ¿Qué cosas hacen su trabajo mas fácil o mas difícil?
• Datos: entradas y salidas clave, datos ya existentes
– Listar las entradas y salidas
– ¿Cuál es el problema? ¿Cómo se resuelve ahora? ¿Como le gustaría
que se resolviera?
• Procesos: propósito, objetivos y metas
– ¿Quién necesita la aplicación?
– ¿Cuántos usuarios la van a usar y de qué tipo?
• Ubicaciones: lugares involucrados, contexto de los usuarios
– Entorno de los usuarios, computadoras, plataformas
– Aplicaciones relevantes existentes
– Experiencia de los usuarios con este tipo de aplicación, expectativas de
tiempo de entrenamiento

13/05/2021
Entrevista – Patrón para conducirla (2)
• Evaluar confiabilidad, desempeño y soporte necesario:
– ¿Cuáles son las expectativas respecto a la confiabilidad?
– ¿Y respecto a la performance?
– ¿Qué tipo de mantenimiento se espera?
– ¿Qué nivel de control y seguridad?
– ¿Qué requisitos de instalación existen?, ¿cómo se distribuye el
software? , ¿debe ser empaquetado?
• Otros
– ¿Existen requisitos legales, regulatorios u otros estándares que deban
ser tenidos en cuenta?
• Factores críticos de éxito:
– ¿Qué se considera una buena solución?
• Tener en cuenta:
– Si el entrevistado comienza a hablar sobre los problemas existentes, no
cortarlo con una próxima pregunta
– Luego de la entrevista y mientras los datos aún están en mente, resumir
los principales req. (aprox. 3) de este entrevistado

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
¿Qué es una reunión?
• Un suceso puntual en que un conjunto de
personas, que puede que no se conozcan
y no se vuelvan a ver, tratan sobre un
tema. Suelen tener un objetivo común.

13/05/2021
Reuniones
• Extensiones de entrevista. Muy activas. De corta
duración e intensas con un determinado foco
– Braisntorm: lluvia de ideas
– Workshop de requisitos: existe un moderador
– JAD(Join application design): se avanza en un
principio de construcción, más organizado y
racional con generación de documentos,
compromisos, fechas.
▪ Ventajas
▪ Favorecen la aparición de
múltiples opiniones,
creación, feedback y
consenso colectivo.
▪ Desventajas
▪ Puede haber dispersión,
incomodidad en el grupo.
▪ El pensamiento es generado
a nivel de grupo, eliminando
problemas particulares.
▪ Altos costo.

13/05/2021
Preparación de una reunión.
• Definir objetivos de la reunión.
• Seleccionar a los participantes.
• Planificar el desarrollo.
• Convocar a los participantes.
• Organizar el material para la reunión.

13/05/2021
Definir objetivos de la reunión.
• ¿Que resultados se desean alcanzar?
• ¿Se puede alcanzar por otro medio?
• Para buen clima, mejor una copas.
• Para informar el teléfono ¿?.
• Objetivos = Resultados
• definidos y anotados
• Priorizar los objetivos.
• Ineludible, además, secundario.
• Titulo, es muy importante.

13/05/2021
Seleccionar a los participantes.
• La reunión depende de ellos.
• Las personas que pueden aportar
– ¿Aportará información útil?
– ¿Aportará ideas?
– ¿Influirá en la decisión?
– ¿Dinamizará la reunión?
– ¿Problemas si no se le invita?
• Cantidad: de 8 a 10 participantes.

13/05/2021
Planificar el desarrollo.
• Crear el orden del día:
– Lista de temas
– Orden en que se abordaran.
– Tiempo asignado a cada tema.
• Detallar mucho el orden del día permitirá
preparar mejor los puntos.
• Si se conocen los tiempos, algunos
participantes solo estarán lo necesario.

13/05/2021
Convocar a los participantes.
• La convocatoria:
– ¿Suscita el interés de los asistentes?
– Debe justificar el porqué.
– Explicara el cómo se desarrollará.
– Informará
• Quien coordinará.
• Los asistentes y su participación.
• Fecha, hora y lugar.
• Debe resultar atractiva...

13/05/2021
Organizar el material para la reunión.
• No deben descuidarse:
– El material necesario para
presentar y distribuir.
– La sala, material de
proyección, limpieza, aire
acondicionado, situación
circular de los asientos,
Papelografos…

13/05/2021
Iniciar la reunión
• Presentar a los participantes.
• Generar un clima de confianza.
• Centrar el tema de la reunión.
• Fijar objetivos.
• Definir los métodos de trabajo.
• Definir el papel del secretario.

13/05/2021
Durante la reunión
• El moderador:
– Invitar a que la gente se exprese.
– Controlar el exceso de posesión de palabra.
– Facilitar un clima de confianza.

13/05/2021
Durante la reunión
• Los participantes:
– Utilizar el uso de la palabra de forma
consciente.
• Estimar el coste horario de una reunión.
– Tomar la palabra cuando se tiene algo que
decir… cualquier argucia es buena.
– No dejar la palabra hasta haber terminado de
decir lo que se desea.

13/05/2021
Finalización de la reunión.
• Hacer una síntesis y que sea
consensuada.
• Analizar la reunión.
• Explicar la forma en que se documentarán
los resultados.
• Dar feedback a los asistentes.

13/05/2021
Resumen
• Las reuniones son necesarias, pero
– A la gente no le gusta ir a una reunión si no
hace falta.
– Es importante invitar a los que hacen falta.
– El objetivo ha de estar claro.
– Las reuniones son muy caras.
– La organización de la reunión llevara a
reuniones más productivas.

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Reuniones para recoger información.
• El que convoca
necesita obtener
información de los
asistentes.
• Ejemplo:
– Responsable de
proyecto y situación
actual para visitar al
cliente.
Pregunta
información

13/05/2021
Joint Application Development (JAD)
• El JAD se basa en organizar reuniones integradas por
miembros del equipo de desarrollo y miembros de la
organización para la que se va a desarrollar el sistema
software.
• Los asistentes incluyen oficiales de administración de alto
nivel, quienes se aseguran de que el producto provea los
reportes y la información requerida al final.
• Durante una sesión de JAD, el coordinador plantea las
cuestiones a discutir para determinar los objetivos y
los requisitos generales del sistema a desarrollar y los
participantes contestan a dichas cuestiones.
– Si quedan temas abiertos, el coordinador de la sesión debe
documentarlo para programar otra reunión en la que se aborden
dichos temas.
– Si ya se dispone de los modelos de negocio del sistema a
desarrollar, este material puede resultar útil para consultar y
aclarar algunos aspectos durante la sesión.

13/05/2021
Componentes básicos de una sesión JAD
Los componentes básicos de una sesión JAD se enumeran a
continuación:
• Patrocinador ejecutivo: el ejecutivo que funda el proyecto, el
propietario del sistema. Deben ser lo suficientemente altos en la
organización para poder tomar decisiones y brindar los recursos y el
apoyo necesarios para el proyecto. Pueden asistir a la sesión de
apertura y clausura.
• Líder / gerente de PROYECTO: generalmente el líder del equipo de
desarrollo de aplicaciones responde preguntas sobre el proyecto con
respecto al alcance, tiempo, problemas de coordinación y recursos.
Pueden contribuir a las sesiones siempre que no inhiban a los
participantes.
• FACILITADOR / LÍDER DE LA SESIÓN: Preside la reunión y dirige el
tráfico manteniendo al grupo en la agenda de la reunión.
– El facilitador es responsable de identificar los problemas que se pueden resolver
como parte de la reunión y los que deben asignarse al final de la reunión para la
investigación de seguimiento y la resolución.
– El facilitador atiende a los participantes y no aporta información a la reunión.

13/05/2021
Componentes básicos de una sesión JAD
• SCRIBE / MODELER / Recorder / Documentation Expert: Registra y
publica las actas de la reunión y no aporta información a la reunión.
• PARTICIPANTES: Clientes del área de negocio afectados directa o
indirectamente por este proyecto, que sean expertos en su campo y
puedan tomar decisiones sobre su trabajo. Son la fuente de información
para la sesión.
• OBSERVADORES: Generalmente miembros del equipo de desarrollo de
aplicaciones asignados al proyecto. Deben sentarse detrás de los
participantes y observar en silencio los procedimientos.
Además de las personas mencionadas anteriormente, cada sesión de JAD
tiene objetivos bien definidos, una agenda y directrices detalladas, ayudas
visuales y un documento final que contiene todas las decisiones tomadas por
el grupo.

13/05/2021
Joint Application Development (JAD)
• Conjunto de reuniones de 2 a 4 días.
• Cuatro principios: dinámica de grupo, uso de técnicas
audiovisuales, organización y documentación WYSIWYG.
• Roles en JAD
– Jefe de JAD: responsable general, controla las reuniones.
– Analista: responsable de la documentación generada.
– Patrocinador ejecutivo: decide si el proyecto se lleva a cabo o no.
– Representantes de los usuarios: directivos o futuros usuarios
finales.
– Representantes de sistemas de información: asesoran sobre las
posibilidades tecnológicas y de coste.
– Especialistas: asesoran en aspectos técnicos o del dominio del
problema.
▪ Ventajas
▪ Trabajo conjunto de
desarrolladores y clientes
▪ Documentación WYSIWYG
▪ Desventajas
▪ Se adapta mal a los horarios de
los clientes y usuarios, siendo
muy compleja de organizar

13/05/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

13/05/2021
Reuniones para generar ideas
• Son reuniones en
las que los
asistentes tienen
total libertad para
expresar sus ideas,
no se suelen criticar
pero si refinar.
Ideas

13/05/2021
Tormenta de ideas (Brainstorming)
• Generación de ideas.
• No se critican
• Creatividad.
• Genera ideas,… pero
para seleccionar…

13/05/2021
Brainstorming
• Desarrollado en 1941 por A. F. Osborne,
el brainstorming fue diseñado para:
– Alentar a expresar ideas
– Diferir el juicio crítico hasta más tarde.
• Todo el mundo ofrece ideas que se
relacionan, se combinan, se mejoran, y se
cambian en otras varias ideas.
• Al final, el grupo está de acuerdo en una
solución final.

13/05/2021
Brainstorming
• La idea es crear un entorno que no inhiba y que
aliente las ideas y pensamientos imaginativos.
• Los dos principios básicos del brainstorming
son:
– 1. La cantidad produce calidad. Cuantas más ideas
más probabilidades de llegar a la solución mejor.
– 2. Diferir el juicio. Es mejor revisar las ideas más
tarde con algo de objetividad.
• Ayuda a reeducar a la gente para que piense
positivamente en las ideas.

13/05/2021
Tormenta de Ideas (Brainstorming)
• Objetivo: Lograr consenso sobre los requisitos
• Ayuda a la participación de todos los involucrados
• Permite pensar en otras ideas
• Un secretario saca notas de todo lo discutido.
– Puede hacer uso de mapas mentales o brainwriting
• Reglas
– No se permite criticar ni debatir
– Dejar volar la imaginación
– Generar tantas ideas como sea posible
– Mutar y combinar ideas

13/05/2021
Tormenta de Ideas – Fase de Generación
• Los principales stakeholders se juntan en un
cuarto.
• Se explican las reglas.
• Se establece el objetivo:
– ¿Qué características esperan en el producto?
– ¿Qué servicios esperan que provea?
Los objetivos permiten decidir cuando terminar.
• Se pide que cada participante escriba sus
ideas, luego las ideas son leídas para que
otros piensen en ideas relacionadas y de esa
forma las ideas mutan y se combinan.

13/05/2021
Tormenta de Ideas – Fase de Reducción
• El secretario lee cada idea y pregunta si es válida
– Si hay cualquier desacuerdo, la idea se queda
• Agrupamiento de ideas
– Nombrar los grupos
• Definición
– Se escribe una breve descripción de lo que la idea significa para
la persona que la escribió
– Ayuda a tener un entendimiento común del requerimiento
– Lleva unos minutos por idea
• Priorización (opcional)
– Test de los $100: Cada persona tiene dinero para comprar
ideas, se ordena según ideas más compradas
• Solo se puede hacer una vez
• Se debe limitar la cantidad a gastar en 1 sola idea

13/05/2021
El procedimiento es:
• 1. Selección del problema, tan específicamente
como sea posible.
• 2. Elija a los participantes
– 6 a 12
– actitud mental positiva y ser unos pensadores fluidos
y flexibles.
– personalidades independientes y fuertes que se
entusiasmen participando y
– sientan una auténtica necesidad de mejorar los
bienes y servicios.

13/05/2021
• 3. Elija el entorno.
– una habitación confortable
– Crear las sensaciones de:
• Urgencia
• Hambre de ideas innovadoras
– permitir descansos frecuentes.

13/05/2021
• 4. Seleccione a un líder del grupo.
• habilidades interpersonales y ser capaz de parafrasear y de
encontrar analogías.
– Prepara por anticipado tanto como sea posible.
– Invita a gente de diversas áreas, Desanima a los observadores,
espectadores e invitados.
– Redacte un orden del día y mándala.
– Emplea variedad de técnicas de creatividad.
– Concéntrese en el asunto.
– Anime absolutamente todas las ideas, y cuanto más
extravagantes mejor.
– Prepárate para volver atrás y manipular ideas
– Enfatiza la contribución única de todo el mundo.

13/05/2021
• 5. Seleccione a un secretario.
– Después del brainstorming, ordenar las ideas en
grupos relacionados para priorizarlas y evaluarlas.
• 6. Seguimiento. celebrar los logros del grupo.
• 7. Evalúe las ideas. Si intenta usted obtener al
mismo tiempo agua caliente y agua fría de un
grifo, todo lo que consigue es agua tibia.

13/05/2021
Sesiones de Trabajo (Workshop)
• Ámbito para las tormentas de ideas
• Preparación
– Venderlo a los posibles miembros de la reunión
– Asegurarse que asisten los stakeholders correctos
– Estructurar la invitación, el lugar, etc.
– Enviar material previo a la reunión
• Doc de requisitos
• Entrevistas, defectos de los sistemas existentes, etc.
• Asegurarse de enviar lo necesario, sin exagerar
– Organizar la Agenda
• Introducción
• Tormenta de ideas – generación
• Tormenta de ideas – reducción
• Priorización
• Resumen

13/05/2021
Mapas mentales
Lluvia de ideas

IDR Unidad 2: Elicitación de requerimientos

IDR Unidad 2: Elicitación de requerimientos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a IDR Unidad 2: Elicitación de requerimientos

Similar a IDR Unidad 2: Elicitación de requerimientos (20)

Más de Franklin Parrales Bravo

Más de Franklin Parrales Bravo (20)

Último

Último (20)

IDR Unidad 2: Elicitación de requerimientos