TÉCNICAS PARA LA OBTENCIÓN DE REQUERIMIENTOS

Existe un gran número de técnicas para obtener requerimientos. A continuación,

describo las más utilizadas. Hay que aclarar que ninguna de estas técnicas es suficiente
por sí sola y que es recomendable combinarlas para obtener requerimientos completos.

Entrevistas
La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o
descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una
mayor preparación y experiencia por parte del analista. La entrevista se puede definir
como un “intento sistemático de recoger información de otra persona” a través de una
comunicación interpersonal que se lleva a cabo por medio de una conversación
estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda
la información necesaria. Es muy importante la forma en que se plantea la conversación
y la relación que se establece en la entrevista.
Estos son algunos de los aspectos más importantes a tener en cuenta al realizar
entrevistas:

 Preparación. Es necesario documentarse e investigar la situación de la

organización analizando los documentos disponibles, de tal forma que la
entrevista se enfoque en aquellos aspectos que están solamente en la mente del
entrevistado y que no son accesibles por otros medios como la observación o el
análisis de documentos.
 Entrevistar al personal adecuado. La mayoría de los analistas adoptan un
enfoque top-down, comenzando a entrevistar a directivos para que brinden un
panorama general de hacia donde deberían ir las cosas, y terminando por hablar
con los empleados que aportan detalles importantes de la operación.
 Duración. Una entrevista debería durar a lo sumo un par de horas.
 Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados
puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

Desarrollo Conjunto de Aplicaciones ( JAD )

Es una 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.

Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas
(que no son totalmente operativos) de la aplicación pedida. Esta técnica es
particularmente útil cuando:

 El área de la aplicación no está bien definida (posiblemente por ser algo muy
novedoso).
 El costo del rechazo de la aplicación por los usuarios es muy alto.
 Es necesario evaluar previamente el impacto del sistema en los usuarios y en la
organización.

Los prototipos de sistema permiten a los usuarios experimentar para ver cómo éste
ayuda a su trabajo. Fomentan el desarrollo de ideas que desembocan en
requerimientos. Además 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 están
incompletos.
3. Aunque limitado, se dispone rápidamente de un sistema que funciona y
demuestra la factibilidad y usabilidad de la aplicación a administrar.
4. El prototipo se utiliza como base para escribir la especificación para la
producción.

En general, el uso de esta técnica 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 construcción 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 también se
utiliza como un medio para formalizar la aceptación previa del cliente de los requisitos
del proyecto.

Observación
Por medio de esta técnica el analista obtiene información de primera mano sobre la
forma en que se efectúan las actividades. Este método 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 práctica. Los observadores experimentados saben qué
buscar y cómo evaluar la relevancia de lo que observan.

Estudio de documentación
Varios tipos de documentación, como manuales y reportes, pueden proporcionar al
analista información valiosa con respecto a las organizaciones y a sus operaciones. La
documentación difícilmente 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 operación y el
vocabulario que utiliza.

Cuestionarios
El uso de cuestionarios permite a los analistas reunir información proveniente de un
grupo grande de personas. El empleo de formatos estandarizados para las preguntas
puede proporcionar datos más confiables que otras técnicas; por otra parte, su amplia
distribución asegura el anonimato de los encuestados, situación que puede conducir a
respuestas más 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 dirección para solicitar a las personas de la organización 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.

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
después de recopilar todas las ideas se realiza un análisis detallado de cada propuesta.
Esta técnica se puede utilizar para identificar un primer conjunto de requisitos en
aquellos casos donde no están muy claras las necesidades que hay que cubrir, o cuando
se esta creando un sistema que habilitará un servicio nuevo para la organización.

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde los puntos de

vista Humano y Técnico )
Constituye un método bastante evolucionado para fomentar la participación de los
usuarios en los proyectos. Creado por E. Mumford en 1979, coordina la perspectiva
social de los sistemas con su implementación técnica. Un sistema no tiene éxito si no
se ajusta a los factores sociales y organizacionales que rigen a la empresa. Se busca la
satisfacción de los empleados en el trabajo a través de estudios integrales. Los
requisitos técnicos del sistema serán los necesarios para mejorar la situación de los
empleados (y, por lo tanto, su productividad) en función de dichos análisis.

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 métodos orientados a puntos de vista (viewpoints) toman en consideración estas
perspectivas diferentes y las utilizan para estructurar y organizar tanto el proceso de
obtención, como los requerimientos mismos. Uno de estos métodos es el método VORD
(Definición de Requerimientos Orientado a Puntos de Vista), el cual provee un marco de
trabajo orientado para la obtención y documentación de requerimientos. Las etapas
principales de este método son:
 1. Identificación de puntos de vista, que implica descubrir los que reciben los
servicios del sistema e identificar los servicios específicos que se suministran a
cada punto de vista.
2. Estructuración de puntos de vista, que comprende agrupar los relacionados en
una jerarquía. Los servicios comunes se ubican en los niveles altos de la
jerarquía y se heredan los puntos de vista de bajo nivel.
3. Documentación de puntos de vista, que comprende refinar la descripción de
éstos y los servicios identificados.
4. Trazado del punto de vista del sistema, que comprende identificar los objetos en
un diseño orientado a objetos utilizando la información del servicio encapsulado
en los puntos de vista.

Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le
presentan eventos específicos. Cada evento de interacción distinto, o la selección de un
servicio del sistema, se documentan como un escenario de eventos distinto. Los
escenarios de eventos incluyen una descripción 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 información 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 están
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 después de completar el escenario se
muestra en un recuadro sombreado.

Los Casos de Uso son una técnica que se basa en escenarios para la obtención de
requerimientos. Actualmente se han convertido en una técnica fundamental que se
utiliza para analizar y describir modelos de sistemas orientados a objetos. En su forma
más simple, un caso de uso identifica a los actores involucrados en una interacción y
nombra al tipo de ésta.

Etnografía
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
crítico para el éxito del sistema. Una razón 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 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 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 están involucrados. La etnografía
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 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.

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. La etnografía tampoco está diseñada
para identificar nuevas propiedades a agregar al sistema. Por lo tanto, la etnografía no
es un enfoque completo para la obtención de requerimientos y debe utilizarse en
conjunto con otras técnicas, como el análisis de casos de uso.