Obtención de Requerimientos
TÉCNICAS Y ESTRATEGIAS
La ingeniería de requerimientos comprende las actividades de
obtención (captura, descubrimiento y adquisición), análisis,
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.
TÉCNICAS PARA LA OBTENCIÓN DE REQUERIMIENTOS
Existe un gran número de técnicas para obtener requerimientos.
Dentro de las técnicas mas utilizadas, ninguna de éstas es suficiente por sí sola y se
recomienda combinarlas para obtener requerimientos completos.
Entrevistas
Desarrollo Conjunto de Aplicaciones JAD
Desarrollo de Prototipos
Observación
Estudio de Documentación
Cuestionarios
Tormenta de Ideas
ETHICS
Puntos de Vista, Escenarios, Etnografías
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, requiere preparación y experiencia por parte del analista.
Se define 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, importante es la forma en que se plantea la conversación y la relación que se
establece en la entrevista.
ASPECTOS A TENER EN CUENTA
• Preparación. Documentarse e investigar la situación de la organización
analizando los documentos disponibles, es una buena manera de 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)
Técnica utilizada 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, con la idea de 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, 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, ya que requiere una mayor organización que las entrevistas y
porque el ambiente en las empresas no facilita 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í satisfacción de los usuarios.
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 ésto 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 importancia 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
Un 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.
ESTRATEGIA PARA LA OBTENCIÓN DE REQUERIMIENTOS
Hemos descrito un número considerable de técnicas para la obtención de requerimientos. A
continuación se sugiere una estrategia de cómo aplicar estas técnicas dentro de un proceso
ordenado y que aproveche al máximo cada técnica.
Esto evitará que los analistas con poca experiencia caigan en un error muy común, 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,
eso ayudará a no quitarle tiempo a la gente.
2. 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.
3. 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.
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
técnicas cómo Escenarios, Tormenta de ideas, Puntos de Vista, ETHICS y
Desarrollo de Prototipos.
5. Se verifican los requerimientos a través del uso de técnicas como Entrevistas,
Observación y orientados a Puntos de Vista.
BIBLIOGRAFIA
1. Flaaten, P. O., McCubbrey, D.J., O´Riordan, P.D., Burgués, K., “Foundations of
Business Systems”. Chicago (EE.UU.), The Dryden Pres, 1989.
2. 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.
3. Kontonya, G. & Sommerville I., “Requirements Engineering: Processes and
Techniques”. John Wiley and Sons, 2002.
4. Kotonya, G. y Sommerville, I. (1996). “Requirements Engineering with
viewpoints”. BCS/IEE Software Engineering J.
