Tecnicas capturarequisitos

1. 2.1. Técnicas de captura o elicitación de requisitos
Para llevar a cabo las tareas de recolectar información, procesarla y validarla con
usuarios y clientes existen muchas estrategias y herramientas. A continuación se
mencionan algunas de ellas:
La entrevista
Es la técnica más usada durante el proceso de captura de requisitos, ya que
permite una interacción informal con los stakeholders de la organización. Para
aplicarlas es preciso contar con habilidades de comunicación social, capacidad para
escuchar y conocimiento de tácticas de entrevistas.
Las entrevistas pueden ser abiertas o cerradas. En el primer tipo no se lleva un
derrotero de las preguntas a hacer, y en la segunda sí. En las entrevistas se
pueden identificar tres fases: preparación, realización y análisis [Tuffley:2005]
Primera fase: Preparación. Las tareas a realizar son las siguientes:
1. Estudiar el dominio del problema: Luego de conocer la empresa y reconocer el
problema a abordar es preciso pensar cómo solucionarlo mediante la fabricación
de software. Para esto también es útil, una vez identificado el problema y la
forma de solucionarlo, buscar documentación sobre herramientas que hagan
algo similar a lo que debe hacer el software a construir.
2. Selecciona r las personas a entrevistar: de ser posible incluir clientes y usuarios.
3. Determinar objetivo y contenido de la entrevista. Para ello apoyarse en un
formato que contenga la siguiente información:

2.  Objetivo de la entrevista: Conocer el proceso involucrado. Capturar
requisitos de la aplicación.
 Derrotero de la reunión (preguntas a hacer)
 Todo se debe registrar en actas, que tengan la siguiente información:
Número de acta, Fecha de la reunión, Hora de inicio, Hora finalización,
Objetivos de la reunión, Lugar de la reunión, Asistentes, Temas a tratar:
aquí se incluyen las preguntas que se harán al cliente, Desarrollo de la
reunión: Aquí se indican las respuestas a las preguntas hechas.
 Preguntas obligadas en la construcción de un sistema: sistemas que
deberán conectarse con el sistema en desarrollo? Se conectan para entregar
insumos al nuevo software? Se conectan para obtener insumos del sistema
en construcción? Tiempos de respuesta de las diferentes operaciones?
Segunda fase: Realización: Las tareas son:
1. Apertura: Presentación de los participantes y objetivo de la reunión
2. Desarrollo: la entrevista no debe durar más de 2 horas, con una mayor
participación de del entrevistado. Incluir muchas preguntas de la forma de
hacer el proceso.
3. Terminación: recapitular todo lo dicho en la entrevista para detectar
confusiones y malos entendidos.
Tercera fase: análisis de entrevistas. Las tareas son: contrastar lo dicho en todas
las entrevistas para verificar si se tiene información suficiente y si hay
contradicciones entre los entrevistados para resolverlas.
No olvide seleccionar bien el personal que va a entrevistar:
 Nivel directivo
 Nivel operativo
Claves para una entrevista:
 El entrevistador deja que hable el entrevistado, no lo interrumpe, y trata
siempre de estar en posición de escucha y de análisis.
 El entrevistador toma nota de todo y periódicamente valida haber entendido
lo que dijo el entrevistado.
 Hacer entender a los entrevistados la importancia de su tiempo, y que sin la
entrevista no será posible detectar las necesidades reales.
Recuerde que: Nunca debe ir a donde sus clientes sin un derrotero de temas a
tratar ya que será improductivo el encuentro.
Actividad: Elabore una derrotero de entrevista para el proyecto que
comenzó a desarrollar en el primer módulo. Póngala a consideración
del docente para recibir sugerencias

3. La encuesta
Similar a las entrevistas cerradas, solo que se
trata en lo posible de fabricar preguntas de las
cuales se conocen las posibles respuestas, y se
solicita al encuestado que seleccione de las
opciones provistas.
Se usa cuando en la organización no tienen
mucho tiempo para entrevistas, y se puede usar
el correo como medio para enviar encuestas por
diligenciar y posteriormente diligenciadas.
Cuestionario de recordación: Cuál es la diferencia básica entre la entrevista y
la encuesta?
Tormenta de ideas (Brainstorming)
Técnica grupal (4 a 10 personas) en la cual es posible compartir ideas libremente
sobre el proyecto de software [Durán, 2003]. En el brainstorming se distinguen las
siguientes fases [Raghavan et al 1994]:
Primera fase: Preparación
En este punto se seleccionan los participantes (incluyendo el jefe de la sesión,
clientes, usuarios, ingenieros de requisitos, desarrolladores y, si es necesario,
algún experto en temas relevantes para el proyecto), se citan y preparan los
recursos para llevar a cabo la sesión.

4. Segunda fase: Generación
En esta parte se abre la sesión, tarea a cargo del jefe, que comienza exponiendo
un enunciado general del problema a tratar, que hace de semilla para la
generación de ideas. Los participantes aportan libremente nuevas ideas sobre el
problema semilla de acuerdo a indicaciones del jefe de la sesión (en cuanto a
orden de intervención). Este proceso continúa hasta que se cumpla el criterio de
parada indicado por el jefe de la sesión (algunos criterios son el número de ideas
recopiladas, el tiempo empleado, el número de intervenciones por parte de los
participantes). Para la realización de esta fase es importante tener en cuenta las
siguientes restricciones:
 Se prohíbe la crítica de ideas ya que está técnica promueve la libertad de
expresión
 Todos los miembros del equipo son libres de formular cualquier idea.
 Se tienen en cuenta en la primera ronda todas las ideas aunque no sean
factibles, como forma para estimular a los demás participantes a explorar
nuevas soluciones.
 Se debe generar un gran número de ideas que luego serán filtradas
 Las ideas generadas por diferentes participantes pueden ser ensambladas
para fabricar una más elaborada.
 Deben estar visibles todo el tiempo las ideas de los participantes de la
sesión, y para ello se usan fichas que se pegan en un tablero.
 Una posibilidad es utilizar como semilla objetivos del sistema e ir
identificando requisitos.
Tercera fase: Consolidación
En esta fase se deben organizar y evaluar las ideas generadas en la fase anterior,
atendiendo los tres pasos siguientes:
 Revisar ideas: se revisan las ideas generadas para clarificarlas. Es habitual
identificar ideas similares, en cuyo caso se unifican en un solo enunciado.
 Descartar ideas: aquellas ideas que los participantes consideren poco
factibles se descartan.
 Priorizar ideas: se priorizan las ideas restantes, identificando las
absolutamente esenciales, dejando como opcionales aquellas que son
buenas pero no imprescindibles.
 Documentación: después de la sesión, el jefe produce la documentación
oportuna conteniendo las ideas priorizadas y comentarios generados.
Algunas claves para realizar una lluvia de ideas:
 Es preciso definir un líder o facilitador, que será quien lance la pregunta que
desencadena la discusión.
 Con cada comentario sobre el tema se genera una ficha o tarjeta, y esto se
trata de agrupar en tópicos.

5.  Al final de la reunión se cuenta con un mapa conceptual que se socializa y
se llega a acuerdos.
 Invitar no solo a personas del nivel operativo, sino a personas de otros
niveles como el administrativo. Los técnicos conocen el proceso
detalladamente, conocen que datos hay que almacenar, restricciones, pero
los del nivel administrativo conocen resultados del proceso y requieren
informes para la toma de decisiones.
 Se debe seleccionar adecuadamente el equipo que participará en el sesión
de brainstorming y definir un tiempo límite que al terminar permite hacer un
balance de todo lo hecho.
Enlace de ampliación 1: http://www.neuronilla.com/content/view/82/70/
Recuerde que: la lluvia de ideas es una técnica grupal en la que no se admite
juzgar ninguna idea expuesta por los participantes.
Actividad:
1. Analice los videos que se referencian en los siguientes enlaces de
ampliación:
Enlace de ampliación 2: http://www.youtube.com/watch?v=Q0AELaNge18
Enlace de ampliación 3: http://www.youtube.com/watch?v=sP9deEY2S8w
2. Aplique los conceptos ampliados en este video sobre tormenta de ideas para
recopilar los requisitos de una aplicación que sistematice el proceso de
admisión de una universidad. Esta actividad debe ser ejecutada en grupos
de 2 o 3 personas.
Cuestionario de recordación: ¿Cuál es la diferencia básica entre las entrevistas
y la lluvia de ideas?

6. JAD (Joint Application Design)
En el siguiente mapa conceptual se observa un resumen de esta técnica
Para la aplicación de la técnica se pueden distinguir seis clases de participantes o
roles:
Jefe del JAD: Es el coordinador de todo el proceso y asume el
liderazgo durante las reuniones (rol de moderador). Debe tener fluidez
verbal y capacidades para hacerse entender y mediar situaciones de
dificultad que se presentan si los participantes tienen ideas encontradas
frente al problema que se debe resolver. Se debe preocupar por
encaminar las reuniones si considera que están tomando un rumbo que
no permite resolver los interrogantes iniciales.
Analista: es el responsable de producir los documentos
derivados de las reuniones, al igual que las actas
respectivas. Debe tener excelente redacción y capacidad de
síntesis. Si durante las sesiones se utilizan herramientas
software, el analista debe ser capaz de manejarlas
eficientemente.
Patrocinador ejecutivo: es el que decide si se continúa con
el desarrollo del software, y quien finalmente lo pagará. Debe

7. proporcionar a los demás participantes información sobre la necesidad del nuevo
sistema y los beneficios que se obtendrán.
Representantes de los usuarios: Son participantes
que aportan a los demás asistentes ideas concretas
sobre funcionalidades que debe proveer el software a
construir, porqué serán quienes lo usen en el futuro y
quienes conocen el proceso que se está sistematizando.
Representantes de sistemas de información: son
expertos en sistemas de información que deben ayudar a los
demás participantes a comprender qué es o no factible con
la tecnología actual y el esfuerzo que implica.
Especialistas: son expertos en los procesos que se van a
sistematizar y en el dominio bajo estudio. 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, ya que manipulan software ya
existente dentro de ésta.
JAD está constituido por las siguientes actividades pre-workshop (Andriano, 2006):
 Identificación de los objetivos y limitaciones del proyecto: La definición del
alcance del proyecto permite definir que procesos de la organización serán
intervenidos y cuales quedan para futuros desarrollos.
 Establecimiento de los factores críticos de éxito: en este punto se definen
criterios bajo los cuales el proyecto de desarrollo puede considerar exitoso.
Se resuelven interrogantes como: ¿Cuáles son los indicadores para
determinar el éxito del proyecto?
 Definición de los entregables: Entendiendo estos entregables como los
directamente asociados a la aplicación de la técnica JAD, en este punto se
define el formato de la documentación, incluyendo tipo de diagramas a usar
y herramientas de apoyo para las tareas.

8.  Definición el cronograma de actividades para el workshop: Esta actividad
garantiza que durante los 1 a 5 días de aplicación de la técnica no se
dejaran por fuera reuniones importantes y se cubrirán todos los temas
previstos, logrando el objetivo de capturar los requisitos.
 Selección de los participantes: se recomienda involucrar a diversos niveles
de la organización, desde aquellos empleados que operan el proceso
susceptible de sistematización, hasta el nivel gerencial y administrativo y de
considerarse conveniente, expertos externos.
 Preparación del material para el workshop: el gerente del proyecto y el
moderador recopilan y construyen el material de apoyo para la realización
de las reuniones. Como material es posible tener hojas de trabajo,
documentación de procesos, diagramas e incluso apuntes que le permitan a
los participantes entender la función del negocio.
 Organización de las actividades y ejercicios: el moderador deberá diseñar
ejercicios y actividades que permitan abordar los puntos críticos del
workshop.
 Preparar, informar y educar a los participantes: todos los participantes de la
técnica, previamente reciben capacitación para el uso del JAD.
En cuanto a las actividades propias del workshop se tienen:
 Coordinar la logística del workshop: estas reuniones deben realizarse fuera
de la empresa para evitar interrupciones y garantizar un ambiente en el cual
sea más fácil concentrarse durante lapsos de tiempo extendidos. Se deben
preparar proyectores, pantallas, computadoras, mesas, fibras, entre otros,
responsabilidad del moderador.
 Ejecución del workshop: Durante esta actividad central es preciso que el
moderador tome atenta nota sobre los aportes de los participantes.
 Conclusión de la reunión: Al finalizar el conjunto de reuniones se debe hacer
un cierre que consiste en revisar los objetivos perseguidos y de éstos cuales
fueron logrados y cuáles quedaron pendientes.

9. Por último, el JAD implica una serie de actividades a llevar a cabo post-workshop:
 Recopilación de ideas y documentación lograda durante el workshop para
determinar si se resolvieron todos los interrogantes planteados
 El moderador y el experto en documentación trabajan en conjunto para
finalizar el soporte escrito del workshop. El gerente de proyecto es el que
recibirá esta documentación para remitirla a todos los interesados dentro de
la organización y recibir los avales respectivos.
 Posterior a la validación de la documentación derivada de la captura de
requisitos JAD se proponen una serie de actividades relacionadas con el
diseño de la aplicación, apartado omitido por no hacer parte del alcance del
curso.
Algunos de los beneficios al aplicar JAD se listan a continuación:
 Incentiva el sentido de pertenencia por parte de los interesados.
 Durante el workshop los participantes están enfocados en una meta común,
lo cual facilita el entendimiento de los problemas del sistema.
 Los participantes desarrollan una visión y un lenguaje común del proyecto
para la discusión de los problemas. Estos elementos permanecerán con el
equipo durante la vida del proyecto y facilitarán las demás tareas.
 Ahorra tiempo al evitar que las opiniones de los clientes se contrasten por
separado.
 Todo el grupo, incluyendo los clientes y los futuros usuarios, revisan la
documentación generada, lo cual disminuye la probabilidad de que se filtren
errores en la definición de requisitos.
 Implica más a los clientes y usuarios en el desarrollo.
Cuestionario de recordación: ¿Cuáles son las diferencias relevantes entre las
técnicas vistas hasta el momento?
Enlace de ampliación 4: metodologiaAmadorDuran.pdf
Enlace de ampliación 5: TecnicasCapturaRequisitos.pdf
Prototipación como técnica para capturar requisitos
Un prototipo de requerimientos de software es una implementación parcial del
sistema como apoyo a desarrolladores, usuarios y clientes para el entendimiento
del sistema, en especial de los requerimientos que están menos claros
[Kotonya:2000].
Con la prototipación se busca desde etapas tempranas mostrarle a
clientes/usuarios características relevantes del sistema que están esperando a
través de un prototipo (aspecto visible del software- interfaces de usuario).

10. Se trata de plasmar todos los requerimientos de usuarios y clientes en un
aplicativo que solo exhibe características gráficas pero no tiene programadas las
funcionalidades (Andriano, 2006). En esta técnica se pueden conseguir diversos
prototipos de acuerdo al nivel de detalle que proporcionen los participantes e
interesados, por lo tanto el proceso es iterativo y siempre busca determinar la
apariencia del sistema. Esta técnica es realmente útil cuando el prototipo puede
ser construido rápidamente.
Esta técnica puede ser usada con apoyo de herramientas como plataformas de
programación en las cuales se construyen los aspectos visibles de la aplicación, o
también tomando como instrumentos papel y lápiz para plasmar pantallas de la
futura aplicación (IEEE- Swebok, 2004).
La prototipación es un medio común para validar la interpretación de los
requerimientos de software hecha por los analistas, así como también para la
elicitación de los mismos. Dentro del proceso de elicitación de requerimientos,
existe una amplia variedad de técnicas de prototipado. Una de las principales
ventajas de esta técnica es la posibilidad de detectar errores desde fases
tempranas ya que se busca proporcionarle a los interesados vistas parciales del
sistema que finamente obtendrán. Por ejemplo, el comportamiento dinámico de
una interfaz de usuario puede ser mejor entendida a través de un prototipo
animado que a través de una descripción textual o modelos gráficos. También
existen desventajas tales como el peligro de que la atención del usuario se aparte
de la funcionalidad principal por problemas cosméticos o problemas de calidad del
prototipo, o el aumento de costos en su fabricación.
La prototipación usualmente se combina con otras técnicas. Por ejemplo se usa un
prototipo para provocar una discusión en una técnica de elicitación grupal o como
base para una encuesta (Andriano, 2006).
Cuestionario de recordación: Haga un listado de ventajas que provee utilizar el
prototipado como técnica de captura de requisitos en lugar de técnicas como la
entrevista o el JAD

11. Etnografía
Las personas a menudo encuentran difícil describir "lo que hacen" pues la
costumbre les lleva a omitir detalles de forma inconsciente. Muchas veces la mejor
manera de entenderlo es observarlos en su trabajo, o sea, haciendo un trabajo
etnográfico.
La etnografía (también conocida como observación) se traduce etimológicamente
como el estudio de las etnias y significa el análisis del modo de vida de una raza o
grupo de individuos mediante la observación y descripción de lo que la gente hace,
cómo se comportan y cómo interactúan entre sí, para describir sus creencias,
valores, motivaciones, perspectivas y variaciones en dicho comportamiento. Para
"hacer etnografía" es necesario adentrarse en el grupo, aprender su lenguaje, sus
costumbres, haciendo una observación participativa.
En un estudio realizado por expertos [Davis, 2003] identificó la etnografía como
extremadamente efectiva para la captura de requerimientos. La observación es
una buena forma de recolectar requerimientos cuando los usuarios están
demasiados ocupados para involucrarse con las entrevistas, sesiones grupales o
encuestas. Muchos analistas reconocen que los stakeholders deberían ser
observados siempre que sea posible.
Para aplicar etnografía en el desarrollo de sistemas los analistas de software
aprenden sobre las tareas del usuario mediante la inmersión en su ambiente
laboral y la observación de cómo los usuarios ejecutan un proceso sin el apoyo del
sistema que posteriormente se implantará para sistematizar algunas de esas
tareas. Aunque el uso de este método es costoso, permite aclarar tareas y
procesos de negocio de los usuarios que son demasiado sutiles y complejas como
para describirlas fácilmente (IEEE- Swebok, 2004).

12. Esta técnica solo se debería utilizar cuando existe la necesidad de obtener la
magnitud total de proceso a ser resuelto o para verificar una hipótesis de un
enfoque. Si la tarea a ser observada es rutinaria para un experto, entonces el
experto se sentirá librado a dar explicaciones más detalladas de su enfoque y así el
observador obtendrá un conocimiento más significativo. El observador pasa
tiempo con el sujeto a observar, hasta poder convertirse en un miembro del grupo.
La técnica de observación tiene la característica de ser discreta, y participativa, ya
que se trata de un método contextualizado que permite revelar detalle que otros
métodos no logran.
Algunas ventajas de usarla se enuncian a continuación:
 Representa una carga horaria mínima para los usuarios, ya que ellos sólo
deben realizar su trabajo de manera normal y natural [Sindre:2005].
 Permite al analista comprobar la dinámica de los procesos que actualmente
se están ejecutando, ya que es posible que el encargado de dicho proceso
omita detalles.
 El observado no necesita abstraerse de su medio natural, y de esta manera
se siente libre para hacer sus tareas en medio de la cotidianidad, sin ocultar
detalles.
Como principal desventaja se tiene el consumo excesivo de tiempo por parte de los
desarrolladores, y a esto se añade la cantidad de información recopilada que
puede volverse muy difícil de procesar.

13. Pasos a seguir en la etnografía [Green, 2003]:
1. Se observa al encargado del proceso ejecutar sus tareas.
2. Se toma nota cada vez que una acción se ejecuta.
3. Se formulan preguntas para clarificar la naturaleza del trabajo y las acciones
ejecutadas, asociadas a formatos diligenciados, enlace entre pasos del
proceso, entre otros.
4. Analizar las notas tomadas teniendo en cuenta aspectos como: Procesos
actuales, cambios posibles, factibles, y deseables al proceso, requerimientos
que debería cumplir un sistema para satisfacer la dinámica del proceso.
Enlace de ampliación 6: EtnografiaDr.mp4
Enlace de ampliación 7: EtnografíaTiteres.mp4
2.2 Problemas frecuentes durante la captura de requisitos
Como se dijo anteriormente la educción de requerimientos es el primer paso
dentro de la IR y el más crítico. Realizado de manera errónea conduce a la
fabricación de productos con calidad pobre, fechas de entregas tardías y costos
fuera del presupuesto (Bohem, 1981).
Algunos inconvenientes que normalmente se encuentran a la hora de capturar
requisitos para el desarrollo de una aplicación se enuncian a continuación:

14. El usuario está consciente de cuáles son sus
necesidades pero no es capaz de expresarlas.
Ante este problema se recomienda usar
técnicas como el análisis etnográfico ya que
usted tiene oportunidad de detectar los
problemas que se presentan y ayudar al
cliente para aclarar sus necesidades
El usuario no está consciente de cuáles
son sus necesidades, y de esta manera
hace mucho más difícil la labor del
analista, quien deberá poseer experticia
para orientar el desarrollo y delimitar el
alcance de la aplicación que se está
desarrollando.
El analista de requisitos no posee el perfil
adecuado, y por lo tanto no genera confianza
entre los usuarios y clientes, razón por la cual
ellos no se atreven a expresar sus angustias,
preocupaciones y reales necesidades.
El analista no entiende lo que los
usuarios le están expresando y estas
malas interpretaciones se extienden a
otras fases del desarrollo, generando
como consecuencia la construcción de
un software que no satisface las
necesidades de usuarios y clientes

15. Barreras en la comunicación por aspectos
como: falta de empatía entre analista y
clientes/usuarios, medios de comunicación
insuficientes; diferentes tipos de
personalidades y valores
Limitaciones en el
conocimiento por: falta de
información del dominio
sobre el cual se implantará la
solución informática;
preconcepción de una
solución; dificultades con la
escala y la complejidad del
problema a resolver
Problemas de comportamiento humano:
ambigüedades; los usuarios/clientes asumen que otra
persona será la encargada de mencionarle la necesidad
al desarrollador; el desarrollador asume que se le
proveerá toda la información completa del dominio; los
usuarios asumen que el desarrollador hará las
preguntas correctas
Problemas técnicos: los requerimientos
cambian con el tiempo; la tecnología
cambia rápidamente; existen
demasiadas fuentes de requerimientos;
la similitud o novedad del sist
Recuerde que: La fase de ingeniería de requisitos se hace más compleja porque
juegan un papel vital factores humanos que no son controlables

16. Revise el siguiente enlace para recibir consejos sobre la forma de abordar una
sesión de toma de requisitos, que básicamente es un espacio para generación de
ideas con respecto al software que se construirá:
Enlace de ampliación 8: http://www.youtube.com/watch?v=m--qj01aPSI