Ingenieria de Requerimientos - Material de Estudio

ASIGNATURA
INGENIERÍA DE
REQUERIMIENTOS
(MÓDULO AUTOINSTRUCTIVO)
AUTOINSTRUCTIVO)
Asignatura: Ingeniería de Requerimientos
Universidad Continental de Ciencias e Ingeniería

Material publicado con fines de estudio
Primera edición
Huancayo, 2010
2
PRESENTACIÓN
Ingeniería de Requerimientos, es una asignatura diseñada para proporcionar al

estudiante, los modelos, técnicas y herramientas para extraer, analizar, validar e integrar
los requerimientos para la construcción de un sistema de software.
En general, los contenidos propuestos en el material de estudio, se dividen en los

siguientes temas: Fundamentos de Ingeniería de Requerimientos, Fases de los
Requerimientos, Herramientas y Técnicas en el modelado de requerimientos, Prototipos y
Metodologías Ágiles de desarrollo. El material ha sido seleccionado de los textos incluidos
en la bibliografía, unido a la experiencia profesional del autor.
Es recomendable que el estudiante desarrolle una permanente lectura de estudio

junto con el desarrollo de los trabajos aplicativos de la asignatura. El contenido del
material se complementará con las lecciones presenciales y lecturas adicionales.
Agradecemos a quienes con sus aportes y sugerencias han contribuido a recopilar

la presente edición, el que servirá a nuestros estudiantes para afrontar el mercado
laboral.
El Autor.
3
ÍNDICE
Pág.
PRESENTACIÓN 03
ÍNDICE 04
ORGANIZADOR DE CONTENIDOS 05
PRIMERA UNIDAD
Tema Nº 1: Introducción a la Ingeniería de Requerimientos 06
Tema Nº 2: Fases de la Ingeniería de Requerimientos 13
Tema Nº 3: Tipos de Requerimientos 21
Tema Nº 4: Gestión del Proyecto de Requerimientos 30
SEGUNDA UNIDAD
Tema Nº 5: Herramientas y Técnicas de la Ingeniería de Requerimientos 37
Tema Nº 6: Especificación de Requerimientos 43
Tema Nº 7: Construcción de Prototipos 46
Tema Nº 8: Metodologías Ágiles 51
REFERENCIAS BIBLIOGRÁFICAS 63
4
5
PRIMERA UNIDAD
Tema Nº 1: Introducción a la Ingeniería de Requerimientos
¿Por qué importan los requerimientos?
En uno de los párrafos más citados en la bibliografía de la Ingeniería del

Software, Frederick P. Brooks dice "La parte más difícil de construir un sistema es
precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan
difícil como establecer los requerimientos técnicos detallados, incluyendo todas las
interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta
tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante...
Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la
extracción iterativa y el refinamiento de los requerimientos del producto."
Los requerimientos se deben descubrir antes de empezar a construir un producto, y

que puede ser algo que el producto debe hacer o una cualidad que el producto debe
tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas
funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del
producto final. Así que si no se tienen los requerimientos correctos, no se puede diseñar o
construir el producto correcto y, consecuentemente, el producto no permitirá a los usuarios
finales realizar su trabajo. Y esto está confirmado por estudios que demuestran que más
del 60% de los errores de diseño se originan durante las etapas de requerimientos y
análisis.
¿Qué es la Ingeniería de Requerimientos (IR)?
La Ingeniería de Requerimientos se define como un "conjunto de actividades en las

cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la
especificación de una solución (a veces más de una)."
Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las

actividades involucradas en el descubrimiento, documentación y mantenimiento de los
requerimientos para un producto determinado. El uso del término "ingeniería" implica que
se deben utilizar técnicas sistemáticas y repetibles para asegurar que los
requerimientos del sistema estén completos y sean consistentes y relevantes.
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:
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. Condición o capacidad que debe satisfacer o poseer un sistema o una
componente de un sistema para satisfacer un contrato, un estándar, una
especificación u otro documento formalmente impuesto
3. Representación documentada de una condición o capacidad como en 1 ó 2.
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.
6
• 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.
Cuando nos encontramos al frente de un proyecto de desarrollo de sistemas es

importante dejar claramente definidos los requerimientos del software, 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.
En el proceso de Ingeniería de Requerimientos la validación de los diferentes

productos requiere una fuerte interacción con el usuario, 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.
La construcción de prototipos constituye un método alternativo, que da como

resultado un modelo ejecutable del software a partir del cual se pueden refinar los
requerimientos. Para poder construir el prototipo se necesitan técnicas y herramientas
especiales.
El análisis de requerimientos establece el proceso de definición de requerimientos

como una serie de tareas o actividades mediante las cuales se busca ganar
conocimientos relevantes del problema, que se utilizarán para producir una
especificación formal del software necesario para resolverlo. En este proceso se
deben conciliar diferentes puntos de vista y utilizar una combinación de métodos,
personas y herramientas. El resultado final constituye la documentación de los
requerimientos. Éstos deben expresarse de forma clara y estructurada de manera que
puedan ser entendidos tanto por expertos como por el usuario, quien deberá participar en
la validación.
Como resultado del análisis se desarrolla la especificación de requerimientos del

software. La revisión es esencial para asegurar que el realizador del software y el
cliente tengan la misma percepción del sistema.
7
Una vez finalizado nuestro proyecto de desarrollo de sistemas, y contando con

un buen análisis de requerimientos, podremos evaluar la calidad del producto terminado.
¿Para qué un Proceso de Ingeniería de Requerimientos?
El Proceso de ingeniería de requerimientos es un conjunto estructurado de actividades,

mediante las cuales obtenemos, validamos y mantenemos el documento de especificación
de requerimientos.
Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la

negociación y la validación. 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 muchas veces tenemos también que recurrir a consultores, ya que
ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.
Cualquier tarea en donde el resultado sea importante, se puede realizar de mejor

manera al utilizar algún tipo de proceso ordenado. Para obtener este orden, diseñamos
nuestros procesos basándonos en algún modelo que nos guíe a la hora de diferenciar y
secuenciar las actividades. Por ende, veremos a continuación los modelos aplicables a la
Ingeniería de Requerimientos, los analizaremos y veremos cuál se aplica mejor a
nuestro escenario, para continuar con el análisis detallado de las diferentes etapas
implicadas en este proceso, y las herramientas que mejor se aplican a cada una.
Modelo de proceso de IR
Un modelo es una simplificación de la realidad que incluye aquellos elementos que

tienen una gran influencia y omite aquellos elementos que no son relevantes para el nivel
de abstracción dado. En definitiva, los modelos son abstracciones simplificadas y
estandarizadas de actividades repetitivas, generalmente producidos desde un punto de
vista determinado, por lo que pueden existir diferentes modelos para un mismo proceso.
Sin embargo, en el caso del proceso de IR y desde una perspectiva "intelectual", podemos
decir que todos esos diversos modelos parten de una misma base, un modelo
"madre" que llamaremos "modelo-abstracto". Este tipo de modelo nos brinda una
vista preliminar del proceso, una secuenciación aproximada y general de las
actividades que luego deberemos realizar. Así, presentamos el siguiente ejemplo, en
donde cada uno de los compartimientos cubre una sección particular del proceso.
8
Las diversas necesidades de las diferentes organizaciones comienzan a surgir a partir de

la aplicación de modelos más detallados. Así, tenemos dos modelos básicos que
permiten estudiar el proceso de IR y del cual se derivan numerosas variante que
dependerán del caso de estudio en cuestión.
Modelo Tradicional en Cascada
Este modelo sugiere que los resultados de una tarea del proceso llevan a la siguiente, y
así sucesivamente. En el ejemplo presentado, la extracción lleva al análisis, el análisis
desencadena la documentación, y la documentación inicia la validación.
Si vemos a este modelo como una descripción general del proceso, es un modelo
útil. Sin embargo, debemos entender que la realidad del proceso de IR es mucho
más compleja que lo que se vislumbra a partir del modelo en cascada: no existen
fases claramente delimitadas ya que hay una retroalimentación constante entre las
distintas etapas; los requerimientos del sistema van cambiando por circunstancias ajenas
al proceso (como una ley nueva o un cambio de mercado que a su vez cambia las
necesidades de la empresa) durante el desarrollo del mismo; se descubren
problemas durante la validación que llevan a un cambio de requerimientos, etc.; y todo
esto hará que más de una vez tengamos que volver "hacia atrás" en el proceso de IR.
Modelo en Espiral
Un modo alternativo de presentar modelos de actividad que toma en cuenta la

retroalimentación entre etapas y la repetición de tareas, es el llamado Modelo en
Espiral.
9
En este diagrama, el uso de la espiral implica que las diferentes actividades de la

ingenieria de requerimientos son repetidas hasta que se toma la decisión final, que es la
aceptación del documento de especificación de requerimientos. Es decir, si en el diseño
preliminar se encuentran problemas, entonces recorremos el ciclo nuevamente
(extracción-análisis-especificación-validación) hasta que todos sean resueltos, que es
lo mismo que decir que este ciclo continuará hasta que se pueda elaborar un
documento aceptable. Pero también existen factores externos que pueden determinar la
finalización del ciclo, como por ejemplo la presión por cumplir con un determinado
cronograma.
¿Cómo realizar la ingeniería de requerimientos?
El proceso del establecimiento de requerimientos de un sistema de software, como

ya mencionamos, es el primer paso esencial en entregar lo que el cliente desea. A
pesar de esto, la insuficiencia de tiempo y esfuerzo son a menudo encontrado en
esta actividad y existen pocos métodos sistemáticos para soportarlo. Entre los métodos
conocidos se puede citar a los siguientes:
Para Pressman, en el proceso de análisis de requerimientos del software se puede

identificar cinco tareas o etapas fundamentales:
1. Reconocimiento del problema

Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto
del software. Realmente se necesita llegar a comprender el software dentro del
contexto del sistema. El analista debe establecer un canal adecuado de
comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la
función primordial del analista en todo momento es reconocer los elementos del problema
tal y como los percibe el usuario.
2. Evaluación y síntesis
En esta etapa el analista debe centrarse en el flujo y estructura de la información, definir
las funciones del software, determinar los factores que afectan el desarrollo de
nuestro sistema, establecer las características de la interfaz del sistema y descubrir las
restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la
determinación del problema de forma sintetizada.
3. Modelización
Durante la evaluación y síntesis de la solución, se crean modelos del sistema que
servirán al analista para comprender mejor el proceso funcional, operativo y de
contenido de la información. El modelo servirá de pilar para el diseño del software
y como base para la
creación de una especificación del software.
4. Especificación
Las tareas asociadas con la especificación intenta proporcionar una representación
del software. Esto más adelante permitirá llegar a determinar si se ha llegado a
comprender el software, en los casos que se lleguen a modelar se pueden dejar
plasmados manuales.
5. Revisión
Una vez que se han descrito la información básica, se especifican los criterios de
validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software. La documentación del
análisis de requerimientos y manuales, permitirán una revisión por parte del cliente, la
cual posiblemente traerá consigo modificaciones en las funciones del sistema
por lo que deberán revisarse el plan de desarrollo y las estimaciones previstas
inicialmente.
10
Método CORE
El método Controlled Requirements Expression (CORE) es un conjunto de

notaciones textuales y gráficas, con guías especificadas para la captura y validación
de requerimientos del sistema, en las etapas iniciales del diseño del sistema. CORE
ha sido, por tradición, pensado como puramente una técnica de captura y análisis de
requerimientos (RCA), aunque soporta algunos aspectos de diseño tales como estructuras
de datos. CORE está basada en el principio de primero definir el problema a ser analizado
(definición del problema), y luego dividirlo en unidades o puntos de vista a considerar.
El método CORE consiste en siete etapas. Cada una produce salidas que alimentan a la
etapa subsecuente como entrada o que forman parte de la especificación de
requerimientos final. CORE pretende examinar el sistema y su ambiente en un número de
niveles, con detalles más finos progresivamente en cada nivel. Las siete etapas se
presentan a continuación:
1. Definición del problema.

El propósito de la definición del problema es identificar los límites del mismo. Contiene
detalles de los objetivos de la empresa de los usuarios del sistema, la base para la
necesidad de un nuevo sistema, limitaciones de costo y tiempo, y quién va a ser el
responsable de la revisión y aceptación de los resultados finales.
2. Estructuración del punto de vista.

El propósito de esta etapa es descomponer el ambiente del sistema en los elementos para
que el sistema propuesto pueda ser analizado desde los puntos de vista de todas las
entidades que se comunican con él, la más importante de las cuales son los
usuarios. Durante esta etapa, todas las entidades que son fuentes potenciales de
información deben ser identificadas.
3. Colección tabular.
Esta etapa es cuando la información sobre los flujos de datos entre los puntos de vista y el
procesamiento de éstos son reunidos. Esto ayuda a establecer la totalidad y consistencia.
4. Estructuración de datos.
En la etapa previa, los elementos de información que pasan entre los puntos de vista son
referidos por sus nombres generales. En esta etapa, se da una vista más cercana al
contenido, a la estructura y a la derivación de datos, al producir diagramas de estructura
de datos.
5. Modelación individual de puntos de vista.

Esta etapa puede dividirse en dos partes. Lo único concerniente a la primera es convertir
las TCF'S en una notación diferente para producir los diagramas individuales del
modelo de punto de vista. La segunda parte se refiere a agregar alguna
información nueva perteneciente a flujos de datos internos, control de acciones y tiempo
de acciones.
6. Modelación combinada de punto de vista.

Esta etapa facilita el análisis de una secuencia de eventos de más de un punto de vista.
Cada diagrama de modelo combinado de punto de vista producido durante esta etapa
es una representación del procesamiento de información que ocurre entre puntos de
vista.
7. Análisis de restricciones.
En esta etapa, se consideran restricciones adicionales tales como desempeño y
seguridad. Éstas pueden afectar los diagramas de puntos de vista ya producidos. Las
restricciones se documentan en una especificación de restricción del sistema.
Los métodos analizados, como gran parte de los existentes, conciernen a la producción
del documento de especificación de requerimientos y no direcciona el proceso de captura
de requerimiento en detalle, a menudo sólo proporcionan guías simples de técnicas de
11
entrevista y algunas veces áreas claves que deben investigarse pero que a menudo se
olvidan. Cada método individualmente, dará diferentes soluciones para diferentes
proyectos, incluyendo aquellos casos en los que el dominio y el área del problema
son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal
para la Ingeniería de Requerimientos; encontrar el método o la técnica perfecta es una
ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema,
no obstante la aplicación de alguno de ellos nos ayuda a la producción de
especificación de requerimientos.
El proceso de ingeniería de requerimientos plantea que en esta fase hay que

considerar por lo menos tres aspectos fundamentales:
1. Comprender el problema
2. Describir formalmente el problema
3. Obtener un acuerdo sobre la naturaleza del problema
Esto nos llevaría a simplificar el proceso a tres etapas para obtener los
requerimientos del problema que estamos atacando, estas etapas son las siguientes:
1. Elicitación de requerimientos
2. Especificación
3. Validación
Elicitación de requerimientos
El propósito de la elicitación de requerimientos es ganar conocimientos relevantes

del problema, que se utilizarán para producir una especificación formal del software
necesario para resolverlo. “Un problema puede ser definido como la diferencia entre las
cosas como se perciben y las cosas como se desean”1. Aquí vemos
nuevamente la importancia que tiene una buena comunicación entre
desarrolladores y clientes; de esta comunicación con el cliente depende que
entendamos sus necesidades. Al final de la fase de análisis de requerimientos el analista
podría llegar a tener un conocimiento extenso en el dominio del problema.
Especificación
Una especificación puede ser vista como un contrato entre usuarios y

desarrolladores de software, que define el comportamiento funcional deseado del artefacto
de software (y otras propiedades de éste, tales como perfomance, confiabilidad,
etc.), sin mostrar cómo será alcanzada tal funcionalidad.
Validación
La validación es el proceso que certifica que el modelo de los requerimientos

es consistente con las intenciones de los clientes y los usuarios; ésta es una visión más
general que el concepto común de validación, pues se produce en paralelo con la
elicitación y la especificación, tratando de asegurar que tanto las ideas como los
conceptos presentados en una descripción se identifican y explican con claridad La
necesidad de validación aparece cuando:
• Se incorpora una nueva pieza de información al modelo actual.

• Cuando diferentes piezas de información se incorporan en un todo coherente.
La validación no sólo se aplica al modelo final de los requerimientos, sino también a los
modelos intermedios.
12
PRIMERA UNIDAD
Tema Nº 2: Fases de la Ingeniería de Requerimientos

Elicitación.
El análisis de requerimientos siempre comienza con una comunicación entre dos o

más partes. En el libro Ingeniería de Software de R. Pressman, nos sugiere que
un cliente tiene un problema al que puede encontrar una solución basada en
computadora. El desarrollador responde a la petición del cliente. La comunicación ha
comenzado. Pero, el camino entre la comunicación y el entendimiento está lleno de
baches.
Antes de mantener las reuniones con los clientes y usuarios e identificar los
requerimientos es fundamental conocer el dominio del problema. Enfrentarse a un
desarrollo sin conocer las características principales ni el vocabulario propio de su
dominio suele provocar que el producto final no sea el esperado por clientes ni
usuarios. Por otro lado, mantener reuniones con clientes y usuarios sin conocer las
características de su actividad hará que probablemente no se entiendan sus
necesidades y que su confianza inicial hacia el desarrollo se vea deteriorada
enormemente.
Para conocer el dominio del problema se puede obtener información de fuentes externas
al negocio del cliente: folletos, informes sobre el sector, publicaciones, consultas con
expertos, etc. En el caso de que se trate de un dominio muy específico puede ser
necesario recurrir a fuentes internas al propio negocio del cliente, en cuyo caso pueden
utilizarse las técnicas de elicitación de requerimientos como el estudio de
documentación, observación in situ, cuestionarios, etc.
En realidad una primera reunión entre el cliente y el analista servirá como un período corto
de preguntas y respuestas, el cual, en adelante debe sustituirse por reuniones que
busquen entender el problema del usuario.
Normalmente encontramos que los clientes y analistas se enfrascan en el proyecto de

forma unilateral y no en equipo. Cada parte define su propio “territorio” y se
comunica a través de una serie de notas, impresos formales, documentos y
sesiones de preguntas y respuestas. Este enfoque no es muy efectivo, abundan los
malentendidos, se pierde información importante y nunca se establece una relación de
trabajo satisfactoria.
Con estos problemas presentes, se desarrollaron numerosas técnicas para tratar de

superar este difícil momento, que es el inicio del proceso. Cada técnica puede aplicarse
en una o más actividades de la ingeniería de requerimientos; en la práctica, la
técnica más apropiada para cada actividad dependerá del proyecto que esté
desarrollándose.
A continuación se resumen algunas de las más conocidas:
Entrevistas
Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente
inevitables en cualquier desarrollo. En las entrevistas se pueden identificar claramente tres
fases: preparación, realización y análisis, que se describen a continuación.
Preparación de entrevistas
Las entrevistas no deben improvisarse, por lo que conviene realizar las
siguientes tareas previas:
13
• 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
• 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.
Brainstorming
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo

objetivo es la generación de ideas en un ambiente libre de críticas o juicios.
Este método comenzó en el ámbito de las empresas, aplicándose a temas tan

variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones
para los productos del mercado, encontrar nuevos métodos que desarrollen el
pensamiento creativo a todos los niveles, etc. Pero pronto se extendió a otros ámbitos,
incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los
involucrados en un proyecto desarrollen su creatividad, promoviendo la introducción de
los principios creativos.
14
Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez
participantes, uno de los cuales es el jefe de la sesión, encargado más de comenzar la
sesión que de controlarla.
Como técnica de elicitación de requerimientos, el brainstorming puede ayudar a

generar una gran variedad de vistas del problema y a formularlo de diferentes
formas, sobre todo al comienzo del proceso de elicitación, cuando los requerimientos son
todavía muy difusos.
Fases del brainstorming
Preparación: La preparación para una sesión de brainstorming requiere que

se seleccione a los participantes y al jefe de la sesión, citarlos y preparar la sala
donde se llevará a cabo la sesión. Los participantes en una sesión de
brainstorming para elicitación de requerimientos son normalmente clientes,
usuarios, ingenieros de requerimientos, desarrolladores y, si es necesario, algún
experto en temas relevantes para el proyecto.
Generación: El jefe abre la sesión exponiendo un enunciado general del problema

a tratar, que hace de semilla para que se vayan generando ideas. Los
participantes aportan libremente nuevas ideas sobre el problema semilla, bien
por un orden establecido por el jefe de la sesión, bien aleatoriamente. El jefe
es siempre el responsable de dar la palabra a un participante. Este proceso
continúa hasta que el jefe decide parar, bien porque no se están generando
suficientes ideas, en cuyo caso la reunión se pospone, bien porque el número de
ideas sea suficiente para pasar a la siguiente fase. Durante esta fase se deben
observar las siguientes reglas:
• Se prohíbe la crítica de ideas, de forma que los participantes se sientan

libres de formular cualquier idea.
• Se fomentan las ideas más avanzadas, que aunque no sean factibles,
estimulan a los demás participantes a explorar nuevas soluciones más
creativas.
• Se debe generar un gran número de ideas, ya que cuantas más ideas
se presenten más probable será que se generen mejores ideas.
• Se debe alentar a los participantes a combinar o completar las ideas de
otros participantes.
Consolidación: en esta fase se deben organizar y evaluar las ideas

generadas durante la fase anterior. Se suelen seguir tres pasos:
• Revisar ideas: se revisan las ideas generadas para clarificarlas. Es habitual

identificar ideas similares, en cuyo caso se unifican en un solo enunciado.
• Descartar ideas: aquellas ideas que los participantes consideren
excesivamente avanzadas se descartan.
• Priorizar ideas: se priorizan las ideas restantes, identificando las
absolutamente esenciales, las que estarían bien pero que no son
esenciales y las que podrían ser apropiadas para una próxima versión
del sistema a desarrollar.
Documentación: después de la sesión, el jefe produce la documentación

oportuna conteniendo las ideas priorizadas y comentarios generados durante
la consolidación.
Especificación
Los casos de uso son una técnica para la especificación de requerimientos funcionales
que actualmente forma parte de la propuesta de UML [Booch]. Un caso de uso es la
descripción de una secuencia de interacciones entre el sistema y uno o más actores en
la que se considera al sistema como una caja negra.
15
Los casos de uso son una técnica para especificar el comportamiento de un sistema: “Un
caso de uso es una secuencia de interacciones entre un sistema y actores que usan
alguno de sus servicios”.
Los actores son personas u otros sistemas que interactúan con el sistema cuyos
requerimientos se están describiendo. Un actor puede participar en varios casos de uso y
un caso de uso puede estar relacionado con varios actores.
Los casos de uso presentan ciertas ventajas sobre la descripción meramente

textual de los requerimientos funcionales [Firesmith97], ya que facilitan la elicitación
de requerimientos y son fácilmente comprensibles por los clientes y usuarios. Además,
pueden servir de base a las pruebas del sistema y
a la documentación para los usuarios.
La idea de especificar un sistema a partir de su interacción con el ambiente es

original de McMenamin y Palmer, dos precursores del análisis estructurado, que en
1984 definieron un concepto muy parecido al del caso de uso: el Evento. Para
McMenamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante
lo cual el sistema debe responder.
Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las
principales son:
• Los eventos se centran en describir qué hace el sistema cuando el evento

ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo
entre el usuario y el sistema.
• Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera
una salida, mientras que los casos de uso se prolongan a lo largo del tiempo
mientras dure la interacción del usuario con el sistema. De esta forma, un
caso de uso puede agrupar a varios eventos.
• Para los eventos, lo importante es qué datos ingresan al sistema o salen
de él cuando ocurre el evento (estos datos se llaman datos esenciales),
mientras que para los casos de uso la importancia del detalle sobre la
información que se intercambia es secundaria.
Los casos de uso combinan el concepto de evento del análisis estructurado

con otra técnica de especificación de requerimientos bastante poco difundida: aquella que
dice que una buena forma de expresar los requerimientos de un sistema es escribir su
manual de usuario antes de construirlo [Howes]. Esta técnica, si bien ganó pocos
adeptos, se basa en un concepto muy interesante: al definir requerimientos, es
importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no
desde el punto de vista del que lo va a construir. De esta forma, es más fácil
validar que los requerimientos documentados son los verdaderos requerimientos de los
usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.
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
16
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.).
Otras técnicas
Un ejemplo son las técnicas para facilitar la especificación de la aplicación (TFEA)

[Pressman], cuyos dos enfoques más populares son Joint Application Development
(JAD–Desarrollo Conjunto de Aplicaciones), desarrollado por IBM, y The METHOD
(EL METODO), desarrollado por Perfomance Resources, Inc., Falls Church, VA. La
técnica denominada JAD (Joint Application Development), 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: 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. En la siguiente página se observar una
comparativa entre las distintas técnicas.
Validación de Requerimientos
La validación de requerimientos trata de mostrar que éstos realmente definen el sistema

que el cliente desea. Coincide parcialmente con el análisis ya que éste implica encontrar
problemas con los requerimientos. La validación de requerimientos es importante debido a
que los errores en el documento de requerimientos pueden conducir a importantes costes
al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el
sistema esté en uso. El coste de arreglar un problema en los requerimientos haciendo un
cambio en el sistema es mucho mayor que reparar los errores de diseño o los de
codificación. La razón de esto es que un cambio en los requerimientos normalmente
significa que el diseño y la implementación del sistema también deben cambiar y que éste
debe probarse nuevamente.
17
18
Durante el proceso de validación de requerimientos, se deben llevar a cabo verificaciones

sobre requerimientos en el documento de requerimientos. Estas verificaciones
comprenden:
1 Verificaciones de validez. Un usuario puede pensar que se necesita un sistema para

llevar a cabo ciertas funciones. Sin embargo, el razonamiento y el análisis pueden
identificar que se requieren funciones adicionales o diferentes. Los sistemas tienen
diversos stakeholders con diferentes necesidades, y cualquier conjunto de
requerimientos es inevitablemente un compromiso en el entorno del stakeholder.
2 Verificaciones de consistencia. Los requerimientos en el documento no deben contra
decirse. Esto es, no debe haber restricciones o descripciones contradictorias de la
misma función del sistema.
3 Verificaciones de completitud. El documento de requerimientos debe incluir
requerimientos que definan todas las funciones y restricciones propuestas por el
usuario del sistema.
4 Verificaciones de realismo. Utilizando el conocimiento de la tecnología existente, los
requerimientos deben verificarse para asegurar que se pueden implementar. Estas
verificaciones también deben tener en cuenta el presupuesto y la confección de
agendas para el desarrollo del sistema.
5 Verificabilidad. Para reducir la posibilidad de discusiones entre el cliente y el
contratista, los requerimientos del sistema siempre deben redactarse de tal forma que
sean verificables. Esto significa que debe poder escribir un conjunto de pruebas que
demuestren que el sistema a entregar cumple cada uno de los requerimientos
especificados.
Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación de

requerimientos:
1. Revisiones de requerimientos. Los requerimientos son analizados

sistemáticamente por un equipo de revisores. Este proceso se trata en la siguiente
sección.
2. Construcción de prototipos En este enfoque de validación, se muestra un modelo
ejecutable del sistema a los usuarios finales y a los clientes. Éstos pueden
experimentar con este modelo para ver si cumple sus necesidades reales.
3. Generación de casos de prueba. Los requerimientos deben poder probarse. Si las
pruebas para éstos se conciben como parte del proceso de validación, a menudo
revela los problemas en los requerimientos. Si una prueba es difícil o imposible de
diseñar, normalmente significa que los requerimientos serán difíciles de
implementar y deberían ser considerados nuevamente. Desarrollar pruebas para
los requerimientos del usuario antes de que se escriba código es una parte
fundamental de la programación extrema.
No deben subestimarse los problemas en la validación de requerimientos. Es difícil

demostrar que un conjunto de requerimientos cumple las necesidades del usuario. Los
usuarios deben imaginarse el sistema en funcionamiento y cómo éste encajaría en su
trabajo. Para los informáticos expertos es difícil llevar a cabo este tipo de análisis
abstracto, pero para los usuarios del sistema es aún más difícil. Como consecuencia, rara
vez se encuentran todos los pro-blemas en los requerimientos durante el proceso de
validación de éstos. Es inevitable que haya cambios adicionales de requerimientos para
corregir las omisiones y las malas interpretaciones después de que el documento de
requerimientos haya sido aprobado.
Una revisión de requerimientos es un proceso manual que involucra a personas tanto

de la organización del cliente como de la del contratista. Ellos verifican el documento de
requerimientos en cuanto a anomalías y omisiones. El proceso de revisión se puede
gestionar de la misma forma que las inspecciones de programas. Alternativamente, se
puede organizar como una actividad más amplia con diferentes personas que verifican
diferentes partes del documento.
19
Las revisiones de requerimientos pueden ser informales o formales. Las informales

sencillamente implican que los contratistas deben tratar los requerimientos con tantos
stakeholders del sistema como sea posible. Es sorprendente la frecuencia con la que
finaliza la comunicación entre los desarrolladores y los stakeholders del sistema después
de la obtención de requerimientos y que no exista confirmación de que los requerimientos
documentados son real-mente lo que dijeron que deseaban los stakeholders.
Antes de llevar a cabo una reunión para una revisión formal, muchos problemas se
pueden detectar simplemente hablando del sistema con los stakeholders.
En la revisión formal de requerimientos, el equipo de desarrollo debe «conducir» al cliente

a través de los requerimientos del sistema, explicándole las implicaciones de cada
requerimiento. El equipo de revisión debe verificar cada requerimiento para la consistencia
además de verificar los requerimientos como un todo para la completitud. Los revisores
también pueden comprobar la:
1 Verificabilidad. ¿Puede probarse el requerimiento de modo realista?

2 Comprensibilidad. ¿Las personas que adquieren el sistema o los usuarios finales
comprenden correctamente el requerimiento?
3 Rastreabilidad. ¿Está claramente establecido el origen del requerimiento? Puede tener
que volver a la fuente del requerimiento para evaluar el impacto del cambio. La
rastreabilidad es importante ya que permite evaluar el impacto del cambio en el resto
del sistema. Se trata esto con mayor detalle en la siguiente sección.
4 Adaptabilidad. ¿Es adaptable el requerimiento? Es decir, ¿puede cambiarse el
requerimiento sin causar efectos de gran escala en los otros requerimientos del
sistema?
Los conflictos, contradicciones, errores y omisiones en los requerimientos deben ser

señalados por los revisores y registrarse formalmente en el informe de revisión. Queda en
los usuarios, la persona que adquiere el sistema y el desarrollador de éste negociar una
solución para estos problemas identificados.
20
PRIMERA UNIDAD
Tema Nº 3: Tipos de Requerimientos

Tipología de los Requerimientos
Los requerimientos para un sistema son la descripción de los servicios proporcionados por
el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de
los clientes de un sistema que ayude a resolver algún problema como el control de un
dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar,
documentar y verificar estos servicios y restricciones se denomina ingeniería de
requerimientos (RE). El término requerimiento no se utiliza de una forma constante en la
industria de software. En algunos casos, un requerimiento es simplemente una declaración
abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de
éste. En el otro extremo, es una definición detallada y formal de una función del sistema.
Davis (Davis, 1993) explica por qué existen estas diferencias:
Si una compañía desea establecer un contrato para un proyecto de desarrollo de

software grande, debe definir sus necesidades de una forma suficientemente
abstracta para establecer a partir de ella una solución. Los requerimientos deben
redactarse de tal forma que varios contratistas pueden licitar el contrato,
ofreciendo, quizás, formas diferentes de cumplir las necesidades de los clientes en
la organización. Una vez que el contrato se asigna, el contratista debe redactar
una definición del sistema para el cliente más detalladamente de forma que éste
comprenda y pueda validar lo que hará el software. Ambos documentos se pueden
denominar documento de requerimientos para el sistema.
Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos

son resultado de no hacer una clara separación entre estos diferentes niveles de
descripción. Aquí se distinguen utilizando la denominación requerimientos del usuario para
designar los requerimientos abstractos de alto nivel, y requerimientos del sistema para
designar la descripción detallada de lo que el sistema debe hacer. Los requerimientos del
usuario y del sistema se pueden definir como se muestra a continuación:
1 Los requerimientos del usuario son declaraciones, en lenguaje natural y en

diagramas, de los servicios que se espera que el sistema proporcione y de fas
restricciones bajo las cuales debe funcionar.
2 Los requerimientos del sistema establecen con detalle las funciones, servicios
y restricciones operativas del sistema. El documento de requerimientos del
sistema (algunas veces denominado especificación funcional) debe ser
preciso. Debe definir exactamente qué es lo que se va a implementar. Puede
ser parte del contrato entre el comprador del sistema y los desarrolladores del
software.
Diferentes niveles de especificación del sistema son de utilidad debido a que comunican la
información del sistema a diferentes tipos de lectores. Este ejemplo de un sistema de
biblioteca muestra la manera en que un requerimiento del usuario se expande en varios
requerimientos del sistema. Puede verse en la figura de la siguiente página que el
requerimiento del usuario es más abstracto, y que los requerimientos del sistema añaden
detalle, explicando los servicios y funciones que deben ser proporcionados por el sistema
a desarrollar. Es necesario redactar los requerimientos en diversos niveles de detalle
debido a que diferentes tipos de lectores los utilizan de distinta manera. La figura de la
siguiente página muestra los tipos de lectores de los requerimientos de usuario y del
sistema. Los lectores de los requerimientos de usuario normalmente no tratan de cómo se
implementará el sistema y pueden ser administradores que no están interesados en los
recursos detallados del sistema. Los lectores de los requerimientos del sistema necesitan
saber con más precisión qué hará el sistema debido a que están interesados en cómo
21
ayudará esto a los procesos de negocio o debido a que están implicados en la

implementación del sistema. Ejemplo del sistema de biblioteca LIBSYS:
Requerimientos Funcionales
Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer.

Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles
usuarios del software y del enfoque general tomado por la organización al redactar
requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se
describen de una forma bastante abstracta. Sin embargo, los requerimientos funcionales
del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones,
etcétera. Los requerimientos funcionales para un sistema software se pueden expresar de
diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos
funcionales para un sistema de biblioteca universitario, denominados LIBSYS, utilizados
por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.
1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la

base de datos o seleccionar un subconjunto de ella.
2. El sistema deberá proporcionar visores adecuados para que el usuario lea
documentos en el almacén de documentos.
3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que
el usuario podrá copiar al área de almacenamiento permanente de la cuenta.
22
Estos requerimientos funcionales del usuario definen los recursos específicos que el
sistema debe proporcionar. Dichos requerimientos se toman del documento de
requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden
redactar los requerimientos funcionales (contraste los requerimientos 1 y 3).
La impresión en la especificación de requerimientos es la causa de muchos de los

problemas de la ingeniería del software. Para un desarrollador de sistemas es natural dar
interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación.
Sin embargo, a menudo no es lo que el cliente desea. Se deben establecer nuevos
requerimientos y hacer cambios en el sistema. Por supuesto, esto retrasa la entrega de
éste e incrementa los costes.
Considere el segundo ejemplo de los requerimientos para el sistema de biblioteca que se

refiere a los «visores adecuados» que debe proporcionar el sistema. El sistema de
biblioteca puede mostrar documentos en diferentes formatos; la intención de este
requerimiento es que los visores para todos estos formatos estén disponibles. Sin
embargo, el requerimiento está ambiguamente redactado; no clarifica que se deben
proporcionar los visores de cada formato. Un desarrollador bajo la presión del tiempo
sencillamente podría proporcionar un visor de texto y afirmar que se ha cumplido el
requerimiento.
En principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente. La completitud significa que todos los servicios solicitados por
el usuario deben estar definidos. La consistencia significa que los requerimientos no deben
tener definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es
prácticamente imposible alcanzar los requerimientos de consistencia y completitud.
Una razón de esto es que es fácil cometer errores y omisiones cuando se redactan
especificaciones para sistemas grandes y complejos. Otra razón es que los stakeholders
del sistema tienen necesidades diferentes, y a menudo contradictorias. Estas
contradicciones pueden no ser obvias cuando los requerimientos se especifican por
primera vez, por lo que se incluyen requerimientos contradictorios en la especificación. Es
posible que los problemas surjan solamente después de un análisis más profundo o, a
veces, después de que se termine el desarrollo y el sistema se entregue al cliente.
Requerimientos No Funcionales
Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos

que no se refieren directamente a las funciones específicas que proporciona el sistema,
sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la
capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema
como la capacidad de los dispositivos de entrada/salida y las representaciones de datos
que se utilizan en las interfaces del sistema. Los requerimientos no funcionales rara vez se
asocian con características particulares del sistema. Por lo tanto, pueden especificar el
rendimiento del sistema, la protección, la disponibilidad, y otras propiedades emergentes.
Esto significa que a menudo son más críticos que los requerimientos funcionales
particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar
alrededor de una función del sistema que realmente no cumple sus necesidades.
Sin embargo, el incumplimiento de un requerimiento no funcional puede significar que el

sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus
requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un
sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las
funciones de control no funcionarán correctamente. Los requerimientos no funcionales no
sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden
restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de
requerimientos de procesos son la especificación de los estándares de calidad que se
deben utilizar en el proceso, una especificación que el diseño debe producir con una
herramienta CASE particular y una descripción del proceso a seguir.
23
Los requerimientos no funcionales surgen de las necesidades del usuario, debido a las
restricciones en el presupuesto, a las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas software o hardware, o a factores externos como
regulaciones de seguridad o legislaciones sobre privacidad. La siguiente figura es una
clasificación de los requerimientos no funcionales. Puede verse en este diagrama que los
requerimientos no funcionales pueden venir de las características requeridas del software
(requerimientos del producto), de la organización que desarrolla el software
(requerimientos organizacionales) o de fuentes externas. Los tipos de requerimientos no
funcionales son:
1. Requerimientos del producto. Estos requerimientos especifican el comportamiento del

producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez de
ejecución del sistema y cuánta memoria se requiere; los requerimientos de fiabilidad que
fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos deportabilidad,
y los requerimientos de usabilidad.
2. Requerimientos organizacionales. Estos requerimientos se derivan de políticas y
procedimientos existentes en la organización del cliente y en la del desarrollador. Algunos
ejemplos son los estándares en los procesos que deben utilizarse; los requerimientos de
implementación, como los lenguajes de programación o el método de diseño a utilizar, y
los requerimientos de entrega que especifican cuándo se entregará el producto y su
documentación.
3. Requerimientos externos. Este gran apartado incluye todos los requerimientos que se
derivan de los factores externos al sistema y de su proceso de desarrollo. Éstos pueden
incluir los requerimientos de interoperabilidad que definen la manera en que el sistema
interactúa con sistemas de otras organizaciones; los requerimientos legislativos que deben
seguirse para asegurar que el sistema funcione dentro de la ley, y los requerimientos
éticos. Estos últimos son puestos en un sistema para asegurar que será aceptado por sus
usuarios y por el público en general.
El requerimiento del producto restringe la libertad de los diseñadores del LIBSYS en la

implementación de la interfaz de usuario del sistema. No dice nada acerca de la
funcionalidad del LIBSYS e identifica claramente una restricción del sistema más que una
función. Se incluye este requerimiento debido a que simplifica el problema de asegurar
que el sistema funcione con navegadores diferentes.
El requerimiento organizacional especifica que el sistema se debe desarrollar conforme a

un proceso estándar de la compañía definido como XYZCo-SP-STAN-95. El requerimiento
24
externo se deriva de la necesidad del sistema de cumplir la legislación sobre privacidad.

Especifica que no se debe permitir al personal de la biblioteca el acceso a datos, como la
dirección de los usuarios del sistema, que no necesitan para realizar su trabajo.
Un problema común con los requerimientos no funcionales es que pueden ser difíciles de
verificar. Los usuarios o cuentes declaran a menudo estos requerimientos como metas
generales tales como la facilidad de uso, la capacidad del sistema para recuperarse de los
fallos o la respuesta rápida al usuario. Estas metas imprecisas causan problemas a los
desabolladores del sistema puesto que dejan abierta la posibilidad a interpretación, lo que
provoca discusiones subsecuentes una vez que el sistema se entrega.
En la práctica, sin embargo, los clientes de un sistema pueden encontrar prácticamente

imposible traducir sus metas en requerimientos cuantitativos. Para algunas metas, como
las de mantenibilidad, no existen métricas que se puedan utilizar. En otros casos, aun
cuando sea posible la especificación cuantitativa, es posible que los clientes no puedan
relacionar sus necesidades con estas especificaciones. No entienden lo que significa un
cierto número que define la fiabilidad requerida (por ejemplo) en función de su experiencia
diaria con los sistemas informáticos. Además, el coste de verificar de forma objetiva los
requerimientos no funcionales cuantitativos puede ser muy alto, y los clientes que pagan el
sistema quizás piensen que estos costes no son justificados.
Por lo tanto, los documentos de los requerimientos a menudo incluyen las declaraciones
de las nietas mezcladas con los requerimientos. Dichas metas pueden ser útiles para los
desarrolladores puesto que dan idea de las prioridades del cliente. Sin embargo, siempre
se les debe advertir que están abiertas a interpretaciones erróneas y que no se pueden
verificar de forma objetiva.
A menudo, los requerimientos no funcionales entran en conflicto e interactúan con otros

requerimientos funcionales o no funcionales. Por ejemplo, puede haber un requerimiento
que especifique que la capacidad máxima de memoria utilizada por un sistema no debe
ser mayor de 4 Mbytes. Las restricciones de memoria son comunes en los sistemas
embebidos donde el espacio y el peso están limitados y se debe minimizar el número de
chips de ROM que almacenan el sistema software. Otro requerimiento podría ser que el
sistema debe codificarse utilizando Ada, un lenguaje de programación para el desarrollo
de software crítico de tiempo real. Sin embargo, puede que no sea posible compilar con
menos de 4 Mbytes un programa en Ada con la funcionalidad requerida. Por lo tanto, tiene
que haber un equilibro entre estos requerimientos: un lenguaje alternativo de desarrollo o
un aumento en la memoria del sistema.
Es de utilidad diferenciar los requerimientos funcionales y no funcionales en el documento

de requerimientos. En la práctica, esto es difícil. Si los requerimientos no funcionales se
declaran de forma separada de los funcionales, algunas veces es difícil ver la relación
entre ellos. Si se declaran con los requerimientos funcionales, puede resultar difícil separar
las consideraciones funcionales y no funcionales e identificar los requerimientos que se
refieren al sistema como un todo. Sin embargo, se deben resaltar explícitamente los
requerimientos que claramente se refieran a las propiedades emergentes del sistema,
25
como el rendimiento o la fiabilidad. Se puede hacer colocándolos en una sección aparte o

diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
Los requerimientos no funcionales como los requerimientos de seguridad y protección son

especialmente importantes en los sistemas críticos. Por lo tanto, se tratan con mayor
detalle los requerimientos de confiabilidad en el Capítulo 9, el cual incluye la especificación
de los sistemas críticos.
Requerimientos del Dominio
Los requerimientos del dominio se derivan del dominio de aplicación del sistema más que
de las necesidades específicas de los usuarios. Normalmente incluyen terminología
especializada del dominio o referencias a conceptos del dominio. Pueden ser
requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben
ejecutar cálculos particulares. Debido a que éstos se especializan, a los ingenieros de
software a menudo les resulta difícil entender cómo se relacionan con los otros
requerimientos del sistema. Los requerimientos del dominio son importantes debido a que
a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no
se satisfacen, puede ser imposible hacer que el sistema funcione de forma satisfactoria. El
sistema LIBSYS incluye varios requerimientos del dominio:
1. Deberá existir una interfaz de usuario estándar para todas las bases de datos
que estará basada en el estándar Z39.50.
2. Debido a las restricciones en los derechos de autor, algunos documentos
deberán borrarse inmediatamente después de su llegada. Dependiendo de los
requerimientos del usuario, estos documentos se imprimirán de forma local en
el servidor del sistema para ser distribuidos de forma manual al usuario o se
enviarán a la impresora de la red.
El primer requerimiento es una restricción de diseño. Establece que la interfaz de usuario

para la base de datos debe implementarse según un estándar bibliotecario específico. Los
desarrolladores, por lo tanto, tienen que informarse sobre el estándar antes de empezar el
diseño de la interfaz. El segundo requerimiento se introduce debido a las leyes de
derechos de autor que se aplican a los materiales utilizados en las bibliotecas. Establece
que el sistema debe incluir un recurso automático para borrar algunas clases de
documentos al ser impresos. Esto significa que los usuarios del sistema de biblioteca no
pueden tener su propia copia electrónica del documento.
Requerimientos del Usuario
Los requerimientos del usuario para un sistema deben describir los requerimientos
funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del
sistema sin conocimiento técnico detallado. Únicamente deben especificar el
comportamiento externo del sistema y deben evitar, tanto como sea posible, las
características de diseño del sistema. Por consiguiente, si se están redactando
requerimientos del usuario, no se debe utilizar jerga del software, notaciones estructuradas
o formales, o describir los requerimientos por la descripción de la implementación del
sistema. Deben redactarse en un lenguaje sencillo, con tablas y formularios sencillos y
diagramas intuitivos.
Sin embargo, pueden surgir diversos problemas cuando se redactan con frases del
lenguaje natural en un documento de texto:
1. Falta de claridad. Algunas veces es difícil utilizar el lenguaje de forma precisa y no

ambigua sin hacer el documento poco conciso y difícil de leer.
2. Confusión de requerimientos. No se distinguen claramente los requerimientos
funcionales y no funcionales, las metas del sistema y la información para el diseño.
3. Conjunción de requerimientos. Diversos requerimientos diferentes se pueden
expresar de forma conjunta como un único requerimiento.
26
Los requerimientos del usuario que incluyen demasiada información restringen la libertad
del desarrollador del sistema para proporcionar soluciones innovadoras a los problemas
del usuario y son difíciles de comprender. Los requerimientos del usuario deben
simplemente enfocarse a los recursos principales que se deben proporcionar. Cuando sea
posible, se debe intentar asociar un fundamento con cada requerimiento del usuario. El
fundamento debe explicar por qué se ha incluido el requerimiento y es particularmente útil
cuando cambian éstos.
Para minimizar los malentendidos al redactar los requerimientos del usuario, se

recomienda seguir algunas pautas sencillas:
1. Inventar un formato estándar y asegurar que todos los requerimientos se adhieren

al formato. Estandarizar el formato hace que las omisiones sean menos probables
y los requerimientos más fáciles de verificar. El formato utilizado muestra el
requerimiento inicial en negrita, incluyendo una declaración del fundamento con
cada requerimiento del usuario y una referencia a la especificación más detallada
de los requerimientos del sistema. También se puede incluir información sobre
quién propuso el requerimiento (la fuente del requerimiento), de modo que se sepa
a quién consultar si se tiene que cambiar el requerimiento.
2. Utilizar el lenguaje de forma consistente. Siempre debe distinguir entre los
requerimientos deseables y los obligatorios. Los requerimientos obligatorios son
los requerimientos a los que el sistema debe dar soporte y normalmente se
redactan en futuro simple. Los requerimientos deseables no son fundamentales y
se redactan en futuro condicional.
3. Resaltar el texto (con negrita, cursiva o color) para distinguir las partes clave del
requerimiento.
4. Evitar, hasta donde sea posible, el uso de jerga informática. Sin embargo,
inevitablemente se incluirán términos técnicos detallados en los requerimientos del
usuario.
Los Robertson (Roberton y Robertson, 1999), en su libro que estudia el método de

ingeniería de requerimientos VOLERE, recomiendan que los requerimientos del usuario
sean redactados inicialmente en tarjetas, un requerimiento por tarjeta. Sugieren varios
campos en cada tarjeta, como el fundamento de los requerimientos, las dependencias con
otros requerimientos, la fuente de los requerimientos, el material de apoyo, etcétera.
Requerimientos del Sistema
Los requerimientos del sistema son versiones extendidas de los requerimientos del
usuario que son utilizados por los ingenieros de software como punto de partida para el
diseño del sistema. Agregan detalle y explican cómo el sistema debe proporcionar los
requerimientos del usuario. Pueden ser utilizados como parte del contrato para la
implementación del sistema y, por lo tanto, deben ser una especificación completa y
consistente del sistema entero.
En teoría, los requerimientos del sistema simplemente deben describir el comportamiento

externo del sistema y sus restricciones operativas. No deben tratar de cómo se debe
diseñar o implementar el sistema. Sin embargo, en el nivel de detalle requerido para
especificar completamente un sistema software complejo, es imposible, en la práctica,
excluir toda la información de diseño. Existen varias razones para esto:
1. Puede tener que diseñar una arquitectura inicial del sistema para ayudar a
estructurar la especificación de requerimientos. Los requerimientos del sistema se
organizan conforme a los diferentes subsistemas que componen el sistema. Como
se expone en los Capítulos 7 y 18, esta definición arquitectónica es esencial si
quiere reutilizar componentes software cuando implementa el sistema.
2. En muchos casos, los sistemas deben interoperar con otros ya existentes. Esto
restringe el diseño, y estas restricciones imponen requerimientos en el sistema
nuevo.
3. Es necesario el uso de una arquitectura específica para satisfacer los
27
requerimientos no funcionales. Un regulador externo que necesita certificar que el

sistema es seguro puede especificar que un diseño arquitectónico que ya ha sido
certificado sea utilizado.
A menudo se utiliza el lenguaje natural para redactar, además de los requerimientos del
usuario, las especificaciones de requerimientos del sistema. Sin embargo, debido a que
los requerimientos del sistema son más detallados que los requerimientos del usuario, las
especificaciones en lenguaje natural pueden ser confusas y difíciles de entender:
1. La comprensión del lenguaje natural depende de que los lectores y redactores de

la especificación utilicen las mismas palabras para el mismo concepto. Esto
conduce a malas interpretaciones debido a la ambigüedad del lenguaje natural.
Jackson (Jackson,1995) da un excelente ejemplo de esto cuando analiza las
señales mostradas en una escalera mecánica. Éstas indican «Se deben utilizar
zapatos» y «Los perros deben cargarse». Se dejan al lector las diferentes
interpretaciones de estas frases.
2. Una especificación de requerimientos en lenguaje natural es demasiado flexible.
Puede decir lo mismo de formas completamente diferentes. Se deja al lector
decidir cuándo los requerimientos son los mismos y cuándo diferentes.
3. No existe una forma fácil de modularizar los requerimientos en lenguaje natural.
Puede ser difícil encontrar todos los requerimientos relacionados. Para descubrir la
consecuencia de un cambio, puede ser necesario mirar todos los requerimientos
en vez desólo un grupo de requerimientos relacionados.
Debido a estos problemas, las especificaciones de requerimientos redactadas en lenguaje

natural son propensas a malas interpretaciones. A menudo éstas no se descubren hasta
las fases posteriores del proceso del software, y resolverlas puede resultar muy costoso.
El Documento de Requerimientos del Software
Varias organizaciones grandes, como el Departamento de Defensa de los Estados Unidos

y el IEEE, han definido estándares para los documentos de requerimientos. Davis (Davis,
1993) analiza algunos de estos estándares y compara sus contenidos. El estándar más
ampliamente conocido es el IEEE/ANSÍ 830-1998 (IEEE, 1998). Este estándar IEEE
sugiere la siguiente estructura para los documentos de requerimientos:
1. Introducción
1.1 Propósito del documento de requerimientos
1.2 Alcance del producto
1.3 Definiciones, acrónicos y abreviaturas
1.4 Referencias
1.5 Descripción del resto del documento
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones generales
2.5 Suposiciones y dependencias
3. Requerimientos específicos: incluyen los requerimientos funcionales, no
funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del
documento, pero debido a la amplia variabilidad en la práctica organizacional, no
es apropiado definir una estructura estándar para esta sección. Los requerimientos
pueden documentar las interfaces externas, describir la funcionalidad y el
rendimiento del sistema, especificar los requerimientos lógicos de la base de
datos, las restricciones de diseño, las propiedades emergentes del sistema y las
características de calidad.
4. Apéndices
5. Índice
28
Aunque el estándar IEEE no es ideal, contiene muchos consejos sobre cómo redactar los
requerimientos y cómo evitar problemas. Es muy general para que pueda ser un estándar
de una organización. Es un marco general que se puede transformar y adaptar para definir
un estándar ajustado a las necesidades de una organización en particular.
Por supuesto, la información que se incluya en un documento de requerimientos debe

depender del tipo de software a desarrollar y del enfoque de desarrollo que se utilice. Si se
adopta un enfoque evolutivo para un producto de software (por ejemplo), el documento de
requerimientos dejará fuera muchos de los capítulos detallados sugeridos anteriormente.
El interés estará en definir los requerimientos del usuario y los requerimientos del sistema
no funcionales de alto nivel. En este caso, los diseñadores y programadores utilizan su
juicio para decidir cómo satisfacer el esquema de los requerimientos del usuario para el
sistema.
El documento de requerimientos es fundamental cuando un contratista exterior está

desarrollando el sistema software. Sin embargo, los métodos de desarrollo ágiles
sostienen que los requerimientos cambian tan rápidamente que un documento de
requerimientos se queda desfasado en cuanto se redacta, por lo que el esfuerzo en gran
parte se malgasta. Más que un documento formal, enfoques como la programación
extrema (Beck, 1999) proponen que los requerimientos del usuario deberían ser recogidos
incrementalmente y escritos en tarjetas. El usuario entonces da prioridad a los
requerimientos que se han de implementar en el siguiente incremento del sistema.
Para sistemas de negocio donde los requerimientos son inestables, pienso que este
enfoque es bueno. Sin embargo, argumentaría que todavía es útil redactar un breve
documento de soporte que defina el negocio y los requerimientos de confiabilidad del
sistema. Es fácil olvidarse de los requerimientos que se aplican al sistema en su totalidad
al centrarse en los requerimientos funcionales para la siguiente entrega del sistema.
29
PRIMERA UNIDAD
Tema Nº 4: Gestión del Proyecto de Requerimientos

Introducción
El objetivo de la planificación del proyecto de software es proporcionar un marco de

trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y
planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo
limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente a
medida que progresa el proyecto. Además, las estimaciones deberían definir los
escenarios del “mejor caso” y “peor caso” de forma que los resultados del proyecto puedan
limitarse. El objetivo de la planificación se logra mediante un proceso de descubrimiento
de la información que lleve a estimaciones razonables. En las secciones siguientes, se
estudian cada una de las actividades asociadas a la planificación del proyecto de software.
Ámbito del Software
La primera actividad de la planificación del proyecto de software es determinar el ámbito

del software. Se deben evaluar la función y el rendimiento que se asignaron al software
durante la fase de requerimientos. Para establecer un ámbito de proyecto que no sea
ambiguo, ni incomprensible para directivos y técnicos. Se debe delimitar la declaración del
ámbito del software. El ámbito del software describe el control y los datos a procesar,
la función, el rendimiento, las restricciones, las interfaces y la fiabilidad. Se evalúan las
funciones descritas en la declaración del ámbito, y en algunos casos se refinan para dar
más detalles antes del comienzo de la estimación. Dado que las estimaciones del coste y
de la planificación temporal están orientadas a la función, muchas veces es útil llegar a
un cierto grado de descomposición. Las consideraciones de rendimiento abarcan los
requisitos de tiempo de respuesta y de procesamiento. Las restricciones identifican los
límites del software originados por el hardware externo, por la memoria disponible y por
otros sistemas existentes.
Al principio de un proyecto de software las cosas siempre están un poco borrosas. Se ha

definido una necesidad y se han enunciado las metas y objetivos básicos, pero todavía no
se ha establecido la información necesaria para definir el ámbito (prerrequisito para la
estimación). La técnica utilizada con más frecuencia para acercar al cliente y al
desarrollador, y para hacer que comience el proceso de comunicación es establecer una
reunión o una entrevista preliminar. La primera reunión entre un ingeniero de software (el
analista) y el cliente puede compararse a la primera cita entre adolescentes. Ninguna
persona sabe lo que decir o preguntar; ambos están preocupados por si lo que dicen es
mal interpretado; ambos están pensando hasta dónde podrían llegar (probablemente los
dos tienen aquí diferentes expectativas); ambos quieren quitárselo pronto de encima; pero
al mismo tiempo quieren que salga bien.
Sin embargo, se debe iniciar la comunicación. El analista debe comenzar haciendo

preguntas de contexto libre. Es decir, una serie de preguntas que lleven a un
entendimiento básico del problema, las personas que están interesadas en la solución, la
naturaleza de la solución que se desea y la efectividad prevista del primer encuentro.
El primer conjunto de cuestiones de contexto libre se centran en el cliente, en los objetivos

globales y en los beneficios. Por ejemplo, el analista podría preguntar:
• ¿Quién está detrás de la solicitud de este trabajo?

• ¿Quién utilizará la solución?
• ¿Cuál será el beneficio económico de una buena solución?
• ¿Hay otro camino para la solución?
30
Las preguntas siguientes permiten que el analista comprenda mejor el problema y que el
cliente exprese sus percepciones sobre una solución:
• ¿Cómo caracterizaría [el cliente] un resultado «correcto» que se generaría con

una solución satisfactoria?
• ¿Con qué problema(s) se afrontará esta solución?
• ¿Puede mostrarme (o describirme) el entorno en el que se utilizará la solución?
• ¿Hay aspectos o limitaciones especiales de rendimiento que afecten a la forma en
que se aborde la solución?
La última serie de preguntas se centra en la efectividad de la reunión.
• ¿Es usted la persona apropiada para responder a estas preguntas?

• ¿Son «oficiales» sus respuestas?
• ¿Son relevantes mis preguntas para su problema?
• ¿Estoy realizando muchas preguntas?
• ¿Hay alguien más que pueda proporcionar información adicional?
• ¿Hay algo más que debiera preguntarle?
Estas preguntas (y otras) ayudarán a «romper el hielo» y a iniciar la comunicación esencial

para establecer el ámbito del proyecto. Sin embargo, una reunión basada en preguntas y
respuestas no es un enfoque que haya tenido un éxito abrumador. En realidad, la sesión
P&R sólo se debería utilizar para el primer encuentro, reemplazándose posteriormente por
un tipo de reunión que combine elementos de resolución de problemas, negociación y
especificación.
Los clientes y los ingenieros de software con frecuencia tienen establecido

inconscientemente el pensamiento de «nosotros y ellos». En lugar de trabajar como un
equipo para identificar y refinar los requisitos, cada uno define su propio «territorio» y se
comunica por medio de memorandos, documentos formales de situación, sesiones de
preguntas y respuestas e informes. La historia ha demostrado que este enfoque es muy
pobre. Abundan los malentendidos, se omite información importante y nunca se establece
una relación de trabajo con éxito.
Una vez se ha identificado el ámbito (con la ayuda del cliente), es razonable preguntarse:
«¿Podemos construir el software de acuerdo a este ámbito? ¿Es factible el proyecto?».
Con frecuencia, las prisas de los ingenieros de software sobrepasan estas preguntas (o
están obligados a pasarlas por los clientes o gestores impacientes), solo se tienen en
cuenta en un proyecto condenado desde el comienzo.
Los proyectos de los que no se tiene experiencia no son fáciles. Un equipo puede pasarse
varios meses descubriendo cuáles son los requisitos principales, y cuáles son aquéllos
difíciles de implementar para una nueva aplicación. ¿Podría ocurrir que alguno de estos
requerimientos presentara algunos riesgos que hicieran inviable el proyecto? ¿Podrían
superarse estos riesgos? El equipo de factibilidad debe asumir la arquitectura y el diseño
de los requerimientos de alto riesgo hasta el punto de poder responder todas estas
preguntas. En algunos casos, cuando el equipo proporciona respuestas negativas, esto
puede negociarse con una reducción de los requisitos.
Mientras tanto, los altos ejecutivos están repicando sus dedos en la mesa. A menudo,
mueven sus cigarros de forma elegante, pero de forma impaciente y rodeados de humo
exclaman ¡Ya es suficiente! ¡Hazlo!. Muchos de estos proyectos que se han aprobado de
esta forma aparecen a los pocos años en la prensa como proyectos defectuosos.
El estudio de viabilidad es importante, pero las necesidades de la gestión son incluso más
importantes. No es bueno construir un producto o sistema de alta tecnología que en
realidad nadie quiera.
31
Recursos
La segunda tarea de la planificación del desarrollo de software es la estimación de los

recursos requeridos para acometer el esfuerzo de desarrollo de software. La figura
siguiente ilustra los recursos de desarrollo en forma de pirámide.
En la base de la pirámide de recursos se encuentra el entorno de desarrollo herramientas

de hardware y software que proporciona la infraestructura de soporte al esfuerzo de
desarrollo. En un nivel más alto se encuentran los componentes de software reutilizables
–los bloques de software que pueden reducir drásticamente los costes de desarrollo y
acelerar la entrega-. En la parte más alta de la pirámide está el recurso primario -el
personal-. Cada recurso queda especificado mediante cuatro características: descripción
del recurso, informe de disponibilidad, fecha cronológica en la que se requiere el recurso,
tiempo durante el que será aplicado el recurso. Las dos últimas características pueden
verse como una ventana temporal. La disponibilidad del recurso para una ventana
específica tiene que establecerse lo más pronto posible.
Recursos humanos
El encargado de la planificación comienza elevando el ámbito y seleccionando las
habilidades que se requieren para llevar a cabo el desarrollo. Hay que especificar tanto la
posición dentro de la organización (por ejemplo: gestor, ingeniero de software
experimentado, etc.) como la especialidad (por ejemplo: telecomunicaciones, bases de
datos, cliente/servidor). Para proyectos relativamente pequeños (una persona-año o
menos) una sola persona puede llevar a cabo todos los pasos de ingeniería del software,
consultando con especialistas siempre que sea necesario. El número de personas
requerido para un proyecto de software sólo puede ser determinado después de hacer una
estimación del esfuerzo de desarrollo (por ejemplo, personas-mes). Estas técnicas de
estimación del esfuerzo se estudiarán después.
Recursos de software reutilizables

La ingeniería del software basada en componentes destaca la reutilización esto es, la
creación y la reutilización de bloques de construcción de software. Dichos bloques de
construcción, Ilamados componentes, deben establecerse en catálogos para una consulta
más fácil, estandarizarse para una fácil aplicación y validarse para una fácil integración.
Deberían ser consideradas las directrices siguientes por el planificador de software cuando
los componentes reutilizables se especifiquen como recurso:
1. Si los componentes ya desarrollados cumplen los requisitos del proyecto, adquiéralos.

El coste de la adquisición y de la integración de los componentes ya desarrollados
serán casi siempre menores que el coste para desarrollar el software equivalente6.
Además, el riesgo es relativamente bajo.
32
2. Si se dispone de componentes ya experimentados, los riesgos asociados a la

modificación y a la integración generalmente se aceptan. El plan del proyecto debería
reflejar la utilización de estos componentes.
3. Si se dispone de componentes de experiencia parcial para el proyecto actual, su uso
se debe analizar con detalle. Si antes de que se integren adecuadamente los
componentes con otros elementos del software se requiere una gran modificación,
proceda cuidadosamente. El coste de modificar los componentes de experiencia
parcial algunas veces puede ser mayor que el coste de desarrollar componentes
nuevos.
Recursos de entorno
El entorno incorpora hardware y software. El hardware proporciona una plataforma con
las herramientas (software) requeridas para producir los productos que son el resultado de
una buena práctica de la ingeniería del software. Como la mayoría de las organizaciones
de software tienen muchos aspectos que requieren acceso a E/S, un planificador de
proyecto debe determinar la ventana temporal requerida para el hardware y el software, y
verificar que estos recursos estarán disponibles.
Cuando se va a desarrollar un sistema basado en computadora (que incorpora hardware y

software especializado), el equipo de software puede requerir acceso a los elementos en
desarrollo por otros equipos de ingeniería.
Comprensión del ámbito del proyecto
Casi todos los proyectos se planifican e implementan en un contexto social, económico y

ambiental y tienen impactos positivos y negativos deseados y/o no deseados. El equipo
del proyecto debe considerar el proyecto en el contexto de su entorno cultural, social,
internacional, político y físico.
• Entorno cultural y social. El equipo tiene que entender cómo afecta el proyecto a las
personas y cómo afectan las personas al proyecto. Esto puede requerir una
comprensión de los aspectos económicos, demográficos, educativos, éticos, étnicos,
religiosos, y de otras características de las personas a quienes afecta el proyecto o
que puedan tener un interés en éste. El director del proyecto también debe examinar
la cultura de la organización y determinar si se reconoce que la dirección de proyectos
desempeña un rol válido con responsabilidad y autoridad para gestionar el proyecto.
• Entorno internacional y político. Es posible que algunos miembros del equipo tengan
que estar familiarizados con las leyes y costumbres internacionales, nacionales,
regionales y locales aplicables, así como con el clima político que podría afectar al
proyecto. Otros factores internacionales a tener en cuenta son las diferencias de
husos horarios, los días festivos nacionales y regionales, los requisitos de viaje para
reuniones cara a cara y la logística de teleconferencias.
• Entorno físico. Si el proyecto va a afectar a su ámbito físico, algunos miembros del
equipo deberán estar familiarizados con la ecología local y la geografía física que
podrían afectar al proyecto o ser afectadas por el proyecto.
Conocimientos y habilidades de dirección general
La dirección general comprende la planificación, organización, selección de personal,

ejecución y control de las operaciones de una empresa en funcionamiento. Incluye
disciplinas de respaldo como por ejemplo:
• Gestión financiera y contabilidad

• Compras y adquisiciones
• Ventas y comercialización
• Contratos
• Logística y cadena de suministro
• Planificación estratégica, planificación táctica y planificación operativa
• Estructuras y comportamiento de la organización, administración de personal,
compensaciones, beneficios y planes de carrera
33
La dirección general proporciona los fundamentos para desarrollar habilidades de

dirección de proyectos y a menudo es esencial para el director del proyecto. En cualquier
proyecto, es posible que se requieran habilidades relativas a una gran cantidad de temas
generales de dirección. La bibliografía sobre dirección general documenta estas
habilidades y su aplicación es esencialmente igual en un proyecto.
Habilidades interpersonales
La gestión de las relaciones interpersonales incluye:
• Comunicación efectiva. Intercambio de información

• Influencia en la organización. Capacidad para “lograr que las cosas se hagan”
• Liderazgo. Desarrollar una visión y una estrategia, y motivar a las personas a lograr
esa visión y estrategia
• Motivación. Estimular a las personas para que alcancen altos niveles de rendimiento y
superen los obstáculos al cambio
• Negociación y gestión de conflictos. Consultar con los demás para ponerse de
acuerdo o llegar a acuerdos con ellos
• Resolución de problemas. Combinación de definición de problemas, identificación y
análisis de alternativas, y toma de decisiones.
Oficina de Gestión de Proyectos
Una oficina de gestión de proyectos (PMO) es una unidad de la organización para

centralizar y coordinar la dirección de proyectos a su cargo. Una PMO también puede
denominarse “oficina de gestión de programas”, “oficina del proyecto” u “oficina del
programa”. Una PMO supervisa la dirección de proyectos, programas o una combinación
de ambos. Es posible que la única relación entre los proyectos respaldados o
administrados por la PMO sea que son dirigidos al mismo tiempo. Sin embargo, algunas
PMO coordinan y dirigen proyectos relacionados. En muchas organizaciones, esos
proyectos están agrupados o relacionados de alguna forma, de acuerdo con la manera en
que la PMO vaya a coordinar y dirigir esos proyectos. La PMO pone el énfasis en la
planificación coordinada, la priorización y la ejecución de proyectos y subproyectos
vinculados con los objetivos de negocio generales de la organización matriz o del cliente.
Las PMO pueden operar con continuidad en aspectos que van desde proporcionar las
funciones de respaldo para la dirección de proyectos bajo la forma de formación, software,
políticas estandarizadas y procedimientos, hasta la dirección y responsabilidad directas en
sí mismas para lograr los objetivos del proyecto. Se puede delegar a una PMO específica
la autoridad para actuar como interesada integral y estar encargada de tomar decisiones
clave durante la etapa de iniciación de cada proyecto; también puede estar autorizada
para hacer recomendaciones o concluir proyectos a fin de ser congruente con sus
objetivos de negocio. Además, la PMO puede participar en la selección, dirección y
reubicación, si fuera necesario, del personal compartido de los proyectos y, si es posible,
del personal dedicado de los proyectos.
Ciclo de vida del proyecto.
Para facilitar la gestión, los directores de proyectos o la organización pueden dividir los
proyectos en fases, con los enlaces correspondientes a las operaciones de la organización
ejecutante. El conjunto de estas fases se conoce como ciclo de vida del proyecto. Muchas
organizaciones identifican un conjunto de ciclos de vida específico para usarlo en todos
sus proyectos.
El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con su
fin. Por ejemplo, cuando una organización identifica una oportunidad a la cual le
interesaría responder, frecuentemente autoriza un estudio de viabilidad para decidir si se
emprenderá el proyecto. La definición del ciclo de vida del proyecto puede ayudar al
director del proyecto a determinar si deberá tratar el estudio de viabilidad como la primera
34
fase del proyecto o como un proyecto separado e independiente. Cuando el resultado de

dicho esfuerzo preliminar no sea claramente identificable, lo mejor es tratar dichos
esfuerzos como un proyecto por separado.
La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente
implica y, por lo general, está definida por alguna forma de transferencia técnica.
Generalmente, los productos entregables de una fase se revisan para verificar si están
completos, si son exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No
obstante, no es inusual que una fase comience antes de la aprobación de los productos
entregables de la fase previa, cuando los riesgos involucrados se consideran aceptables.
Esta práctica de superponer fases, que normalmente se realiza de forma secuencial, es un
ejemplo de la aplicación de la técnica de compresión del cronograma denominada
ejecución rápida.
No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal de un
proyecto. Algunas organizaciones han establecido políticas que estandarizan todos los
proyectos con un ciclo de vida único, mientras que otras permiten al equipo de dirección
del proyecto elegir el ciclo de vida más apropiado para el proyecto del equipo. Asimismo,
las prácticas comunes de la industria a menudo conducen a usar un ciclo de vida preferido
dentro de dicha industria.
Los ciclos de vida del proyecto generalmente definen:
• Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué fase se debe
realizar el trabajo del arquitecto?)
• Cuándo se deben generar los productos entregables en cada fase y cómo se revisa,
verifica y valida cada producto entregable
• Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente requiere
que los implementadores estén involucrados en las fases de requisitos y de diseño)
• Cómo controlar y aprobar cada fase.
• Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy
detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir
formularios, diagramas y listas de control para proporcionar estructura y control.
• La mayoría de los ciclos de vida de proyectos comparten determinadas características
comunes:
• En términos generales, las fases son secuenciales y, normalmente, están definidas
por alguna forma de transferencia de información técnica o transferencia de
componentes técnicos.
• El nivel de coste y de personal es bajo al comienzo, alcanza su nivel máximo en las
fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión.
35
La conclusión y la aprobación de uno o más productos entregables caracteriza a una fase

del proyecto. Un producto entregable es un producto de trabajo que se puede medir y
verificar, tal como una especificación, un informe del estudio de viabilidad, un documento
de diseño detallado o un prototipo de trabajo. Algunos productos entregables pueden
corresponder al mismo proceso de dirección de proyectos, mientras que otros son los
productos finales o componentes de los productos finales para los cuales se creó el
proyecto. Los productos entregables, y en consecuencia las fases, son parte de un
proceso generalmente secuencial, diseñado para asegurar el adecuado control del
proyecto y para obtener el producto o servicio deseado, que es el objetivo del proyecto.
Interesados en el proyecto
Los interesados en el proyecto son personas y organizaciones que participan de forma

activa en el proyecto o cuyos intereses pueden verse afectados como resultado de la
ejecución del proyecto o de su conclusión. Se les conoce también como Stakeholders.
También pueden influir sobre los objetivos y resultados del proyecto. El equipo de
dirección del proyecto debe identificar a los interesados, determinar sus requisitos y
expectativas y, en la medida de lo posible, gestionar su influencia en relación con los
requisitos para asegurar un proyecto exitoso. La siguiente figura ilustra la relación entre los
interesados y el equipo del proyecto.
36
SEGUNDA UNIDAD
Tema Nº 5: Herramientas y Técnicas de la Ingeniería de

Requerimientos
Entrevistas y cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de

personas o grupos, información que se obtiene conversando con el encuestado. Para la
realización de las entrevistas debemos coordinar previamente la fecha y hora, y debemos
realizar un plan de agenda, en el cual hacemos un punteo del objetivo de la entrevista. Por
ejemplo, en la primer entrevista estableceremos un plan de comunicación, en el cual se
intercambiarán los teléfonos, celulares, direcciones de e-mail y horarios de contacto.
Para realizar las entrevistas, conviene llevar preparado un cuestionario. En términos

generales, un cuestionario consiste en un conjunto de preguntas presentadas a una
persona para su respuesta. La forma de la pregunta puede influir en las respuestas, por lo
que hay que planearlas cuidadosamente.
Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas
abiertas permiten que los encuestados respondan con su propia terminología.
Generalmente estas son más reveladoras, ya que los interrogados no están limitados en
sus respuestas. Son especialmente útiles en la etapa exploratoria de la investigación,
cuando el AN busca penetrar en el pensamiento del encuestado.
37
A continuación se presentan algunos ejemplos de preguntas abiertas:
• ¿Cuál es la razón por la que quiere resolver este problema?

• ¿Cómo se resuelve el problema actualmente?
• ¿Cuál es el valor de una solución exitosa?
• ¿Quién usará el sistema que se va a construir?
• ¿Cómo desearía llevar a cabo esta actividad?
Por su parte, las preguntas cerradas predeterminan todas las posibles respuestas y el
interrogado elige entre las opciones presentadas. Estas preguntas las podemos utilizar
cuando estamos estableciendo el criterio de priorización de los casos de uso con el
cliente. Para cada uno preguntamos si es a corto plazo, a futuro, o Indispensable. Como
vemos, la respuesta está acotada a tres opciones. También podemos volver a utilizarla
cuando tenemos que negociar algún requerimiento con el cliente.
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 interfases
de usuario, observando el tipo de información que se maneja y cómo es manejada. Esto
puede ser útil para descubrir información importante a tener en cuenta, información que
tal vez el cliente/usuario haya fallado en comunicar.
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.
Luego de este análisis también podemos realizar una tormenta de ideas y así obtener
requerimientos sumamente interesantes. Desde mi punto de vista y, aunque requiere de
cierto grado de trabajo (investigación y análisis), la podemos realizar a priori sin que
intervenga el cliente/usuario; para ello, existen en internet cantidad de demos de productos
que pueden resultar similares y, también, podemos establecer contacto con profesionales
que desarrollan sistemas de características comparables.
Otra ventaja que presenta esta técnica es que como estos sistemas ya están en
producción, ya han pasado por la curva de aprendizaje del dominio del problema.
Entonces, cuando analizamos estos sistemas, tenemos que tratar de pensar, por ejemplo,
por qué manejan cierta información y para qué sirve, lo que resultará de suma utilidad para
nuestro cliente. También es recomendable que luego de haber analizado el sistema, se lo
mostremos al cliente/usuario, ya que por su experiencia puede sugerir importantes ideas
nuevas.
Grabaciones de Video y de Audio
Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las
entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo,
es importante por cuanto permite centrar la atención en la entrevista en sí en vez de
distraerse tomando notas de todo lo que se dice. Cuando se está grabando la
conversación, basta con "puntear" en una libreta los temas tratados para después tener
una guía básica de los temas tratados y saber en qué lugar de la grabación buscar.
Además, permite analizar los temas con más
detenimiento y con una visión más global, pues ya se ha conversado sobre todos los
puntos necesarios y se han visto los procesos ad hoc.
Cuando se trata de analizar algún proceso en particular, su ayuda es inestimable (sobre

todo las filmaciones de video) ya que permite ver y analizar en detalle ese proceso la
cantidad de veces que sea necesario. Y no olvidemos que filmando el lugar de trabajo
estamos capturando el proceso de trabajo, lo que evita que impongamos nuestras
expectativas y preferencias.
Para finalizar, mencionamos que siempre es conveniente comenzar las grabaciones con
38
preguntas poco importantes que sirvan para "relajar el ambiente", ya que el entrevistado
puede ponerse nervioso durante los primeros minutos de grabación. Debemos darle
tiempo a las personas para que se distiendan y se sientan cómodas con la idea de ser
grabados o filmados.
Brainstorming (Tormenta de Ideas)
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. Luego, se irán eliminando en base a
distintos cr iterios 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 salvajes 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.
Arqueología de Documentos
Con la aplicación de esta herramienta se tratan de determinar posibles requerimientos

sobre la base de inspeccionar la documentación utilizada por la empresa; por ejemplo,
boletas, facturas, remitos, etc. Esta herramienta sirve más que nada como complemento
de las demás técnicas, y nos ayuda a obtener información que de otra manera sería
sumamente difícil conseguir. Por ejemplo, en las facturas podemos encontrar información
que no se pensaba manejar y que en definitiva resulta de suma utilidad, como un número
propio de la empresa que se utliza para saber el orden que tiene la factura en la carpeta y
que permite encontrar las copias del documento con mayor rapidez. En definitiva, se debe
recolectar cualquier formulario o documento que sea utilizado para registrar o enviar
información.
Para el análisis de cada uno de estos documentos, debemos realizar algunas preguntas,
como:
• ¿Cuál es el propósito de este documento?

• ¿Quién lo usa? ¿Por qué? ¿Para qué?
• ¿Cuáles son las tareas que realizan con este documento?
• ¿Se puede encontrar una relación entre los documentos?
• ¿Cuál es el proceso que realiza la conexión?
• ¿Cuál es el documento que da más problemas a los usuarios?
Aprendiz
Esta herramienta se basa en la idea del maestro y el aprendiz, y es una buena forma de
observar el trabajo real. Aquí, el aprendiz es representado por el alumno, y el
usuario/cliente cumple el rol de maestro. El aprendiz se sienta con el maestro a aprender
por medio de la observación, haciendo preguntas como ¿por qué hizo eso? y ¿qué
significa eso?, y también realizando algún trabajo bajo la supervisión del maestro. Esta
técnica puede ser combinada con la herramienta de modelo conceptual. A medida que el
trabajo es observado y explicado, el alumno puede realizar bosquejos para cada una de
las tareas realizadas, y también puede bosquejar como se conectan por medio de los
39
distintos flujos de datos. La aplicación de esta herramienta es muy útil, ya que a veces es
difícil para el cliente/usuario el explicar cómo realiza su trabajo. Es también una técnica
apropiada para un proyecto donde el problema no es estructurado, ya que es una de las
mejores formas de obtener el conocimiento que se encuentra en la "cabeza" del cliente.
Una de las posibles objeciones que se le pueden hacer a esta herramienta es que su
implementación requiere de mucho tiempo.
Observación
Es sumamente difícil describir cómo hacer el nudo de un calzado deportivo, pero es

sumamente fácil mostrar los pasos para hacerlo. Observar cómo se hacen las cosas es
una buena manera de entender lo que estas requieren. Conectarse íntimamente con la
cultura de la organización, vivirla, es una herramienta que debe ser tomada en cuenta.
También podemos realizar filmaciones del lugar de trabajo, para luego observarlas y
analizarlas, buscando patrones, procesos, problemas, etc. Siempre tenemos que estar
atentos a lo que sucede en el entorno de la organización; por ejemplo, ver cómo resuelven
un problema que surge, como un llamado telefónico que puede ocurrir mientras estamos
presentes. Dentro de la estrategia de observar tenem os que tratar de buscar estructuras
y patrones. La estructura del trabajo para los usuarios suele ser invisible, por lo que será
nuestro trabajo realizar las abstracciones necesarias.
Run Use Case WorkShop (Talleres de Trabajo basados en los Casos de Uso)
Estos talleres de trabajo se realizan entre el cliente/usuario y el equipo de requerimientos.

La primer parte del WorkShop consiste en generar los escenarios. Para esto se necesita la
información que tiene para brindar el usuario/cliente. La idea es conversar por medio de
los casos de uso y extraer de los usuarios las cosas esenciales que suceden cuando
ocurre un evento determinado. Así, tratamos de definir la serie de usuarios y reconocer
los pasos que se realizan para el caso de uso en estudio. Luego preguntamos si los pasos
registrados están bien o si hay que cambiarlos o mejorarlos. Como resultado de este
proceso obtenemos un excelente bosquejo del caso de uso. Una vez finalizada la etapa
anterior, el equipo de requerimientos retorna a la oficina a especificar y deducir los
requerimientos, a partir del conocimiento previamente adquirido.
Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que algunos

requerimientos no estén demasiado claros o que no estemos muy seguros 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 en base a los
requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y
efectiva.
Los prototipos se pueden clasificar en:
a. Prototipo evolutivo
Por ejemplo, cuando el usuario no puede o no está dispuesto a articular sus
requerimientos de ninguna forma, sólo se podrán determinar mediante un proceso de
ensayo y error. Así se van realizando evoluciones sobre la base del mismo prototipo
hasta determinar claramente los requerimientos.
b. Prototipo Bosquejado
Para realizar esta clase de prototipo nos apoyamos, por un lado, en el rol del analista
de requerimientos (AN), simulando las respuestas del sistema y realizando bosquejos
de las interfases de usuario; y, por otro, el usuario, que es quien realiza las entradas
("utiliza el prototipo"). También podemos llevar el caso de uso y bosquejar la interfase
de usuario y, mediante el diálogo, manejamos la interactividad entre el usuario y el
40
sistema. Una de las ventajas más importantes es el poco esfuerzo que realizamos
para aplicar los cambios. Como desventaja podemos mencionar que si bien
capturamos la idea, el usuario no percibe como será realmente el diálogo hombre-
máquina, sobre todo si existe un requerimiento no funcional como el de usabilidad.
c. Prototipo Tangible/Usable
Los términos tangible y usable se refieren a desarrollar una aplicación (software) que
el usuario pueda utilizar, es decir, con la cual pueda interactuar como si fuera la
aplicación final. Cualquiera sea la herramienta de software, que elijamos utilizar, para
desarrollar el prototipo, debemos recordar los siguientes puntos:
• Debe demandar poco esfuerzo para realizar los cambios

• Debe poseer amplia flexibilidad para el manejo de las interfases de usuario.
• Debe consumir poco tiempo para generar un nuevo prototipo (maqueta).
Cabe remarcar que tenemos que dejar bien en claro al usuario/cliente que se trata de un
prototipo y que no es el producto final; para explicar esta diferencia podemos hacer una
analogía con las maquetas de los arquitectos. El prototipo tangible/usable también resulta
de suma utilidad cuando nos encontramos frente a un requerimiento no funcional de
usabilidad, más precisamente, el de facilidad de uso.
Entre las deventajas más importantes de los prototipos que podemos mencionar, se
encuentran:
• Costo de entrenamiento/capacitación en la herramienta
• Costo de realizar el prototipo.
• Problema de calendario.
• Incompletitud (puede confundir a los usuarios, haciendolos pensar que el producto
final quedará como el prototipo, incompleto).
Modelo de Clase Conceptual | Diagrama Conceptual | Diagrama de Clases Conceptual
Un modelo conceptual es una representación de conceptos del dominio del problema.

[Fowler96]. Permite mostrar conceptos, asociaciones entre conceptos y atributos de
conceptos. La creación del modelo también ayuda a comprender la terminología del
dominio y comunica cuáles son los términos importantes y las relaciones existentes entre
ellos.
Concepto: categoría de idea o cosas. La intención del concepto es la descripción de sus

atributos, operaciones y significado. Para representar un concepto podemos basarnos en
la metodología orientada a objetos, utilizando las clases como forma de representar el
concepto, dado que una clase representa un concepto del dominio del problema que
abarca un amplio espectro, como un pedido, una máquina, una tarea, un trabajo, etc.
Esta herramienta puede ser utilizada para capturar el vocabulario del sistema que se está
desarrollando. Mediante ella podemos incluir abstracciones que forman parte del dominio.
Para especificar el modelo conceptual utilizamos el diagrama de clases en el cual

mostramos las relaciones existentes entre las clases. Es decir, mostramos los conceptos
que se manejan en el negocio y como se relacionan entre sí.
Es una buena forma para obtener un idea general de cómo funciona el negocio (relaciones
entre las clases/concepto), y capturar vocabulario y conceptos (clase). También es de
ayuda para incluir nuevos conceptos al glosario.
Glosario
El glosario es una simple lista de términos en donde se explica su significado. En esta lista
se incluyen y definen todos los términos que requieren explicación, mejorando así la
comunicación intergrupal y la ocmunicación con el cliente, y mitigando el riesgo de malos
entendidos. Los términos que se incluyen provienen de todas las áreas del proyecto:
41
casos de uso, terminología propia del negocio, etc. El glosario se va actualizando durante
el transcurso del proceso de IR, perfeccionándolo en cada nuevo ciclo.
Diagrama de actividad
Para representar un proceso de negocio podemos utlizar otra de las herramientas que nos
proporciona el UML, que es el diagrama de actividad. El diagrama de actividad o diagrama
de proceso, se asemeja a un mapa de procedimientos, mostrando el flujo de actividades:
se toman decisiones (bifurcaciones) de acuerdo a las condiciones (condición de guarda),
para luego pasar a la siguiente actividad o estado (transición). Este modelo también
permite representar actividades que ocurren en paralelo, o aquellos casos en los que una
única actividad desencadena más de una tarea (división de control), o cuando se unen dos
o más actividades para formar una tercera (unión de control).
Documento ESRE | Casos de uso
El objetivo del documento ESRE (Documento de Especificación de Requerimientos) es el

de especificar los requerimientos del sistema, o sea "qué" debe hacer el sistema.
Solamente se incluyen los requerimientos del producto. Estos requerimientos los podemos
clasificar en dos grandes categorías, los no-funcionales y los funcionales. Los no-
funcionales definen las caracteristícas que indican cómo el sistema debe realizar su
trabajo; por ejemplo, eficiencia, hardware necesario, software, etc.
Por su parte, los requerimientos funcionales definen qué hace el sistema; básicamente
describen todas las entradas y salidas, y las relaciones respectivas, relaciones que el
sistema debe manejar. Resumiendo, y como el nombre lo indica, los requerimientos
funcionales describen las funciones del sistema.
En este documento debemos colocar la lista de requerimientos con las respectivas

referencias a los documentos de todos los casos de uso que satifacen los requerimientos.
Casos de uso
El caso de uso es un documento narrativo que describe la secuencia de eventos de un

actor (agente externo) que utiliza un sistema para completar un proceso. Es una técnica
diseñada para especificar el comportamiento de un sistema. Este documento describe 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. No es una simple historia específica de
eventos específicos intercambiados entre el sistema y los actores o escenario, sino que es
una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un
evento inicial desde un actor hacia el sistema. Los requerimientos se pueden expresar de
diferentes formas, desde texto sin formato estricto hasta expresiones en un lenguaje
formal, pasando por todas las formas intermedias. La mayoria de los requerimientos
funcionales, sino todos, se pueden expresar con casos de uso.
Checklist (Lista de Verificación)
Esta herramienta es muy fácil de utilizar y proporciona una gran utilidad. En general es
una lista de preguntas que se debe usar para evaluar cada requerimiento. Se verifica y
marca los puntos de esta lista mientras leen el documento de requerimientos. Cuando se
descubren problemas potenciales, deben ser anotados, ya sea en los márgenes del
documento, ya sea en una lista de análisis. Las checklist son útiles porque brindan un
recordatorio de lo que se debe buscar y reducen las chances de pasar por alto alguna
verificación importante. Y no sólo son útiles para verificar requerimientos; también se
puede aplicar con los casos de uso y con los puntos a ser tratados en el plan de agenda.
Este análisis se puede implementar con una hoja de cálculo en donde las filas
representan, por ejemplo, los distintos requerimientos, y las columnas representan los
puntos a verificar (el contenido de la checklist).
42
SEGUNDA UNIDAD
Tema Nº 6: Especificación de Requerimientos
El Cambio en los Requerimientos
Los requerimientos para sistemas software grandes son siempre cambiantes. Una razón
es que estos sistemas normalmente se desarrollan para abordar problemas «traviesos».
Debido a que el problema no puede definirse completamente, es muy probable que los
requerimientos del software sean incompletos. Durante el proceso del software, la
comprensión del problema por parte de los stakeholders está cambiando constantemente.
Estos requerimientos deben entonces evolucionar para reflejar esta perspectiva cambiante
del problema. Además, una vez que un sistema se ha instalado, inevitablemente surgen
nuevos requerimientos. Es difícil para los usuarios y clientes del sistema anticipar qué
efectos tendrá el sistema nuevo en la organización. Cuando los usuarios finales tienen
experiencia con un sistema, descubren nuevas necesidades y prioridades:
1. Normalmente, los sistemas grandes tienen una comunidad de usuarios diversa

donde los usuarios tienen diferentes requerimientos y prioridades. Éstos pueden
contradecirse o estar en conflicto. Los requerimientos finales del sistema son
inevitablemente un compromiso entre ellos y, con la experiencia, a menudo se
descubre que la ayuda suministrada a los diferentes usuarios tiene que cambiarse.
2. Las personas que pagan por el sistema y los usuarios de éste raramente son la
misma persona. Los clientes del sistema imponen requerimientos debido a las
restricciones organizacionales y de presupuesto. Éstos pueden estar en conflicto
con los requerimientos de las usuarios finales y, después de la entrega, pueden
tener que añadirse nuevas características de apoyo al usuario si el sistema tiene
que cumplir sus objetivos.
3. El entorno de negocios y técnico del sistema cambia después de la instalación, y
estos cambios se deben reflejar en el sistema. Se puede introducir nuevo
hardware, puede ser necesario que el sistema interactúe con otros sistemas, las
prioridades de negocio pueden cambiar con modificaciones consecuentes en la
ayuda al sistema, y puede haber una nueva legislación y regulaciones que deben
ser implementadas por el sistema.
La gestión de requerimientos es el proceso de comprender y controlar los cambios en los

requerimientos del sistema. Es necesario mantenerse al tanto de los requerimientos
particulares y mantener vínculos entre los requerimientos dependientes de forma que se
pueda evaluar el impacto de los cambios en los requerimientos. Hay que establecer un
proceso formal para implementar las propuestas de cambios y vincular éstos a los
requerimientos del sistema. El proceso de gestión de requerimientos debería empezar en
cuanto esté disponible una versión preliminar del documento de requerimientos, pero se
debería empezar a planificar cómo gestionar los requerimientos que cambian durante el
proceso de obtención de requerimientos.
Requerimientos Duraderos y Volátiles
La evolución de los requerimientos durante el proceso de ingeniería de requerimientos y

después de que un sistema esté en uso es inevitable. El desarrollo de requerimientos
software centra su atención en las capacidades de éste, los objetivos del negocio y otros
sistemas de la organización. Conforme se va desarrollando la definición de los
requerimientos, normalmente tiene una mejor comprensión de las necesidades de los
usuarios. Esto retroalimenta la información del usuario, quien puede entonces proponer un
cambio en los requerimientos. Además, especificar y desarrollar un sistema grande puede
llevar varios años. Durante ese tiempo, el entorno del sistema y los objetivos del negocio
cambian, y los requerimientos evolucionan para reflejar esto.
43
Desde una perspectiva evolutiva, los requerimientos se dividen en dos clases:
1. Requerimientos duraderos. Son requerimientos relativamente estables que se derivan

de la actividad principal de la organización y que están relacionados directamente con
el dominio del sistema. Por ejemplo, en un hospital siempre habrá requerimientos que
se refieren a los pacientes, médicos, enfermeras y tratamientos. Estos requerimientos
se pueden derivar de los modelos del dominio que muestran las entidades y relaciones
que caracterizan un dominio de aplicación (Easterbrook, 1993; Prieto-Díaz y Arango,
1991).
2. Requerimientos volátiles. Son requerimientos que probablemente cambian durante el
proceso de desarrollo del sistema o después de que éste se haya puesto en
funcionamiento. Un ejemplo serían los requerimientos resultantes de las políticas
gubernamentales sobre sanidad. Harker y otros (Harker et al., 1993) han indicado que
los requerimientos volátiles se dividen en cinco clases.
Planificación de la Gestión de Requerimientos
La planificación es una primera etapa esencial del proceso de gestión de requerimientos.

La gestión de requerimientos tiene un coste elevado. Para cada proyecto, la etapa de
planificación establece el nivel de detalle necesario en la gestión de requerimientos.
Durante la etapa de gestión de requerimientos, habrá que decidir sobre:
1 La identificación de requerimientos. Cada requerimiento se debe identificar de forma

única de tal forma que puedan ser remitidos por otros requerimientos de manera que
pueda utilizarse en las evaluaciones de rastreo.
2 Un proceso de gestión del cambio. Éste es el conjunto de actividades que evalúan el
impacto y coste de los cambios.
3 Políticas de rastreo. Estas políticas definen las relaciones entre los requerimientos, y
entre éstos y el diseño del sistema que se debe registrar y la manera en que estos
registros se deben mantener.
4 Ayuda de herramientas CASE. La gestión de requerimientos comprende el
procesamiento de grandes cantidades de información sobre los requerimientos. Las
herramientas que se pueden utilizar van desde sistemas de gestión de requerimientos
especializados hasta hojas de cálculo y sistemas sencillos de bases de datos.
Existen muchas relaciones entre los requerimientos y entre éstos y el diseño del sistema.
También existen vínculos entre los requerimientos y las razones fundamentales por las
que éstos se propusieron. Cuando se proponen cambios, se debe rastrear el impacto de
estos cambios en los otros requerimientos y en el diseño del sistema. El rastreo es una
propiedad de la especificación de requerimientos que refleja la facilidad de encontrar
requerimientos relacionados.
Existen tres tipos de información de rastreo que pueden ser mantenidos:
1 La información de rastreo de la fuente vincula los requerimientos con los stakeholders

que propusieron los requerimientos y la razón de éstos. Cuando se propone un
cambio, esta información se utiliza para encontrar y consultar a los stakeholders sobre
el cambio.
2 La información de rastreo de los requerimientos vincula los requerimientos
dependientes en el documento de requerimientos. Esta información se utiliza para
evaluar cómo es probable que muchos requerimientos se vean afectados por un
cambio propuesto y la magnitud de los cambios consecuentes en los requerimientos.
3 La información de rastreo del diseño vincula los requerimientos a los módulos del
diseño en los cuales son implementados. Esta información se utiliza para evaluar el
impacto de los cambios de los requerimientos propuestos en el diseño e
implementación del sistema.
A menudo, la información de rastreo se representa utilizando matrices de rastreo, las

cuales relacionan los requerimientos con los stakeholders, con los módulos del diseño o
los requerimientos entre ellos.
44
La gestión de requerimientos necesita ayuda automatizada; las herramientas CASE para

esto deben elegirse durante la fase de planificación. Se precisan herramientas de ayuda
para:
1 Almacenar requerimientos. Los requerimientos deben mantenerse en un almacén de

datos seguro y administrado que sea accesible a todos los que estén implicados en el
proceso de ingeniería de requerimientos.
2 Gestionar el cambio. Este proceso se simplifica si está disponible una herramienta de
ayuda.
3 Gestionar el rastreo. Como se indicó anteriormente, las herramientas de ayuda para el
rastreo permiten que se descubran requerimientos relacionados. Algunas
herramientas utilizan técnicas de procesamiento del lenguaje natural para ayudarle a
descubrir posibles relaciones entre los requerimientos.
Para sistemas pequeños, es posible que no sea necesario utilizar herramientas de gestión
de requerimientos especializadas. El proceso de gestión de requerimientos puede llevarse
a cabo utilizando los recursos disponibles en los procesadores de texto, hojas de cálculo y
bases de datos en PC. Sin embargo, para sistemas grandes, se requieren herramientas de
ayuda más especializadas. En el sitio web del libro he incluido enlaces a herramientas de
gestión de requerimientos como DOORS y RequisitePro.
La gestión del cambio de los requerimientos se debe aplicar a todos los cambios
propuestos en los requerimientos. La ventaja de utilizar un proceso formal para gestionar
el cambio es que lodos los cambios propuestos son tratados de forma consistente y que
los cambios en el documento de requerimientos se hacen de forma controlada. Existen
tres etapas principales en un proceso de gestión de cambio:
1 Análisis del problema y especificación del cambio. El proceso empieza con la

identificación de un problema en los requerimientos o, algunas veces, con una
propuesta de cambio específica. Durante esta etapa, el problema o la propuesta de
cambio se analiza para verificar que ésta e& válida. Los resultados del análisis se
pasan al solicitante del cambio, y algunas veces se hace una propuesta de cambio de
requerimientos más específica.
2 Análisis del cambio y cálculo de costes. El efecto de un cambio propuesto se valora
utilizando la información de rastreo y el conocimiento general de los requerimientos del
sistema. El coste de hacer un cambio se estima en términos de modificaciones al
documento de requerimientos y, si es apropiado, al diseño e implementación del
sistema. Una vez que este análisis se completa, se toma una decisión sobre si se
continúa con el cambio de requerimientos.
3 Implementación del cambio. Se modifica el documento de requerimientos y, en su
caso, el diseño e implementación del sistema. Debe organizar el documento de
requerimientos de modo que pueda hacer cambios en él sin tener que hacer grandes
reorganizaciones o redactar nuevamente gran cantidad del mismo. Como sucede con
los programas, los cambios en los documentos se llevan a cabo minimizando las
referencias externas y haciendo las secciones del documento tan modulares como sea
posible. De esta manera, se pueden cambiar y reemplazar secciones individuales sin
afectar a otras partes del documento.
Si se requiere de forma urgente un cambio en los requerimientos del sistema, existe

siempre la tentación de hacer ese cambio al sistema y entonces modificar de forma
retrospectiva el documento de requerimientos. Esto conduce casi inevitablemente a que la
especificación de requerimientos y la implementación del sistema se desfasen. Una vez
que se han hecho los cambios en el sistema, los del documento de requerimientos se
pueden olvidar o se hacen de forma que no concuerdan con los cambios del sistema. Los
procesos de desarrollo iterativo, como la programación extrema, se han diseñado para
hacer frente a los requerimientos que cambian durante el proceso de desarrollo.
45
SEGUNDA UNIDAD
Tema Nº 7: Construcción de Prototipos

Introducción
Como ingeniero de requerimientos que presenta un prototipo del sistema de

información, usted está bastante interesado en las reacciones de los usuarios y los
directivos de la organización hacia el prototipo. Usted desea saber detalladamente cómo
reaccionarán al trabajar con el prototipo y qué tan bien satisfarán sus necesidades las
características del sistema a partir de las cuales se elaboró el prototipo. Las reacciones se
recopilan a través de la observación, las entrevistas y las hojas de retroalimentación
(posiblemente los cuestionarios) diseñados para obtener la opinión de cada persona
sobre el prototipo después de que interactúan con él. La información recopilada en la
fase de elaboración de prototipos permite al analista establecer las prioridades y
cambiar el rumbo de los planes a bajo costo, con un mínimo de molestias. Debido a
esta característica, la elaboración de prototipos y la planeación van de la mano.
Clases de Prototipos
La palabra prototipo se usa de muchas formas diferentes. En lugar de intentar sintetizar to-
dos estos usos en una sola definición o de tratar de convenir en un enfoque correcto al
tema un tanto polémico de la elaboración de prototipos, ilustramos la manera en que cada
una de varias concepciones de la elaboración de prototipos se puede aplicar
convenientemente en una situación particular.
Prototipo corregido. La primera clase de elaboración de prototipos tiene que ver con la
construcción de un sistema que funciona pero se corrige simultáneamente. En la
ingeniería a este enfoque se le llama elaboración de una tabla experimental: la creación,
46
en una tableta de pruebas, de un modelo funcional de un circuito integrado (que en la vida

real sería microscópico).
Un ejemplo en sistemas de información es un modelo funcional que tiene todas las

características necesarias pero es ineficiente. En este ejemplo de elaboración de
prototipos, los usuarios pueden interactuar con el sistema, acostumbrándose a la interfaz y
los tipos de salidas disponibles. Sin embargo, la recuperación y almacenamiento de
información podrían ser ineficientes, debido a que los programas se escribieron
rápidamente con el objetivo de ser funcionales en lugar de eficaces.
Prototipo no funcional. El segundo tipo de prototipo es un modelo no funcional a escala

con- figurado para probar ciertos aspectos del diseño. Un ejemplo de este enfoque es un
modelo a escala completa de un automóvil que se usa para pruebas en un túnel de viento.
El tamaño y forma del automóvil son precisos, pero el automóvil no es funcional. En este
caso sólo se incluyen las características del automóvil que son fundamentales para la
prueba en el túnel de viento. Un modelo no funcional a escala de un sistema de
información podría producirse cuando la codificación requerida por las aplicaciones es
demasiado extensa para incluirse en el prototipo pero cuando se puede conseguir una
idea útil del sistema a través de la elaboración de un prototipo de la entrada y la salida. En
este caso, el procesamiento, debido al excesivo costo y el tiempo requerido, no podría
incluirse en el prototipo. Sin embargo, aún se podrían tomar algunas decisiones sobre la
utilidad del sistema con base en la entrada y la salida incluidas en el prototipo.
Primer prototipo de una serie. Un tercer tipo de prototipos involucra la creación de un

primer modelo a escala completa de un sistema, con frecuencia llamado piloto. Un ejemplo
es la elaboración de un prototipo del primer avión de una serie. El prototipo es
completamente funcional y es una materialización de lo que el diseñador espera será una
serie de aviones con características idénticas. Este tipo de elaboración de prototipos es útil
cuando se planean muchas instalaciones del mismo sistema de información. El modelo
funcional a escala completa permite a los usuarios experimentar la interacción real con
el nuevo sistema, pero minimiza el costo de superar cualquier problema que se
presente. La creación de un modelo funcional es uno de los tipos de elaboración de
prototipos que se hace con RAD. Por ejemplo, cuando una cadena de tiendas de
abarrotes minoristas considera el uso del EDI (intercambio electrónico de datos) para
comprobar los envíos de los proveedores a varias tiendas, se podría instalar un modelo a
escala completa en una tienda para resolver cualquier problema antes de que el sistema
se implemente en todas las demás tiendas. Otro ejemplo es el de las instalaciones
bancarias para la transferencia electrónica de fondos. Primero, se instala un prototipo a
escala completa en una o dos sucursales, y si tiene éxito, se instalan los duplicados en
todas las sucursales con base en los patrones de uso de los clientes y en otros factores
importantes.
Prototipo de características seleccionadas. Una cuarta concepción de la elaboración de

prototipos involucra la creación de un modelo funcional que incluya algunas, pero
no todas, de las características que tendrá el sistema final. Una analogía sería que un
nuevo centro comercial minorista abriera antes de que se terminara la construcción de
todas las tiendas. Cuando se elaboran prototipos de los sistemas de información de esta
manera, se incluyen algunas de las características principales, aunque no todas. Por
ejemplo, en la pantalla podría aparecer un menú del sistema que muestre seis
características: agregar un registro, actualizar un registro, eliminar un registro, buscar una
palabra clave en un registro, listar un registro o examinar un registro. Sin embargo, en el
prototipo del sistema tal vez sólo estén disponibles tres de las seis características, de
manera que el usuario podría agregar un registro (característica 1), eliminar un registro
(característica 3) y listar un registro (característica 5). Cuando se recurre a este tipo de
elaboración de prototipos, el sistema se completa por módulos de forma que si las
características que se incluyen en los prototipos se evalúan exitosamente, se puedan
incorporar en el sistema final más grande sin necesidad de realizar demasiado esfuerzo en
la interacción. Los prototipos hechos de esta forma son parte del sistema real. No son sólo
un modelo como en el caso de los prototipos no funcionales que se describieron antes.
47
Elaboración de Prototipos
Algunos analistas argumentan que la elaboración de prototipos se debe considerar

como una alternativa para el ciclo de vida del desarrollo de sistemas (SDLC).
Las quejas relativas al proceso del SDLC se centran en dos preocupaciones

interrelacionadas. La primera preocupación es todo el tiempo que se requiere para pasar
por el ciclo de vida del desarrollo. Conforme aumenta la inversión de tiempo del analista,
el costo del sistema entregado se incrementa proporcionalmente.
La segunda preocupación sobre el uso del SDLC es que los requerimientos del usuario
cambian a través del tiempo. Los requerimientos del usuario evolucionan durante el
considerable intervalo existente entre el análisis de los requerimientos del usuario y la
fecha en que se entrega el sistema final. Por lo tanto, debido al extenso ciclo del
desarrollo, el sistema resultante podría ser criticado por abordar deficientemente los
requerimientos de información del usuario actual.
Un corolario al problema de mantenerse al tanto de los requerimientos de información del

usuario es la teoría de que los usuarios realmente no saben lo que hacen o no lo desean
sino hasta que ven algo tangible. En el SDLC tradicional, una vez que se entrega un
sistema, con frecuencia es demasiado tarde para modificarlo.
Para resolver estos problemas, algunos analistas proponen la elaboración de prototipos

como una alternativa al ciclo de vida del desarrollo de sistemas. Cuando la elaboración de
prototipos se usa de esta forma, el analista reduce efectivamente el tiempo entre la
determinación de los requerimientos de información y la entrega de un sistema funcional.
Además, el uso de la elaboración de prototipos en lugar del SDLC tradicional podría
resolver algunos problemas como el de identificar con precisión los requerimientos de
información del usuario.
Entre las desventajas de sustituir el SDLC por la elaboración de prototipos está la de la

configuración prematura de un sistema antes de que el problema u oportunidad en
cuestión se entienda completamente. También, el uso de la elaboración de
prototipos como una alternativa podría producir un sistema aceptado por grupos
específicos de usuarios pero inadecuado para las necesidades globales del sistema.
El enfoque que apoyamos aquí es usar la elaboración de prototipos como una parte del
SDLC tradicional. Desde esta perspectiva, la elaboración de prototipos se considera como
un método adicional y especializado para determinar los requerimientos de información de
los usuarios.
Como desarrollar un Prototipo
El término elaboración de prototipos se interpreta en el sentido de la última definición que

se explicó, es decir, un prototipo de características seleccionadas que incluirá algunas
pero no todas las características; uno que, si tiene éxito, será parte del sistema final que
se entregue.
La elaboración de prototipos es una excelente forma de obtener retroalimentación sobre el

sistema propuesto y sobre la facilidad con que está cumpliendo las necesidades de
información de sus usuarios. El primer paso de la elaboración de prototipos es estimar los
costos necesarios para la construcción de un módulo del sistema.
Si los costos del tiempo de programadores y analistas y los del equipo que
utilizarán están dentro del presupuesto, se puede proceder a la elaboración del prototipo.
La elaboración de prototipos es una excelente forma de facilitar la integración del
sistema de información con el sistema principal de la organización. Una vez que se ha
tomado la decisión de elaborar un prototipo, se deben observar cuatro lineamientos
principales al integrar la elaboración de prototipos con la fase de determinación de
requerimientos del SDLC:
48
1. Trabajar en módulos manejables.

2. Construir rápidamente el prototipo.
3. Modificar el prototipo en iteraciones sucesivas.
4. Poner énfasis en la interfaz de usuario.
Como puede ver, los lineamientos sugieren acciones relativas al prototipo que
necesariamente se interrelacionan. Cada uno de los lineamientos se explica en las
subsecciones siguientes.
El trabajo en módulos manejables. Cuando el prototipo de algunas de las características

de un sistema se integra para formar un modelo funcional, es indispensable que el analista
trabaje en módulos manejables. Una ventaja evidente de la elaboración de prototipos es
que no es necesario ni deseable construir un sistema operativo completo para los
propósitos del prototipo. Un módulo manejable es aquel que permite a los usuarios
interactuar con sus características clave pero que se puede construir de forma separada
de otros módulos del sistema. Las características del módulo que se juzgan de menor
importancia se omiten intencionalmente en el prototipo inicial.
Construcción rápida del prototipo. La rapidez es esencial para la elaboración

exitosa del prototipo de un sistema de información. Recuerde que una de las quejas
expresadas en contra del SDLC tradicional es que el intervalo entre la determinación de
requerimientos y la entrega de un sistema completo es demasiado largo para satisfacer
eficazmente las cambiantes necesidades del usuario. Los analistas pueden usar la
elaboración de prototipos con el fin de reducir esta brecha utilizando las técnicas
tradicionales de recopilación de información para determinar con precisión los
requerimientos de información que surjan sobre la marcha, y a continuación tomar
rápidamente las decisiones que den lugar a un modelo funcional.
Modificación del prototipo. Un tercer lineamiento para desarrollar el prototipo es que

su construcción debe soportar modificaciones. Hacer modificable el prototipo significa
crearlo en módulos que no sean demasiado interdependientes. Si se observa este
lineamiento, se encontrará menos resistencia cuando sea necesario realizar cambios al
prototipo. Generalmente, el prototipo se modifica varias veces al pasar por diversas
iteraciones. Los cambios en el prototipo deben propiciar que el sistema se acerque cada
vez más a lo que los usuarios consideren importante. Cada modificación necesita
otra evaluación por parte de los usuarios. El prototipo no es un sistema terminado.
Abordar la fase de elaboración de prototipos con la idea de que el prototipo requerirá
modificaciones es una actitud positiva que demuestra a los usuarios cuan necesaria es
su retroalimentación para mejorar el sistema.
Énfasis en la interfaz de usuario. La interfaz de usuario con el prototipo (y

posteriormente con el sistema) es muy importante. Puesto que en realidad su principal
objetivo con el prototipo es conseguir que los usuarios expresen mucho mejor sus
requerimientos de información, éstos deben interactuar fácilmente con el prototipo del
sistema. Para muchos usuarios la interfaz es el sistema. Esto no debe representar un
obstáculo. Aunque no se desarrollarán muchos aspectos del sistema en el prototipo, la
interfaz de usuario se debe desarrollar lo mejor posible para permitir a los usuarios
una rápida comprensión del sistema y no sentirse desorientados. Los sistemas
interactivos en línea que usan interfaces gráficas son particularmente apropiados para los
prototipos.
Desventajas de la Elaboración de Prototipos
Como en cualquier técnica de recopilación de información, la elaboración de

prototipos tiene varias desventajas. La primera es que puede ser bastante difícil manejar la
elaboración de prototipos como un proyecto en el esfuerzo de sistemas más
grandes. La segunda desventaja es que los usuarios y los analistas podrían adoptar un
prototipo como si fuera un sistema final cuando de hecho es deficiente y su propósito
nunca fue el de servir como sistema terminado. El analista necesita sopesar estas
49
desventajas contra las ventajas conocidas al decidir si hace el prototipo, cuándo lo hace y
de qué partes del sistema lo hace.
Ventajas de la Elaboración de Prototipos
La elaboración de prototipos no es necesaria o apropiada en todos los proyectos de

sistemas, como hemos visto. Sin embargo, también se deben considerar las ventajas al
momento de decidir si se hace el prototipo. Las tres ventajas principales de la elaboración
de prototipos son la posibilidad de modificar el sistema en las primeras etapas del
desarrollo, la oportunidad de suspender el desarrollo de un sistema que no sea
funcional y la posibilidad de desarrollar un sistema que se acerque más a satisfacer las
necesidades y expectativas de los usuarios.
El papel del Usuario en la Elaboración de Prototipos
El papel del usuario en la elaboración de prototipos se puede resumir en dos palabras:

intervención honrada. Sin la intervención del usuario hay poca razón para elaborar el
prototipo. Los comportamientos precisos y necesarios para interactuar con un
prototipo pueden variar, pero está claro que el usuario es fundamental en el
proceso de la elaboración de prototipos. Comprendiendo la importancia que tiene el
usuario en el éxito del proceso, los miembros del equipo de análisis de sistemas deben
propiciar y recibir de buena manera la retroalimentación y deben evitar su propia
resistencia natural a cambiar el prototipo.
Interacción con el Prototipo
Hay tres formas principales en las que un usuario puede ayudar en la elaboración de
prototipos:
1. Experimentando con el prototipo.

2. Dando reacciones sinceras sobre el prototipo.
3. Sugiriendo adiciones o eliminaciones al prototipo.
Los usuarios deben tener libertad para experimentar con el prototipo. En contraste
con una simple lista de características de sistemas, el prototipo permite a los usuarios la
interacción real. Una forma de facilitar esta interacción es instalar un prototipo en un
sitio Web interactivo.
Otro aspecto del papel de los usuarios en la elaboración de prototipos requiere

que proporcionen reacciones sinceras acerca del prototipo. Por desgracia, estas
reacciones no se dan bajo demanda. Más bien, lograr que los usuarios se sientan
suficientemente seguros para dar una reacción sincera es parte de la relación entre
analistas y usuarios que su equipo debe procurar establecer.
Los analistas necesitan estar presentes por lo menos en el momento en que ocurre la
experimentación. Entonces pueden observar las interacciones de los usuarios con el
sistema, y están obligados a ver las interacciones que nunca planearon.
Un tercer aspecto del papel de los usuarios en la elaboración de prototipos es su

disposición para sugerir adiciones o eliminaciones de las características
experimentadas. El papel del analista es producir tales sugerencias asegurando a
los usuarios que la retroalimentación que ellos proporcionan se toma en serio,
observándolos cuando interactúen con el sistema y haciendo entrevistas cortas y
específicas con usuarios que tengan experiencias relacionadas con el prototipo.
Aunque se les pedirá a los usuarios que den sugerencias e innovaciones para el
prototipo, al final el analista tiene la responsabilidad de analizar esta retroalimentación
y traducirla a los cambios que sean necesarios. Para facilitar el proceso de la
elaboración de prototipos, el analista debe comunicar claramente a los usuarios los
propósitos de dicha elaboración, junto con la idea de que sólo es valiosa cuando los
usuarios se involucran significativamente.
50
SEGUNDA UNIDAD
Tema Nº 8: Metodologías Ágiles
Desarrollo Rápido de Aplicaciones
El desarrollo rápido de aplicaciones (RAD) es un enfoque orientado a objetos para el

desarrollo de sistemas que incluye un método de desarrollo así como también
herramientas de software. Es lógico discutir RAD y la elaboración de prototipos en el
mismo capítulo, debido a que están conceptualmente muy unidos. Ambos tienen
como meta la reducción del tiempo que generalmente se necesita en un SDLC
tradicional entre el diseño y la implementación del sistema de información. Finalmente,
el RAD y la elaboración de prototipos se enfocan en satisfacer más de cerca los
requerimientos cambiantes de los negocios. Una vez que ha aprendido los conceptos
de la elaboración de prototipos, es mucho más fácil entender la esencia del RAD, que
se puede considerar como una implementación específica de la elaboración de
prototipos. Algunos desarrolladores están considerando al RAD como un enfoque útil
para los nuevos entornos de comercio electrónico basados en la Web, en el cual podría
ser importante el estatus de primero en tomar la iniciativa de un negocio. En otras
palabras, para poner una aplicación en la Web antes que sus competidores, las empresas
podrían requerir que su equipo de desarrollo experimente con el RAD.
Fases del RAD
Hay tres fases amplias del RAD que vinculan a usuarios y analistas en la evaluación,
diseño e implementación. Observe que el RAD involucra a los usuarios en cada parte
del esfuerzo de desarrollo, con una intensa participación en la parte de negocios del
diseño.
Fase de planeación de requerimientos. En esta fase, usuarios y analistas se

reúnen para identificar los objetivos de la aplicación o sistema y para identificar los
requerimientos de información que surgen de dichos objetivos. Esta fase requiere que
ambos grupos se involucren intensamente; no se trata simplemente de firmar una
propuesta o documento. Además, esto podría involucrar a usuarios de los diferentes
niveles de la organización. En la fase de planeación de requerimientos, cuando aún se
están determinando los requerimientos de información, usted podría estar trabajando
con el director de información (si es una organización grande) así como también con
la gente de planeación estratégica, sobre todo si usted está trabajando con una aplicación
de comercio electrónico cuyo propósito es impulsar los objetivos estratégicos de la
organización. La orientación en esta fase tiene el objetivo de resolver los problemas de
negocios. Aunque algunas de las soluciones propuestas podrían surgir de la tecnología
de información disponible, el enfoque siempre será alcanzar los objetivos del negocio.
51
Taller de diseño del RAD. El proceso de diseñar y refinar los prototipos se puede
representar mejor como un taller. Cuando imagina un taller, sabe que la participación es
intensa, no pasiva, y que generalmente se hace con las manos. Normalmente los usuarios
están sentados en mesas redondas o en una configuración en forma de “U” de
sillas con escritorios adheridos donde cada persona puede ver a otra y donde hay
espacio para trabajar con una computadora portátil. Si usted es bastante afortunado para
disponer de un salón para sistemas de apoyo a la toma de decisiones en grupo (GDSS) en
la compañía o a través de una universidad local, utilícelo para conducir por lo menos una
parte de su taller de diseño de RAD. Durante el taller de diseño del RAD, los usuarios
responden a los prototipos operativos reales y los analistas refinan los módulos diseñados
(utilizando algunas de las herramientas de software que se mencionan más adelante)
basados en las respuestas del usuario. El formato del taller es muy emocionante y
estimulante, y si están presentes los usuarios y los analistas experimentados, no hay
ninguna duda de que este esfuerzo creativo puede impulsar el desarrollo a gran velocidad.
Fase de implementación. Tan pronto como sean convenidos estos aspectos y los
sistemas sean construidos y se refinen, los nuevos sistemas, o parte de ellos, son
probados e introducidos en la organización. Debido a que el RAD se puede usar para
crear las nuevas aplicaciones de comercio electrónico para las cuales no hay ningún
sistema viejo, por lo general no se necesita ejecutar los sistemas viejos y nuevos en
paralelo antes de la implementación (además que no hay forma real de hacerlo). En este
punto, el taller de diseño del RAD habrá generado el interés, sentido de perte- nencia del
usuario y la aceptación de la nueva aplicación. Generalmente, el cambio que se produce
de esta forma es mucho menos doloroso que cuando un sistema se entrega con poca o
ninguna participación del usuario.
Programación Extrema
La programación extrema (XP) es un enfoque de desarrollo de software que adopta lo que

generalmente designamos como prácticas de desarrollo de software aceptable y las lleva
al extremo. Por ejemplo, la retroalimentación es importante para los programadores,
analistas, diseñadores, usuarios y computadoras. Así que la programación extrema usa
ciclos de retroalimentación cada vez más rápidos e intensos, que proporcionan más
información. La administración de proyectos es importante, de tal manera que la
programación extrema intenta definir rápidamente un plan global del sistema,
desarrollar y liberar rápidamente el software y posteriormente revisarlo continuamente
para incorporarle características adicionales. Los programadores, analistas y
diseñadores ordinarios que trabajan independientemente y luego integran su trabajo
logran resultados sólidos; los programadores extremos que trabajan en pareja pueden ser
excelentes. Pero la programación extrema no sólo se basa en los resultados. Se basa en
los valores, principios y prácticas. Ahora examinaremos cómo los valores y principios de
XP dan forma al desarrollo de sistemas extremos.
Valores y Principios de la Programación Extrema
Para la programación extrema es importante que se declaren los valores y principios

que crean el contexto para la colaboración entre programadores y clientes. Para
considerarse analista de XP, se debe apegar a los siguientes valores y principios
desarrollados por Beck [2000].
Cuatro valores de XP. Hay cuatro valores que crean un entorno en el cual se pueden
servir adecuadamente diseñadores y negocios. Debido a que con frecuencia hay una
tensión entre lo que los diseñadores hacen a corto plazo y lo que es comercialmente
deseable a largo plazo, es importante que esté consciente de apoyar valores que formarán
una base para colaborar jun- tos en un proyecto de software. Los cuatro valores son
comunicación, sencillez, retroalimentación y valentía.
Empecemos con la comunicación. Cada esfuerzo humano tiene la posibilidad de fallar en

la comunicación. Los proyectos de los sistemas que requieren una actualización constante
y un diseño técnico son especialmente propensos a dichos errores. Agregue a este
52
proyecto fechas límite ajustadas, jerga especializada y el estereotipo de que los

programadores prefieren hablar con las máquinas que con las personas, y usted tiene los
ingredientes para algunos problemas serios de comunicación. Los proyectos pueden ser
retrasados; se puede resolver el problema equivocado; se castiga a los programadores
incluso por mencionar a los gerentes que hay problemas; las personas abandonan o se
unen al proyecto a la mitad sin estar al corriente; y así continúa la letanía.
Prácticas típicas de XP tal como la programación en parejas, estimación de las

tareas y las pruebas del software, requieren de una buena comunicación. Los
problemas se resuelven rápidamente, los agujeros se tapan y la opinión débil se
fortalece rápidamente a través de la interacción con otros en el equipo. Un instructor de
XP está presente para observar si alguien ha interrumpido la comunicación y para
reunirlos. El segundo valor de la programación extrema es la simpleza. Cuando estamos
trabajando en un proyecto de desarrollo de software, nuestra primera reacción es
abrumarnos por la complejidad y magnitud de la tarea. Sin embargo, usted no puede
correr si no sabe caminar, ni caminar si no sabe ponerse de pie. La simpleza en el
desarrollo de software significa que empezaremos con la cosa más sencilla que podemos
hacer. La simpleza lleva tiempo, y es algo en lo que el instructor de XP podría ayudarle. El
valor de XP de simpleza nos pide que hoy hagamos la cosa más sencilla, comprendiendo
que mañana se podría cambiar un poco. Esto requiere un enfoque claro de las metas del
proyecto y realmente es un valor básico.
La retroalimentación es el tercer valor básico que es importante para tener un enfoque

de la programación extrema. Cuando piensa en la retroalimentación en este contexto, es
bueno considerar que ésta se relaciona con el concepto de tiempo. Una retroalimentación
buena y concreta, que es útil para el programador, analista y cliente puede ocurrir en
segundos, minutos, días, semanas o meses, dependiendo de lo que se necesita, quién
está comunicando y lo que se hará con dicha retroalimentación. Un colega programador
podría encontrar un caso de prueba que hiciera que un código que usted escribió fallara.
Esto podría ocurrir sólo horas antes de la fecha de entrega, pero dicha
retroalimentación es casi invaluable en lo que se refiere a poder cambiar lo que no
está funcionando antes de que se acepte y se inserte en el sistema.
La retroalimentación ocurre cuando los clientes crean pruebas funcionales para

todas las historias que los programadores habrán de implementar. La
retroalimentación crítica sobre el programa de trabajo viene de clientes que comparan la
meta del plan con el progreso que se ha tenido. La retroalimentación ayuda a los
programadores a hacer los ajustes y permite a los negocios tener una experiencia a
tiempo de lo que el nuevo sistema se parecerá una vez que sea totalmente funcional.
La valentía es el cuarto valor enunciado en la programación extrema. La valentía tiene que

ver con un nivel de confianza que debe existir en el equipo de desarrollo. Significa que no
se debe tener miedo de tirar una tarde o un día de programación y empezar de nuevo si
todo está mal. Significa tomar en cuenta los propios instintos (y resultados de la
prueba) respecto de lo que funciona y lo que no.
La valentía también significa responder a una retroalimentación concreta, tomar una

decisión basándose en el presentimiento de un compañero de equipo cuando creen que
tienen una forma más simple o mejor de lograr su meta. La valentía es un valor de alto
riesgo y de alta recompensa qué anima a la experimentación que el equipo puede tomar
de una forma más rápida e innovadora para lograr su meta. La valentía significa
que usted y sus compañeros se tienen suficiente confianza mutua y en sus clientes como
para actuar en formas que mejorarán continuamente lo que se está haciendo en el
proyecto, aun cuando ello requiera tirar el código, reconsiderar las soluciones o, más aún,
simplificar los enfoques. La valentía también implica que usted, como analista de
sistemas, aplique con empeño las prácticas extremas de XP.
Principios básicos de XP. En un mundo perfecto, los clientes y su equipo de desarrollo

de software estarían de acuerdo en todo y no sería necesaria la comunicación. Sabemos
que no existe el mundo ideal. ¿Pero cómo podemos hacer nuestros proyectos de
53
desarrollo de software más parecidos al ideal? Una razón para que esto no ocurra se
debe a que hasta ahora estamos intentando operar en un sistema poco claro de valores
compartidos. Son un buen principio, pero realmente no son operativos en el punto en que
podamos medir nuestro éxito de forma significativa. De manera que trabajamos para
derivar los principios básicos que nos pueden ayudar a verificar si lo que estamos
haciendo en nuestro proyecto de software realmente está midiendo los valores que
compartimos. Aunque hay alrededor de una docena de principios que podemos derivar de
nuestros valores, los principios básicos que describimos son: proporcionar una rápida
retroalimentación, dar por hecho la sencillez, cambiar progresivamente, aceptar el cambio
y alentar el trabajo de calidad.
El principio básico para recordar respecto a la retroalimentación rápida es que para que
las personas o los sistemas hagan una conexión entre estímulo y reacción, la
retroalimentación debe ocurrir en un intervalo razonablemente corto. Si a una impresora se
le termina el papel, debe desplegar instantáneamente un mensaje "no hay papel"
como retroalimentación para el usuario, de manera que la situación se pueda remediar y
la impresión pueda continuar. La retroalimentación rápida para el equipo de desarrollo
significa que entre más cercano sea el tiempo de una acción [codificar una característica
derivada de un reporte del usuario) al tiempo de la comprobación, más significativa será la
retroalimentación (los resultados de la prueba}. Entre más pronto en la vida de un sistema
éste se ponga en producción (en lugar de simplemente estar en desarrollo), mayor será el
valor de la retroalimentación para el negocio al medir si el sistema está cumpliendo sus
metas.
El siguiente principio básico es que el equipo de desarrollo debe adoptar la simpleza. La

premisa es que alrededor de 90 por ciento de los problemas se puede resolver con
absoluta sencillez. Observe que esto se contrapone a la mayoría del entrenamiento
tradicional, el cual les pide a los desarrolladores que planeen para el futuro, entiendan
todas las interfaces, y así sucesivamente, antes de empezar. La programación extrema
dice que la simpleza rige el día, y que los programadores deben confiar en su habilidad de
agregar la complejidad el próximo día si se requiere. Éste es un principio muy difícil de
dominar para muchos diseñadores.
El tercer principio que examinamos es el cambio progresivo. Esto significa que usted
constantemente está haciendo el cambio más pequeño posible que aún resulte en una
diferencia en el esfuerzo de desarrollo. Ningún cambio mayor en el código, el equipo y los
requerimientos del negocio. Ellos requieren cambio progresivamente, incluso después de
que se libera el producto. Esto se adapta bien con la idea de XP de evolución.
Un cuarto principio básico que podemos derivar de los valores de XP es el de aceptar el

cambio. Necesitamos mantener abiertas todas nuestras opciones, pero, al mismo
tiempo, necesitamos ser capaces de resolver cualquier obstáculo que se presente.
Aunque siempre hay pros y contras, sabemos con seguridad que el cambio es bienvenido.
Ese dinamismo permite que el proyecto siga adelante y anima el espíritu del equipo del
proyecto.
El último principio es la noción de alentar el trabajo de calidad. El principio proviene de la

idea de que todos los participantes deben hacer un trabajo de calidad. Si no hicieran
trabajo de calidad, ¿por qué considerar ser incluidos en un esfuerzo de programación
extrema? El punto es hacer el trabajo agradable, trabajar adecuadamente con el equipo y
mantener el proyecto sano y salvo.
Existen algunos principios más que ayudarán a los desarrolladores a saber cómo proceder
cuando surja una situación particular. En pocas palabras: incluyen la obligación de
enseñar a aprender; el estímulo para hacer una pequeña inversión inicial de manera
que se haga un buen, pero no extravagante, trabajo; jugar para ganar, no jugar para
evitar perder; y usar experimentos concretos para probar el trabajo que se está haciendo.
Otros conceptos importantes que apoyan la programación extrema son la idea de usar la
comunicación abierta y honrada sin miedo; aprovechar las tendencias naturales de las
54
personas (querer ser exitoso, interactuar con otros, tener la autonomía en su trabajo, ser
parte de un equipo ganador, ser confiado, tener en funcionamiento su software); asumir la
responsabilidad de hacer algo en lugar de ordenarle a alguien que lo haga; adaptar
localmente el enfoque que está aprendiendo para la programación extrema; y buscar
utilizar una medida honrada que no pretenda alcanzar una precisión que no existe.
Actividades, Recursos y Prácticas de la Programación Extrema
La programación extrema involucra varias actividades que se necesita completar en

algún momento durante el proceso de desarrollo de XP. Esta sección discute dichas
actividades, recursos y prácticas que son únicos para la programación extrema.
Hay cuatro actividades básicas de desarrollo que utiliza la programación extrema.

Dichas actividades son codificar, probar, escuchar y diseñar. El analista de XP
necesita identificar la cantidad de esfuerzo que entrará en cada actividad y el equilibrio
necesario con los recursos para completar el proyecto. En XP, por un lado son las
actividades. En el otro lado son los recursos.
Codificar se designa como una actividad dado que no es posible hacer nada sin
ella. Un autor afirma que la cosa más valiosa que recibimos de la codificación es el
"aprendizaje". El proceso básicamente es esto: tenga un pensamiento, codifíquelo,
pruébelo y vea si ese pensamiento era lógico. También se puede codificar para comunicar
ideas que de otra manera permanecerían borrosas o sin forma. Cuando veo su
código, puedo generar un nuevo pensamiento. El código fuente es la base para que un
sistema sobreviva. Es esencial para el desarrollo.
La segunda actividad básica del desarrollo es probar. La programación extrema da mucha

importancia a las pruebas automatizadas. La programación extrema apoya la
generación de pruebas escritas para verificar la codificación, la funcionalidad, el
rendimiento y la conformidad con los objetivos. XP se apoya en las pruebas automatizadas
y existen grandes bibliotecas de pruebas para la mayoría de los lenguajes de
programación. Estas pruebas necesitan ser actualizadas conforme sea necesario durante
el progreso del proyecto. Hay razones de corto y largo plazos para hacer pruebas. Probar
a corto plazo le proporciona la confianza extrema en lo que está construyendo. Si las
pruebas se ejecutan perfectamente usted puede seguir adelante con la confianza
renovada. A largo plazo, probar mantiene vivo un sistema, y le permite hacer muchos más
cambios de los que serían posibles si ninguna prueba fuera escrita o ejecutada.
La tercera actividad básica del desarrollo es escuchar. En la programación extrema,

esta actividad se lleva al extremo. Los desarrolladores escuchan de manera activa a
sus compañeros de programación. En XP se depende menos de la comunicación formal
escrita y por ello escuchar se vuelve una habilidad muy importante. El desarrollador
también escucha de manera activa al cliente. Los desarrolladores asumen que no saben
nada acerca del negocio en el que están colaborando, y por lo tanto deben escuchar
cuidadosamente a los usuarios para obtener las respuestas a sus preguntas. El
desarrollador necesita entender la eficacia de escuchar. Si no escucha, no sabrá lo que
debe codificar o lo que debe probar.
La cuarta actividad básica en el desarrollo es diseñar, lo cual es una forma de crear una
estructura para organizar toda la lógica en el sistema. Diseñar es una actividad evolutiva,
y por ello los sistemas que se diseñan con un enfoque de la programación extrema se
conceptualizan como en constante evolución, siempre diseñándose.
Con frecuencia un buen diseño es simple. También, éste debe permitir la flexibilidad:
Diseñar bien permite agregar extensiones al sistema haciendo cambios en un solo
lugar. El diseño eficaz ubica la lógica cerca de los datos en que estará operando. Sobre
todo, el diseño debe ser útil para todos aquellos que lo necesitarán conforme
avance el esfuerzo de desarrollo, incluyendo a clientes y programadores. Cuatro
variables de control de recursos de XP Con el objetivo de lograr las actividades descritas
anteriormente, los analistas de XP necesitan recursos. Se pueden ajustar cuatro recursos
55
para completar el proyecto antes de una fecha límite: tiempo, costo, calidad y alcance.
Cuando se incluyen adecuadamente estas cuatro variables de control en la
planeación, hay un estado de equilibrio entre los recursos y las actividades necesarias
para completar el proyecto.
Cuatro prácticas esenciales distinguen notablemente a XP de otros enfoques, y por

consiguiente hacen extremo a XP: liberación limitada; se mana de trabajo de 40 horas;
alojar al cliente en el sitio, y el uso de la programación en parejas.
1. La liberación limitada significa que el equipo de desarrollo reduce el tiempo entre las
liberaciones de su producto. En lugar de liberar una versión completamente
desarrollada por un año, usando la práctica de liberación limitada reducirán el tiempo
de liberación incluyendo primero las características más importantes, liberando ese
sistema o producto y mejorándolo después.
2. La semana de trabajo de 40 horas significa que los equipos de desarrollo de XP
apoyan conscientemente una práctica esencial cultural en la cual el equipo labora
intensamente en conjunto durante una semana típica de 40 horas de trabajo. Como
consecuencia a esta práctica, la cultura refuerza la idea de que trabajar horas extras
por más de una semana en un turno es muy malo para la salud del proyecto y
los diseñadores. Esta práctica esencial intenta motivar a los miembros del
equipo a trabajar intensamente durante sus horas de trabajo, y después tomar
un descanso para que cuando vuelvan estén relajados y menos estresados. Esto
ayuda a los miembros del equipo a identificar los problemas más rápidamente, y
previene errores costosos y omisiones debido al desempeño ineficaz o
desgastante.
3. El cliente en el sitio significa que un usuario experto en los aspectos de
negocios del proyecto en desarrollo está en el sitio durante este proceso. Esta
persona es fundamental para el proyecto, escribe las historias del usuario, comunica
a los miembros del equipo, ayuda a priorizar y equilibrar las necesidades de largo
plazo del negocio y toma decisiones sobre qué características se deben incluir
primero.
4. La programación en parejas es una práctica esencial importante. Significa que
usted trabaja con otro programador de su propia elección. Ambos codifican, ambos
aplican las pruebas. Con frecuencia, la persona con más experiencia tomará el
mando de la codificación inicial, pero conforme se involucra la persona con menos
experiencia, cualquiera de los dos que tenga la visión más clara de la meta trabajaría
en la codificación. Cuando le pide a otra persona que trabaje con usted, el
protocolo de la programación en parejas dice que está obligada a aceptar.
Trabajar con otro programador le ayuda a aclarar su pensamiento. Las parejas
cambian con frecuencia, sobre todo durante la fase de exploración del proceso
de desarrollo. La programación en parejas ahorra tiempo, reduce las
distracciones, activa la creatividad y es una forma divertida de programar.
Proceso y Herramientas del Desarrollo De XP
Ahora que ha aprendido algo de las actividades, los recursos y las prácticas esenciales de
XP, podemos poner en práctica dicho conocimiento. Esta sección describe el proceso de
desarrollo de la programación extrema, explica los detalles involucrados en el registro de
las historias del usuario y examina algunas de las herramientas disponibles actualmente
para desarrollar sistemas con un enfoque de XP.
Proceso de desarrollo de XP. La programación extrema también posee un proceso de

desarrollo, pero es mucho más interactivo, reiterativo e integrador que el del SDLC. Sin
embargo, XP no guía al desarrollador a través de las fases. Más bien es incremental y con
frecuencia las actividades se hacen al mismo tiempo. Observe que diario se hacen
muchos pasos del ciclo de XP. Esto contrasta claramente con el SDLC, mismo que
procede a un paso mucho más lento y para el cual algunas actividades (el análisis de
requerimientos, probar, etc.) deben ser completadas en fases distintas. El proceso de XP
permite lograr las actividades.
56
Las cinco fases del proceso de desarrollo de XP son la exploración, planeación, iteracio
nes a la primera versión, puesta en producción y mantenimiento. La sección siguiente
describe específicamente cómo se despliega una sesión típica de trabajo de XP durante
el proceso de desarrollo. Por ejemplo, el proceso típico sería asumir una tarea que se
relaciona directamente a una característica del sistema que un cliente desea,
probarla, implementarla en un diseño existente, e integrarla, todo esto durante un solo
episodio del desarrollo. El día podría empezar al analizar el reporte de un usuario pedido
en una cédula, en el cual se registra una tarea específica. Durante un informe, pedido
para la reunión, usted hace unas preguntas sobre el trabajo hecho el día anterior que
podría ayudar en esta tarea. Después le pide a otro programador que le ayude en la tarea.
Se consulta rápidamente a otros expertos en el sitio que podrían conocer las respuestas a
las preguntas específicas.
Después se consulta el paquete existente de casos de prueba. Probablemente

algunos se aplicarán y algunos otros se deberían escribir. El próximo paso sería anotar la
siguiente tarea en una lista especial. Después podría escribir un caso de prueba para
cualquier cosa que esté intentando averiguar. Finaliza y lo ejecuta. Probablemente fallará.
Usted y su compañero miran otros casos de prueba y depuran lo que escribieron.
Continúa con el siguiente caso de prueba, y el siguiente. Finalmente, usted llega al último
elemento de su lista de pendientes, que sería reestructurar los otros casos de pruebas; y
lo hace. Usted carga la versión actualizada y los cambios. Después aplica todos los
casos de prueba, depura cualquiera que no se ejecute y repara el código.
Cuando lo ejecuta nuevamente y funciona, usted ha terminado. Entonces el código se

puede liberar. Aún se podría estar preguntando cómo iniciar una tarea de desarrollo de
XP. Un autor experimentado consigue ir directamente al corazón del problema y sólo
siendo ligeramente gracioso, escribió: "Escoja su peor problema, resuélvalo con XP.
Cuando deje de ser su peor problema, repita" (Wells, citado por Beck, 2000, p. 123). De
esta forma, está mostrando una gran valentía. Se está enfocando en resolver primero
su problema más urgente, y está aplicando las estrategias de desarrollo de XP para
trabajar a través del problema de probar, codificar, escuchar, diseñar e integrar.
Está completando todas las tareas del desarrollo de XP en cada asignación de la
programación diaria y está reconociendo que el proceso de mejorar el sistema y dirigirse
a los problemas graves simple y directamente son la clave para el éxito.
Aún y cuando el título de esta sección sea "Cómo escribir las historias de XP", el énfasis
en la creación de las historias del usuario está en la interacción hablada entre
desarrolladores y usuarios, no en la comunicación escrita. En las historias del
usuario, el desarrollador ante todo busca identificar los requerimientos valiosos del
usuario de negocios. Generalmente los usuarios estarán ocupados diariamente en las
conversaciones con los desarrolladores sobre el significado de las historias del
usuario que han escrito. Estas conversaciones frecuentes son interacciones
determinadas que tienen como su meta la prevención de malos entendidos o malas
interpretaciones de los requerimientos del usuario. Por lo tanto, las historias del
usuario sirven como recordatorios para los desarrolladores que deben sostener
conversaciones seguras para dichos requerimientos.
Hay muchos tipos diferentes de herramientas disponibles que dan soporte a las
actividades que necesitaría realizar al hacer el desarrollo de XP. Se incluyen
herramientas que facilitan la colaboración tales como Wilci Wiki, Whiteboard, Project
Web, NetMeeting e IBM's Rational Project Console. También hay herramientas tales
como IBM's Pational ClearCase, Visual Intercept, Compuware Track Record y Bliplt que
dan soporte a la admi nistración de defectos.
Los probadores unitarios automatizados, probadores de aceptación y probadores de

GUI incluyen JUnit, ComUnit, VBUnit, Nunit, httpUnit y Rational Visual Test Tools.
DevPartner Code Review ayuda con el control de calidad. Además hay herramientas que
ayudan con la medición del sistema y desempeño de componentes tales como
Jmeter, JUnitPerf, PerfMon, TrueTime, RealTime y Microsoft Visual Studio Analyzer.
También hay herramientas que ayudan con la administración de la configuración del
57
código fuente, incluyendo CVS, Visual Source Safe y PVCS. Por último, hay una clase
de herramientas con la cual probablemente ya está familiarizado, los entornos de
desarrollo de IBM VisualAge, Microsoft Visual Studio .NET y JBuilder.
Scrum
Scrum es una metodología para la gestión y desarrollo de software basada en un proceso

iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de
software. Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de
software, puede ser utilizado en equipos de mantenimiento de software, o en una
aproximación de gestión de programas.
En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación

holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos
comerciales. Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual
las fases se traslapan de manera intensa y el proceso completo es realizado por un equipo
con funciones transversales, como en el rugby, donde el equipo entero «actúa como un
solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a
otro».[cita requerida] Los casos de estudio provienen de las industrias automovilísticas, así
como de fabricación de máquinas fotográficas, computadoras e impresoras.
En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions
(A problemas malvados, soluciones virtuosas), se refirieron a esta aproximación como
Scrum, un término propio del rugby mencionado en el artículo por Takeuchi y Nonaka.
A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a
poner en práctica el scrum en su compañía, Advanced Development Methods. Por aquel
tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el
primero en denominarla Scrum. En 1995 Schwaber y Sutherland, durante el OOPSLA '95
desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum,
siendo ésta la primera aparición pública de la metodología. Durante los años siguientes,
Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así
como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a
lo que ahora se le conoce como scrum. En 2001, Schwaber y Mike Beedle describieron la
metodología en el libro Agile Software Development with Scrum.
Características de Scrum
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que

puede tomarse como punto de partida para definir el proceso de desarrollo que se
ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que
mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner,
que representa a los stakeholders (clientes externos o internos), y el Team que incluye a
los desarrolladores.
Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo),
el equipo crea un incremento de software potencialmente entregable (utilizable). El
conjunto de características que forma parte de cada sprint viene del Product Backlog, que
es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los
elementos del Product Backlog que forman parte del sprint se determinan durante la
reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los
elementos del Product Backlog que quiere ver completados y los hace del conocimiento
del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede
comprometerse a completar durante el siguiente sprint.[4] Durante el sprint, nadie puede
cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el
sprint.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de

todos los miembros del equipo, y la comunicación verbal entre todos los miembros y
disciplinas involucrados en el proyecto.
58
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes

pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado
requirements churn), y que los desafíos impredecibles no pueden ser fácilmente
enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una
aproximación pragmática, aceptando que el problema no puede ser completamente
entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar
rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que

van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las
mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco
esfuerzo para comenzarse a utilizar.
Roles en Scrum
En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas.
El nombre de los grupos están inspirados en el chiste sobre un cerdo y una gallina que se
relata a continuación.
Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey,
¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea,
¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta: "¿Por qué no lo
llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría
comprometido pero tú solamente estarías involucrada".
De esta forma, los cerdos están comprometidos a construir software de manera regular y
frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente
irrelevantes porque, si éste falla, no son un cerdo, es decir, no son los que de manera
comprometida ponen su propio pellejo (y carne) para sacar el proyecto adelante. Las
necesidades, deseos, ideas e influencias de los roles gallina se tienen en cuenta, pero no
de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum.
Roles "Cerdo"
Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos
son los que "ponen el jamón en el plato".
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum
trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe
historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los
obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es
el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección
entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que
el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas
se cumplan.
Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9
personas con las habilidades transversales necesarias para realizar el trabajo (diseñador,
desarrollador, etc).
Roles "Gallina"
Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en
cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el
59
proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es

importante que esa gente participe y entregue retroalimentación con respecto a la salida
del proceso a fin de revisar y planear cada sprint.
Análisis de la frase "Rol gallina": La gallina alimenta al proyecto "poniendo huevos", no se

ve comprometida como el cerdo que va al matadero.
Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el
bosque cuando no hay nadie ¿Hace ruido? Aqui la definicion sería Si el software no es
usado ¿fue alguna vez escrito?.
Stakeholders (Clientes, Proveedores, Inversores)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el
beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del
sprint.
Managers
Es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama
"daily standup". El scrum tiene unas guías específicas:
• La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por

el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una
gallina de plástico del cuello, etc)
• Todos son bienvenidos, pero solo los "cerdos" pueden hablar.
• La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño
del equipo.
• Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión
corta)
• La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
• ¿Qué has hecho desde ayer?

• ¿Qué es lo que estás planeando hacer hoy?
• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel
del ScrumMaster recordar estos impedimentos).
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
• Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose

especialmente en áreas de solapamiento e integración.
• Asiste una persona asignada por cada equipo.
La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:
• ¿Qué ha hecho tu equipo desde nuestra última reunión?

• ¿Qué hará tu equipo antes que nos volvamos a reunir?
• ¿Hay algo que demora o estorba a tu equipo?
• ¿Estás a punto de poner algo en el camino del otro equipo?
60
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva
a cabo.
• Seleccionar que trabajo se hará

• Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará
hacer el trabajo.
• Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual
Sprint
• Ocho horas como límite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y
la “Retrospectiva del Sprint”
Reunión de Revisión del Sprint (Sprint Review Meeting)
• Revisar el trabajo que fue completado y no completado

• Presentar el trabajo completado a los interesados (alias “demo”)
• El trabajo incompleto no puede ser demostrado
• Cuatro horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los
miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito
de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un
tiempo fijo de cuatro horas.
Documentos
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene
descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.
priorizadas según su valor para el negocio (business value). Es el qué va a ser construido.
Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del
valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al
product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las
diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la
que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a
que su ROI será más alto.
Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a
implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con
ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá
ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son
tomadas por los miembros del equipo del modo que les parezca oportuno.
Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando
una línea que conecte los puntos de todos los Sprints completados, podremos ver el
progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que
todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no
varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha
terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si
durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en
61
determinados segmentos, y si se modifican algunos requisitos la pendiente variará o

incluso valdrá cero en algunos tramos.
Scrum aplicado al desarrollo de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se

emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y
flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel

Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en
VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo
presentó junto con Ken Schwaber como proceso formal, también para gestión del
desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los
promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado
como modelo ágil por la Agile Alliance.
62
REFERENCIAS BIBLIOGRÁFICAS
• IEEE Std 830-1998 IEEE. Recommended Practice for Software

Requirements Specifications – Description.
• Wiegers, Karl E. (2003). Software Requirements: Practical techniques
for gathering and managing requirements throughout the product
development cycle, 2nd ed., Redmond: Microsoft Press. ISBN 0-7356-
1879-8.
• McConnell, Steve (1996). Rapid Development: Taming Wild Software
Schedules, 1st ed., Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
• Andrew Stellman and Jennifer Greene (2005). Applied Software Project
Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
• 004.1 P85. Pressman, Roger S. Ingeniería del Software. Ed. McGraw Hill,
2002.
• 004.1 S67. Sommerville, Ian. Ingeniería del Software. Ed. Pearson
Educación, 2005.
63

Ingenieria de Requerimientos - Material de Estudio

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Requerimientos - Material de Estudio

Cargado por

Copyright:

Formatos disponibles

ASIGNATURA

Universidad Continental de Ciencias e Ingeniería

Ingeniería de Requerimientos, es una asignatura diseñada para proporcionar al

En general, los contenidos propuestos en el material de estudio, se dividen en los

Es recomendable que el estudiante desarrolle una permanente lectura de estudio

Agradecemos a quienes con sus aportes y sugerencias han contribuido a recopilar

Tema Nº 1: Introducción a la Ingeniería de Requerimientos

¿Por qué importan los requerimientos?

En uno de los párrafos más citados en la bibliografía de la Ingeniería del

Los requerimientos se deben descubrir antes de empezar a construir un producto, y

¿Qué es la Ingeniería de Requerimientos (IR)?

La Ingeniería de Requerimientos se define como un "conjunto de actividades en las

Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las

Los Requerimientos fueron definidos por la IEEE como [IEEE90]:

1. Condición o capacidad requerida por el usuario para resolver un

• Rama de la ingeniería del software que trata con el establecimiento de los

• Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer

• Ingeniería de Requerimientos es la disciplina para desarrollar una

• Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y

• Es el proceso mediante el cual se intercambian diferentes puntos de vista

Cuando nos encontramos al frente de un proyecto de desarrollo de sistemas es

En el proceso de Ingeniería de Requerimientos la validación de los diferentes

La construcción de prototipos constituye un método alternativo, que da como

El análisis de requerimientos establece el proceso de definición de requerimientos

Como resultado del análisis se desarrolla la especificación de requerimientos del

Una vez finalizado nuestro proyecto de desarrollo de sistemas, y contando con

¿Para qué un Proceso de Ingeniería de Requerimientos?

El Proceso de ingeniería de requerimientos es un conjunto estructurado de actividades,

Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la

Cualquier tarea en donde el resultado sea importante, se puede realizar de mejor

Un modelo es una simplificación de la realidad que incluye aquellos elementos que

Las diversas necesidades de las diferentes organizaciones comienzan a surgir a partir de

Modelo Tradicional en Cascada

Un modo alternativo de presentar modelos de actividad que toma en cuenta la

En este diagrama, el uso de la espiral implica que las diferentes actividades de la

¿Cómo realizar la ingeniería de requerimientos?

El proceso del establecimiento de requerimientos de un sistema de software, como

Para Pressman, en el proceso de análisis de requerimientos del software se puede

1. Reconocimiento del problema

El método Controlled Requirements Expression (CORE) es un conjunto de

1. Definición del problema.

2. Estructuración del punto de vista.

5. Modelación individual de puntos de vista.

6. Modelación combinada de punto de vista.

El proceso de ingeniería de requerimientos plantea que en esta fase hay que

El propósito de la elicitación de requerimientos es ganar conocimientos relevantes

Una especificación puede ser vista como un contrato entre usuarios y

La validación es el proceso que certifica que el modelo de los requerimientos

• Se incorpora una nueva pieza de información al modelo actual.

Tema Nº 2: Fases de la Ingeniería de Requerimientos

El análisis de requerimientos siempre comienza con una comunicación entre dos o

Normalmente encontramos que los clientes y analistas se enfrascan en el proyecto de

Con estos problemas presentes, se desarrollaron numerosas técnicas para tratar de

A continuación se resumen algunas de las más conocidas:

• Estudiar el dominio del problema: se debe conocer la terminología básica del

• Apertura: el entrevistador debe presentarse e informar al entrevistado sobre

Análisis de las entrevistas

Una vez realizada la entrevista es necesario leer las notas tomadas,

El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo

Este método comenzó en el ámbito de las empresas, aplicándose a temas tan

Como técnica de elicitación de requerimientos, el brainstorming puede ayudar a

Fases del brainstorming

Preparación: La preparación para una sesión de brainstorming requiere que