CAPÍTULO 5 COMPRENSIÓN DE LOS REQUERIMIENTOS 103

pantes de la comunidad del negocio (por ejemplo, los directivos, personal de mercadotecnia,
gerentes de producto, etc.) definen un caso de negocios para la idea, tratan de identificar el ritmo
y profundidad del mercado, hacen un análisis de gran visión de la factibilidad e identifican una
descripción funcional del alcance del proyecto. Toda esta información está sujeta a cambio, pero
es suficiente para desencadenar análisis con la organización de ingeniería de software.2 En la
concepción del proyecto,3 se establece el entendimiento básico del problema, las personas que
quieren una solución, la naturaleza de la solución que se desea, así como la eficacia de la
comunicación y colaboración preliminares entre los otros participantes y el equipo de software.

Indagación. En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras
personas cuáles son los objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se
ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el
sistema o producto en las operaciones cotidianas. Pero no es simple: es muy difícil. 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. Para superar estos problemas, debe
enfocarse la obtención de requerimientos en forma organizada.

Elaboración. La información obtenida del cliente durante la concepción e indagación se expande y

refina durante la elaboración. Esta tarea se centra en desarrollar un modelo refinado de los
requerimientos (véanse los capítulos 6 y 7) que identifique distintos aspectos de la función del
software, su comportamiento e información. La elaboración está motivada por la creación y
mejora de escenarios de usuario que describan cómo interactuará el usuario final (y otros actores)
con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases de
análisis, que son entidades del dominio del negocio visibles para el usuario final. Se definen los
atributos de cada clase de análisis y se identifican los servicios4 que requiere cada una de ellas. Se
identifican las relaciones y colaboración entre clases, y se producen varios diagramas adicionales.

Negociación. No es raro que los clientes y usuarios pidan más de lo que puede lograrse dado lo
limitado de los recursos del negocio. También es relativamente común que distintos clientes

2 Si va a desarrollarse un sistema basado en computadora, los análisis comienzan en el contexto

de un proceso de ingeniería de sistemas. Para más detalles de la ingeniería de sistemas, visite el
sitio web de esta obra. 3 Recuerde que el proceso unificado (véase el capítulo 2) define una “fase
de concepción” más amplia que incluye las fases de concepción, indagación y elaboración, que son
estudiadas en dicho capítulo. 4 Un servicio manipula los datos agrupados por clase. También se
utilizan los términos operación y método. Si no está familiarizado con conceptos de la orientación
a objetos, consulte el apéndice 2, en el que se presenta una introducción básica.
La elaboración es algo bueno, pero hay que saber cuándo detenerse. La clave es describir el
problema en forma que establezca una base firme para el diseño. Si se trabaja más allá de este
punto, se está haciendo diseño. CONSEJO

¿Por qué es difícil llegar al entendimiento claro de lo que quiere el cliente?

www.FreeLibros.me

104 PARTE DOS MODELADO

o usuarios propongan requerimientos conflictivos con el argumento de que su versión es “esencial

para nuestras necesidades especiales”. Estos conflictos deben reconciliarse por medio de un
proceso de negociación. Se pide a clientes, usuarios y otros participantes que ordenen sus
requerimientos según su prioridad y que después analicen los conflictos. Con el empleo de un
enfoque iterativo que da prioridad a los requerimientos, se evalúa su costo y riesgo, y se enfrentan
los conflictos internos; algunos requerimientos se eliminan, se combinan o se modifican de modo
que cada parte logre cierto grado de satisfacción.

Especificación. En el contexto de los sistemas basados en computadora (y software), el término

especificación tiene diferentes significados para distintas personas. Una especificación puede ser
un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, un
conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos. Algunos sugieren
que para una especificación debe desarrollarse y utilizarse una “plantilla estándar” [Som97], con el
argumento de que esto conduce a requerimientos presentados en forma consistente y por ello
más comprensible. Sin embargo, en ocasiones es necesario ser flexible cuando se desarrolla una
especificación. Para sistemas grandes, el mejor enfoque puede ser un documento escrito que
combine descripciones en un lenguaje natural con modelos gráficos. No obstante, para productos
o sistemas pequeños que residan en ambientes bien entendidos, quizá todo lo que se requiera sea
escenarios de uso.

PUNTO CLAVE La formalidad y el formato de una especificación varían con el tamaño y

complejidad del software que se va a construir.

Una especificación de requerimientos de software (ERS) es un documento que se crea cuando

debe especificarse una descripción detallada de todos los aspectos del software que se va a
elaborar, antes de que el proyecto comience. Es importante notar que una ERS formal no siempre
está en forma escrita. En realidad, hay muchas circunstancias en las que el esfuerzo dedicado a la
ERS estaría mejor aprovechado en otras actividades de la ingeniería de software. Sin embargo, se
justifica la ERS cuando el software va a ser desarrollado por una tercera parte, cuando la falta de
una especificación crearía problemas severos al negocio, si un sistema es complejo en extremo o si
se trata de un negocio de importancia crítica. Karl Wiegers [Wie03], de la empresa Process Impact
Inc., desarrolló un formato útil (disponible en www.processimpact.com/
process_assets/srs_template.doc) que sirve como guía para aquellos que deben crear una ERS
completa. Su contenido normal es el siguiente:
Tabla de contenido Revisión de la historia 1. Introducción 1.1 Propósito 1.2 Convenciones del
documento 1.3 Audiencia objetivo y sugerencias de lectura 1.4 Alcance del proyecto 1.5
Referencias 2. Descripción general 2.1 Perspectiva del producto

2.2 Características del producto 2.3 Clases y características del usuario 2.4 Ambiente de
operación 2.5 Restricciones de diseño e implementación 2.6 Documentación para el usuario 2.7
Suposiciones y dependencias 3. Características del sistema 3.1 Característica 1 del sistema 3.2
Característica 2 del sistema (y así sucesivamente) 4. Requerimientos de la interfaz externa 4.1
Interfaces de usuario 4.2 Interfaces del hardware 4.3 Interfaces del software 4.4 Interfaces de las
comunicaciones 5. Otros requerimientos no funcionales 5.1 Requerimientos de desempeño 5.2
Requerimientos de seguridad 5.3 Requerimientos de estabilidad 5.4 Atributos de calidad del
software 6. Otros requerimientos Apéndice A: Glosario Apéndice B: Modelos de análisis Apéndice
C: Lista de conceptos Puede obtenerse una descripción detallada de cada ERS si se descarga el
formato desde la URL mencionada antes.

INFORMACIÓN

Formato de especificación de requerimientos de software

En una negociación eficaz no debe haber ganador ni perdedor. Ambos lados ganan porque un
“trato” con el que ambas partes pueden vivir es algo sólido. CONSEJO

www.FreeLibros.me

CAPÍTULO 5 COMPRENSIÓN DE LOS REQUERIMIENTOS 105

Validación. La calidad de los productos del trabajo que se generan como consecuencia de la
ingeniería de los requerimientos se evalúa durante el paso de validación. La validación de los
requerimientos analiza la especificación5 a fin de garantizar que todos ellos han sido enunciados
sin ambigüedades; que se detectaron y corrigieron las inconsistencias, las omisiones y los errores,
y que los productos del trabajo se presentan conforme a los estándares establecidos para el
proceso, el proyecto y el producto. El mecanismo principal de validación de los requerimientos es
la revisión técnica (véase el capítulo 15). El equipo de revisión que los valida incluye ingenieros de
software, clientes, usuarios y otros participantes, que analizan la especificación en busca de
errores de contenido o de interpretación, de aspectos en los que tal vez se requiera hacer
aclaraciones, falta de información, inconsistencias (problema notable cuando se hace la ingeniería
de productos o sistemas grandes) y requerimientos en conflicto o irreales (no asequibles).

5 Recuerde que la naturaleza de la especificación variará con cada proyecto. En ciertos casos, la
“especificación” no es más que un conjunto de escenarios de usuario. En otros, la especificación
tal vez sea un documento que contiene escenarios, modelos y descripciones escritas. 6 La
administración formal de los requerimientos sólo se practica para proyectos grandes que tienen
cientos de requerimientos identificables. Para proyectos pequeños, esta actividad tiene
considerablemente menos formalidad.

Un aspecto clave durante la validación de los requerimientos es la consistencia. Utilice el modelo

de análisis para asegurar que los requerimientos se han enunciado de manera consistente.
CONSEJO
Lista de verificación para validar requerimientos Con frecuencia es útil analizar cada requerimiento
en comparación con preguntas de verificación. A continuación se presentan algunas: • ¿Los
requerimientos están enunciados con claridad? ¿Podrían interpretarse mal? • ¿Está identificada la
fuente del requerimiento (por ejemplo, una persona, reglamento o documento)? ¿Se ha estudiado
el planteamiento final del requerimiento en comparación con la fuente original? • ¿El
requerimiento está acotado en términos cuantitativos? • ¿Qué otros requerimientos se relacionan
con éste? ¿Están comparados con claridad por medio de una matriz de referencia cruzada u otro
mecanismo?

• ¿El requerimiento viola algunas restricciones del dominio? • ¿Puede someterse a prueba el
requerimiento? Si es así, ¿es posible especificar las pruebas (en ocasiones se denominan criterios
de validación) para ensayar el requerimiento? • ¿Puede rastrearse el requerimiento hasta
cualquier modelo del sistema que se haya creado? • ¿Es posible seguir el requerimiento hasta los
objetivos del sistema o producto? • ¿La especificación está estructurada en forma que lleva a
entenderlo con facilidad, con referencias y traducción fáciles a productos del trabajo más
técnicos? • ¿Se ha creado un índice para la especificación? • ¿Están enunciadas con claridad las
asociaciones de los requerimientos con las características de rendimiento, comportamiento y
operación? ¿Cuáles requerimientos parecen ser implícitos? INFORMACIÓN

Administración de los requerimientos. Los requerimientos para sistemas basados en

computadora cambian, y el deseo de modificarlos persiste durante toda la vida del sistema. La
administración de los requerimientos es el conjunto de actividades que ayudan al equipo del
proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en
cualquier momento del desarrollo del proyecto.6 Muchas de estas actividades son idénticas a las
técnicas de administración de la configuración del software (TAS) que se estudian en el capítulo
22.

www.FreeLibros.me

106 PARTE DOS MODELADO

5.2 ESTABLECER LAS BASES

En el caso ideal, los participantes e ingenieros de software trabajan juntos en el mismo equipo.8
En esas condiciones, la ingeniería de requerimientos tan sólo consiste en sostener conversaciones
significativas con colegas que sean miembros bien conocidos del equipo. Pero es frecuente que en
la realidad esto sea muy diferente. Los clientes o usuarios finales tal vez se encuentren en
ciudades o países diferentes, quizá sólo tengan una idea vaga de lo que se requiere, puede ser que
tengan opiniones en conflicto sobre el sistema que se va a elaborar, que posean un conocimiento
técnico limitado o que dispongan de poco tiempo para interactuar con el ingeniero que recabará
los requerimientos. Ninguna de estas posibilidades es deseable, pero todas son muy comunes y es
frecuente verse forzado a trabajar con las restricciones impuestas por esta situación. En las
secciones que siguen se estudian las etapas requeridas para establecer las bases que permiten
entender los requerimientos de software a fin de que el proyecto comience en forma tal que se
mantenga avanzando hacia una solución exitosa.
5.2.1 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.

7 Las herramientas mencionadas aquí no son obligatorias sino una muestra de las que hay en esta
categoría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus
respectivos desarrolladores. 8 Este enfoque es ampliamente recomendable para proyectos que
adoptan la filosofía de desarrollo de software ágil.

Objetivo: Las herramientas de la ingeniería de los requerimientos ayudan a reunir éstos, a

modelarlos, administrarlos y validarlos. Mecánica: La mecánica de las herramientas varía. En
general, éstas elaboran varios modelos gráficos (por ejemplo, UML) que ilustran los aspectos de
información, función y comportamiento de un sistema. Estos modelos constituyen la base de
todas las demás actividades del proceso de software. Herramientas representativas:7 En el sitio de
Volere Requirements, en www.volere.co.uk/tools. htm, se encuentra una lista razonablemente
amplia (y actualizada) de herramientas para la ingeniería de requerimientos. En los capítulos 6 y 7
se estudian las herramientas que sirven para modelar aquéllos. Las que se mencionan a
continuación se centran en su administración.

EasyRM, desarrollada por Cybernetic Intelligence GmbH (www. easy-rm.com), construye un

diccionario/glosario especial para proyectos, que contiene descripciones y atributos detallados de
los requerimientos. Rational RequisitePro, elaborada por Rational Software (www-306.
ibm.com/software/awdtools/reqpro/), permite a los usuarios construir una base de datos de
requerimientos, representar relaciones entre ellos y organizarlos, indicar su prioridad y
rastrearlos.

En el sitio de Volere ya mencionado, se encuentran muchas herramientas adicionales para

administrar requerimientos, así como en la dirección www.jiludwig.com/Requirements_
Management_Tools.html

HERRAMIENTAS DE SOFTWARE

Ingeniería de requerimientos

PUNTO CLAVE Un participante es cualquier persona que tenga interés directo o que se beneficie
del sistema que se va a desarrollar.

www.FreeLibros.me

CAPÍTULO 5 COMPRENSIÓN DE LOS REQUERIMIENTOS 107

Durante la concepción, debe hacerse la lista de personas que harán aportes cuando se recaben los
requerimientos (véase la sección 5.3). La lista inicial crecerá cuando se haga contacto con los
participantes porque a cada uno se le hará la pregunta: “¿A quién más piensa que debe
consultarse?”

5.2.2 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.