Resumen

El diseño y construcción de software de computadora es difícil, creativo y sencillamente

divertido. En realidad, elaborar software es tan atractivo que muchos desarrolladores
de software quieren ir directo a él antes de haber tenido el entendimiento claro de lo
que se necesita. Argumentan que las cosas se aclararán a medida que lo elaboren, que
los participantes en el proyecto podrán comprender sus necesidades sólo después de
estudiar las primeras iteraciones del software, que las cosas cambian tan rápido que
cualquier intento de entender los requerimientos en detalle es una pérdida de tiempo,
que las utilidades salen de la producción de un programa que funcione y que todo lo
demás es secundario.
La ingeniería de requerimientos tiende un puente para el diseño y la construcción. Otros
tal vez sugieran que empieza con una definición más amplia del sistema, donde el
software no es más que un componente del dominio del sistema mayor. Pero sin
importar el punto de arranque, el recorrido por el puente lo lleva a uno muy alto sobre
el proyecto, lo que le permite examinar el contexto del trabajo de software que debe
realizarse; las necesidades específicas que deben abordar el diseño y la construcción; las
prioridades que guían el orden en el que se efectúa el trabajo, y la información, las
funciones y los comportamientos que tendrán un profundo efecto en el diseño
resultante.
Christel y Kang [Cri92] identificaron cierto número de problemas que se encuentran
cuando ocurre la indagación:

 Problemas de alcance. La frontera de los sistemas está mal definida o los clientes
o usuarios finales especifican detalles técnicos innecesarios que confunden, más
que clarifican, los objetivos generales del sistema.
 Problemas de entendimiento. Los clientes o usuarios no están completamente
seguros de lo que se necesita, comprenden mal las capacidades y limitaciones de
su ambiente de computación, no entienden todo el dominio del problema, tienen
problemas para comunicar las necesidades al ingeniero de sistemas, omiten
información que creen que es “obvia”, especifican requerimientos que están en
conflicto con las necesidades de otros clientes o usuarios, o solicitan
requerimientos ambiguos o que no pueden someterse a prueba.
 Problemas de volatilidad. Los requerimientos cambian con el tiempo.

- Identificación de los participantes

Sommerville y Sawyer [Som97] definen participante como “cualquier persona que se
beneficie en forma directa o indirecta del sistema en desarrollo”. Ya se identificaron los
candidatos habituales: gerentes de operaciones del negocio, gerentes de producto,
personal de mercadotecnia, clientes internos y externos, usuarios finales, consultores,
ingenieros de producto, ingenieros de software e ingenieros de apoyo y mantenimiento,
entre otros. Cada participante tiene un punto de vista diferente respecto del sistema,
obtiene distintos beneficios cuando éste se desarrolla con éxito y corre distintos riesgos
si fracasa el esfuerzo de construcción.

- Reconocer los múltiples puntos de vista

Debido a que existen muchos participantes distintos, los requerimientos del sistema se
explorarán desde muchos puntos de vista diferentes. Por ejemplo, el grupo de
mercadotecnia se interesa en funciones y características que estimularán el mercado
potencial, lo que hará que el nuevo sistema sea fácil de vender. Los gerentes del negocio
tienen interés en un conjunto de características para que se elabore dentro del
presupuesto y que esté listo para ocupar nichos de mercado definidos. Los usuarios
finales tal vez quieran características que les resulten familiares y que sean fáciles de
aprender y usar. Los ingenieros de software quizá piensen en funciones invisibles para
los participantes sin formación técnica, pero que permitan una infraestructura que dé
apoyo a funciones y características más vendibles. Los ingenieros de apoyo tal vez se
centren en la facilidad del software para recibir mantenimiento.
Cada uno de estos integrantes (y otros más) aportará información al proceso de
ingeniería de los requerimientos. A medida que se recaba información procedente de
múltiples puntos de vista, los requerimientos que surjan tal vez sean inconsistentes o
estén en conflicto uno con otro. Debe clasificarse toda la información de los
participantes (incluso los requerimientos inconsistentes y conflictivos) en forma que
permita a quienes toman las decisiones escoger para el sistema un conjunto de
requerimientos que tenga coherencia interna.

- Trabajar hacia la colaboración

Si en un proyecto de software hay involucrados cinco participantes, tal vez se tengan
cinco (o más) diferentes opiniones acerca del conjunto apropiado de requerimientos. En
los primeros capítulos se mencionó que, para obtener un sistema exitoso, los clientes (y
otros participantes) debían colaborar entre sí (sin pelear por insignificancias) y con los
profesionales de la ingeniería de software.
El trabajo del ingeniero de requerimientos es identificar las áreas de interés común (por
ejemplo, requerimientos en los que todos los participantes estén de acuerdo) y las de
conflicto o incongruencia (por ejemplo, requerimientos que desea un participante, pero
que están en conflicto con las necesidades de otro). Es la última categoría la que, por
supuesto, representa un reto.
 - Hacer las primeras preguntas
Las preguntas que se hacen en la concepción del proyecto deben estar “libres del
contexto” [Gau89]. El primer conjunto de ellas se centra en el cliente y en otros
participantes, en las metas y beneficios generales. Por ejemplo, tal vez se pregunte:

 ¿Quién está detrás de la solicitud de este trabajo?

 ¿Quién usará la solución?
 ¿Cuál será el beneficio económico de una solución exitosa?
 ¿Hay otro origen para la solución que se necesita?
Estas preguntas ayudan a identificar a todos los participantes con interés en el software
que se va a elaborar. Además, las preguntas identifican el beneficio mensurable de una
implementación exitosa y las posibles alternativas para el desarrollo de software
personalizado.
Las preguntas siguientes permiten entender mejor el problema y hacen que el cliente
exprese sus percepciones respecto de la solución:

 ¿Cuál sería una “buena” salida generada por una solución exitosa?
 ¿Qué problemas resolvería esta solución?
 ¿Puede mostrar (o describir) el ambiente de negocios en el que se usaría la
solución?
 ¿Hay aspectos especiales del desempeño o restricciones que afecten el modo en
el que se enfoque la solución?
Las preguntas finales se centran en la eficacia de la actividad de comunicación en sí.
Gause y Weinberg [Gau89] las llaman “metapreguntas” y proponen la siguiente lista
(abreviada):

 ¿Es usted la persona indicada para responder estas preguntas? ¿Sus respuestas
son “oficiales”?
 ¿Mis preguntas son relevantes para el problema que se tiene?
 ¿Estoy haciendo demasiadas preguntas?
 ¿Puede otra persona dar información adicional?
 ¿Debería yo preguntarle algo más?
Estas preguntas (y otras) ayudarán a “romper el hielo” y a iniciar la comunicación, que
es esencial para una indagación exitosa. Pero una reunión de preguntas y respuestas no
es un enfoque que haya tenido un éxito apabullante. En realidad, la sesión de preguntas
y respuestas sólo debe usarse para el primer encuentro y luego ser reemplazada por un
formato de indagación de requerimientos que combine elementos de solución de
problemas, negociación y especificación. En la sección 5.3 se presenta un enfoque de
este tipo.
 - Despliegue de la función de calidad
El despliegue de la función de calidad (DFC) es una técnica de administración de la
calidad que traduce las necesidades del cliente en requerimientos técnicos para el
software. El DFC “se concentra en maximizar la satisfacción del cliente a partir del
proceso de ingeniería del software” [Zul92]. Para lograr esto, el DFC pone el énfasis en
entender lo que resulta valioso para el cliente y luego despliega dichos valores en todo
el proceso de ingeniería. El DFC identifica tres tipos de requerimientos [Zul92]:
Requerimientos normales. Objetivos y metas que se establecen para un producto o
sistema durante las reuniones con el cliente. Si estos requerimientos están presentes, el
cliente queda satisfecho. Ejemplos de requerimientos normales son los tipos de gráficos
pedidos para aparecer en la pantalla, funciones específicas del sistema y niveles de
rendimiento definidos.
Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean tan
importantes que el cliente no los mencione de manera explícita. Su ausencia causará
mucha insatisfacción. Algunos ejemplos de requerimientos esperados son: fácil
interacción humano/máquina, operación general correcta y confiable, y facilidad para
instalar el software.
Requerimientos emocionantes. Estas características van más allá de las expectativas del
cliente y son muy satisfactorias si están presentes. Por ejemplo, el software para un
nuevo teléfono móvil viene con características estándar, pero si incluye capacidades
inesperadas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a todos
los usuarios del producto.
Aunque los conceptos del DFC son aplicables en todo el proceso del software [Par96a],
hay técnicas específicas de aquél que pueden aplicarse a la actividad de indagación de
los requerimientos.
El DFC utiliza entrevistas con los clientes, observación, encuestas y estudio de datos
históricos (por ejemplo, reportes de problemas) como materia prima para la actividad
de recabación La escena: Sala de juntas. Está en marcha la primera
reunión para recabar los requerimientos.
Participantes: Jamie Lazar, integrante del equipo de software; Vinod Raman, miembro
del equipo de software; Ed Robbins, miembro del equipo de software; Doug Miller,
gerente de ingeniería de software; tres trabajadores de mercadotecnia; un
representante de ingeniería del producto, y un facilitador.
La conversación: Facilitador (apunta en un pizarrón): De modo que ésa es la lista actual
de objetos y servicios para la función de seguridad del hogar.
Persona de mercadotecnia: Eso la cubre, desde nuestro punto de vista.
Vinod: ¿No dijo alguien que quería que toda la funcionalidad de CasaSegura fuera
accesible desde internet? Eso incluiría la función de seguridad, ¿o no? Persona de
mercadotecnia: Sí, así es… tendremos que añadir esa funcionalidad y los objetos
apropiados.

- Escenarios de uso
A medida que se reúnen los requerimientos, comienza a materializarse la visión general
de funciones y características del sistema. Sin embargo, es difícil avanzar hacia
actividades más técnicas de la ingeniería de software hasta no entender cómo
emplearán los usuarios finales dichas funciones y características. Para lograr esto, los
desarrolladores y usuarios crean un conjunto de escenarios que identifican la naturaleza
de los usos para el sistema que se va a construir. Los escenarios, que a menudo se llaman
casos de uso [Jac92], proporcionan la descripción de la manera en la que se utilizará el
sistema.

- Elementos del modelo de requerimientos

Hay muchas formas diferentes de concebir los requerimientos para un sistema basado
en computadora. Algunos profesionales del software afirman que es mejor seleccionar
un modo de representación (por ejemplo, el caso de uso) y aplicarlo hasta excluir a todos
los demás. Otros piensan que es más benéfico usar cierto número de modos de
representación distintos para ilustrar el modelo de requerimientos. Los modos
diferentes de representación fuerzan a considerar los requerimientos desde distintos
puntos de vista, enfoque que tiene una probabilidad mayor de detectar omisiones,
inconsistencia y ambigüedades.
Los elementos específicos del modelo de requerimientos están determinados por el
método de análisis de modelado (véanse los capítulos 6 y 7) que se use. No obstante, la
mayoría de modelos tiene en común un conjunto de elementos generales.

- Patrones de análisis
Cualquiera que haya hecho la ingeniería de los requerimientos en varios proyectos de
software ha observado que ciertos problemas son recurrentes en todos ellos dentro de
un dominio de aplicación específico.18 Estos patrones de análisis [Fow97] sugieren
soluciones (por ejemplo, una clase, función o comportamiento) dentro del dominio de
la aplicación que pueden volverse a utilizar cuando se modelen muchas aplicaciones.

- Requerimientos funcionales
Los requerimientos funcionales para un sistema refieren lo que el sistema debe hacer.
Tales requerimientos dependen del tipo de software que se esté desarrollando, de los
usuarios esperados del software y del enfoque general que adopta la organización
cuando se escriben los requerimientos. Al expresarse como requerimientos del usuario,
los requerimientos funcionales se describen por lo general de forma abstracta que
entiendan los usuarios del sistema. Sin embargo, requerimientos funcionales más
específicos del sistema detallan las funciones del sistema, sus entradas y salidas, sus
excepciones, etcétera.

- Requerimientos no funcionales
Los requerimientos no funcionales, como indica su nombre, son requerimientos que no
se relacionan directamente con los servicios específicos que el sistema entrega a sus
usuarios. Pueden relacionarse con propiedades emergentes del sistema, como
fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa, pueden
definir restricciones sobre la implementación del sistema, como las capacidades de los
dispositivos I/O o las representaciones de datos usados en las interfaces con otros
sistemas. Los requerimientos no funcionales, como el rendimiento, la seguridad o la
disponibilidad, especifican o restringen por lo general características del sistema como
un todo.
Los requerimientos no funcionales a menudo son más significativos que los
requerimientos funcionales individuales. Es común que los usuarios del sistema
encuentren formas para trabajar en torno a una función del sistema que realmente no
cubre sus necesidades. No obstante, el fracaso para cubrir los requerimientos no
funcionales haría que todo el sistema fuera inútil. Por ejemplo, si un sistema de
aeronave no cubre sus requerimientos de fiabilidad, no será certificado para su
operación como dispositivo seguro; si un sistema de control embebido fracasa para
cubrir sus requerimientos de rendimiento, no operarán correctamente las funciones de
control.
1. Los requerimientos no funcionales afectan más la arquitectura global de un
sistema que los componentes individuales. Por ejemplo, para garantizar que se
cumplan los requerimientos de rendimiento, quizá se deba organizar el sistema
para minimizar las comunicaciones entre componentes.
2. Un requerimiento no funcional individual, como un requerimiento de seguridad,
podría generar algunos requerimientos funcionales relacionados que definan
nuevos servicios del sistema que se requieran. Además, también podría generar
requerimientos que restrinjan los requerimientos ya existentes.

REQUERIMIENTO DEL PRODUCTO

El MHC-PMS estará disponible en todas las clínicas durante las horas de trabajo
normales (lunes a viernes, de 8:30 a 17:30). En cualquier día, los tiempos muertos dentro
de las horas laborales normales no rebasarán los cinco segundos.
REQUERIMIENTOS DE LA ORGANIZACIÓN
Los usuarios del sistema MHC-PMS se acreditarán a sí mismos con el uso de la tarjeta de
identidad de la autoridad sanitaria.
REQUERIMIENTOS EXTERNOS
Como establece la HStan-03-2006-priv, el sistema implementará provisiones para la
privacidad del paciente.
Los requerimientos no funcionales entran a menudo en conflicto e interactúan con otros
requerimientos funcionales o no funcionales. Por ejemplo, el requerimiento de
autenticación en la figura 4.4 requiere, indiscutiblemente, la instalación de un lector de
tarjetas en cada computadora unida al sistema. Sin embargo, podría haber otro
requerimiento que solicite acceso móvil al sistema desde las computadoras portátiles
de médicos o enfermeras. Por lo general, las computadoras portátiles no están
equipadas con lectores de tarjeta, de modo que, ante tales circunstancias,
probablemente deba permitirse algún método de autenticación alternativo.

El documento de requerimientos de software

Llamado algunas veces especificación de requerimientos de software o SRS, es un
comunicado oficial de lo que deben implementar los desarrolladores del sistema.
Incluye tanto los requerimientos del usuario para un sistema, como una especificación
detallada de los requerimientos del sistema. En ocasiones, los requerimientos del
usuario y del sistema se integran en una sola descripción. En otros casos, los
requerimientos del usuario se definen en una introducción a la especificación de
requerimientos del sistema. Si hay un gran número de requerimientos, los
requerimientos del sistema detallados podrían presentarse en un documento aparte.
Son esenciales los documentos de requerimientos cuando un contratista externo diseña
el sistema de software. Sin embargo, los métodos de desarrollo ágiles argumentan que
los requerimientos cambian tan rápidamente que un documento de requerimientos se
vuelve obsoleto tan pronto como se escribe, así que el esfuerzo se desperdicia en gran
medida. En lugar de un documento formal, los enfoques como la programación extrema
(Beck, 1999) recopilan de manera incremental requerimientos del usuario y los escriben
en tarjetas como historias de usuario. De esa manera, el usuario da prioridad a los
requerimientos para su implementación en el siguiente incremento del sistema.
Este enfoque es adecuado para sistemas empresariales donde los requerimientos son
inestables. Sin embargo, aún resulta útil escribir un breve documento de apoyo que
defina los requerimientos de la empresa y los requerimientos de confiabilidad para el
sistema; es fácil olvidar los requerimientos que se aplican al sistema como un todo,
cuando uno se enfoca en los requerimientos funcionales para la siguiente liberación del
sistema.
La diversidad de posibles usuarios significa que el documento de requerimientos debe
ser un compromiso entre la comunicación de los requerimientos a los clientes, la
definición de los requerimientos con detalle preciso para desarrolladores y
examinadores, y la inclusión de información sobre la posible evolución del sistema. La
información de cambios anticipados ayuda tanto a los diseñadores del sistema a evitar
decisiones de diseño restrictivas, como a los ingenieros de mantenimiento del sistema
que deben adaptar el sistema a los nuevos requerimientos.
El nivel de detalle que se incluya en un documento de requerimientos depende del tipo
de sistema a diseñar y el proceso de desarrollo utilizado. Los sistemas críticos necesitan
tener requerimientos detallados porque la seguridad y la protección también deben
analizarse de forma pormenorizada. Cuando el sistema lo desarrolla una compañía
independiente (por ejemplo, mediante la subcontratación), deben detallarse y
precisarse las especificaciones del sistema. Si se utiliza un proceso de desarrollo iterativo
interno, entonces el documento de requerimientos suele ser mucho menos detallado y
cualquier ambigüedad puede resolverse durante el desarrollo del sistema.

- Especificación de requerimientos
La especificación de requerimientos es el proceso de escribir, en un documento de
requerimientos, los requerimientos del usuario y del sistema. De manera ideal, los
requerimientos del usuario y del sistema deben ser claros, sin ambigüedades, fáciles de
entender, completos y consistentes. Esto en la práctica es difícil de lograr, pues los
participantes interpretan los requerimientos de formas diferentes y con frecuencia en
los requerimientos hay conflictos e inconsistencias inherentes.
Los requerimientos del usuario para un sistema deben describir los requerimientos
funcionales y no funcionales, de forma que sean comprensibles para los usuarios del
sistema que no cuentan con un conocimiento técnico detallado. De manera ideal,
deberían especificar sólo el comportamiento externo del sistema. El documento de
requerimientos no debe incluir detalles de la arquitectura o el diseño del sistema. En
consecuencia, si usted escribe los requerimientos del usuario, no tiene que usar jerga
de software, anotaciones estructuradas o formales. Debe escribir los requerimientos del
usuario en lenguaje natural, con tablas y formas sencillas, así como diagramas intuitivos.
Los requerimientos del usuario se escriben casi siempre en lenguaje natural,
complementado con diagramas y tablas adecuados en el documento de requerimientos.
Los requerimientos del sistema se escriben también en lenguaje natural, pero de igual
modo se utilizan otras notaciones basadas en formas, modelos gráficos del sistema o
modelos matemáticos del sistema.

- Especificación en lenguaje natural

Desde los albores de la ingeniería de software, el lenguaje natural se usa para escribir
los requerimientos de software. Es expresivo, intuitivo y universal. También es
potencialmente vago, ambiguo y su significado depende de los antecedentes del lector.
Como resultado, hay muchas propuestas para formas alternativas de escribir los
requerimientos. Sin embargo, ninguna se ha adoptado de manera amplia, por lo que el
lenguaje natural seguirá siendo la forma más usada para especificar los requerimientos
del sistema y del software. Para minimizar la interpretación errónea al escribir los
requerimientos en lenguaje natural, se recomienda seguir algunos lineamientos
sencillos:
 1. Elabore un formato estándar y asegúrese de que todas las definiciones de
requerimientos se adhieran a dicho formato. Al estandarizar el formato es
menos probable cometer omisiones y más sencillo comprobar los
requerimientos. El formato que usa el autor expresa el requerimiento en una
sola oración. A cada requerimiento de usuario se asocia un enunciado de razones
para explicar por qué se propuso el requerimiento. Las razones también pueden
incluir información sobre quién planteó el requerimiento (la fuente del
requerimiento), de modo que usted conozca a quién consultar en caso de que
cambie el requerimiento.
2. Utilice el lenguaje de manera clara para distinguir entre requerimientos
obligatorios y deseables. Los primeros son requerimientos que el sistema debe
soportar y, por lo general, se escriben en futuro “debe ser”. En tanto que los
requerimientos deseables no son necesarios y se escriben en tiempo
pospretérito o como condicional “debería ser”.
3. Use texto resaltado (negrilla, cursiva o color) para seleccionar partes clave del
requerimiento.
4. No deduzca que los lectores entienden el lenguaje técnico de la ingeniería de
software. Es fácil que se malinterpreten palabras como “arquitectura” y
“módulo”. Por lo tanto, debe evitar el uso de jerga, abreviaturas y acrónimos.
5. Siempre que sea posible, asocie una razón con cada requerimiento de usuario.
La razón debe explicar por qué se incluyó el requerimiento. Es particularmente
útil cuando los requerimientos cambian, pues ayuda a decidir cuáles cambios
serían indeseables.

- Especificaciones estructuradas
El lenguaje natural estructurado es una manera de escribir requerimientos del sistema,
donde está limitada la libertad del escritor de requerimientos y todos éstos se anotan
en una forma estándar. Aunque este enfoque conserva la mayoría de la expresividad y
comprensibilidad del lenguaje natural, asegura que haya cierta uniformidad sobre la
especificación. Las anotaciones en lenguaje estructurado emplean plantillas para
especificar requerimientos del sistema. La especificación utiliza constructos de lenguaje
de programación para mostrar alternativas e iteración, y destaca elementos clave con el
uso de sombreado o de fuentes distintas.
Cuando use una forma estándar para especificar requerimientos funcionales, debe
incluir la siguiente información:
1. Una descripción de la función o entidad a especificar.
2. Una descripción de sus entradas y sus procedencias.
3. Una descripción de sus salidas y a dónde se dirigen.
4. Información sobre los datos requeridos para el cálculo u otras entidades en el
sistema que se utilizan (la parte “requiere”).
5. Una descripción de la acción que se va a tomar.
 6. Si se usa un enfoque funcional, una precondición establece lo que debe ser
verdadero antes de llamar a la función, y una postcondición especifica lo que es
verdadero después de llamar a la función.
7. Una descripción de los efectos colaterales (si acaso hay alguno) de la operación.

- Procesos de ingeniería de requerimientos

Como vimos en el capítulo 2, los procesos de ingeniería de requerimientos incluyen
cuatro actividades de alto nivel. Éstas se enfocan en valorar si el sistema es útil para la
empresa (estudio de factibilidad), descubrir requerimientos (adquisición y análisis),
convertir dichos requerimientos en alguna forma estándar (especificación) y comprobar
que los requerimientos definan realmente el sistema que quiere el cliente (validación).
Este modelo en espiral acomoda enfoques al desarrollo, donde los requerimientos se
elaboraron con diferentes niveles de detalle. El número de iteraciones de la espiral
tiende a variar, de modo que la espiral terminará después de adquirir algunos o todos
los requerimientos del usuario. Se puede usar el desarrollo ágil en vez de la creación de
prototipos, de manera que se diseñen en conjunto los requerimientos y la
implementación del sistema.

- Adquisición y análisis de requerimientos

Después de un estudio de factibilidad inicial, la siguiente etapa del proceso de ingeniería
de requerimientos es la adquisición y el análisis de requerimientos. En esta actividad,
los ingenieros de software trabajan con clientes y usuarios finales del sistema para
descubrir el dominio de aplicación, qué servicios debe proporcionar el sistema, el
desempeño requerido de éste, las restricciones de hardware, etcétera.
En una organización, la adquisición y el análisis de requerimientos pueden involucrar a
diversas clases de personas. Un participante en el sistema es quien debe tener alguna
influencia directa o indirecta sobre los requerimientos del mismo. Los participantes
incluyen a usuarios finales que interactuarán con el sistema, y a cualquiera en una
organización que resultará afectada por él. Otros participantes del sistema pueden ser
los ingenieros que desarrollan o mantienen otros sistemas relacionados,
administradores de negocios, expertos de dominio y representantes de asociaciones
sindicales.
La adquisición y la comprensión de los requerimientos por parte de los participantes del
sistema es un proceso difícil por diferentes razones:
1. Los participantes con frecuencia no saben lo que quieren de un sistema de
cómputo, excepto en términos muy generales; pueden encontrar difícil articular
qué quieren que haga el sistema; pueden hacer peticiones inalcanzables porque
no saben qué es factible y qué no lo es.
2. Los participantes en un sistema expresan naturalmente los requerimientos con
sus términos y conocimientos implícitos de su trabajo. Los ingenieros de
 requerimientos, sin experiencia en el dominio del cliente, podrían no entender
dichos requerimientos.
3. Diferentes participantes tienen distintos requerimientos y pueden expresarlos
en variadas formas. Los ingenieros de requerimientos deben descubrir todas las
fuentes potenciales de requerimientos e identificar similitudes y conflictos.
4. Factores políticos llegan a influir en los requerimientos de un sistema. Los
administradores pueden solicitar requerimientos específicos del sistema, porque
éstos les permitirán aumentar su influencia en la organización.
5. El ambiente económico y empresarial donde ocurre el análisis es dinámico.
Inevitablemente cambia durante el proceso de análisis. Puede cambiar la
importancia de requerimientos particulares; o bien, tal vez surjan nuevos
requerimientos de nuevos participantes a quienes no se consultó originalmente.

- Descubrimiento de requerimientos
El descubrimiento de requerimientos (llamado a veces adquisición de requerimientos)
es el proceso de recopilar información sobre el sistema requerido y los sistemas
existentes, así como de separar, a partir de esta información, los requerimientos del
usuario y del sistema. Las fuentes de información durante la fase de descubrimiento de
requerimientos incluyen documentación, participantes del sistema y especificaciones de
sistemas similares. La interacción con los participantes es a través de entrevistas y
observaciones, y pueden usarse escenarios y prototipos para ayudar a los participantes
a entender cómo será el sistema. Los participantes varían desde administradores y
usuarios finales de un sistema hasta participantes externos como los reguladores,
quienes certifican la aceptabilidad del sistema.
Todas estas diferentes fuentes de requerimientos (participantes, dominio, sistemas) se
representan como puntos de vista del sistema, y cada visión muestra un subconjunto de
los requerimientos para el sistema. Diferentes puntos de vista de un problema enfocan
el problema de diferentes formas. Sin embargo, sus perspectivas no son totalmente
independientes, sino que por lo general se traslapan, de manera que tienen
requerimientos comunes. Usted puede usar estos puntos de vista para estructurar tanto
el descubrimiento como la documentación de los requerimientos del sistema.

- Entrevistas
Las entrevistas formales o informales con participantes del sistema son una parte de la
mayoría de los procesos de ingeniería de requerimientos. En estas entrevistas, el equipo
de ingeniería de requerimientos formula preguntas a los participantes sobre el sistema
que actualmente usan y el sistema que se va a desarrollar. Los requerimientos se derivan
de las respuestas a dichas preguntas. Las entrevistas son de dos tipos:
1. Entrevistas cerradas, donde los participantes responden a un conjunto de
preguntas preestablecidas.
 2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de
ingeniería de requerimientos explora un rango de conflictos con los participantes
del sistema y, como resultado, desarrolla una mejor comprensión de sus
necesidades.

- Escenarios
Por lo general, las personas encuentran más sencillo vincularse con ejemplos reales que
con descripciones abstractas. Pueden comprender y criticar un escenario sobre cómo
interactuar con un sistema de software. Los ingenieros de requerimientos usan la
información obtenida de esta discusión para formular los verdaderos requerimientos
del sistema.
Los escenarios son particularmente útiles para detallar un bosquejo de descripción de
requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción.
Cada escenario abarca comúnmente una interacción o un número pequeño de
interacciones posibles. Se desarrollan diferentes formas de escenarios y se ofrecen
varios tipos de información con diversos niveles de detalle acerca del sistema. Las
historias que se usan en programación extrema, estudiadas en el capítulo 3, son un tipo
de escenario de requerimientos.

- Casos de uso
Los casos de uso son una técnica de descubrimiento de requerimientos que se introdujo
por primera vez en el método Objectory (Jacobson et al., 1993).
Los casos de uso se documentan con el empleo de un diagrama de caso de uso de alto
nivel. El conjunto de casos de uso representa todas las interacciones posibles que se
describirán en los requerimientos del sistema. Los actores en el proceso, que pueden
ser individuos u otros sistemas, se representan como figuras sencillas. Cada clase de
interacción se constituye como una elipse con etiqueta. Líneas vinculan a los actores con
la interacción.
Los casos de uso identifican las interacciones individuales entre el sistema y sus usuarios
u otros sistemas. Cada caso de uso debe documentarse con una descripción textual.
Entonces pueden vincularse con otros modelos en el UML que desarrollará el escenario
con más detalle. Por ejemplo, una breve descripción del caso de uso.

- Etnografía
Los sistemas de software no existen aislados. Se usan en un contexto social y
organizacional, y dicho escenario podría derivar o restringir los requerimientos del
sistema de software. A menudo satisfacer dichos requerimientos sociales y
organizacionales es crítico para el éxito del sistema. Una razón por la que muchos
sistemas de software se entregan, y nunca se utilizan, es que sus requerimientos no
consideran de manera adecuada cómo afectaría el contexto social y organizacional la
operación práctica del sistema.
La etnografía es una técnica de observación que se usa para entender los procesos
operacionales y ayudar a derivar requerimientos de apoyo para dichos procesos. Un
analista se adentra en el ambiente laboral donde se usará el sistema. Observa el trabajo
diario y toma notas acerca de las tareas existentes en que intervienen los participantes.
El valor de la etnografía es que ayuda a descubrir requerimientos implícitos del sistema
que reflejan las formas actuales en que trabaja la gente, en vez de los procesos formales
definidos por la organización.
Las personas con frecuencia encuentran muy difícil articular los detalles de su trabajo,
porque es una segunda forma de vida para ellas. Entienden su trabajo, pero tal vez no
su relación con otras funciones en la organización. Los factores sociales y
organizacionales que afectan el trabajo, que no son evidentes para los individuos, sólo
se vuelven claros cuando los percibe un observador sin prejuicios. Por ejemplo, un grupo
de trabajo puede organizarse de modo que sus miembros conozcan el trabajo de los
demás y se suplan entre sí cuando alguien se ausenta. Es probable que esto no se
mencione durante una entrevista, pues el grupo podría no verlo como una parte integral
de su función.
La etnografía puede combinarse con la creación de prototipos (figura 4.16). La
etnografía informa del desarrollo del prototipo, de modo que se requieren menos ciclos
de refinamiento del prototipo. Más aún, la creación de prototipos se enfoca en la
etnografía al identificar problemas y preguntas que entonces pueden discutirse con el
etnógrafo. Siendo así, éste debe buscar las respuestas a dichas preguntas durante la
siguiente fase de estudio del sistema (Sommerville et al., 1993).

- Validación de requerimientos
La validación de requerimientos es el proceso de verificar que los requerimientos
definan realmente el sistema que en verdad quiere el cliente. Se traslapa con el análisis,
ya que se interesa por encontrar problemas con los requerimientos. La validación de
requerimientos es importante porque los errores en un documento de requerimientos
pueden conducir a grandes costos por tener que rehacer, cuando dichos problemas se
descubren durante el desarrollo del sistema o después de que éste se halla en servicio.
En general, el costo por corregir un problema de requerimientos al hacer un cambio en
el sistema es mucho mayor que reparar los errores de diseño o codificación. La razón es
que un cambio a los requerimientos significa generalmente que también deben cambiar
el diseño y la implementación del sistema. Más aún, el sistema debe entonces ponerse
a prueba de nuevo.
No hay que subestimar los problemas incluidos en la validación de requerimientos.
A final de cuentas, es difícil demostrar que un conjunto de requerimientos, de hecho, no
cubre las necesidades de los usuarios. Estos últimos necesitan una imagen del sistema
en operación, así como comprender la forma en que dicho sistema se ajustará a su
trabajo. Es difícil, incluso para profesionales de la computación experimentados, realizar
este tipo de análisis abstracto, y más aún para los usuarios del sistema.
 - Administración de requerimientos
Los requerimientos para los grandes sistemas de software siempre cambian. Una razón
es que dichos sistemas se desarrollaron por lo general para resolver problemas
“horrorosos”: aquellos problemas que no se pueden definir por completo. Como el
problema no se logra definir por completo, los requerimientos del software están
condenados también a estar incompletos. Durante el proceso de software, la
comprensión que los participantes tienen de los problemas cambia constantemente.
La administración de requerimientos es el proceso de comprender y controlar los
cambios en los requerimientos del sistema. Es necesario seguir la pista de
requerimientos individuales y mantener los vínculos entre los requerimientos
dependientes, de manera que pueda valorarse el efecto del cambio en los
requerimientos. También es preciso establecer un proceso formal para hacer cambios a
las propuestas y vincular éstos con los requerimientos del sistema. El proceso formal de
la administración de requerimientos debe comenzar tan pronto como esté disponible
un borrador del documento de requerimientos.
Sin embargo, hay que empezar a planear cómo administrar el cambio en los
requerimientos durante el proceso de adquisición de los mismos.

- Planeación de la administración de requerimientos

La planeación es una primera etapa esencial en el proceso de administración de
requerimientos. Esta etapa establece el nivel de detalle que se requiere en la
administración de requerimientos.
Para sistemas pequeños, quizá no sea necesario usar herramientas especializadas de
administración de requerimientos. El proceso de administración de requerimientos
puede apoyarse con el uso de funciones disponibles en procesadores de texto, hojas de
cálculo y bases de datos de PC. Sin embargo, para sistemas más grandes se requieren
herramientas de apoyo más especializadas. En las páginas Web del libro se incluyen
vínculos a información acerca de herramientas de administración de requerimientos.

- Administración del cambio en los requerimientos

La administración del cambio en los requerimientos debe aplicarse a todos los cambios
propuestos a los requerimientos de un sistema, después de aprobarse el documento de
requerimientos. La administración del cambio es esencial porque es necesario
determinar si los beneficios de implementar nuevos requerimientos están justificados
por los costos de la implementación. La ventaja de usar un proceso formal para la
administración del cambio es que todas las propuestas de cambio se tratan de manera
consistente y los cambios al documento de requerimientos se realizan en una forma
controlada.
Si un nuevo requerimiento tiene que implementarse urgentemente, siempre existe la
tentación para cambiar el sistema y luego modificar de manera retrospectiva el
documento de requerimientos. Hay que tratar de evitar esto, pues casi siempre
conducirá a que la especificación de requerimientos y la implementación del sistema se
salgan de ritmo.
Una vez realizados los cambios al sistema, es fácil olvidar la inclusión de dichos cambios
en el documento de requerimientos, o bien, agregar información al documento de
requerimientos que sea inconsistente con la implementación.
Los procesos de desarrollo ágil, como la programación extrema, se diseñaron para
enfrentar los requerimientos que cambian durante el proceso de desarrollo. En dichos
procesos, cuando un usuario propone un cambio de requerimientos, éste no pasa por
un proceso de administración del cambio formal. En vez de ello, el usuario tiene que
priorizar dicho cambio y, si es de alta prioridad, decidir qué características del sistema
planeadas para la siguiente iteración pueden eliminarse.