Técnicas de Recopilación de Requerimientos

El descubrimiento de requerimientos es el proceso de recoger información sobre el

sistema propuesto y los existentes y extraer los requerimientos del usuario y del
sistema de esta información. Las fuentes de información durante la fase del
descubrimiento de requerimientos incluyen la documentación, los stakeholders del
sistema y la especificación de sistemas similares.

Nosotros nos relacionaremos con los stakeholders a través de entrevistas y de la

observación y se puede utilizar escenarios y prototipos para ayudar al descubrimiento
de requerimientos. Entre los stakeholders podemos encontrar desde los usuarios
finales del sistema hasta los gerentes y stakeholders externos como los reguladores,
quienes certifican la aceptabilidad del sistema.

Además de los stakeholders del sistema, ya hemos visto que los requerimientos
pueden venir del dominio de la aplicación y de otros sistemas que interactúan con el
sistema a especificar. Todos estos se deben considerar durante el proceso de
obtención de requerimientos. Estas fuentes de requerimientos (stakeholders, dominio,
sistemas) se pueden representar como puntos de vista del sistema, donde cada uno
presenta un subconjunto de requerimientos para el sistema. Cada punto de vista
proporciona una perspectiva nueva en el sistema, pero estas no son completamente
independientes. Por lo general coinciden parcialmente, por lo que tienen
requerimientos comunes.

PUNTOS DE VISTA

Un punto clave del análisis orientado a puntos de vista es que reconoce varias
perspectivas y proporcionar un marco de trabajo para descubrir conflictos en los
requerimientos propuestos por diferentes stakeholders. Los puntos de vista se pueden
utilizar como una forma de clasificar los stakeholders y otras fuentes de
requerimientos. Existen tres tipos genéricos de puntos de vista:

I. Puntos de vista de los interactuadores: representan a las personas u otros sistemas

que interactúan directamente con el sistema.
2. Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema
ellos mismos pero que influyen en los requerimientos de algún modo.
3. Puntos de vista del dominio: representan las características y restricciones del
dominio que influyen en los requerimientos del sistema.

Por lo general, estos puntos de vista proporcionan diferentes tipos de requerimientos.

Los puntos de vista de los interactuadores proporcionan requerimientos detallados del
sistema que cubren las características e interfaces del mismo. Los puntos de vista
indirectos es más probable que proporcionen requerimientos y restricciones
organizacionales de alto nivel.
Los puntos de vista del dominio proporcionan restricciones del dominio que se aplican
al sistema. La identificación inicial de los puntos de vista que son relevantes a un
sistema a veces puede ser difícil. Para ayudar a este proceso, se debería intentar
identificar tipos de puntos de vista más específicos.
Casi todos los sistemas organizacionales deben interactuar con otros sistemas en la
organización. Cuando se diseña un sistema nuevo, se deben diseñar las interacciones
con los otros sistemas. Las interfaces ofrecidas por estos otros sistemas ya se han
diseñado. Estas pueden poner requerimientos y restricciones en el sistema nuevo.
Además, los sistemas nuevos se pueden tener que ajustar a las regulaciones y
estándares existentes, y estos restringen los requerimientos del sistema.

Se deben identificar los requerimientos no funcionales y de negocio de alto nivel al

inicio del proceso de ingeniería de requerimientos. Las fuentes de estos
requerimientos pueden ser puntos de vista útiles en un proceso más detallado.
Pueden ser capaces de ampliar y desarrollar los requerimientos de alto nivel en
requerimientos del sistema más específicos. Los puntos de vista de la ingeniería
pueden ser importantes por dos razones.
En primer lugar, los ingenieros que desarrollan el sistema pueden tener experiencia
con sistemas similares y sugerir requerimientos a partir de esa experiencia. En
segundo lugar, el personal técnico que tiene que administrar y mantener el sistema
puede tener requerimientos que ayuden a simplificar el soporte del sistema. Los
requerimientos de administración del sistema son cada vez mas importantes debido a
que los costes de administración del sistema son una proporción creciente de los
costes totales para un sistema.

Finalmente, los puntos de vista que proporcionan requerimientos pueden venir de los
departamentos de marketing y asuntos externos en una organización. Esto es
especialmente cierto para sistemas basados en web, particularmente sistemas de
comercio electrónico y productos software empaquetados. Los sistemas basados en
web deben presentar una imagen favorable de la organización además de entregar
funcionalidad al usuario. Para productos software, el departamento de marketing
debería conocer que características del sistema lo harán más comercializable para los
compradores potenciales.

Para cualquier sistema no trivial existe un enorme número de posibles puntos de vista,
y es prácticamente imposible obtener requerimientos de todos ellos. Por lo tanto, es
importante organizar y estructurar los puntos de vista en una jerarquía. Es probable
que los puntos de vista en la misma rama compartan requerimientos comunes.

Una vez que se han identificado y estructurado los puntos de vista, se debe intentar
identificar los más importantes y empezar con ellos al descubrir los requerimientos del
sistema.

ENTREVISTAS

Las entrevistas formales o informales con los stakeholders del sistema son parte de la
mayoría de los procesos de la ingeniería de requerimientos. En estas entrevistas, el
equipo de la ingeniería de requerimientos hace preguntas a los stakeholders sobre el
sistema que utilizan y sobre el sistema a desarrollar. Los requerimientos provienen de
las respuestas a estas preguntas. Las entrevistas pueden ser de dos tipos:

I. Entrevistas cerradas donde los stakeholders responden a un conjunto predefinido de

preguntas.
2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de ]a
ingeniería de requerimientos examina una seria de cuestiones con los stakeholders
del sistema y, por lo tanto, desarrolla una mejor comprensión de sus necesidades.

En la práctica, las entrevistas con los stakeholders normalmente son una mezcla de
estos. Las respuestas a algunas preguntas pueden conducir a otras cuestiones que se
discuten de una forma menos estructurada. Las discusiones completamente abiertas
raramente salen bien; la mayoría de las entrevistas requieren algunas preguntas para
empezar y para mantener la entrevista centrada en el sistema a desarrollar.

Las entrevistas sirven para obtener una comprensión general de lo que hacen los
stakeholders, como podrían interactuar con el sistema y las dificultades a las que se
enfrentan con los sistemas actuales. A la gente le gusta hablar sobre su trabajo y
normalmente se alegran de verse implicados en las entrevistas. Sin embargo, no son
de tanta utilidad para la comprensión de los requerimientos del dominio de la
aplicación.

Es difícil obtener conocimiento del dominio durante las entrevistas debido a dos
razones:

1. Todos los especialistas de la aplicación utilizan terminología y lenguaje especifica

de un dominio. Es imposible para ellos discutir requerimientos del dominio sin utilizar
esta terminología. Normalmente la utilizan de un modo preciso y sutil, por lo que es
fácil que la malinterpreten los ingenieros de requerimientos.
2. Cierto conocimiento del dominio es tan familiar para los stakeholders que lo
encuentran difícil de explicar o piensan que es tan básico que no merece la pena
mencionarlo.

Las entrevistas no son una técnica eficaz para obtener conocimiento sobre los
requerimientos y restricciones organizacionales debido a que existen sutiles poderes e
influencias entre los stakeholders en la organización. Las estructuras organizacionales
publicadas rara vez se corresponden con la realidad de la toma de decisiones en una
organización, pero los entrevistados pueden no desear revelar la estructura real en
vez de la teórica a un desconocido. En general, la mayoría de la gente es reacia a
discutir cuestiones políticas y organizacionales que pueden influir en los
requerimientos.

Los entrevistadores eficaces tienen dos características:

1. No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y están

dispuestos a escuchar. Si el stakeholder propone requerimientos sorprendentes, están
dispuestos a cambiar su opinión del sistema.
2. Instan al entrevistado a empezar las discusiones con una pregunta, una propuesta
de requerimientos o sugiriendo trabajar juntos en un prototipo del sistema. Decir a la
gente “dime lo que quieres” es improbable que cause información de utilidad. La
mayoría de la gente encuentra mucho mas fácil hablar en un contexto definido en vez
de en términos generales.

La información de la entrevistas complementa otras informaciones sobre el sistema de

los documentos, observaciones de los usuarios, etc. Algunas veces, aparte de la
información de los documentos, las entrevistas pueden ser la técnica fuente de
información sobre los requerimientos del sistema. Sin embargo, las entrevistas por si
mismas tienden a omitir información esencial, por lo que deberían ser usadas al lado
de otras técnicas de obtención de requerimientos.

ESCENARIOS

Normalmente, las personas encuentran más fácil dar ejemplos de la vida real que
descripciones abstractas. Pueden comprender y criticar un escenario de cómo podría
interactuar con un sistema software. Los ingenieros de requerimientos pueden utilizar
la información obtenida de esta discusión para formular los requerimientos reales del
sistema.

Los escenarios pueden ser especialmente útiles para agregar detalle a un esbozo de
la descripción de requerimientos. Son descripciones de ejemplos de las sesiones de
interacción.

Cada escenario abarca una o más posibles interacciones. Se han desarrollado varias
formas de escenarios, cada una de las cuales proporciona diferentes tipos de
información en diferentes niveles de detalle sobre el sistema. Utilizar escenarios para
describir requerimientos es una parte fundamental de los métodos ágiles.

El escenario comienza con un esbozo de la interacción y durante la obtención se

agregan detalles para crear una descripción completa de esta interacción. De forma
general, un escenario puede incluir:

1. Una descripción de lo que esperan el sistema y los usuarios cuando el escenario

comienza.
2. Una descripción del flujo normal de eventos en el escenario.
3. Una descripción de lo que puede ir mal y cómo manejarlo.
4. Información de otras actividades que se podrían Ilevar a cabo al mismo tiempo.
5. Una descripción del estado del sistema cuando el escenario termina.

Es posible llevar a cabo de manera informal la obtención de requerimientos basada en

escenarios cuando los ingenieros de requerimientos trabajan con los stakeholders en
la identificación de escenarios y en la captura de detalles de dichos escenarios. Los
escenarios se pueden redactar como texto, complementados por diagramas,
fotografías de las pantallas, etc. De forma alternativa, se puede adoptar un enfoque
más estructurado, como los escenarios de evento o los casos de uso.

CASOS DE USO

Los casos de uso son una técnica que se basa en escenarios para la obtención de
requerimientos.

En su forma más simple, un caso de uso identifica el tipo de interacción y los actores
involucrados. El conjunto de casos de uso representa todas las posibles interacciones
a representar en los requerimientos del sistema.
Algunas veces existe confusión sobre si un caso de uso es un escenario o, como
sugiere Fowler (Fowler y Scott, 1997), un caso de uso encierra un conjunto de
escenarios, y cada uno de estos es un hilo único a través del caso de use. Si un
escenario incluye múltiples hilos, habrá un escenario para la interacción normal y
escenarios adicionales para las posibles excepciones.

Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser
documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en
más detalle. Los diagramas de secuencia se utilizan a menudo para añadir
información a un caso de uso. Estos muestran los actores involucrados en la
interacción, los objetos con los que interactúan y las operaciones asociadas con estos
objetos.

UML es un estándar de facto para el modelado orientado a objetos, por lo que los
casos de uso y la obtención de requerimientos basada en casos de uso se utilizan
cada vez más para la obtenci6n de requerimientos.

Los escenarios y los casos de use son técnicas eficaces para obtener requerimientos
para los puntos de vista de los interactuadores, donde cada tipo de interacción se
puede representar como un caso de uso. También se pueden utilizar conjuntamente
con algunos puntos de vista indirectos cuando éstos reciben resultados (como un
informe de gestión) del sistema. Sin embargo, debido a que se centran en las
interacciones, no son tan eficaces para obtener restricciones y requerimientos de
negocio y no funcionales de alto nivel de puntos de vista indirectos o para descubrir
requerimientos del domino.

ETNOGRAFÍA

Los sistemas software no existen de forma aislada: se utilizan en un contexto social y

organizacional, y los requerimientos de sistemas software se pueden derivar y
restringir según ese contexto. A menudo, satisfacer estos requerimientos sociales y
organizacionales es crítico para el éxito del sistema. Una razón de por qué muchos
sistemas software se entregan pero nunca se utilizan es que no se tiene en cuenta
adecuadamente la importancia de este tipo de requerimientos del sistema.

La etnografía es una técnica de observación que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por si solo en el
entorno laboral donde se utilizara el sistema. Observa el trabajo diario y anota las
tareas reales en las que los participantes están involucrados. El valor de la etnografía
es que ayuda a los analistas a descubrir los requerimientos implícitos que reflejan los
procesos reales más que los formales en los que la gente está involucrada.

A menudo, a la gente le resulta muy difícil articular detalles de su propio trabajo

debido a que lo asumen como algo completamente natural. Comprenden su propio
trabajo pero no su relación con las demás tareas en la organizaci6n. Los factores
sociales y organizacionales que afectan a] trabajo, pero que no son obvios para las
personas, es posible que s6lo queden claros cuando se fije en ellos un observador
imparcial.
Suchman (Suchman, 1987) utilizó la etnografía para estudiar el trabajo de oficina y
observó que las prácticas del trabajo real eran macho más ricas, más complejas y
más dinámicas que los modelos sencillos supuestos por los sistemas de
automatización de oficinas.

La diferencia entre el trabajo supuesto y el real fue la razón más importante de por
qué estos sistemas de oficina no han tenido efectos significativos en la productividad.

La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:

I. Los requerimientos que se derivan de la forma en la que la gente trabaja realmente

más que de la forma en la que las definiciones de los procesos establecen que
debería trabajar.
2. Los requerimientos que se derivan de la cooperación y conocimiento de las
actividades de la gente.

La etnografía se puede combinar con la construcción de prototipos. La etnografía

suministra información al desarrollo del prototipo de forma que se requieran menos
ciclos de refinamiento. Además, la construcci6n de prototipos se centra en la
etnografía para identificar problemas y preguntas que se puedan discutir
posteriormente con el etnógrafo.

Los estudios etnográficos pueden revelar los detalles de los procesos críticos que
otras técnicas de obtención de requerimientos a menudo olvidan. Sin embargo, puesto
que se centran en el usuario final, este enfoque no es apropiado para descubrir los
requerimientos organizacionales o del dominio. Los estudios etnográficos no siempre
pueden identificar nuevas propiedades que se deban agregar al sistema. Por lo tanto,
la etnografía no es un enfoque completo para la obtenci6n de requerimientos por sí
mismo, y debe utilizarse para complementar otros enfoques, como el análisis de
casos de uso.

CUESTIONARIOS

Es un conjunto de preguntas que deben ser contestadas por escrito por una
determinada población, generalmente esta población es amplia. Según el contenido
de los cuestionarios podemos clasificarlos en los siguientes tipos: 1. Abiertos: Las
respuestas no están delimitadas, esto permite mayor libertad de expresión. 2.
Cerrados: Se fuerza a respuestas concretas. Un mismo tipo de pregunta puede
formularse para obtener diferente rango de respuestas: Elección exclusiva
(respuestas del tipo si/no). Por ejemplo: ¿Cree que existen muchos circuitos
integrados defectuosos? Escala cualitativa (acuerdo/desacuerdo). Por ejemplo:
Existen muchos circuitos integrados defectuosos. Las posibles respuestas son: de
acuerdo, totalmente de acuerdo, no estoy seguro, en desacuerdo, totalmente en
desacuerdo. Cantidad, es decir, la pregunta requiere como respuesta una
determinada cantidad. Por ejemplo: De cada 100 circuitos integrados ¿cuántos son
defectuosos? Rango o escala cuantitativa, donde la respuesta es un rango de valores.
Por ejemplo: De cada 100 circuitos integrados son defectuosos (0–5, 6–10, >50, etc.)
Selección de respuestas limitadas. Por ejemplo: Las causas más frecuentes de
circuitos integrados defectuosos son: a) Fallo en la impresión de la pista. b) Fallo en la
conexión de las patillas. c) Fallo en el encapsulado de plástico. 3. Mixtos: una
combinación de los anteriores Los buenos cuestionarios no solo se escriben sino que
se diseñan. Una buena elaboración acompañada de una prueba previa, tanto del
formato como de las preguntas, son la base de una recopilación de datos significativa
a través del cuestionario. Puntos que ayudarán en la formulación de un cuestionario:
1. Determinar qué datos necesitan recabarse y qué personas son las más calificadas
para proporcionarlos. Si hay otros grupos que pueden proporcionar datos variantes y
mayor visión también se identificarán. 2. Seleccionar el tipo de cuestionario a utilizar
(abierto, cerrado o mixto). 3. Desarrollar un grupo de preguntas para incluirlas en el
cuestionario. Las preguntas extras que son intencionalmente redundantes, pueden ser
útiles al asegurar respuestas consistentes por parte de quien responda. 4. Examinar el
cuestionario para encontrarle fallos y defectos, como: a) Interrogantes innecesarias. b)
Preguntas que pueden ser mal interpretadas debido a su enfoque o forma de
escritura. c) Preguntas que el sujeto posiblemente no pueda responder, dado que
desconoce la respuesta. d) Preguntas que están escritas de forma que se escogerá la
respuesta preferida. e) Preguntas que se interpretarán de forma diferente
dependiendo del marco de referencia de cada entrevistado. f) Preguntas que no
proporcionan opciones adecuadas de respuesta. g) Un ordenamiento no adecuado de
las preguntas o respuestas. 5. Probar previamente el cuestionario en un grupo
pequeño de personas, para detectar otros problemas posibles. Así no solamente se
describen los problemas en cuanto a su escritura, espaciado, ortografía, y métodos de
registro de respuestas, sino también proporciona una indicación del tipo de respuestas
que se recopilarán en un grupo mayor. Si existen muchas respuestas inesperadas, se
captarán durante la prueba previa. Hay que asegurar que la muestra de prueba sea
comparable al grupo mayor que recibirá el cuestionario. 6. Analizar las respuestas del
grupo de prueba para asegurar que el análisis de los datos que se busca puede
llevarse a cabo con el tipo de datos recopilados. Si estos datos no revelan algo que
los analistas no reconocen y no necesitan verificar, el cuestionario puede no ser
necesario en su forma actual. 7. Realizar cambios finales de edición, correcciones de
mecanografía y ajustes en la forma; entonces imprimir el cuestionario en una forma
limpia y legible. 8. Distribuir el cuestionario. Cuando sea posible, anotar el nombre de
cada persona. Ventajas 1. En su mayoría, los cuestionarios pueden ser contestados
con rapidez. Los encuestados pueden completar y remitir los cuestionarios cuando
mejor les convenga. 2. Los cuestionarios ofrecen un medio relativamente económico
para recoger datos de un amplio número de personas. 3. Los cuestionarios permiten a
las personas mantener el anonimato. Por consiguiente, es más probable que éstas
informen de los hechos reales, en vez de decir lo que piensan que su jefe aprobaría
que dijera. 4. Las respuestas pueden incluirse en tablas y analizarse rápidamente.
Desventajas 1. El número de encuestados es, a menudo, insuficiente. 2. No existe
garantía de que los encuestados respondan o expliquen todas las preguntas. 3. Los
cuestionarios suelen ser poco flexibles. Impiden que el analista de sistemas obtenga
información voluntaria de las personas o replantee preguntas que puedan haber sido
malinterpretadas. 4. El analista de sistemas no tiene la posibilidad de observar y
analizar el lenguaje corporal del encuestado. 5. No existe una oportunidad inmediata
para aclarar respuestas vagas o incompletas a una pregunta.

MAPAS MENTALES
Generalmente cuando se realiza una entrevista -en este caso nosotros- observamos,
escuchamos y tratamos de tomar notas para recordar y definir lo que estamos
escuchando.

Sin embargo frecuentemente sucede que cuando queremos ocupar dicha información,
nos cuesta un poco de trabajo darle sentido a esas notas y entenderlas de nuevo.
Otro punto en contra de "tomar notas" es el hecho de que no podemos detallar
mucho, pues perdemos parte de la información de la entrevista.

Un mapa mental es una forma de tomar notas más completas y extensas. Con los
mapas mentales utilizamos símbolos, palabras, imágenes y colores para capturar la
esencia del tema que estamos tratando. Al revisarlo después, gracias a la información
personalizada, será más fácil recordar detalles que de otra forma se hubieran perdido
al tomar nota de forma convencional.

Los mapas mentales no solo funcionan como una forma de enriquecer las notas que
tomamos, sino que otra de sus funcionalidades es para realizar un resumen sobre lo
que entendimos de una lectura.

LLUVIA DE IDEAS

Es una técnica de grupo para generar ideas originales en un ambiente relajado. Esta
herramienta creada en el año 1941 por Alex Osborne, cuando su búsqueda de ideas
creativas resultó en un proceso interactivo de grupo no estructurado de “lluvia de
ideas” que generaba más y mejores ideas que las que los individuos podian producir
trabajando de forma independiente.” NO ESTRUCTURADO (Flujo libre) 1. Escoger a
alguien para que sea el facilitador y apunte las ideas. 2. Escribir en un rotafolio o en
un tablero una frase que represente el problema y el asunto de discusión. 3. Escribir
cada idea en el menor número de palabras posible. Verificar con la persona que hizo
la contribución cuando se esté repitiendo la idea. No interpretar o cambiar las ideas. 4.
Establecer un tiempo límite. 5. Fomentar la creatividad. Construir sobre las ideas de
otros. Los miembros del grupo de Lluvia de Ideas y el facilitador nunca deben criticar
las ideas. 6. Revisar la lista para verificar su comprensión. 7. Eliminar las
duplicaciones, problemas no importantes y aspectos no negociables. Llegar a un
consenso sobre los problemas que parecen redundantes o no importantes.
ESTRUCTURADO (En círculo) Tiene las mismas metas que la Lluvia de Ideas No
Estructurada. La diferencia consiste en que cada miembro del equipo presenta sus
ideas en un formato ordenado (ej. de izquierda a derecha). No hay problema si un
miembro del equipo cede su turno si no tiene una idea en ese instante. SILENCIOSA
(lluvia de ideas escritas) Es similar a la Lluvia de Ideas, los participantes piensan las
ideas pero registran en papel sus ideas en silencio. Cada participante pone su hoja en
la mesa y la cambia por otra hoja de papel. Cada participante puede entonces agregar
otras ideas relacionadas o pensar en nuevas ideas. Este proceso continua por cerca
de 30 minutos y permite a los participantes construir sobre las ideas de otros y evitar
conflictos o intimidaciones por parte de los miembros dominantes.

PROTOTIPOS

Los prototipos constituyen la manera más fácil de validar los requerimientos del
sistema dado que el usuario puede trabajar sobre un elemento concreto y no
abstracto como son los modelos. Según el área de aplicación que se esté analizando
el prototipo puede ser distinto. Por ejemplo, en el caso de una aplicación interactiva la
descripción de la funcionalidad podría realizarse mediante la presentación de las
pantallas, menús, diálogos, etc. En el caso de una aplicación de procesamiento de
información el prototipo podría mostrar la información de entrada y la información de
salida, sin detallar, necesariamente, el algoritmo asociado. En el caso de una
aplicación web, el prototipo podría incluir las páginas del sistema con una simulación
de la navegación deseada.

Cuando se utilizan prototipos para la identificación de los requerimientos del cliente, e

incluye una funcionalidad mínima de tal manera que el usuario pueda utilizar el
prototipo. Normalmente, durante el proceso de desarrollo, se deben construir varios
prototipos. El análisis de requerimientos que debe realizarse previo a la elaboración
de los prototipos dependerá exclusivamente de la naturaleza del problema a resolver.
Es recomendable que los prototipos sean elaborados exclusivamente para la
generación de un conjunto válido de requerimientos; una vez que éstos han sido
identificados se deben documentar y continuar con el proceso de desarrollo. Es
fundamental encontrar el prototipo adecuado para la presentación ante el cliente.

DESARROLLO CONJUNTO DE APLICACIONES ( JAD )

Técnica que se utiliza para promover la cooperación y el trabajo en equipo entre

usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios
expertos del dominio junto a analistas de software. La idea es aprovechar la dinámica
de grupos aplicando un proceso de trabajo sistemático y organizado, apoyado por
elementos visuales de comunicación y comprensión de soluciones.
Las razones que sirven de base a JAD son las siguientes:
• Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino
también en redactar un conjunto de requisitos coherente a partir de opiniones
diferentes de los distintos entrevistados.
• Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo
el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y
detectar defectos.
• El JAD propugna una participación más profunda de los usuarios en el proyecto,
hasta tal punto que los usuarios que participan adquieren un cierto sentido de
propiedad en el sistema que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organización que
las entrevistas y porque el ambiente o los métodos de trabajo convencionales en las
empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de
coordinación de tanta gente, dificultad para convencer a la dirección, etc.). No
obstante las empresas que han implantado este método han informado de
importantes ahorros de tiempo en el desarrollo de software, así como de una mayor
satisfacción de los usuarios con los sistemas construidos

TALLERES DE REQUERIMIENTOS

Los requisitos tienen a menudo necesidades cruzadas desconocidas para las

personas implicadas individuales y que a menudo no se descubren en las entrevistas
o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas
pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un
analista, en donde las personas implicadas participan en discusiones para descubrir
requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la
selección de un secretario dedicado a la documentación de la discusión, liberando al
analista para centrarse en el proceso de la definición de los requisitos y para dirigir la
discusión.

BOSQUEJOS

Es una revisión breve (expresada típicamente en palabras y frases en lugar de

oraciones completas) de los puntos principales de un texto, organizada
jerárquicamente de tal forma que los niveles de importancia, al igual que el orden de
las ideas, estén claramente indicados.

Se puede crear un bosquejo formal o informal, primero se debes utilizar las diferentes
técnicas para la generación de ideas (la redacción libre, la lluvia de ideas, etcétera) y
para la organización de ideas (el mapa semántico). Después puedes hacer el
bosquejo. En otras palabras, no es bueno comenzar por el bosquejo, ya que esto
puede restringir y limitar la exploración de un tema. Lo que le ayuda a la mayoría de la
gente es escribir sus ideas en la forma en que se presentan en lugar de apegarse al
orden de las ideas presentadas en un bosquejo. Es decir, primero inicias la
generación de ideas; una vez que tengas las ideas y el mensaje, puedes crear el
bosquejo con los puntos esenciales que piensas incluir en el texto.