1.

Tcnicas para la captura de Requisitos

9 mayo 2013 Luis Miguel Gracia

Todos sabemos lo complejo que es capturar los requisitos (de modo que lo que entendemos
sea lo que el cliente quera decirnos) sobre todo si el entorno de trabajo es desconocido para
el equipo de analistas.

Existen algunas tcnicas clsicas que pueden ayudarnos a realizar esta ingeniera de
requisitos.

ENTREVISTAS: resultan una tcnica muy aceptada dentro de la ingeniera de requisitos y

su uso est ampliamente extendido.

Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los
objetivos de la solucin buscada.

A travs de esta tcnica el equipo de trabajo se acerca al problema de una forma natural.
Existen muchos tipos de entrevistas y son muchos

la estructura de la entrevista abarca estos pasos:

-identificacin de los entrevistados,

-preparacin de la entrevista,

-realizacin de la entrevista y

-documentacin de los resultados (protocolo de la entrevista).

No es una tcnica sencilla de aplicar: requiere que el entrevistador sea

experimentado y tenga capacidad para elegir bien a los entrevistados y obtener de
ellos toda la informacin posible en un perodo de tiempo siempre limitado.

JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): esta

tcnica resulta una alternativa a las entrevistas.

Es una prctica de grupo que se desarrolla durante varios das y en la que participan
analistas, usuarios, administradores del sistema y clientes (IBM, 1997).

Est basada en cuatro principios fundamentales:

-dinmica de grupo,

-el uso de ayudas visuales para mejorar la comunicacin,

-mantener un proceso organizado y racional y

-una filosofa de documentacin WYSIWYG (What You See Is What You Get, lo que ve es lo
que obtiene), es decir, durante la aplicacin de la tcnica se trabajar sobre lo que se
generar.

Tras una fase de preparacin del JAD al caso concreto, el equipo de trabajo se rene en
varias sesiones. En cada una de ellas se establecen los requisitos de alto nivel a trabajar, el
mbito del problema y la documentacin.
 Durante la sesin se discute en grupo sobre estos temas, llegndose a una serie de
conclusiones que se documentan. En cada sesin se van concretando ms las necesidades
del sistema.

Esta tcnica presenta una serie de ventajas frente a las entrevistas tradicionales,
ya que ahorra tiempo al evitar que las opiniones de los clientes se tengan que
contrastar por separado, pero requiere un grupo de participantes bien integrados y
organizados.

BRAINSTORMING (Tormenta de ideas):

es tambin una tcnica de reuniones en grupo cuyo objetivo es que los participantes
muestren sus ideas de forma libre

Consiste en la mera acumulacin de ideas y/o informacin sin evaluar las mismas.

El grupo de personas que participa en estas reuniones no debe ser muy numeroso (mximo
10 personas), una de ellas debe asumir el rol de moderador de la sesin, pero sin carcter
de controlador.

Como tcnica de captura de requisitos es sencilla de usar y de aplicar, contrariamente al

JAD, puesto que no requiere tanto trabajo en grupo como ste.

Adems suele ofrecer una visin general de las necesidades del sistema, pero
normalmente no sirve para obtener detalles concretos del mismo, por lo que suele
aplicarse en los primeros encuentros.

CONCEPT MAPPING:

Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vrtices
representan conceptos y las aristas representan posibles relaciones entre dichos conceptos.

Estos grafos de relaciones se desarrollan con el usuario y sirven para aclarar los conceptos
relacionados con el sistema a desarrollar.

Son muy usados dentro de la ingeniera de requisitos, pues son fciles de entender por el
usuario, ms an si el equipo de desarrollo hace el esfuerzo de elaborarlo en el lenguaje de
ste.

Sin embargo, deben ser usados con cautela porque en algunos casos pueden ser muy
sugestivos y pueden llegar a ser ambiguos en casos complejos, si no se acompaa de
una descripcin textual.

SKETCHES Y STORYBOARDS:

Est tcnica es frecuentemente usada por los diseadores grficos de aplicaciones en el

entorno web.

Consiste en representar sobre papel en forma muy esquemtica las diferentes interfaces al
usuario (sketches).

Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de
navegacin (storyboard).

CASOS DE USO
 Aunque inicialmente se desarrollaron como tcnica para la definicin de requisitos
(Jacobson, 1995), algunos autores proponen casos de uso como tcnica para la captura de
requisitos

Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos

funcionales expresados como casos de uso) de un sistema.

Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y

los actores del mismo para realizar una determinada funcin.

La ventaja esencial de los casos de uso es que resultan muy fciles de entender para el
usuario o cliente, sin embargo carecen de la precisin necesaria si no se acompaan con una
informacin textual o detallada con otra tcnica como pueden ser los diagramas de
actividades.

CUESTIONARIOS Y CHECKLISTS:

Esta tcnica requiere que el analista conozca el mbito del problema en el que est
trabajando.

Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y

concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist).

Este cuestionario ser cumplimentado por el grupo de personas entrevistadas o

simplemente para recoger informacin en forma independiente de una entrevista.

Comparacin de terminologa:

Uno de los problemas que surge durante la toma de requisitos es que usuarios y expertos
no llegan a entenderse debido a problemas de terminologa.

Esta tcnica es utilizada en forma complementaria a otras tcnicas para obtener consenso
respecto de la terminologa a ser usada en el proyecto de desarrollo.

Para ello es necesario identificar el uso de trminos diferentes para los mismos conceptos
(correspondencia), misma terminologa para diferentes conceptos (conflictos) o cuando no
hay concordancia exacta ni en el vocabulario ni en los conceptos (contraste)

Existen ms tcnicas para la captura de requisitos incluso tambin es comn encontrar

alternativas que combinen varias de estas tcnicas

Como resumen podramos concluir:

Que el uso de lenguajes naturales producen resultados ms imprecisos que una descripcin
con casos de uso y sta a su vez es ms imprecisa que requisitos descriptos formalmente.

Los casos de uso son apropiados tanto para pequeos como grandes sistemas,

El uso de plantillas resultan menos aptas para grandes sistemas.

Tcncias como JAD son ms difciles de usar y consumen mucho ms tiempo que
entrevistas, permitiendo en cambio obtener resultados de mayor calidad.
Como sabemos, un rea de conocimiento de gran importancia en el
desarrollo de software, es la ingeniera de requerimientos. Esta comprende las
actividades de obtencin (captura, descubrimiento y adquisicin), anlisis (y
negociacin), especificacin, y validacin de requisitos. Adems, establece una
actividad de gestin de requerimientos para manejar los cambios, mantenimiento
y rastreabilidad de los requerimientos.

El proceso de obtencin de requisitos, cuya finalidad es llevar a la luz los

requisitos, no solo es un proceso tcnico, sino tambin un proceso social que
envuelve a diferentes personas, lo que conlleva dificultades aadidas a su
realizacin.

1.1 Tcnicas Para la Obtencin de

Requerimientos
Existe un gran nmero de tcnicas para obtener requerimientos. A continuacin
describo las ms utilizadas. Hay que aclarar que ninguna de estas tcnicas es
suficiente por s sola y que es recomendable combinarlas para obtener
requerimientos completos.

1.1.1 Entrevistas
La entrevista es de gran utilidad para obtener informacin cualitativa como
opiniones, o descripciones subjetivas de actividades. Es una tcnica muy utilizada,
y requiere una mayor preparacin y experiencia por parte del analista. La
entrevista se puede definir como un intento sistemtico de recoger informacin
de otra persona a travs de una comunicacin interpersonal que se lleva a cabo
por medio de una conversacin estructurada. Debe quedar claro que no basta con
hacer preguntas para obtener toda la informacin necesaria. Es muy importante la
forma en que se plantea la conversacin y la relacin que se establece en la
entrevista.

Estos son algunos de los aspectos ms importantes a tener en cuenta al realizar

entrevistas:

Preparacin. Es necesario documentarse e investigar la situacin de la

organizacin analizando los documentos disponibles, de tal forma que la
entrevista se enfoque en aquellos aspectos que estn solamente en la
 mente del entrevistado y que no son accesibles por otros medios como la
observacin o el anlisis de documentos.

Entrevistar al personal adecuado. La mayora de los analistas adoptan un

enfoque top-down, comenzando a entrevistar a directivos para que brinden
un panorama general de hacia donde deberan ir las cosas, y terminando
por hablar con los empleados que aportan detalles importantes de la
operacin.

Duracin. Una entrevista debera durar a lo sumo un par de horas.

Formato. Se recomienda utilizar preguntas abiertas, donde los

entrevistados puedan elaborar y dar detalles, ms all de simplemente
responder si o no.

1.1.2 Desarrollo Conjunto de Aplicaciones

( JAD )
Es una tcnica que se utiliza para promover la cooperacin 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 dinmica de grupos aplicando un proceso de trabajo sistemtico y organizado,
apoyado por elementos visuales de comunicacin y comprensin 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 tambin en redactar un conjunto de requisitos coherente a partir de
opiniones diferentes de los distintos entrevistados.

Es ms difcil apreciar posibles errores en la especificacin de requisitos, ya

que slo el analista revisa el documento. En el JAD todo el grupo puede
actuar como revisor y detectar defectos.

El JAD propugna una participacin ms 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 organizacin que
las entrevistas y porque el ambiente o los mtodos de trabajo convencionales en
las empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de
coordinacin de tanta gente, dificultad para convencer a la direccin, etc.). No
obstante las empresas que han implantado este mtodo han informado de
importantes ahorros de tiempo en el desarrollo de software, as como de una
mayor satisfaccin de los usuarios con los sistemas construidos.
 1.1.3 Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de
pantallas (que no son totalmente operativos) de la aplicacin pedida. Esta tcnica
es particularmente til cuando:

El rea de la aplicacin no est bien definida (posiblemente por ser algo

muy novedoso).

El costo del rechazo de la aplicacin por los usuarios es muy alto.

Es necesario evaluar previamente el impacto del sistema en los usuarios y

en la organizacin.

Los prototipos de sistema permiten a los usuarios experimentar para ver cmo
ste ayuda a su trabajo. Fomentan el desarrollo de ideas que desembocan en
requerimientos. Adems de permitir a los usuarios mejorar las especificaciones de
requerimientos, el desarrollo de un prototipo tiene otras ventajas:

1. Al demostrar las funciones del sistema se identifican las discrepancias entre

los desarrolladores y los usuarios.

2. Durante el desarrollo del prototipo, el personal del desarrollo de software

puede darse cuenta de que los requerimientos son inconsistentes y/o estn
incompletos.

3. Aunque limitado, se dispone rpidamente de un sistema que funciona y

demuestra la factibilidad y usabilidad de la aplicacin a administrar.

4. El prototipo se utiliza como base para escribir la especificacin para la

produccin.

En general, el uso de esta tcnica es un medio que permite solventar objeciones

del usuario del tipo: No s exactamente lo que quiero, pero lo sabr cuando lo
vea. Por lo general, la construccin de prototipos incrementa los costos en las
etapas iniciales de un proyecto, pero esto se recupera en etapas posteriores
gracias al mejor entendimiento de los requerimientos por parte de los
desarrolladores. En algunos casos tambin se utiliza como un medio para
formalizar la aceptacin previa del cliente de los requisitos del proyecto.

1.1.4 Observacin
Por medio de esta tcnica el analista obtiene informacin de primera mano sobre
la forma en que se efectan las actividades. Este mtodo permite observar la
forma en que se llevan a cabo los procesos y, por otro, verificar que realmente se
sigan todos los pasos especificados. Como sabemos, en muchos casos los
procesos son una cosa en papel y otra muy diferente en la prctica. Los
observadores experimentados saben qu buscar y cmo evaluar la relevancia de
lo que observan.

1.1.5 Estudio de documentacin

Varios tipos de documentacin, como manuales y reportes, pueden proporcionar
al analista informacin valiosa con respecto a las organizaciones y a sus
operaciones. La documentacin difcilmente refleja la forma en que realmente se
desarrollan las actividades, o donde se encuentra el poder de la toma de
decisiones. Sin embargo, puede ser de gran impotancia para introducir al analista
al dominio de operacin y el vocabulario que utiliza.

1.1.6 Cuestionarios
El uso de cuestionarios permite a los analistas reunir informacin proveniente de
un grupo grande de personas. El empleo de formatos estandarizados para las
preguntas puede proporcionar datos ms confiables que otras tcnicas; por otra
parte, su amplia distribucin asegura el anonimato de los encuestados, situacin
que puede conducir a respuestas ms honestas.

El inconveniente es que la respuesta puede ser limitada, ya que es posible que no

tenga mucha importancia para los encuestados llenar el cuestionario. Es
recomendable conseguir apoyo de la alta direccin para solicitar a las personas de
la organizacin que contesten el cuestionario.

Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista
debe asegurar que el conocimiento y experiencia de stos califiquen para dar
respuestas a las preguntas.

1.1.7 Tormenta de ideas ( Brainstorming )

Consiste en reuniones con cuatro a diez personas donde como primer paso
sugieren toda clase de ideas sin juzgar su validez por muy disparatadas que
parezcan, y despus de recopilar todas las ideas se realiza un anlisis detallado
de cada propuesta. Esta tcnica se puede utilizar para identificar un primer
conjunto de requisitos en aquellos casos donde no estn muy claras las
necesidades que hay que cubrir, o cuando se esta creando un sistema que
habilitar un servicio nuevo para la organizacin.

1.1.8 ETHICS ( Implementacin Efectiva de

Sistemas Informticos desde los puntos de
vista Humano y Tcnico )
Constituye un mtodo bastante evolucionado para fomentar la participacin de los
usuarios en los proyectos. Creado por E. Mumford en 1979, coordina la
perspectiva social de los sistemas con su implementacin tcnica. Un sistema no
tiene xito si no se ajusta a los factores sociales y organizacionales que rigen a la
empresa. Se busca la satisfaccin de los empleados en el trabajo a travs de
estudios integrales. Los requisitos tcnicos del sistema sern los necesarios para
mejorar la situacin de los empleados (y, por lo tanto, su productividad) en funcin
de dichos anlisis.

1.1.9 Puntos de Vista

Cualquier sistema de software no trivial debe satisfacer las necesidades de un
grupo diverso de interesados (stakeholders). Cada uno de estos puede tener
intereses diferentes en el sistema de software, y por lo tanto sus necesidades
pueden generar requerimientos que tengan conflicto entre s, o incluso se
contradigan.

Los mtodos orientados a puntos de vista (viewpoints) toman en consideracin

estas perspectivas diferentes y las utilizan para estructurar y organizar tanto el
proceso de obtencin, como los requerimientos mismos. Uno de estos mtodos es
el mtodo VORD (Definicin de Requerimientos Orientado a Puntos de Vista), el
cual provee un marco de trabajo orientado para la obtencin y documentacin de
requerimientos. Las etapas principales de este mtodo son:

1. Identificacin de puntos de vista, que implica descubrir los que reciben los
servicios del sistema e identificar los servicios especficos que se
suministran a cada punto de vista.

2. Estructuracin de puntos de vista, que comprende agrupar los relacionados

en una jerarqua. Los servicios comunes se ubican en los niveles altos de la
jerarqua y se heredan los puntos de vista de bajo nivel.

3. Documentacin de puntos de vista, que comprende refinar la descripcin

de stos y los servicios identificados.

4. Trazado del punto de vista del sistema, que comprende identificar los
objetos en un diseo orientado a objetos utilizando la informacin del
servicio encapsulado en los puntos de vista.

1.1.10 Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le
presentan eventos especficos. Cada evento de interaccin distinto, o la seleccin
de un servicio del sistema, se documentan como un escenario de eventos distinto.
Los escenarios de eventos incluyen una descripcin del flujo de datos y las
acciones del sistema, y documenta las excepciones que puedan surgir.

Las convenciones para los diagramas utilizados en los escenarios de eventos son:

1. Los datos proporcionados desde un punto de vista o proporcionados a ste

se representan como elipses.
 2. Las entradas y salidas de la informacin de control se ubican en la parte
superior de cada recuadro.

3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no estn

encerradas, significa que pertenecen al sistema.

4. Las excepciones se muestran en la parte inferior del recuadro. Si existen

varias excepciones posibles, stas se encierran en un recuadro.

5. El nombre del siguiente evento esperado despus de completar el

escenario se muestra en un recuadro sombreado.

Los Casos de Uso son una tcnica que se basa en escenarios para la obtencin de
requerimientos. Actualmente se han convertido en una tcnica fundamental que
se utiliza para analizar y describir modelos de sistemas orientados a objetos. En su
forma ms simple, un caso de uso identifica a los actores involucrados en una
interaccin y nombra al tipo de sta.

1.1.11 Etnografa
Los sistemas de software no existen de forma aislada; se utilizan en un contexto
social y organizacional, y los requerimientos de sistemas de software se derivan y
se restringen acorde a ese contexto. Satisfacer esos requerimientos sociales y
organizacionales es crtico para el xito del sistema. Una razn de por qu muchos
sistemas de software se entregan pero nunca se utilizan es porque no se toma en
cuenta la importancia de este tipo de requerimientos.

La etnografa es una tcnica de observacin que se puede utilizar para entender

los requerimientos sociales y organizacionales. Un analista se sumerge por s solo
en el entorno laboral donde el sistema se utilizar. El trabajo diario se observa y se
hacen notas de las tareas reales en las que los participantes estn involucrados. La
etnografa es especialmente efectiva para descubrir dos tipos de requerimientos:

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

realmente ms que de la forma en la que las definiciones de los procesos
establecen que debera trabajar.

2. Los requerimientos que se derivan de la cooperacin y conocimiento de las

actividades de la gente.

Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que
otras tcnicas de obtencin 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. La etnografa
tampoco est diseada para identificar nuevas propiedades a agregar al sistema.
Por lo tanto, la etnografa no es un enfoque completo para la obtencin de
requerimientos y debe utilizarse en conjunto con otras tcnicas, como el anlisis
de casos de uso.

1.2 Estrategia para la obtencin de requerimientos

Hemos descrito un nmero considerable de tcnicas para la obtencin de
requerimientos. A continuacin sugiero una estrategia de cmo aplicar estas
tcnicas dentro de un proceso ordenado y que aproveche al mximo cada tcnica.
Esto evitar que los analistas con poca experiencia caigamos en un error muy
comn, que es el de pasar demasiado pronto a las entrevistas, lo cual es un
desperdicio de tiempo.

Los pasos de la estrategia sugerida son:

1. Aprender todo lo que se pueda de los documentos, formularios, informes y

archivos existentes. Es sorprendente lo que se puede aprender de un
sistema sin necesidad de quitarle tiempo a la gente.

2. De ser posible, se observar el sistema en accin. No se plantearn

preguntas. Tan slo se observar y se tomarn notas o dibujos. Conviene
asegurarse de que las personas observadas saben que no se les est
evaluando. En caso contrario, harn su trabajo de manera ms eficaz que lo
normal.

3. Disear y distribuir cuestionarios para aclarar cuestiones que no se

comprenden bien. Ser tambin buen momento para solicitar opiniones
sobre los problemas y las limitaciones. Los cuestionarios requieren que los
usuarios inviertan una parte de su tiempo. Pero son ellos los que pueden
elegir cundo les viene mejor hacerlo.

4. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se

ha recogido una base de requerimientos iniciales en los pasos anteriores,
se pueden utilizar las entrevistas para verificar y aclarar las cuestiones y los
problemas de mayor dificultad. En este punto se pueden llegar a aplicar
algunas de las otras tcnicas cmo Escenarios, Tormenta de ideas, Puntos
de Vista, ETHICS y Desarrollo de Prototipos.

5. Se verifican los requerimientos a travs del uso de tcnicas como

Entrevistas, Observacin y orientados a Puntos de Vista.

Esta estrategia no es intocable. Aunque habra que desarrollar una estrategia de

investigacin de hechos para todas las fases pertinentes del desarrollo de
sistemas, cada proyecto tiene sus propias particularidades. A veces, la observacin
o los cuestionarios pueden no ser apropiados. Pero debera mantenerse la idea de
recabar siempre todos los hechos que sea posible antes de concertar entrevistas.
Referencias