Introducción

La Ingeniería de Requerimientos en la actualidad, son muchos los procesos de

desarrollo de software que existen. Con el paso de los años, la Ingeniería del Software
ha introducido y popularizado una serie de estándares para medir y certificar la
calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Como
sabemos, un área de conocimiento de gran importancia en el desarrollo de software,
es la ingeniería de requerimientos. Esta comprende las actividades de obtención
(captura, descubrimiento y adquisición), análisis (y negociación), especificación, y
validación de requisitos. Además, establece una actividad de gestión de
requerimientos para manejar los cambios, mantenimiento y rastreabilidad de los
requerimientos.

El proceso de obtención de requisitos, cuya finalidad es llevar a la luz los requisitos,

no solo es un proceso técnico, sino también un proceso social que envuelve a
diferentes personas, lo que conlleva dificultades añadidas a su realización.

Hoy en día la economía global depende más de sistemas automatizados que en épocas
pasadas. Esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva
década de procesos y estándares de calidad ,a pesar de los avances que ha dado la
tecnología, aún existen procesos de producción informales, parciales. La Ingeniería de
Requerimientos cumple un papel primordial en el proceso de producción de software,
ya que enfoca un área fundamental ,la definición de lo que se desea producir. Su
principal tarea consiste en la generación de especificaciones correctas que describan
con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento
del sistema. De esta manera, se pretende minimizar los problemas relacionados al
desarrollo de sistemas.

Estrategias para determinar requerimientos

Existe un gran número de técnicas para obtener requerimientos. Hay que aclarar que
ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas
para obtener requerimientos completos. Algunas de las técnicas más habituales en la
elicitación de requerimientos son las entrevistas, el Joint Application Development
(JAD) o Desarrollo Conjunto de Aplicaciones, el brainstorming o tormenta de ideas y
la utilización de escenarios, más conocidos como casos de uso.

Estas técnicas, que se describen se suelen completar con otras técnicas

complementarias como la observación in situ, el estudio de documentación, los
cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de
requerimientos sean aprendices del cliente.

Entrevistas

Las entrevistas son la técnica de elicitación más utilizada, y de hecho son

practicamente inevitables en cualquier desarrollo ya que son una de las formas de
comunicación más naturales entre personas. En las entrevistas se pueden identificar
tres fases: preparación, realización y análisis.

Preparación de entrevistas: Las entrevistas no deben improvisarse, por lo que

conviene realizar las siguientes tareas previas:
Estudiar el dominio del problema: Conocer las categorías y conceptos de la
comunidad de clientes y usuarios es fundamental para poder entender las necesidades
de dicha comunidad y su forma de expresarlas, y para generar en los clientes y
usuarios la confianza de que el ingeniero de requerimientos entiende sus problemas.
Para conocer el dominio del problema se puede recurrir a técnicas de estudio de
documentación, a bibliografía sobre el tema, documentación de proyectos similares
realizados anteriormente, la inmersión dentro de la organización para la que se va a
desarrollar o a periodos de aprendizaje por parte de los ingenieros de requerimientos.
Seleccionar a las personas a las que se va a entrevistar: Se debe minimizar el número
de entrevistas a realizar, por lo que es fundamental seleccionar a las personas a
entrevistar. Normalmente se comienza por los directivos (que pueden ofrecer una
visión global), y se continúa con los futuros usuarios (que pueden aportar información
más detallada) y con el personal técnico (que aporta detalles sobre el entorno
operacional de la organización). Conviene también estudiar el perfil de los
entrevistados, buscando puntos en común con el entrevistador que ayuden a romper el
hielo.
Determinar el objetivo y contenido de las entrevistas: Para minimizar el tiempo de la
entrevista es fundamental fijar el objetivo que se pretende alcanzar y determinar
previamente su contenido. Previamente a su realización, se pueden enviar
cuestionarios (que los futuros entrevistados deben rellenar y devolver) y un pequeño
documento de introducción al proyecto de desarrollo (de forma que el entrevistado
conozca los temas que se van a tratar, y el entrevistador recoja información para
preparar la entrevista). Es importante que los cuestionarios, si se usan, se preparen
cuidadosamente teniendo en cuenta quién los va a responder y no incluir conceptos
que se asuman conocidos cuando puedan no serlo.
Planificar las entrevistas: La fecha, hora, lugar y duración de la entrevista deben
fijarse teniendo en cuenta siempre la agenda del entrevistado. En general, se deben
buscar sitios agradables donde no se produzcan interrupciones y que resulten
naturales a los entrevistados.
Realización de entrevistas: Dentro de la realización de las entrevistas se distinguen
tres etapas:
Apertura: El entrevistador debe presentarse e informar al entrevistado sobre la razón
de la entrevista, qué se espera conseguir, cómo se utilizará la información, la
mecánica de las preguntas, etc. Si se va a utilizar algún tipo de notación gráfica o
matemática que el entrevistado no conozca debe explicarse antes de utilizarse. Es
fundamental causar buena impresión en los primeros minutos.
Desarrollo: La entrevista en sí no debería durar más de dos horas, distribuyendo el
tiempo en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar
los monólogos y mantener el control por parte del entrevistador, contemplando la
posibilidad de que una tercera persona tome notas durante la entrevista o grabar la
entrevista en cinta de vídeo o audio, siempre que el entrevistado esté de acuerdo.
Durante esta fase se pueden emplear distintas técnicas:
Preguntas abiertas: También denominadas de libre contexto, estas preguntas no
pueden responderse con un «sí» o un «no», permiten una mayor comunicación y
evitan la sensación de interrogatorio. Por ejemplo, «¿Qué se hace para registrar un
pedido?», «Dígame qué se debe hacer cuando un cliente pide una factura» o «¿Cómo
se rellena un albarán?». Estas preguntas se suelen utilizar al comienzo de la entrevista,
pasando posteriormente a preguntas más concretas. En general, se debe evitar la
tendencia de anticipar una respuesta a las preguntas que se formulan.
Utilizar palabras apropiadas: Se deben evitar tecnicismos que no conozca el
entrevistado y palabras o frases que puedan perturbar emocionalmente la
comunicación.
Mostrar interés en todo momento: Es fundamental cuidar la comunicación no verbal
durante la entrevista: tono de voz, movimiento, expresión facial, etc. Por ejemplo,
para animar a alguien a hablar puede asentirse con la cabeza, decir «ya entiendo»,
«sí», repetir algunas respuestas dadas, hacer pausas, poner una postura de atención,
etc. Debe evitarse bostezar, reclinarse en el sillón, mirar hacia otro lado, etc.
Terminación: Al terminar la entrevista se debe recapitular para confirmar que no ha
habido confusiones en la información recogida, agradecer al entrevistado su
colaboración y citarle para una nueva entrevista si fuera necesario, dejando siempre
abierta la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la
información o al contrastarla con otros entrevistados.
Análisis de las entrevistas: Una vez realizada la entrevista es necesario leer las notas
tomadas, pasarlas a limpio, reorganizar la información, contrastarla con otras
entrevistas o fuentes de información, etc. Una vez elaborada la información, se puede
enviar al entrevistado para confirma los contenidos. También es importante evaluar la
propia entrevista para determinar los aspectos mejorables.

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:

Al demostrar las funciones del sistema se identifican las discrepancias entre los
desarrolladores y los usuarios.
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.
Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la
factibilidad y usabilidad de la aplicación a administrar.
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:

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.
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.
Documentación de puntos de vista, que comprende refinar la descripción de éstos y
los servicios identificados.
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:

Los datos proporcionados desde un punto de vista o proporcionados a éste se

representan como elipses.
Las entradas y salidas de la información de control se ubican en la parte superior de
cada recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas,
significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, éstas se encierran en un recuadro.
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.

Se ha descrito un número considerable de técnicas para la obtención de

requerimientos. Una estrategia de cómo aplicar estas técnicas dentro de un proceso
ordenado y que aproveche al máximo cada técnica.
Los pasos de la estrategia sugerida son:

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.
De ser posible, se observará el sistema en acción. No se plantearán preguntas. Tan
sólo se observará y se tomarán notas o dibujos. Conviene asegurarse de que las
personas observadas saben que no se les está evaluando. En caso contrario, harán su
trabajo de manera más eficaz que lo normal.
Diseñar y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien.
Será también 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 cuándo les viene mejor hacerlo.
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 técnicas cómo
Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de Prototipos.
Se verifican los requerimientos a través del uso de técnicas como Entrevistas,
Observación y orientados a Puntos de Vista.
Esta estrategia no es intocable. Aunque habría que desarrollar una estrategia de
investigación de hechos para todas las fases pertinentes del desarrollo de sistemas,
cada proyecto tiene sus propias particularidades. A veces, la observación o los
cuestionarios pueden no ser apropiados. Pero debería mantenerse la idea de recabar
siempre todos los hechos que sea posible antes de concertar entrevistas.

Un diagrama de flujo de datos

Es una técnica muy apropiada para reflejar de una forma clara y precisa los procesos
que conforman el sistema de información. Permite representar gráficamente los
límites del sistema y la lógica de los procesos, estableciendo qué funciones hay que
desarrollar. Además, muestra el flujo o movimiento de los datos a través del sistema y
sus transformaciones como resultado de la ejecución de los procesos.

Esta técnica consiste en la descomposición sucesiva de los procesos, desde un nivel

general, hasta llegar al nivel de detalle necesario para reflejar toda la semántica que
debe soportar el sistema en estudio.

El diagrama de flujo de datos se compone de los siguientes elementos:

Entidad externa: representa un ente ajeno al sistema que proporciona o recibe

información del mismo. Puede hacer referencia a departamentos, personas, máquinas,
recursos u otros sistemas. El estudio de las relaciones entre entidades externas no
forma parte del modelo.
Puede aparecer varias veces en un mismo diagrama, así como en los distintos niveles
del DFD para mejorar la claridad del diagrama.
Proceso: representa una funcionalidad que tiene que llevar a cabo el sistema para
transformar o manipular datos. El proceso debe ser capaz de generar los flujos de
datos de salida a partir de los de entrada, más una información constante o variable al
proceso.
El proceso nunca es el origen ni el final de los datos, puede transformar un flujo de
datos de entrada en varios de salida y siempre es necesario como intermediario entre
una entidad externa y un almacén de datos.
Almacén de datos: representa la información en reposo utilizada por el sistema
independientemente del sistema de gestión de datos (por ejemplo un. fichero, base de
datos, archivador, etc.). Contiene la información necesaria para la ejecución del
proceso.
El almacén no puede crear, transformar o destruir datos, no puede estar comunicado
con otro almacén o entidad externa y aparecerá por primera vez en aquel nivel en que
dos o más procesos accedan a él.
Flujo de datos: representa el movimiento de los datos, y establece la comunicación
entre los procesos y los almacenes de datos o las entidades externas.
Un flujo de datos entre dos procesos sólo es posible cuando la información es
síncrona, es decir, el proceso destino comienza cuando el proceso origen finaliza su
función.
Los flujos de datos que comunican procesos con almacenes pueden ser de los
siguientes tipos:
De consulta: representan la utilización de los valores de uno o más campos de un
almacén o la comprobación de que los valores de los campos seleccionados cumplen
unos criterios determinados.
De actualización: representan la alteración de los datos de un almacén como
consecuencia de la creación de un nuevo elemento, por eliminación o modificación de
otros ya existentes.
De diálogo: es un flujo entre un proceso y un almacén que representa una consulta y
una actualización.
Existen sistemas que precisan de información orientada al control de datos y requieren
flujos y procesos de control, así como los mecanismos que desencadenan su
ejecución. Para que resulte adecuado el análisis de estos sistemas, se ha ampliado la
notación de los diagramas de flujo de datos incorporando los siguientes elementos:

Proceso de control: representa procesos que coordinan y sincronizan las actividades

de otros procesos del diagrama de flujo de datos.
Flujo de control: representa el flujo entre un proceso de control y otro proceso. El
flujo de control que sale de un proceso de control activa al proceso que lo recibe y el
que entra le informa de la situación de un proceso. A diferencia de los flujos
tradicionales, que pueden considerarse como procesadores de datos porque reflejan el
movimiento y transformación de los mismos, los flujos de control no representan
datos con valores, sino que en cierto modo, se trata de eventos que activan los
procesos (señales o interrupciones).

El objetivo del diagrama de flujo de datos es la obtención de un modelo lógico de

procesos que represente el sistema, con independencia de las restricciones físicas del
entorno. Así se facilita su comprensión por los usuarios y los miembros del equipo de
desarrollo.

El sistema se divide en distintos niveles de detalle, con el objetivo de:

Simplificar la complejidad del sistema, representando los diferentes procesos de que

consta.
Facilitar el mantenimiento del sistema.
Conclusiones

Se ha descrito un número considerable de técnicas para la obtención de

requerimientos. Una estrategia de cómo aplicar estas técnicas dentro de un proceso
ordenado y que aproveche al máximo cada técnica. En definitiva los pasos de la
estrategia sugerida son, aprender todo lo que se pueda de los documentos,
formularios, informes y archivos existentes. De ser posible, se observará el sistema en
acción. No se plantearán preguntas. Tan sólo se observará y se tomarán notas o
dibujos. Conviene asegurarse de que las personas observadas saben que no se les está
evaluando. En caso contrario, harán su trabajo de manera más eficaz que lo normal.
Diseñar y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien.
Será también 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 cuándo les viene mejor hacerlo.
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 técnicas cómo
Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de Prototipos.
Se verifican los requerimientos a través del uso de técnicas como Entrevistas,
Observación y orientados a Puntos de Vista.
Esta estrategia no es intocable. Aunque habría que desarrollar una estrategia de
investigación de hechos para todas las fases pertinentes del desarrollo de sistemas,
cada proyecto tiene sus propias particularidades. A veces, la observación o los
cuestionarios pueden no ser apropiados. Pero debería mantenerse la idea de recabar
siempre todos los hechos que sea posible antes de concertar entrevistas.

Referencias

Flaaten, P. O., McCubbrey, D.J., O´Riordan, P.D., Burgués, K., “Foundations of

Business Systems”. Chicago (EE.UU.), The Dryden Pres, 1989.
Raghavan, S., Zelesnik, G., Ford, G., “Lecture Notes on Requirements Elicitation”.
CMU/SEI-94-EM-10, Pittsburgh (E.E.U.U.), Software Engineering Institute
(Carnegie Mellon University), 1994.
Kontonya, G. & Sommerville I., “Requirements Engineering: Processes and
Techniques”. John Wiley and Sons, 2002.
Kotonya, G. y Sommerville, I. (1996). “Requirements Engineering with viewpoints”.
BCS/IEE Software Engineering J.