UNIDAD 12

GESTIN DE REQUISITOS


12. GESTIN DE REQUISITOS .................................................................. 1
12.1. LA GESTIN DE CAMBIOS.......................................................... 2
12.1.1. IMPACTO DEL CAMBIO................................................... 3
12.1.2. MEDIDA DEL IMPACTO DEL CAMBIO............................ 4
12.1.3. TRAZABILIDAD.............................................................. 5
12.1.4. IMPLEMENTACIN DE UN ESQUEMA DE TRAZABILIDAD 6
12.1.5. PROCESO DE GESTIN DE CAMBIOS............................... 7
12.2. SELECCIN DE REQUISITOS O TRIAGE........................................ 8
12.2.1. INFLUENCIA DE LOS REQUISITOS EN EL TRIAGE ............ 9
12.2.2. EVALUACIN DEL BENEFICIO...................................... 11
12.2.3. REALIZACIN PRCTICA DEL TRIAGE.......................... 12





La especificacin de requisitos es propensa a cambiar a lo largo de la vida del producto, e incluso
mucho antes de que el producto haya sido entregado.
La actividad de gestin de requisitos es la encargada de controlar los cambios de los requisitos, su
trazabilidad y el control de versiones y lneas de productos. sta actividad tiene lugar a lo largo de
todo el proceso de requisitos, tal y como se muestra en la Figura 1 y, lo que es muchsimo ms
importante, durante el resto del proceso de desarrollo. La gestin de requisitos es vital para el xito
del proyecto, ya que, en su ausencia, lo ms probable es que el proyecto nunca llegue a completarse
o, en el mejor de los casos, sobrepase ampliamente el coste y tiempo asignados.
No obstante, y an a pesar de la complejidad intrnseca de la gestin de los cambios, lo indicado
anteriormente no deja de ser una situacin idlica. Lejos queda la poca en que los sistemas software
se construan para satisfacer completamente una necesidad bien definida. Por el contrario, hoy en
da es frecuente que el software se construya no para satisfacer una necesidad, sino para aprovechar
una oportunidad, o rellenar un nicho de mercado. O incluso, cuando ello no es cierto, las
restricciones temporales impiden un desarrollo pausado, exigiendo que las entregas (versiones o
releases) se realicen en plazos cada vez mas reducidos e implementando nicamente una fraccin de
los requisitos del producto final.
Por consiguiente, la gestin de requisitos es ms que una gestin de cambios. Implica tambin la
seleccin de requisitos (esto es, los requisitos que debern implementarse en una release
determinada) y la planificacin de releases, con la complejidad que supone poner de acuerdo a las


Asignatura: Gestin de Requisitos 1


distintas partes implicadas, tales como clientes, usuarios, gestores, personal de marketing, etc. Ello
es lo que se conoce, entre otras denominaciones, como triage
1
.
En las secciones siguientes, se tratarn los dos aspectos de la gestin de requisitos, antes citados: la
gestin de cambios y la seleccin de requisitos o triage.
punto de decisin
requisitos informales

captura de anlisis y negociacin
requisitos de requisitos
requisitos
negociados
documento de
requisitos e
informe de
Validacin de documentacin
validacin
requisitos de requisitos
borrador documento de requisitos
Gestin de requisitos

Figura 1. La gestin de requisitos en el proceso de requisitos.

12.1. La gestin de cambios
Los requisitos son, por su propia naturaleza, cambiantes. Los cambios en los requisitos pueden
ocurrir por muchos motivos como, por ejemplo:
La aparicin de nuevos requisitos, al cambiar las necesidades del negocio y, o, al lograr los
usuarios un mejor entendimiento del sistema.
La existencia de diferentes puntos de vista que pueden generar modificaciones posteriores.
Cambios en la prioridad en los requisitos.
Avances en la tecnologa.
Cambios en las leyes y/o regulaciones.



1
Triage viene del francs trier, que significa ordenar. Es una estrategia utilizada en la medicina de
emergencias cuando el nmero de pacientes supera los recursos disponibles. Ver, por ejemplo,
http://en.wikipedia.org/wiki/Triage

Asignatura: Gestin de Requisitos 2


Independientemente del motivo del cambio, lo nico cierto es que los sistemas cambian y
evolucionan. Existe un dicho en ingeniera del software: Los sistemas con xito cambian. Y los
sistemas con mucho xito cambian continuamente. El cambio es una propiedad intrnseca del
software.
El cambio no es, en principio, perjudicial. Obviamente, ayuda a perfeccionar los sistemas software.
No obstante, cuando el cambio ocurre durante el desarrollo, antes de que el software haya sido
finalizado, dicho cambio puede tener un profundo impacto en la gestin del proyecto. Por
consiguiente, el cambio debe ser gestionado adecuadamente: El impacto del cambio debe poder ser
estimado y, en funcin del volumen de dicho impacto, el cambio debe ser negociado, y aceptado o
rechazado. A ello se dedicarn las siguientes secciones.

12.1.1. Impacto del cambio
Los cambios en los requisitos, cuando tienen lugar durante el proceso de requisitos, poseen
generalmente escasa importancia. No obstante, cuando ello ocurre una vez que el proceso de diseo
ha sido iniciado (o, lgicamente, en fases posteriores del desarrollo), dichos cambios son muy
perjudiciales para una adecuada gestin del proyecto
2
.
Tcnicamente hablando, los cambios en los requisitos no son un desafo tcnico importante. Los
cambios exigen, indudablemente, evaluar qu productos del desarrollo (diseo, cdigo, etc.), y en
qu medida, son afectados por el cambio. No obstante, si se dispone de un esquema de trazabilidad
adecuado (vase la siguiente seccin), ello es relativamente sencillo. Tambin acostumbra a ser
relativamente sencillo realizar los cambios requeridos, ya que para ello slo es necesaria la tpica
pericia tcnica
3
.
Ahora bien: a efectos de gestin, los cambios en los requisitos son, simplemente, una pesadilla. El
motivo es muy simple: aunque modificar un requisito sea simple tcnicamente, su impacto en
trminos de tiempo y esfuerzo puede ser muy considerable. Ntese que, tpicamente, de un requisito
funcional pueden derivarse mltiples procesos o clases y, dentro de cada uno de dichos procesos o
clases, pueden existir mltiples funciones o mtodos. El cambio de un nico requisito tpicamente
implica adaptar uno o varios procesos o clases, con el consiguiente tiempo y esfuerzo que ello
supone. En el peor de los casos, un cambio en los requisitos puede implicar tener que desechar
grandes partes del sistema software ya construidas o diseadas, y tener que comenzar el proceso de
diseo y codificacin desde cero
4
.


2
Ntese que no existe diferencia en este particular entre ciclos de vida. Esto es: tan perjudicial es el cambio
de requisitos para un sistema construido bajo el ciclo de vida en cascada como para uno construido bajo el
ciclo de vida incremental-evolutivo. Ello se debe a que el cambio afecta a los requisitos con los que se est
trabajando actualmente, esto es, los que se van a implementar en la versin actual del software, y no a los que
se implementarn en el futuro.
3
El prrafo anterior puede parecer un tanto optimista. No obstante, ntese que se est hablando de la
complejidad tcnica del cambio, y no de su impacto, en trminos de tiempo o esfuerzo. De ello se hablar a
continuacin.

4
La situacin puede llegar a ser peor en algunos casos: Si los requisitos sometidos a cambio fuesen los que
motivaron la arquitectura del software, ello puede implicar redisear completamente el sistema. Imagnese,
por ejemplo, el que el requisito sometido a cambio implicase la utilizacin de paralelismo en los clculos que
realiza el sistema.

Asignatura: Gestin de Requisitos 3


12.1.2. Medida del impacto del cambio
No es sencillo estimar, o medir, el impacto real de un cambio en los requisitos. Existen varios
motivos. En primer lugar, un cambio en un requisito puede motivar la necesidad de alterar la
especificacin para que sta siga siendo correcta y consistente. Por ejemplo, supngase el siguiente
requisito:
El sistema permitir a los usuarios realizar consultas de la base de datos

Supngase ahora que se fuera necesario que el sistema respetase alguna poltica de
confidencialidad, tal como la Ley de Proteccin de datos personales. Entonces, la especificacin
debera ser modificada, porque esta ley exige que el acceso a los datos personales quede registrado.
De este modo, despus del cambio, los requisitos del sistema seran los siguientes:
El sistema deber respetar la Ley de Proteccin de Datos Personales
El sistema permitir a los usuarios realizar consultas de la base de datos
Se registrar en un fichero de log a todos los usuarios que accedan a datos de carcter
personal.

Ahora bien: El sistema no prevea la identificacin de los usuarios, por lo que ser necesario
instaurar un sistema de claves. Asimismo, es necesario proteger el acceso al fichero de log, para que
no pueda ser alterado y, de este modo, se viole el mandato de la Ley de Proteccin de Datos
Personales, etc., etc., etc. Dicho de otro modo: el cambio de un nico requisito puede provocar la
inclusin de nuevos requisitos en la especificacin o, lo que es incluso ms frecuente, la
modificacin de requisitos ya presentes.
En segundo lugar, debe considerarse que es posible que el software est parcialmente
implementado. Esto es: que un requisitos haya sido llevado a diseo, otro haya sido implementado,
etc. Si el cambio en el requisito implica la modificacin de partes del diseo o cdigo, estimar qu
partes es necesario modificar, y en qu grado, es una tarea nada sencilla.
Por consiguiente, una alternativa razonable para estimar el impacto de los cambios es suponer que
un cambio en un requisito implica desechar todo el trabajo
5
realizado hasta el momento y comenzar
de nuevo el diseo, implementacin, etc. Lo mismo ocurrir con todos los requisitos que deben
modificarse en respuesta al cambio introducido en el sistema.
De este modo, utilizando tcnicas como la de los puntos-funcin, es posible proporcionar una
aproximacin, posiblemente pesimista, del impacto del cambio: Simplemente, es necesario calcular
los puntos funcin correspondientes a los requisitos implicados en el cambio y, utilizando un
modelo como el COCOMO Early Design Model
6
, estimar el tiempo y esfuerzo necesarios. Dicho
tiempo y esfuerzo corresponder con el impacto del cambio.

5
A menos que sea claro que ello no es cierto. Obviamente, la realidad es la que determina la estrategia a
utilizar.

6
Bsicamente, esta estrategia es la misma que se utilizar para el triage. Una implementacin del COCOMO
Early Design Model puede encontrarse en los materiales adicionales a la presente unidad.

Asignatura: Gestin de Requisitos 4


La ventaja de esta aproximacin consiste en que no es necesario considerar nada ms que los
requisitos (pero no el diseo, implementacin, etc.) a la hora de analizar el impacto de un cambio
7
,
simplificando de este modo el anlisis.


12.1.3. Trazabilidad
Se ha indicado anteriormente que, para estimar el impacto de un cambio, es necesario conocer, por
una parte, qu productos se derivan del requisito sometido a cambio y, por otra, los requisitos que
deben modificarse para que, una vez realizado el cambio, la especificacin sea correcta y
consistente.
Obviamente, no parece razonable que, cada vez que se produce un cambio en los requisitos, sea
necesario estudiar todo el sistema para evaluar el impacto del cambio. Ello sera, obviamente, poco
prctico y antieconmico. Por el contrario, en un desarrollo realizado siguiendo principios de
ingeniera, la identificacin de los productos afectados por el cambio se realiza mediante
8
lo que se
conoce como trazabilidad.
Por trazabilidad, debe entenderse el proceso que permite relacionar los requisitos con otros
productos del proceso de desarrollo, as como los requisitos entre si. La trazabilidad es un aspecto
contemplado en los atributos de calidad de los requisitos. Concretamente, se dice que la
especificacin debe ser/estar:
Trazada, esto es, cada requisito debe estar relacionado con su origen. Esto tambin se
conoce como trazabilidad hacia atrs.
Trazable, esto es, cada requisito debe poder relacionarse con los productos subsiguientes
del proceso de desarrollo. Esto es lo que se conoce como trazabilidad hacia adelante.
Con referencias cruzadas, esto es, cada requisito debe poder relacionarse con otros
requisitos (por ejemplo, en el caso de requisitos dependientes unos de los otros, como es el
caso del ejemplo indicado en la seccin 12.1.2). Esto se conoce como trazabilidad interna.

Parece claro, por consiguiente, que cuando la especificacin se ha confeccionado adecuadamente,
los tres tipos de trazabilidad indicados anteriormente
9
permiten identificar
10
de una forma sencilla
los productos, y requisitos, afectados por el cambio en un requisito cualquiera.


7
Para el anlisis, pueden obviarse las funciones, clases o mtodos que se derivan de un requisito. No obstante,
para la implementacin del cambio, es obviamente necesarios considerar dichos aspectos, tal y como se indica
en la siguiente seccin.
8
O, mejor dicho, debera realizarse. Los motivos de ello se indican en la seccin 12.1.4.
9
Para la gestin de cambios, es suficiente con la trazabilidad hacia adelante y la trazabilidad interna. La
trazabilidad hacia atrs es ms til durante la educcin y anlisis.

10
Se desea hacer hincapi de nuevo en que dicha identificacin es necesaria tanto para evaluar el impacto
como para llevar a cabo el cambio requerido.

Asignatura: Gestin de Requisitos 5


12.1.4. Implementacin de un esquema de trazabilidad
Aunque la trazabilidad, en todas sus vertientes, es extremadamente til, no es ni mucho menos
sencilla de llevar a cabo, aunque ello depende del tipo particular de trazabilidad a la que nos
refiramos:
Trazabilidad hacia atrs. Implementar trazabilidad hacia atrs es relativamente sencillo.
Para ello, slo es necesario anotar cada requisito con su origen, sea ste un documento (tal
como la transcripcin de una entrevista, por ejemplo), o un cliente/usuario.
Trazabilidad interna. Este tipo de trazabilidad es tambin fcilmente realizable, al menos
en los casos ms sencillos. Consistira, nuevamente, en una anotacin en cada requisito
donde se indicaran los requisitos relacionados. Obviamente, a medida que la especificacin
aumenta de tamao, esta estrategia es cada vez ms tediosa, y probablemente sera
necesario el soporte de alguna herramienta automatizada (probablemente, una herramienta
de gestin de requisitos)
11
.
Trazabilidad hacia adelante. Esta es, con diferencia, el tipo de trazabilidad ms complejo
de definir y mantener. El motivo reside en que de cada requisito pueden surgir mltiples
productos, tales como: esquemas de bases de datos, procesos o casos de uso, eventos, etc. Y
a su vez, de cada uno de los elementos citados anteriormente, se derivan otros, y as
sucesivamente.
En proyectos sencillos, sin embargo, puede conseguirse un cierto nivel de trazabilidad
cuidando la denominacin y numeracin de los procesos del desarrollo. Cmo proceder
concretamente depender en gran medida de las particularidades del proyecto de desarrollo.
No obstante, es posible ofrecer algunas guas prcticas. Supngase, por ejemplo, que la
especificacin contiene el requisito:

1. El sistema deber generar facturas

Supngase tambin que la metodologa de diseo que se utilizar en el proyecto es la
orientada a objetos. Entonces, podra definirse un caso de uso:

CU1: generarFactura()

Dicho caso de uso puede descomponerse en varias funciones del sistema:

FS1.1: indicarNumeroCliente()
FS1.2: indicarNumeroPedido()
FS1.3: confirmarFactura()

Y as sucesivamente. La trazabilidad hacia delante se ha conseguido implcitamente,
mediante la conservacin del nmero de requisito en el caso de uso y funciones del sistema.
As, si en lugar de referirnos al requisito 1 nos hubiramos referido al requisito 2, el caso de
uso sera el CU2, y las funciones del sistema FS2.1, FS2.2, etc.

Esta estrategia es adecuada para los requisitos funcionales en sistemas sencillos. Es ms
complejo, no obstante, trazar otros productos, como puede ser, por ejemplo, el modelo


11
Si bien es sencillo documentar los requisitos con herramientas simples, como un procesador de textos o una
hoja de clculo, mantener las referencias cruzadas en una tarea ms compleja para la que dichos programas no
estn tpicamente preparados.

Asignatura: Gestin de Requisitos 6


conceptual. No obstante, si el sistema es, como se ha indicado, simple, ello no debera ser
un problema insalvable e incluso es posible que el analista idee alguna alternativa razonable
de trazabilidad.

Para finalizar, parece claro que cuando el sistema es complejo, la estrategia citada es ms
bien dbil. En este caso, la trazabilidad slo puede mantenerse mediante una herramienta de
gestin de requisitos
12
.

Resumiendo la situacin: En proyectos sencillos, y manteniendo cierta disciplina en la
denominacin y numeracin de procesos, casos de uso, etc., es posible mantener un esquema de
trazabilidad que favorezca la gestin de cambios. No obstante, en proyectos complejos, sin la ayuda
de una herramienta de gestin de requisitos, la trazabilidad (sobre todo, la trazabilidad hacia
adelante) es muy difcil de definir y mantener, y la gestin de cambios se ve entonces perjudicada.

12.1.5. Proceso de gestin de cambios
Ya para finalizar, el proceso de gestin de cambios se lleva a cabo tal y como muestra la Figura 2.
ste consta de tres (o cuatro) actividades principales:
Identificacin del cambio: Conceptualmente, esta actividad consiste simplemente en
reconocer la existencia de un cambio, e iniciar el proceso que lleve a su aceptacin o
rechazo. En la prctica, sin embargo, reconocer la existencia de la necesidad de un cambio
no es en modo alguno sencillo, debido a que el cambio puede surgir por mltiples razones
(como las ya citadas al inicio de la presente seccin) y estar motivado por mltiples agentes
(usuarios, clientes, el entorno organizativo o legal, etc.). Por esta razn, la identificacin de
los cambios puede realizarse de mltiples maneras, dependiendo de la organizacin y
entornos particulares (solicitudes de cambio realizadas por telfono, conversaciones
informales en pasillos, noticias del peridico en el caso de modificaciones legales-, etc.)
13
.
Analizar el cambio y su impacto. Esta actividad tiene como objetivo evaluar el impacto
del cambio. Ello puede realizarse tal y como se ha descrito en la secciones anteriores. En
funcin de esta evaluacin, el cambio puede:
o Ser implementado, de la misma forma que se implementara un requisito
cualquiera
14
.
o Ser rechazado, ya sea definitivamente, ya sea para la presente versin del software
a construir
15
.

12
Siempre y cuando est integrada con las herramientas CASE de diseo. En caso contrario, no sera posible
referir cada requisito a los productos que dichos requisitos generan (trazabilidad hacia delante). Es el caso, por
ejemplo, de IBM Requisite Pro. Cualquier herramienta es, por lo general, capaz de manejar la trazabilidad
interna y la trazabilidad hacia atrs.
13
La identificacin del cambio mejora enormemente si existe un procedimiento bien definido para comunicar
los potenciales cambios en los requisitos. Dicho procedimiento debe establecer cmo describir el cambio, y a
quin comunicar ste.

14
Esto es, debidamente diseado y documentado. Adicionalmente, lo cual es vital, los cambios en los
requisitos deben someterse a control de la configuracin del software.

Asignatura: Gestin de Requisitos 7



La decisin acerca de si implementar o rechazar el cambio debe ser llevada a cabo por el
cliente, una vez ste ha sido debidamente informado del coste y esfuerzo que implica.
Identificacin del
cambio
Anlisis del cambio
y evaluacin de
costes
Implementacin
del cambio
Rechazo
del cambio

Figura 2. Actividad de Gestin de cambios.

12.2. Seleccin de requisitos o Triage
La seccin anterior se ha dedicado ntegramente al cambio. El cambio es uno de los responsables de
que el producto software evolucione en el tiempo, pero no es el nico. Muy al contrario, hoy en da
la presin del mercado
16
(plazos de entrega ms cortos, vida til del software ms reducida, etc.) es
un factor de evolucin tan importante como el cambio en si mismo
17
.
La evolucin inducida por el mercado tiene unas caractersticas distintas a la del cambio aleatorio:
es bsicamente previsible. Dicho de otro modo; a diferencia de un cambio en los requisitos, que
ocurre por razones muy diversas y puede suceder en cualquier momento, el mercado posee una
dinmica que puede ser estudiada y, al menos hasta cierto grado, puede igualmente ser prevista.

15
Slo como un comentario, existe una seccin en el IEEE-Std-830-1998 dedicada a recoger aquellos
requisitos del software que no van a ser implementados en la versin actual. Dicha seccin es la 2.6
Apportioning of requirements (distribucin de requisitos).
16
El mercado no tiene por qu ejercer una influencia directa en el producto software. Por ejemplo, el mercado
puede influir en la organizacin que, en respuesta, debe adaptar su software. Asimismo, el trmino Mercado
debe entenderse en un sentido laxo: no slo hablamos de productos y servicios y transacciones comerciales,
sino que tambin debe incluirse otros aspectos ms intagibles, como la relacin entre los ciudadanos y la
administracin pblica.

17
Conviene aclarar lo indicado aqu: Obviamente, el mercado es un generador de cambios, los cuales son
tratados mediante un proceso de gestin de cambios, tal y como se ha indicado en la seccin anterior. No
obstante, cuando se referencia la presin del mercado en la presente seccin, nos queremos referir a un tipo de
cambio mucho ms especfico: el cambio previsible. Sgase leyendo para ms detalles.

Asignatura: Gestin de Requisitos 8


A modo de ejemplo, supngase el instante actual: principios de 2006. Es fcil prever que gran parte
del software comercial debe poseer ciertas caractersticas: independencia de la plataforma,
utilizacin de XML, arquitectura orientada a web services, etc. Si el mercado bajo estudio fuese ms
especfico, como por ejemplo las herramientas CASE, podran identificarse ms caractersticas,
tales como la orientacin a MDA
18
, trabajo colaborativo, etc.
Existe otro aspecto de la presin del mercado que es relativamente predecible: las ventanas de
oportunidad. Este concepto hace referencia a cunto tiempo puede ser rentable un determinado
servicio o tecnologa. Por ejemplo: dado el ritmo de avance tecnolgico, es probable que los web
services dejen de ser un factor diferenciador de producto alrededor del 2008. Por consiguiente, para
todos los productos que se desarrollen despus de esa fecha, ya no tiene sentido afirmar que estn
orientados a web services para captar clientes: A partir del 2008, los clientes ya estarn
acostumbrados a ese tipo de productos.
Por consiguiente, antes de decidir qu requisitos deben implementarse en el software, es necesario
seleccionar stos cuidadosamente, con el objetivo lgico maximizar los beneficios obtenidos
mediante el proyecto de desarrollo
19
. Esto es lo que se conoce como proceso de seleccin o triage.
Para poder realizar el proceso de seleccin, es necesario considerar tres factores: La influencia de
los requisitos en el producto final, los gastos e ingresos y los aspectos tcnico-sociales. A ello se
dedicarn las secciones siguientes.

12.2.1. Influencia de los requisitos en el triage
Existen dos propiedades de los requisitos que son relevantes para el triage: la estabilidad y la
importancia. El primero de estos requisitos evala la resistencia de los requisitos ante el cambio. El
segundo, el impacto que los requisitos ejercen en el retorno de inversin. Finalmente, para realizar
la seleccin de requisitos tambin es importante que la especificacin posea las adecuadas
referencias cruzadas.

12.2.1.1. Estabilidad
La propiedad que determina cunto de cambiantes son los requisitos se denomina estabilidad
20
.
Respecto a esta propiedad, los requisitos pueden ser:
Estables: Tpicamente los requisitos ms estables son aquellos referidos a la esencia del
sistema y al dominio de la aplicacin
21
.

18
Model Driven Architecture (MDA) es una aproximacin que, simplificando bastante, persigue conseguir la
generacin automtica de cdigo mediante el uso de modelos. Para ms detalles, vase
http://www.omg.org/mda/
19
El beneficio no tiene por qu calcularse nicamente de forma monetaria. Los aspectos intangibles
(satisfaccin, penetracin en el mercado, etc.) pueden, o deben, considerarse igualmente.
20
A veces se utiliza el trmino volatilidad. Estabilidad es el antnimo de volatilidad. As, si la estabilidad de
un requisito es alta, su volatilidad es baja, y viceversa.

21
Cuando se habla del dominio del sistema, se hace referencia a todo aquello que es razonablemente
permanente y esencial en lo referido al problema a resolver. Por citar dos ejemplos muy simples: una empresa
compra y vende productos y servicios y un avin despega, vuela y aterriza. Cualquier software para una

Asignatura: Gestin de Requisitos 9


Voltiles: stos son ms difciles de ejemplificar. Podra decirse que son requisitos
potencialmente voltiles aquellos que dependen de las modas, necesidades puntuales, etc.
Una sub-clasificacin de requisitos voltiles podra ser:
o Mutables: por cambios en el entorno (cambia el % de impuestos).
o Emergentes: slo aparecen con el uso del sistema (mejoras en la visualizacin de
datos del sistema).
o Consecuentes: por suposiciones errneas (formas en las que los usuarios utilizarn
el sistema).
o Compatibles: la compatibilidad con otros equipos cambia al cambiar stos.

En proyectos donde los requisitos son voltiles, es aconsejable anotar stos por estabilidad para
facilitar el triage. Los valores de estabilidad de cada requisito no pueden obtenerse habitualmente de
los usuarios, siendo tpicamente necesario algn tipo de actuacin especfica para su anotacin (una
reunin de usuarios expertos y clientes que provean los valores, por ejemplo
22
).
Ntese, adicionalmente, que la anotacin por estabilidad es uno de los atributos de calidad
establecidos en el IEEE-Std-830-1998. Un esquema de anotacin simple para la estabilidad podra
ser: (alta, baja).

12.2.1.2. Importancia
La importancia determina el impacto de los requisitos en el producto final. Este impacto puede ser
objetivo (por ejemplo, ingresos que pueden obtenerse mediante la implementacin de un requisito),
o subjetivo (obtencin de una cuota de mercado, por ejemplo).
Al igual que con la estabilidad, es conveniente anotar los requisitos stos por importancia para
facilitar el triage. Al igual que en el caso de la estabilidad, los valores de importancia de cada
requisito no pueden obtenerse habitualmente de los usuarios (para ellos, todo lo que piden es
importante), siendo tpicamente necesario algn tipo de actuacin especfica para su anotacin (una
reunin de usuarios expertos y clientes que provean los valores, por ejemplo2 2 ).
Ntese, adicionalmente, que la anotacin por importancia relativa es uno de los atributos de calidad
establecidos en el IEEE-Std-830-1998. Un esquema de anotacin simple para la importancia podra
ser: (alta, baja).

12.2.1.3. Referencias cruzadas
Tal y como se ha indicado en las secciones anteriores, una especificacin posee referencias
cruzadas, o trazabilidad interna, cuando los requisitos estn relacionados entre s.

empresa, o un avin, debe considerar y respetar los aspectos anteriores. Cmo comprar o vender, o el modo de
operar los mandos del avin, no son aspectos esenciales, por lo que no pertenecen al dominio de aplicacin,
sino que son caractersticas del software arbitrariamente establecidas.

22
Esta reunin podra ser incluso la misma en la que se estudiase la seleccin de requisitos. Ver seccin
12.2.3.

Asignatura: Gestin de Requisitos 10


Adems de favorecer la gestin de cambios, la trazabilidad interna es importante para realizar la
seleccin de requisitos, debido a que permite identificar los requisitos que deben implementarse
conjuntamente. Esto es, si dos requisitos estn relacionados, es que la implementacin del uno
afecta de algn modo al otro, tpicamente porque deben implementarse conjuntamente. Por ello,
durante el triage no se puede seleccionar uno de estos requisitos y desechar el otro, ya que la
especificacin probablemente no sera correcta ni consistente.
En ausencia de trazabilidad interna, errores como el anterior pueden cometerse fcilmente.

12.2.2. Evaluacin del beneficio
Para poder realizar la seleccin de requisitos de un modo mnimamente riguroso, es necesario
cuantificar, en la medida de lo posible, todos las variables que se vayan a utilizar. Adicionalmente,
proporcionar valores monetarios ayuda sobremanera a que los clientes tomen conciencia de las
implicaciones de las decisiones acerca de si implementar o no un determinado conjunto de
requisitos.
La evaluacin del beneficio se realiza ms fcilmente cuando se separa el aspecto gasto, del aspecto
ingreso.

12.2.2.1. Gastos
Cuantificar los gastos es, tpicamente, sencillo. Basta con estimar los UFP (unajusted function
points) para cada requisito. Los UFP pueden utilizarse posteriormente como entrada para el
COCOMO Early Design Model, el cual proporciona valores para el tiempo, esfuerzo y coste
23
que
incluso se pueden presentar como grficos, tales como el mostrado en la Figura 3.

Figura 3. Grfico resumen


23
Obviamente, esto no deja de ser una estimacin. Otras alternativas de clculo podran ser igualmente
vlidas.

Asignatura: Gestin de Requisitos 11



12.2.2.2. Ingresos
Es mucho ms complicado, por el contrario, cuantificar los ingresos esperados. Existen varias
razones para ello:
En muchos casos, los sistemas se desarrollan para un solo cliente, y los ingresos ya estn
establecidos en el contrato de desarrollo.
Tambin en muchos casos, el cliente para el cual se desarrolla el software es un cliente
interno (perteneciente a la misma organizacin que los desarrolladores), por lo que no se
produce ningn ingreso por desarrollo.
Adems de lo indicado anteriormente, en muchas ocasiones los ingresos son intangibles,
tales como: satisfaccin, rapidez, penetracin en el mercado, etc.

Por consiguiente, no es posible proporcionar una orientacin general de cmo estimar los ingresos.
Debe ser el analista (junto con el cliente), el que idee un mtodo de cuantificacin que permita la
comparacin de productos alternativos (esto es, productos con diferentes conjuntos de requisitos).
Para finalizar, debe indicarse que, en muchas ocasiones, no es necesario estimar los ingresos, sobre
todo para clientes internos. En estos casos, el factor tiempo es habitualmente suficiente para poder
seleccionar los requisitos a implementar en una release determinada.

12.2.3. Realizacin prctica del triage
Aunque no existe un procedimiento bien definido para la realizacin de la seleccin de requisitos, la
Figura 4 muestra una secuencia plausible de actividades.
Anotar por
estabilidad e
importancia
Definir referencias
cruzadas entre requisitos
(trazabilidadinterna)
Estimar el coste
(UFP) de cada
requisito
Toma de decisiones y
planificacin de
releases
Estimar los
ingresos

Figura 4. Actividades genricas para la realizacin de triage


Asignatura: Gestin de Requisitos 12



Las actividades a realizar son:
Definir las referencias cruzadas: Realmente, esta no es una actividad de triage, sino de
documentacin de requisitos. En cualquier caso, si no se hubiera definido la trazabilidad
interna, ello debera realizarse antes de proseguir con las actividades de triage.
Anotar los requisitos por estabilidad e importancia.
Estimar el coste de cada requisito, en UFP. Tambin sera necesario introducir las
estimaciones en una aplicacin que permitiese calcular el COCOMO Early Design Model,
tal y como la hoja Excel proporcionada en los materiales adicionales.
Estimar los ingresos, aunque como ya se ha indicado, esto es mucho ms complicado que
estimar los costes.

La ltima tarea del triage, y la realmente complicada, es la toma de decisiones y planificacin de
releases. Esta tarea debe ser realizada por un grupo de trabajo, en el que participen clientes,
usuarios, analistas, personal del departamento financiero, y marketing si fuera necesario, etc. Es
claro que tomar una decisin acerca de que requisitos implementar es una tarea difcil, sobre todo
cuando debe hacerse en base a evidencias tan escasas como las previsiblemente disponibles. Por
ello, es fundamental que estn presentes todas las partes implicadas y que se entienda perfectamente
lo que se est discutiendo.
A partir de este punto, como en toda negociacin, se producirn las tpicas tensiones entre los que
buscan llegar a un acuerdo. No es posible proporcionar un procedimiento para negociar, pero si una
serie de recomendaciones que, si se cumplen, facilitarn en proceso.
Fomentar una actitud positiva por todas las partes, ya que la bsqueda de la mejor
solucin es el deseo de todos.
Buscar siempre una solucin. No dejar que el tiempo solucione el problema, ya que el
personal de desarrollo es el que acostumbra a sufrir las consecuencias.
Las decisiones no pueden tomarse de forma mecnica, sino de forma consciente
entendiendo los pros y contras. Ello evitar sorpresas desagradables posteriormente.
No sentirse obligado a asumir un compromiso o una planificacin imposible. Este tipo
de compromisos pueden imponerse, pero no pueden aceptarse libremente.
Que todas las partes recuerden que la perfeccin es imposible.

El resultado de la toma de decisiones debe ser una planificacin de releases. Una planificacin de
releases consiste simplemente en determinar cuntas versiones o releases del software se van a
desarrollar, y que requisitos deben implementar cada una de ellas. Es conveniente planificar ms de
una release cada vez que se realice el triage y, en cualquier caso, antes de desarrollar una nueva
release, es tambin conveniente estudiar si es necesario realizar una replanificacin (por ejemplo,
debido a que la importancia de los requisitos haya cambiado).
Finalmente, y como ya se ha indicado anteriormente, la planificacin de releases puede recogerse en
la seccin 2.6 Apportioning of requirements (distribucin de requisitos) del documento de
especificacin de requisitos.


Asignatura: Gestin de Requisitos 13