Este documento presenta los fundamentos de la ingeniería de requisitos y análisis. Explica que la ingeniería de requisitos incluye la recopilación, análisis y verificación de las necesidades del cliente para un sistema de software. Describe las actividades clave de la ingeniería de requisitos como la extracción, análisis, especificación y validación de requisitos. También cubre las técnicas comunes para la elicitación de requisitos como entrevistas, cuestionarios, casos de uso y prototipos.

1. INGENIERIA DEL SOFTWARE II TRAYECTO III
FUNDAMENTOS DE INGENIERÍA DE REQUISITOS Y ANÁLISIS
UNIDAD I
REQUERIMIENTOS DEL SOFTWARE
CONTENIDO
1. Requerimientos
1.1. ¿Qué son los requerimientos o Requisitos?
1.2. Necesidades,
1.3. Objetivos,
1.4. Características de los requerimiento
2. Importancia de la Ingeniería de Requisitos en la práctica
3. Actividades de la ingeniería de requerimientos
3.1. Extracción
3.2. Análisis
3.3. Especificación
3.4. Validación
4. Levantamiento y Recolección de Requerimientos.
4.1. Técnicas de Elicitación más usadas
4.1.1. Entrevistas y Cuestionarios
4.1.2. Sistemas existentes
4.1.3. Brainstorming o tormenta de ideas
4.1.4. Prototipos
4.1.5. Casos de Uso
4.1.6. La técnica JAD (Joint Application Development)
4.1.7. Ventajas y desventajas de las técnicas de elicitación
1.- REQUERIMIENTOS.
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema
de software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de
requerimientos es entregar una especificación de requerimientos de software correcta
y completa. La ingeniería de requerimientos apunta a mejorar la forma en que
comprendemos y definimos sistemas de software complejos. Existen varias
definiciones de requerimientos, de entre las cuales podemos citar las siguientes:
1.1 ¿Qué son los requerimientos o Requisitos?
Los Requerimientos fueron definidos por la IEEE como [IEEE90]:
1. Condición o capacidad requerida por el usuario para resolver un problema o
alcanzar un objetivo

2. 2. Condición o capacidad que debe satisfacer o poseer un sistema o una componente
de un sistema para satisfacer un contrato, un standard, una especificación u otro
documento formalmente impuesto.
Según Zave:
“Rama de la ingeniería del software que trata con el establecimiento de los objetivos,
funciones y restricciones de los sistemas software. Asimismo, se ocupa de la relación
entre estos factores con el objeto de establecer especificaciones precisas”.
Según Boehm:
“Ingeniería de Requerimientos es la disciplina para desarrollar una especificación
completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes
entre todas las partes involucradas y en dónde se describen las funciones que realizará
el sistema”.
Según Loucopoulos:
“Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y
cooperativo de análisis del problema, documentando los resultados en una variedad
de formatos y probando la exactitud del conocimiento adquirido”.
Según Leite:
“Es el proceso mediante el cual se intercambian diferentes puntos de vista para
recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una
combinación de métodos, herramientas y actores, cuyo producto es un modelo del
cual se genera un documento de requerimientos”.
1.2 Necesidades de los requerimientos
Los Requerimientos cumplen 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.
1.3 Objetivos de los Requerimientos
El objetivo principal de esta actividad es desarrollar una propuesta de sistema software
como solución a las necesidades de negocio de clientes y usuarios, haciéndolo con la
mayor calidad posible e intentando asegurar que coincide con las expectativas de
clientes y usuarios.

3. Los principales objetivos que se identifican en la especificación de requisitos software
son [Chalmeta, 2000]:
1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un
determinado software: El cliente debe participar activamente en la especificación de
requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se
llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.
2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En
muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS permite
al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores
tienen una base fija en la que trabajar. Si no se realiza una buena especificación de
requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que
se deben hacer cambios durante la creación de la aplicación.
3. Servir de base para desarrollos de estándares de ERS particulares para cada
organización: Cada entidad puede desarrollar sus propios estándares para definir sus
necesidades. Una buena especificación de requisitos software ofrece una serie de
ventajas entre las que destacan el contrato entre cliente y desarrolladores (como ya se
ha indicado con anterioridad), la reducción del esfuerzo en el desarrollo, una buena
base para la estimación de costes y planificación, un punto de referencia para procesos
de verificación y validación, y una base para la identificación de posibles mejoras en los
procesos analizados.
Los objetivos son afirmaciones de alto nivel que nos guían hacia la dentificación
de requerimientos ya que siempre debe estar claro y presente el Objetivo de Negocio.
Los ingenieros de requisitos deben elaborar la propuesta en forma de requisitos del
sistema software a desarrollar, usando como entrada la información que se va
generando en el procedimiento Identificar las necesidades de negocio de clientes y
usuarios. Lo habitual es comenzar por los aspectos más generales del sistema (su visión
general), para ir avanzando en el nivel de detalle hasta que se considere suficiente
como para que pueda continuarse el desarrollo sin tener que plantear preguntas
continuas sobre la conducta del sistema a desarrollar.
Durante esta actividad es frecuente que en cualquier momento se identifiquen y
registren diversos tipos de problemas en los requisitos, cuya solución debe gestionarse
por la actividad de Gestionar los problemas en los requisitos dentro del procedimiento
Gestionar los requisitos del sistema software a desarrollar.
1.4 Características de los requerimientos:
Es importante no perder de vista que un requerimiento debe ser:
 Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

4.  Posible de probar o verificar. Si un requerimiento no se puede comprobar,
entonces ¿cómo se sabe si se cumplió con él o no?
 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo en un
futuro.
 Completo: Un requerimiento está completo si no necesita ampliar detalles en
su redacción, es decir, si se proporciona la información suficiente para su
comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar confusiones
al lector.
2.- IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS
Sabemos que muchos proyectos de Software fracasan porque no se realiza un estudio
previo de los requisitos del usuario, no se hace una definición completa del alcance del
proyecto. No realizamos el modelado del negocio antes de desarrollar el software, esto
significa que el analista no se involucra en el problema; aunque tiene claro que el
sistema debe desarrollarse para dar soporte a los procesos de la organización, sino se
involucra en la problemática corre el riesgo de que los requisitos identificados no
correspondan a las necesidades para lo que se debe crear.
Otro problema que conocemos es el de no involucrar al usuario activamente en el
desarrollo del producto “UNA BUENA PRACTICA SERIA MODELAR JUNTO AL CLIENTE”.
Requerimientos incompletos y el cambio frecuente de los requerimientos establecidos
sabemos que son otros factores que llevan los sistemas al fracaso.
Entonces, es bien importante que no exista carencia de requerimientos bien definidos
porque así evitamos esta lista de problemas:

5.  No se realizan estimaciones realistas.
 No se emplean coherentemente herramientas de planeación.
 No se pueden realizar revisiones periódicas del progreso en base a las
especificaciones
 La Arquitectura, el diseño y el desarrollo del software carecerán de una base firme.
 Las pruebas se basaran en supuestos, no en lo que el usuario requiere.
 No es posible controlar el crecimiento de los requerimientos.
La Ingeniería de Requerimientos cumple un papel primordial en el proceso productivo
ya que se enfoca en el área fundamental: "LA PRODUCCION", siendo su tarea la
generación de especificaciones correctas que describan con claridad, sin
ambigüedades y en forma compacta las necesidades del cliente, cumpliendo lo antes
expresado se obtendrá un proyecto que minimizará los problemas relacionados con la
gestión de dichos requerimientos.
Respondiendo a la pregunta inicial entonces podemos decir que los requerimientos
son importantes debido a que son el hilo conductor de todo desarrollo de software.
Obtener requerimientos de calidad demuestra que el trabajo realizado culminará con
éxito, esto se debe a dos factores:
1. La utilización adecuada de las técnicas de captura de requerimientos con los
clientes.
2. Las experiencias de los analistas del proyecto.
Esto sucede porque la experiencia de trabajo en el rol le permite al equipo de Analistas
del Proyecto establecer que técnicas van a utilizar a la hora de la entrevista con el
cliente debido a que los clientes no entienden el lenguaje informático, es por eso que
se debe tener en cuenta el lenguaje el cual se va a aplicar a la hora de la entrevista con
el cliente.
Según la autora Lizka Johany Herrera en su documento de la ingeniería de
requerimientos, los principales beneficios que se obtienen de la Ingeniería de
Requerimientos son (2003: 3):
 Permite gestionar las necesidades del proyecto en forma estructurada: Cada
actividad de la IR consiste de una serie de pasos organizados y bien definidos.
 Mejora la capacidad de predecir cronogramas de proyectos, así como sus
resultados: La IR proporciona un punto de partida para controles subsecuentes
y actividades de mantenimiento, tales como estimación de costos, tiempo y
recursos necesarios.
 Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por
un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente

6. aquellas decisiones tomadas durante la IR, ya que es una de las etapas de
mayor importancia en el ciclo de desarrollo de software y de las primeras en
llevarse a cabo.
 Mejora la calidad del software: La calidad en el software tiene que ver con
cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso,
confiabilidad, desempeño, etc.).
 Mejora la comunicación entre equipos: La especificación de requerimientos
representa una forma de consenso entre clientes y desarrolladores. Si este
consenso no ocurre, el proyecto no será exitoso.
 Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al
cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del
marco del problema, por lo que se le involucra durante todo el desarrollo del
proyecto.
3.- Actividades de la ingeniería de requerimientos
Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice
que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo
para completar el proceso. Estas actividades ayudan a reconocer la importancia que
tiene para el desarrollo de un proyecto de software realizar una especificación y
administración adecuada de los requerimientos de los clientes o usuarios.
Las cuatro actividades son: extracción, análisis, especificación y validación, y serán
explicadas a continuación cada una de ellas.
3.1 Extracción
Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente
dado a las actividades involucradas en el descubrimiento de los requerimientos del
sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para
descubrir el problema que el sistema debe resolver, los diferentes servicios que el
sistema debe prestar, las restricciones que se pueden presentar, etc.
Es importante, que la extracción sea efectiva, ya que la aceptación del sistema
dependerá de cuan bien éste satisfaga las necesidades del cliente.
3.2 Análisis

7. Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se
enfoca en descubrir problemas con los requerimientos del sistema identificados hasta
el momento.
Usualmente se hace un análisis luego de haber producido un bosquejo inicial del
documento de requerimientos; en esta etapa se leen los requerimientos, se
conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan
los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones
con el cliente para discutir los requerimientos.
3.3 Especificación
En esta fase se documentan los requerimientos acordados con el cliente, en un nivel
apropiado de detalle.
En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede
decir que la especificación es el "pasar en limpio" el análisis realizado previamente
aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje
de Modelado Unificado), que es un estándar para el modelado orientado a objetos,
por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se
utiliza cada vez más para la obtención de requerimientos.
3.4 Validación
La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es
decir, verificar todos los requerimientos que aparecen en el documento especificado
para asegurarse que representan una descripción, por lo menos, aceptable del sistema
que se debe implementar. Esto implica verificar que los requerimientos sean
consistentes y que estén completos.
Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto
estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un
mantenimiento adecuado al documento de especificación de requerimientos, que es el
documento final, de carácter formal, que se obtiene de este proceso. Es necesario
recalcar que no existe un proceso único que sea válido de aplicar en todas las
organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al
tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de
experiencia y habilidad de las personas involucradas en la ingeniería de
requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de
requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores,
ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el
proceso.

8. 4.- LEVANTAMIENTO Y RECOLECCION DE REQUERIMIENTOS
Cuando nos encontramos al frente de un proyecto de desarrollo de software es
importante dejar claramente definidos los requerimientos, en forma consistente y
compacta, esta tarea es difícil básicamente porque consiste en la traducción de unas
ideas vagas de necesidades de software en un conjunto concreto de funciones y
restricciones. Además el analista debe extraer información dialogando con muchas
personas y cada una de ellas se expresará de una forma distinta, tendrá conocimientos
informáticos y técnicos distintos, y tendrá unas necesidades y una idea del proyecto
muy particulares.
Es justamente este último punto uno de los que se atacará en esta tesis: que el usuario
y el desarrollador compartan el mismo lenguaje asegura la comunicación entre ambos.
[Leite89] sugiere que en particular el uso del lenguaje propio del usuario mejora
considerablemente esta comunicación. En el proceso de Ingeniería de Requerimientos
la validación de los diferentes productos requiere una fuerte interacción con el usuario
[Loucopoulos], la que se ve facilitada por el vocabulario común usuario-desarrollador.
Las diferentes representaciones que se construyen en el proceso de desarrollo de
software encuentran en el vocabulario del usuario un marco referencial que permite al
desarrollador, obtener un vocabulario de trabajo que es un subconjunto de la
terminología del cliente, lo que a su vez facilita el acceso a la documentación por parte
de todos los participantes en el desarrollo. En muchos casos es difícil especificar los
requerimientos de un problema, con la mayor calidad posible en una etapa temprana
del proceso de desarrollo.
Uno de los mayores problemas que surgen en la fase de análisis y definición de los
requerimientos en una etapa temprana del desarrollo, es cómo organizar toda la
información que adquiere el analista en sus entrevistas con las personas involucradas
en un proyecto y cómo poner de acuerdo a todas estas personas sobre cuál es la
solución más adecuada. Mientras que los métodos clásicos se basan en entrevistas
bilaterales (el analista y cada una de las partes) con lo que dejan para el analista toda
la labor de organización y obtención de un consenso, recientemente se tiende a
prácticas más relacionadas con el brainstorming en el que cada parte expone sus ideas
y propuestas y se produce un debate de forma que las posiciones vayan acercándose
sucesivamente hasta que se llegue a un consenso [Raghavan].
4.1 TECNICAS DE ELICITACIÓN MÁS USADAS
Existen varias técnicas para la IR propuestas para ingeniería de requerimientos
(Herrera, 2003: 12), y de las cuales en este artículo solo se abarcarán cinco de ellas. Es
importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del
proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las

9. características propias del proyecto en particular que se esté desarrollándose para
aprovechar al máximo su utilidad.
4.1.1 Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de
personas o de grupos.
Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste
en una serie de preguntas relacionadas con varios aspectos de un sistema.
Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en
potencia del sistema propuesto. En algunos casos, son gerentes o empleados que
proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de
esta técnica, depende de la habilidad del entrevistador y de su preparación para la
misma.
Preparación de entrevistas
Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes
tareas previas:
• Estudiar el dominio del problema: se debe conocer la terminología básica del
dominio del problema, evitando que el cliente tenga que explicar términos que para él
son obvios. Para ello se puede recurrir a la técnica auxiliar de estudio de
documentación, a bibliografía sobre el tema, documentación de proyectos similares
realizados anteriormente, etc.
• 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. El orden de realización de las entrevistas también es importante.
Normalmente se aplica un enfoque top–down, comenzando por los directivos, que
pueden ofrecer una visión global, ayudar a determinar los objetivos y reducir ciertas
reticencias en sus subordinados, y terminando por los futuros usuarios, que pueden
aportar información más detallada.
• 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.
• Planificar las entrevistas: la fecha, hora, lugar y duración de las entrevista deben
fijarse teniendo en cuenta siempre la agenda del entrevistado.
Realización de entrevistas

10. Dentro de la realización de las entrevistas se distinguen tres etapas, tal como se
expone en [Piattini]:
• 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.
• 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.
• Terminación: se debe recapitular sobre la entrevista 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 confirmar los contenidos. También es importante evaluar la propia entrevista
para determinar los aspectos mejorables.
4.1. 2 Sistemas existentes
Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén
relacionados con el sistema a ser construido. Por un lado, podemos analizar las
interfaces de usuario, observando el tipo de información que se maneja y cómo es
manejada, por otro lado también es útil analizar las distintas salidas que los sistemas
producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre
la base de estas.
4.1.3 Lluvia de ideas (Brainstorm)
Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de
generar la máxima cantidad posible de requerimientos para el sistema. No hay que
detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio
es generar, en una primera instancia, muchas ideas.

11. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro",
"impracticable", "imposible", etc.
Las reglas básicas a seguir son:
 Los participantes deben pertenecer a distintas disciplinas y, preferentemente,
deben tener mucha experiencia. Esto trae aparejado la obtención de una
cantidad mayor de ideas creativas.
 Conviene suspender el juicio crítico y se debe permitir la evolución de cada una
de las ideas, porque si no se crea un ambiente hostil que no alienta la
generación de ideas.
 Por más locas o salvaje que parezcan algunas ideas, no se las debe descartar,
porque luego de maduradas probablemente se tornen en un requerimiento
sumamente útil.
 A veces ocurre que una idea resulta en otra idea, y otras veces podemos
relacionar varias ideas para generar una nueva.
 Escribir las ideas sin censura.
4.1.4 Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que algunos
requerimientos no estén demasiado claros o que no se esté muy seguro de haber
entendido correctamente los requerimientos obtenidos hasta el momento, todo lo
cual puede llevar a un desarrollo no eficaz del sistema final.
Entonces, para validar los requerimientos hallados, se construyen prototipos. Los
prototipos son simulaciones del posible producto, que luego son utilizados por el
usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a
si el sistema diseñado con base a los requerimientos recolectados le permite al usuario
realizar su trabajo de manera eficiente y efectiva.
El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores
y clientes se reúnen y definen los objetivos globales del software, identifican todos los
requerimientos que son conocidos, y señalan áreas en las que será necesaria la
profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El
diseño rápido se centra en una representación de aquellos aspectos del software que
serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño
rápido lleva a la construcción de un prototipo.
4.1.5 Casos de Uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema. El
sitio en Internet wikipedia.org, define a un caso de uso como: “Un caso de uso es una
secuencia de transacciones que son desarrolladas por un sistema en respuesta a un

12. evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso
sirven para especificar la funcionalidad y el comportamiento de un sistema mediante
su interacción con los usuarios y/u otros sistemas”
Los casos de uso permiten entonces describir la posible secuencia de interacciones
entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de
un actor, es una descripción de un conjunto de escenarios, cada uno de ellos
comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los
requerimientos funcionales, sino todos, se pueden expresar con casos de uso.
Según el autor Sommerville, 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 característica fundamental de la notación UML (Lenguaje de modelado unificado),
que se utiliza para describir modelos de sistemas orientados a objetos.
Los Casos de Uso y UML
A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos
especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos
de uso como una excelente forma de especificar el comportamiento externo de un
sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje
estándar de modelado UML (Unified Modeling Language) propuesto por Ivar Jacobson,
James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de
Análisis y Diseño Orientado a Objetos, y avalado por las principales empresas que
desarrollan software en el mundo. UML va en camino de convertirse en un estándar
para modelado de sistemas de software de amplia difusión.
A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante
destacar que los casos de uso poco tienen que ver con entender a un sistema como un
conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a
objetos “clásico”. En este sentido, el éxito de los casos de uso no hace más que dar la
razón al análisis estructurado, que propone que la mejor forma de empezar a entender
un sistema es a partir de los servicios o funciones que ofrece a su entorno,
independientemente de los objetos que interactúan dentro del sistema para
proveerlos.
Como era de esperar, es probable que en el futuro los métodos de análisis y diseño
que prevalezcan hayan adoptado las principales ventajas de todos los métodos
disponibles en la actualidad (estructurados, métodos formales, métodos orientados a
objetos, etc.).
4.1.6 La técnica del JAD (Joint Application Development)

13. Desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales que se
desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo de 2 a 4
días. En estas reuniones se ayuda a los clientes y usuarios a formular problemas y
explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del
desarrollo.
Esta técnica se base en cuatro principios [Raghavan]: dinámica de grupo, el uso de
ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia,
herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de
documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se
obtiene), por la que durante las reuniones se trabaja directamente sobre los
documentos a generar.
Debido a las necesidades de organización que requiere y a que no suele adaptarse bien
a los horarios de trabajo de los clientes y usuarios, esta técnica no suele emplearse con
frecuencia, aunque cuando se aplica suele tener buenos resultados, especialmente
para elicitar requerimientos en el campo de los sistemas de información [Raghavan].
En comparación con las entrevistas individuales, presenta las siguientes ventajas:
• Ahorra tiempo al evitar que las opiniones de los clientes se contrasten
• por separado.
• Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la
documentación generada, no sólo los ingenieros de requerimientos.
• Implica más a los clientes y usuarios en el desarrollo.
Podríamos analizar muchos métodos que ofrece esta técnica, pero todos enfocan hacia
las siguientes directrices básicas:
Se efectúa una reunión en un lugar neutral, se establecen reglas para la preparación y
participación, se elabora una agenda, se elige un facilitador, se utiliza un mecanismo
de comunicación y primeramente el objetivo principal debe ser identificar el problema.
4.1.7 Ventajas y desventajas de las técnicas de elicitación
En el cuadro 1 resumimos Como resumen podemos presentar las principales ventajas y
desventajas de cada una de las técnicas utilizadas en las etapas de la Ingeniería de
Requerimientos.
Técnica Ventajas Desventajas
Entrevista
s y
Cuestiona
rios
• Mediante ellas se obtiene una gran
cantidad de información adecuada a
través del usuario.
• Pueden ser usadas para obtener una
visión general del dominio del problema.
• La información obtenida al
principio puede ser
redundante o incompleta.
• Si el volumen de
información manejado es

14. • Son flexibles.
• Permiten combinarse con otras
técnicas.
alto, requiere mucha
organización de parte del
analista, así como la habilidad
para tratar y comprender el
comportamiento de todos los
involucrados.
Tormenta
de
Ideas
• La producción de ideas en grupos
puede ser más efectiva que la individual.
• Aflora una gran cantidad de ideas sin
ataduras.
• Es necesaria una buena
compenetración del grupo
participante.
Casos de
Uso
• Representan los requerimientos desde
el punto de vista del usuario.
• Permiten representar más de un rol
para cada afectado.
• Identifica nuevos requerimientos,
dentro de un conjunto de
requerimientos.
• En sistemas grandes, toma
mucho tiempo definir todos
los casos de uso.
• El análisis de calidad
depende de la calidad con
que se haya hecho la
descripción inicial.
JAD • Ahorra tiempo, elimina retrasos del
proceso y mejora la calidad del sistema.
• Es una de las mejores maneras de
reducir los errores arrastrados de los
resultados de los requerimientos
iniciales.
• Con la participación de gerentes y
usuarios apropiados, el riesgo cultural
típico se mitiga.
• Evita funcionalidad
sobredimensionada.
• Evita que los requerimientos sean
demasiado específicos o demasiados
vagos, que son dos problemas comunes
en el análisis.
• Es costoso Involucrar al
patrocinador del proyecto y
gerente, experto en la
tecnología, y expertos de la
materia, como parte del
equipo del proyecto.
Cuadro 1: Principales ventajas y desventajas de las técnicas de elicitación.
Es importante destacar, que independientemente a la técnica de elicitación que se
utilice y durante todo el proceso de desarrollo del software es indispensable mantener
una adecuada comunicación entre los participantes.

15. Para esto, un enfoque valioso es la utilización del mismo léxico. En la fase de
elicitación, será tarea del analista ocuparse de homogeneizar el vocabulario,
centrándolo en el léxico propio del cliente [Leite89], esto evitará que el analista utilice
el lenguaje común en su medio ambiente. Simultáneamente, el cliente trasmitirá sus
necesidades en su lenguaje habitual.