Experiencias exitosas en la aplicación de técnicas

de elicitación de requerimientos
Master Maria Marta Sandoval Master Maria Adilia García Master Fulvio Lizano Madriz
Carvajal, PMP Vargas Universidad Nacional
Universidad Nacional, Universidad Nacional Escuela de Informática
Escuela de Informática. Escuela de Informática Heredia, Costa Rica
Heredia Costa Rica Heredia Costa Rica flizano@una.ac.cr
msandova@una.ac.cr mgarcia@una.ac.cr

“Nunca debe perderse de vista por qué se desarrolla el software: para satisfacer necesidades reales,
para resolver problemas reales. La única forma de resolver las necesidades reales es comunicarse
con aquellos que tienen dichas necesidades. El cliente o usuario es la persona más importante involucrada en el proyecto”.

Alan Davis
ABSTRACT

En el año 2005, la carrera de Ingeniería en Sistemas de Información de la Escuela de Informática de la Universidad Nacional sufrió
importantes cambios, no solo en los contenidos del plan de estudios, sino en la forma de lograr un adecuado proceso enseñanza
aprendizaje, dando especial atención al desarrollo de habilidades, que van más allá de la codificación de un programa de software. Por
otro lado se ha promovido el acercamiento con el sector productivo del país, entre otras razones, para ofrecer soluciones a empresas
que tienen escaso o del todo no tienen acceso a las ventajas de la Tecnología de Información y Comunicaciones (TIC) facilitando a
los estudiantes, contar con la experiencia que ofrece un trabajo de campo. A través de los cursos de Ingeniería I, II y III los
estudiantes desarrollan sistemas de información, llevando a cabo un proceso completo utilizando el Proceso Unificado de Desarrollo
de Software, ejecutando las actividades asociadas con las áreas de conocimiento establecidas en el Cuerpo del conocimiento de la
Ingeniería de Software (SWEBOK). Precisamente el área de Requerimientos está asociada a una de las principales razones por las
cuales fracasan este tipo de proyectos, como es la deficiente gestión de las expectativas de los involucrados, esto causa una
inadecuada documentación, insatisfacción de los clientes, cambios constantes que pudieron ser previstos, inadecuado utilización de los
recursos y muchos otros. Uno de los principales retos de los nuevos profesionales, es precisamente enfrentarse con un usuario
experimentado en su respectivo campo laboral y muchas veces resistente a colaborar.
En nuestro medio, se utilizan técnicas ya probadas para la recopilación y revisión de los requerimientos, sin embargo muchas veces no
se utilizan de manera sistemática o se utilizan de manera incompleta, las técnicas más utilizadas son la entrevista y el desarrollo de
prototipos. Este artículo presenta las experiencias en la aplicación de tres técnicas para la elicitación de requerimientos, se resumen
sus principales objetivos y actividades, mostrando como han sido aplicadas en casos exitosos permitiendo a los estudiantes liderar
procesos y generar habilidades en campos no necesariamente técnicos. Además han facilitado la participación del usuario, el
compromiso y una adecuada retroalimentación del proceso. Los estudiantes han realizado las tareas de planificación, ejecución y
cierre en el uso de estas técnicas, facilitando su aprendizaje, ofreciendo herramientas concretas que puedan utilizar en su vida laboral y
que le permitan a los futuros profesionales confiar y conocer sus propias habilidades.

PALABRAS CLAVE
Elicitación de requerimientos, Técnicas de elicitación de requerimientos, Desarrollo de habilidades en el proceso enseñanza-
aprendizaje

1. INTRODUCCION
Las técnicas de elicitación son el proceso de adquirir (“eliciting”) todo el conocimiento relevante para producir un modelo de los
requerimientos de un dominio de problema1. A través del tiempo el problema que se ha presentado es la forma en que los usuarios y
clientes expresan sus necesidades y la dificultad de los desarrolladores para interpretar estos requerimientos. Debido a esto, han
surgido algunas técnicas, tales como: entrevista, taller de requerimientos (“workshop”), lluvia de ideas (brainstorming), escenarios
(storyboarding), casos de uso, JAD (Joint Application Development, Desarrollo Conjunto de Aplicaciones), observación in situ, el
estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o que los desarrolladores por un tiempo sean
aprendices del usuario. Al aplicar estas técnicas, algunas veces se obtienen los resultados esperados, sin embargo no siempre es de esta
forma

1
Oloriz Mario G, Elicitación de requerimientos, 2004
Una característica que tiene el uso de una técnica de elicitación es que en muchos casos no se utiliza de manera completa, es decir, se
aplica la técnica pero no se analiza ni se hace una confrontación de las ideas tomadas con el usuario, para corroborar si el mensaje
captado es el deseado o si hubo una mala interpretación de parte del desarrollador.
Para seleccionar la técnica de elicitación más adecuada, se debe tomar en cuenta el tipo de empresa, los recursos con que se cuenta, el
tipo de usuario si es asequible o no y desde luego, la cultura que existe en la organización.
Los estudiantes de los cursos de Ingeniería de Sistemas I, II y III, del Bachillerato en Ingeniería de Sistemas de la Universidad
Nacional, deben desarrollar un proyecto en alguna empresa pública o privada del país, para lo cual deben utilizar la metodología de
ciclo de vida del Proceso Unificado (PU) y tomar en cuenta las áreas de conocimiento establecidas en el SEWBOK2, las cuales se
representan en la Figura No.1.

Figura No.1 Áreas de conocimiento del SWEBOK

En el primer curso los estudiantes deben llevar a cabo la etapa de Inicio del PU, en la cual es de suma importancia definir la viabilidad
del sistema, por lo tanto se deben llevar a cabo la toma de un pequeño porcentaje de requerimientos, utilizando algunas de las técnicas
de elicitación. En el segundo curso se lleva a cabo la etapa de Elaboración en la cual se hace la toma de la mayoría de los
requerimientos del sistema seleccionado, ya en esta etapa se conocen algunos aspectos del sistema, por lo tanto, al inicio del curso
deben llevar a cabo un Taller de requerimientos con el fin de confirmar los requerimientos tomados en la primer etapa (primer curso) y
capturar nuevos requerimientos y en el tercer curso se desarrollan las etapa de Construcción y de Transición del sistema, durante las
cuales deben de continuar tomando nuevos requerimientos y validar los existentes.
Tomando en cuenta que las experiencias han sido muy enriquecedores, considerando la poca experiencia de los estudiantes al
enfrentarse con diferentes tipos de usuarios y que a pesar de ser muy antiguas en no son una práctica generalizada en el proceso de
requerimientos, se seleccionan en este artículo, las siguientes 3 técnicas de elicitación: taller de requerimientos (“workshop”), lluvia
de ideas (“brainstorming”) y escenarios (“storyboarding”).

2. CARACTERÍSTICAS DE LAS 3 TÉCNICAS DE ELICITACIÓN SELECCIONADAS

2.1 Escenarios (“Storyboarding”)

Un escenario es una historia que ilustra cómo un sistema puede satisfacer las necesidades del usuario, permitiéndole retroalimentarse
de una forma ágil. Es una descripción idealizada pero detallada de una instancia específica de interacción hombre-máquina utilizando
diferentes medios tales como texto, dibujos, diagramas, presentación en power point, etc. Estos medios se estructuran en diálogos o
narrativas, por lo que tienen similitud con los prototipos.
En esta técnica se toman en cuenta tres aspectos importantes:
-Quienes intervienen.
-Qué les pasa a los que intervienen.
-Cómo pasan los hechos.
Existe tres tipos de escenarios: pasivos, activos e interactivo. En el pasivo como su nombre lo indica se utilizan bocetos, esquemas,
presentaciones en “Power Point”, el desarrollador va mostrando el material e indica lo que va a pasar, cuándo y cómo. El activo se
puede comparar con una película que el usuario ve que todavía no ha sido producida , es una descripción automatizada presentada por
el analista y el interactivo es una simulación que puede llegar hasta el código, que permite que el usuario interactúe con el sistema
como si lo estuviera haciéndolo en tiempo real.
Entre las ventajas de la técnica de escenarios se puede citar:
a) los usuarios encuentran más fácil transmitir su experticia a través de una historia o historieta, sobre todo en el caso en que
consideren que sus ideas son lo suficientemente claras o se le dificulta expresarlas.
b) es una técnica que permite la utilización de herramientas de bajo costo.
c) el usuario puede hacer una revisión temprana de las interfases del sistema
d) creaciones y modificaciones de requerimientos de una manera sencilla
e) Se pueden utilizar para visualizar y comprender datos, así como para definir y entender las reglas del negocio que serán
implementadas en la nueva aplicación.
Entre las desventajas se puede mencionar:

2
IEEE Computer Society, Guide to the software engineering body of knowledge: 2004 version, SWEBOK, www.swebok.org, 2004.
 a) por falta de creatividad del equipo de trabajo, los resultados podrían no ser los esperados, ya que no se expresa con claridad
los requerimientos.
b) si no se cambia nada, no se aprende nada.
c) si se dedica mucho tiempo en su creación, y hay muchos cambios se pueden perder recursos humanos, de tiempo y
materiales.

2.2 Lluvia de ideas

Es una técnica utilizada en trabajo en equipo que ayuda al proceso de conseguir ideas originales y creativas para determinar un
problema, en un ambiente relajado.
En el año 1941 Alex Osborne dio inicio a esta herramienta, cuando en su afán de buscar ideas creativas se dio un proceso interactivo
de grupo no estructurado, el cuál generó más y mejores ideas que las que los individuos podían producir trabajando
independientemente, dando oportunidad de sugerir sobre un determinado problema y de una vez aprovechar la capacidad creativa de
los participantes.
Los pasos3 que deben ser considerados en la aplicación de esta técnica son:
a) definir el tema o el problema a discutir.
b) nombrar un conductor del ejercicio, con el fin de coordinar en el transcurso de la actividad.
c) al principio de la actividad el conductor deberá explicar las reglas
d) los participantes exponen ideas libremente sin llegar a conclusiones en esta etapa
e) se toma nota de las ideas
f) las ideas no se deben repetir
g) no se critican las ideas ni a los miembros que las exponen (no se rechaza ninguna idea por insignificante que parezca)
h) terminar el ejercicio cuando no se exponen ideas nuevas.
i) se analizan, evalúan y organizan las ideas, para valorar su utilidad en función de los objetivos que se pretendían lograr con el
empleo de esta técnica.
Existen 3 formas de llevar a cabo esta técnica: no estructurada o flujo libre, estructurada o en círculo y silenciosa o lluvia de ideas
escrita.
En la forma no estructurada o flujo libre, se selecciona a la persona que escribirá las ideas, se va escribiendo en un portafolio o en un
tablero una frase que represente el problema y el asunto de discusión, luego se escribe cada idea utilizando el menor número de
palabras posible, seguidamente se verifica con la persona que dio la idea en caso de que sea repetida, no se interpretan o cambian
ideas, todo esto se hace en un tiempo definido previamente.
La forma estructurada es muy parecida a la forma no estructurada, la diferencia es que cada miembro del equipo presenta sus ideas en
un orden predeterminado, en caso de que un miembro del equipo no pueda aportar una nueva idea, le cede el turno a otro miembro.
En la forma silenciosa los participantes piensan las ideas y las anotan en silencio en un papel, cada participante va poniendo la hoja en
un escritorio donde los demás miembros puedan leerlas y luego toma una nueva hoja en caso de que desee aportar una nueva idea, esto
se repite por un tiempo límite y permite a los participantes obtener nuevas ideas sobre las ideas de los otros. Los estudiantes utilizaron
la técnica no estructurada.

2.3 Taller de requerimientos.

El taller de requerimientos consiste una reunión, cuya duración va desde un día hasta 3 días, se llevan a cabo con los usuarios e
involucrados, los desarrolladores y expertos externos. Como ejemplo de los objetivos que se plantean, se pueden mencionar la
definición del alcance del proyecto, validación y definición de requerimientos funcionales, evaluación del diseño del proyecto, la
complejidad de la implementación y otros aspectos relacionados con los requerimientos. El desarrollo de un taller incluye la
planificación, que abarca la definición de una agenda, definición de los objetivos, logística, documentación a distribuir antes y durante
el taller. Además se deberán organizarse los ejercicios y las actividades que se llevarán a cabo, en la medida de lo posible se
recomienda que este taller sea llevado a cabo fuera de la empresa, con el fin de que los usuarios no tengan interrupciones durante la
ejecución. Uno de los principales aspectos asociados al éxito de un taller es la selección de un facilitador, que posee características
tales como imparcialidad, experiencia, conciliador, capacidad de síntesis. El grupo desarrollador deberá ejecutar un análisis y síntesis
con el fin de construir a partir del taller, documentación, como hojas de trabajo, diagramas, esquemas, resoluciones, etc. que facilitan
un mayor entendimiento de las partes involucradas. Los principales beneficios del taller son enfocar al equipo de trabajo hacia un
único de objetivo, permite un mayor acercamiento entre los involucrados del proyecto, es posible exponer y resolver circunstancias
que pueden afectar de forma negativa el éxito del proyecto.

3. EXPERIENCIA EXITOSA UTILIZANDO 3 TÉCNICAS DE ELICITACIÓN

La metodología utilizada para desarrollar el tema de técnicas de elicitación en los cursos de Ingeniería de Sistemas fue promoviendo
en los estudiantes la investigación y presentación de las diferentes técnicas de elicitación, para luego aplicarlas de manera práctica en
la toma de requerimientos de los proyectos que se encuentran desarrollando. De acuerdo a la experiencia que se ha tenido a
continuación se citarán los aspectos relevantes en este trabajo de campo.

3
Ingeniería de Requisitos, Técnicas de elicitación de requerimientos, Instituto Tecnológico Pascual Bravo, 2007,
3.1 Escenarios (storyborading)
La aplicación de esta técnica ha demostrado una gran creatividad por parte de los estudiantes, han utilizado esta técnica de manera
original y con resultados muy positivos para los usuarios y los mismos alumnos. La escasez de recursos, la inexperiencia de los
usuarios y de los mismos estudiantes, ha demostrado la aplicabilidad de esta técnica y han propiciado el aprendizaje colectivo. Como
ejemplo se presentó un caso en que no existían recursos computacionales, ni materiales, por lo que el grupo desarrollador optó por
aplicar esta técnica utilizando medios totalmente manuales, con una gran creatividad los estudiantes optaron por hacer los dibujos de
historietas y posibles pantallas del sistema, incluyendo el logotipo de la empresa y de la Universidad Nacional a mano alzada sobre
láminas de papel periódico. Luego tomaron estas láminas y las colocaron en la pared y se las mostraron a los usuarios, lo cual fue todo
un éxito, sin necesidad de utilizar material muy sofisticado el usuario comprendió el mensaje que deseaba transmitir el equipo
desarrollador y se llevo a cabo una exitosa toma de requerimientos.

3.2 Lluvia de ideas

Esta técnica fue sumamente utilizada por los estudiantes en los casos en existían debilidades de comunicación para expresar los
requerimientos o en casos en que el grupo de usuarios fuera heterogéneo y se dificultaba llegar a consenso con respecto a los
requerimientos del sistema.
En un caso específico, el sistema a desarrollar se trataba de un sistema de matrícula para una universidad, el grupo de estudiantes
colocaron en una pizarra la siguiente idea generadora: “¿Cuáles son los procesos que tomarían en cuenta en el Sistema de
Estudiantes”, y nombraron un secretario que tomaría nota de los aspectos más importantes y un coordinador el cual debía presidir la
lluvia de ideas, diciendo a los usuarios las reglas a seguir tales como:
a) ninguna idea va a ser menos importante que las otras
b) sobre el escritorio se encuentran una serie de fichas para que cada vez que tenga una idea tome una y la escribe en esa ficha.
c) no se deben compartir ideas con los compañeros
d) se pueden repetir ideas
e) deje volar su imaginación, puede escribir cualquier idea por más difícil de realizar que le parezca
Los integrantes del equipo desarrollador iban tomando cada una de las fichas y las fueron colocando en una pizarra, dividiéndolas en
diferentes módulos según las características que tenían, tal como se muestra en la Figura No. 2.

Figura No. 2 Primera etapa de una lluvia de ideas de un sistema de estudiantes

En la siguiente etapa se le asignaron a cada uno de los “stakeholders” 6 fichas más pequeñas, cada una de las cuales tenían las
siguientes puntuaciones:
♦ 2 fichas de 5
♦ 2 fichas de 10
♦ 1 ficha de 15
♦ 1 ficha de 20
Los “stakeholders” debían colocar estas fichas en las ideas que se encontraban en la pizarra, dando un puntaje a los tópicos que
consideraran más importantes, para lo cual debían de colocar una sola ficha por tópico. El resultado de esta parte de la ejecución de la
técnica fue la que se muestra en la figura No. 3.
 Figura No. 3 Segunda etapa de una lluvia de ideas de un sistema de estudiantes

Después de obtener estos resultados, se totaliza cada uno de los tópicos y se da por concluía la actividad. El equipo desarrollador en
una reunión posterior realizó un análisis de los resultados, obteniendo las siguientes estadísticas:

Figura No. 4 Análisis de las estadísticas obtenidas en lluvia de ideas de un sistema de estudiantes
El equipo desarrollador al analizar las estadísticas de esta lluvia de ideas llega a la conclusión de que la prioridad de parte de los
“stakehoders” se encuentra en los procesos: Incluir la matrícula de un estudiante, Modificar la matrícula de un estudiante y Obtener un
historial de un estudiante. Por lo tanto, convoca a una nueva reunión con los “stakehoder” para lograr un consenso de los primeros
procesos que serán desarrollados de acuerdo a los resultados de esta dinámica con lo que estuvieron completamente de acuerdo.
De esta manera, este grupo de estudiantes mediante la utilización de esta técnica de elicitación, logra obtener consenso entre los
procesos prioritarios de un sistema, de una manera conciliadora y documentada que mejora el proceso de levantamiento de
requerimientos.

3.3 Taller de requerimientos (workshop)

Los estudiantes de Ingeniería de Sistemas, al iniciar el segundo curso, deben llevar a cabo un taller de requerimientos, para lo cual
deberán elaborar un plan de acuerdo a la guía que se muestra en la figura 5, la cual es facilitada por el docente:
 Taller de requerimientos
1. Objetivos del taller:
2. Agenda del taller
3. Estrategia para lograr la participación de los asistentes
4. Documentos que se entregarán al usuario para que revise
antes del taller
5. Logística
• Lugar:.
• Día y Hora:
• Participantes:
• Material requerido:

Figura No. 5 Guía para planear un Taller de Requerimientos

Este plan es enviado al docente con el objetivo que lo revise y que les ofrezca recomendaciones a los estudiantes. Una vez que se lleva
a cabo el taller, los estudiantes deben exponer a sus compañeros y al profesor, las debilidades y fortalezas detectadas en el proyecto,
después de la aplicación de la técnica, las principales lecciones aprendidas y recomendaciones para continuar con el desarrollo del
proyecto.
Durante varios ciclos lectivos se ha llevado a cabo esta actividad, con la cual los estudiantes han obtenido excelentes resultados. El
taller ha llevado a un proceso de retroalimentación, donde los involucrados y estudiantes se convencen de las necesidad de cambiar,
eliminar o incluir requerimientos, en casos ellos creían que después del taller de requerimientos no iban a originarse modificaciones.
En otros casos han descubierto nuevos riesgos para el proyecto o incluso que la delimitación del sistema no era la que se había tomado
en cuenta. Todos estos hallazgos han convencido a los estudiantes la importancia de llevar a cabo este taller para continuar con la
siguiente etapa de su proyecto.

4. CONCLUSIONES

Muchas veces los docentes consideran que un tema teórico-práctico ha sido comprendido en su totalidad por los estudiantes, pero aún
así queda el vacío de como será tratado en su campo laboral, que es el momento de la verdad. Los profesores de los cursos de
Ingeniería de Sistemas de la Escuela de Informática de la Universidad Nacional, optan por no correr este riesgo y consideran dentro
del programa de estos cursos, replicar en las empresas ciertos tópicos de la Ingeniería de Requerimientos que son de suma importancia
en la formación profesional del estudiante.
El ambiente en el aula ha propiciado la crítica constructiva y promovido la colaboración en busca de soluciones de los proyectos, a
través de la valoración de los aportes, no solo del profesor, sino de los estudiantes. Lo que indica la experiencia vivida es que al
utilizar estas técnicas, varios aspectos se fortalecen en la vida profesional del estudiante, tal como la creatividad, el logro de un
liderazgo técnico, sentir que el usuario confía en ellos, donde el profesor se convierte en un facilitador del proceso y no el poseedor
único del conocimiento. Los estudiantes han demostrado habilidades gerenciales y el proceso ha sido retroalimentado en el aula para
lograr un aprendizaje, en estudiantes y profesores. Se cuenta con material y documentación fácilmente reproducible para la futura
replica en otras situaciones, esto da un a mayor seguridad al estudiante y le facilita su labor a la hora de dirigir grupos de usuarios,
además ha fortalecido el trabajo en equipo pues se genera un ambiente de libertad intelectual y profesional. Otro logro importante al
ejecutar exitosamente estas técnicas es el hecho de fomentar en los estudiantes la cultura de la calidad, que no sería posible sin el uso
de estándares establecidos como es el caso del SEWBOK y otros más.
Los estudiantes no solo han podido vivir el proceso de selección, planificación y aplicación de las técnicas de elicitación, lo más
importante ha sido la posibilidad de descubrir su utilidad en el desarrollo de su proyecto y propiciar en las empresas prácticas en
beneficio del sector productivo de nuestro país

REFERENCIAS

[1]. Abarca Flor. Material del Curso Docencia Universitaria. Dirección de Docencia. Vicerrectoría Académica de la UNA,
Agosto del 2005
Antonelli Leandro y Alejandro Oliveros, Fuentes utilizadas para desarrolladores de software en Argentina para elicitar
requerimientos, Universidad Nacional de la Plata, Departamento de Computación, Buenos Aires, 2000, oliveros@fibertel.com.ar
[2]. Cox, Alexander y Fallas Jeannette. Estudio de Empleadores de los profesionales en Ingeniería en Costa Rica. Informe final.
Consejo Nacional de Rectores. Costa Rica. 2002.
[3]. Dean Leffingwell, Don Widrig. Managing Software Requeriments. A Unified Approach. Addison Wesley, 2000.
[4]. Escuela de Informática. Plan de Estudios para la carrera de Ingeniería en Sistemas de Información con Grado de
Bachillerato y salida lateral de Diplomado en Programación de Aplicaciones Informáticas. Costa Rica. 2005.
[5]. Escuela de Informática. Plan de Mejoramiento. Universidad Nacional. Costa Rica. 2005.
[6]. IEEE Computer Society, Guide to the software engineering body of knowledge: 2004 version, SWEBOK,
www.swebok.org, 2004.
[7]. Flores, E. Estrategias de evaluación interpretativa de aprendizajes. Editorial UNA. 1997.
[8]. Larman C. Desarrollo iterativo y el Proceso Unificado . UML y Patrones . Prentice Hall. 2003
Ingeniería de Requisitos, Técnicas de elicitación de requerimientos, Instituto Tecnológico Pascual Bravo, 2007,
[9]. Ingeniería de Requisitos, Técnicas de elicitación de requerimientos, Instituto Tecnológico Pascual Bravo, 2007,
http://www.slideshare.net/soreygarcia/clase-4-herramientas-iii
[10]. Mata Francisco, Matarrita Rosaura y Araya Eduardo. Estudio para el fortalecimiento de los centros de enseñanza en
Computación e Informática y la actualización curricular: perfil ocupacional de desempeño para los Ingenieros de Sistemas/Analistas
de Sistemas. PROSOFTWARE. Costa Rica. 2003.
[11]. Oloriz, Mario G., Elicitación de Requerimientos. Agosto 2004,
www.unlu.edu.ar/~ogarcia/se/doc/ElicitaciondeRequerimientos(2).ppt
[12]. Thomas Pablo Javier, Definición de un Proceso de Elicitación de Objetivos, Facultad de Informática, Universidad Nacional
de la Plata, Artentina, 2005,Argentina
http://postgrado.info.unlp.edu.ar/Carrera/Magister/Ingenieria%20de%20Software/Tesis/ThomasPablo.pdf