La Especificacin de Requerimientos de Software.

Alan Davis.
1



Durante el anlisis del problema, el problema es descompuesto repetidamente hasta que es
finalmente entendido completamente. Sin embargo, la fase de requerimientos de software
no esta completa hasta que la especificacin de requerimientos de software (SRS) no sea
escrito. Este captulo introduce el concepto de SRS, describe su contenido apropiado,
explora los atributos de un SRS bien escrito, y ofrece guas sobre como organizar un SRS.

1. Introduccin
Antes que la etapa de requerimientos de software este completa, un SRS debe ser escrito. El
SRS contiene una descripcin completa del comportamiento externo del sistema de
software. Es posible completar el anlisis del problema antes de comenzar a escribir el
SRS. Sin embargo, es ms comn que a medida que se logra el proceso de anlisis y
descomposicin del problema y partes del problema son entendidas, la seccin
correspondiente del SRS es escrito.

El SRS sirve a un nmero de propsitos dependiendo de quien es el que lo escribe.
Primero, el SRS puede ser escrito por un usuario potencial (o cliente) del sistema. Segundo,
el SRS puede ser escrito por un desarrollador del sistema. Los dos escenarios crean
situaciones enteramente diferentes y establece propsitos enteramente diferentes para el
documento. En el primer caso, el propsito primario es establecer la necesidad. Este
documento algunas veces sirve de base para un proceso de seleccin competitiva entre
compaas que desean satisfacer esa necesidad (base para la licitacin). Con el fin de
enfrentar la competencia (el cual ayuda potencialmente al cliente a obtener el mejor
producto al menor costo), el SRS debe ser tan general como sea posible. Veamos por
ejemplo que un dueo de un edificio desea adquirir un sistema de control para un elevador.
El SRS debe ser lo suficientemente general para que varias compaas de elevadores (cada
una con diferente algoritmo de despacho y caminos de viaje del elevador) puedan
responder, pero debe ser lo suficientemente especfico para eliminar claramente de la
competencia a una compaa que ofrece rampas conectando los pisos y paradas de elefantes
caminando de un piso a otro transportando gente en sus espaldas. Idealmente el SRS debe
dividir el universo de sistemas en dos conjuntos independientes: un conjunto de todos los
sistemas que satisfacen las necesidades reales de los usuarios y uno conteniendo todos los
que no.

Por otro lado, un SRS escrito por una organizacin de desarrollo como primer paso para el
proceso de construccin de software debe ser mucho ms especfico. Este tipo de SRS es
materia de nuestra discusin en este captulo, y desarrolla un conjunto enteramente
diferente de funciones del tambin llamado SRS descrito en el prrafo anterior. Su
propsito en proveer un medio de:

1
Tomado de DAVIS, Alan. Software Requirements: Analisys and Specification. Prentice-Hall. 1990.
Comunicacin entre clientes, usuarios, analistas y diseadores.
Soporte a las actividades de prueba del sistema.
Control de la evolucin del sistema.

Discutamos esos tres con ms detalle.

El primer propsito del SRS es proveer un medio de comunicacin entre todas las partes.
Un SRS bien escrito reduce la probabilidad de que un cliente se vea desilusionado con el
producto final. Asumiendo que el SRS no es ambiguo, define el comportamiento externo
del sistema a construir, y no pueden haber malinterpretaciones. Si existe un desacuerdo
entre entre el cliente y los desarrolladores concernientes al comportamiento externo, debe
detectarse durante la etapa de requerimientos y no durante el proceso de entrega del
software, cuando es mucho ms costoso de corregir. Desafortunadamente varios
desarrolladores prefieren mantener el SRS lo ms ambiguo para proveerse ellos mismos de
mayor flexibilidad durante el diseo. Sin embargo, esta flexibilidad incrementa
significativamente el riesgo del cliente. El SRS debe ser muy especfico sobre como el
sistema se observar externamente por el entorno del sistema (o por el usuario). Esto tiene
un efecto de segundo orden al limitar los posibles diseos, pero no es parte de la etapa de
diseo; de hecho algunos diseadores indican que una especificacin es demasiado
restrictiva. Si el escritor del SRS encuentra imposible especificar el comportamiento
externo sin suministrar un diseo, el SRS debera incluir una nota que indica que:

ADVERTENCIA: EL DISEO CONTENIDO AQU ES SUMINISTRADO COMO UNA
AYUDA AL ENTENDIMIENTO DEL COMPORTAMIENTO EXTERNO NICAMENTE, LOS
DISEADORES PUEDEN SELECCIONAR CUALQUIER DISEO QUE DESEE MIENTRAS
SE COMPORTE EXTERNAMENTE DE MANERA IDENTICA AL SISTEMA MENCIONADO.

Porque el diseo usado en el SRS no ser usado como el diseo? La respuesta es simple:
el diseo en el SRS es escogido debido a que ayuda a hacer los requerimientos ms
entendibles; el diseo real es escogido para optimizar calidades como mantenibilidad,
rendimiento, espacio y posibilidad de modificaciones.

El segundo propsito del SRS es servir como base para las actividades de prueba y
verificacin del sistema. El propsito de las pruebas del sistema es estimular el sistema con
escenarios de prueba representativos con el fin de mostrar que el sistema que se ha
construido satisface los requerimientos. Si el SRS es ambiguo o inconsistente o algunos
requerimientos establecidos son inestables, entonces tales pruebas no son posibles. El SRS
es la entrada primaria para la planeacin y generacin de las pruebas del sistema.

El tercer propsito del SRS es ayudar a controlar la evolucin del sistema de software.
Asumamos que un producto de software est en desarrollo o a punto de entregarse, y un
cliente dice yo deseo que el software haga X. Cmo alguien se da cuenta que es un
requerimiento nuevo o uno viejo?. La respuesta debe ser mirar el SRS y encontrarlo. Si se
determina que es un nuevo requerimiento, entonces el proceso adecuado para incorporar el
nuevo requerimiento es (1) actualizar el SRS, (2) actualizar el diseo, (3) actualizar el
cdigo, y as sucesivamente. El SRS sirve como la definicin y la nica definicin de que
se supone que el software debe hacer. Por eso, un control formal del contenido del SRS es
precisamente un control formal de la evolucin del sistema de software. Este proceso de
control es parte de la disciplina de administracin de configuiraciones de software (SCM -
Software Configuration Management), el cual esta por fuera de este texto. SCM trabaja
efectivamente durante las etapas de mantenimiento y mejoras as como en las etapas
iniciales del desarrollo.

2. Qu debe incluirse en un SRS?
Definiendo de la manera ms sencilla, un SRS debe incluir una descripcin concisa y
detallada de la interfaz externa del sistema con su entorno, incluyendo otro software,
puertos de comunicaciones, hardware y usuarios humanos. Esto incluye dos tipos de
requerimientos: de comportamiento y no de comportamiento.

Los requerimientos de comportamiento define que hace el sistema. Ellos describen todas
las entradas y salidas desde y hacia el sistema as como la informacin concerniente a como
las entradas y salidas se interrelacionan. En otras palabras debemos definir completamente
la funcin de transformacin del sistema que esta siendo especificado. Esta descripcin de
cmo las entradas se relacionan con sus salidas son tpicamente llamadas descripciones del
comportamiento o especificaciones operacionales y pueden no ser triviales.

Los requerimientos no de comportamiento definen los atributos del sistema como l
desarrolla su trabajo. Ellos incluyen una descripcin completa de los niveles requeridos de
eficiencia, confiabilidad, seguridad, mantenibilidad, portabilidad, visibilidad, capacidad y
cumplimiento de estndares, para mencionar unos pocos.

3. Que no debe incluirse en un SRS?
Dado el propsito del SRS definido previamente, se torna claro que lo siguiente no hace
parte de un SRS:
Requerimientos del Proyecto (por ejemplo, personal de apoyo, cronogramas, costos,
fechas de terminacin, actividades, fases, procedimientos de reporte a jefes, etc.).
Diseos
Planes de aseguramiento del producto (por ejemplo, planes de administracin de
configuraciones, planes de validacin y verificacin (V&V), planes de pruebas,
planes de aseguramiento de calidad, etc.)

Existen buenas razones por las cuales cada uno de ellos deben excluirse explcitamente de
un SRS, como se describe en los siguientes prrafos.

Por qu excluir los requerimientos de proyecto de un SRS? El SRS y los requerimientos
del proyecto tienen unos tiempos de vida enteramente diferentes. Aunque algunos creen
que el producto de software es slo el cdigo, el producto de software debe ser considerado
como el SRS, la documentacin de diseo, el cdigo, los planes de prueba, los manuales
del usuario, etc. Dado ese hecho, el tiempo de vida del SRS es el mismo que el tiempo de
vida del producto, por ejemplo, 5 aos, 10 aos, 15 aos, etc. Por otro lado, tems como
fechas de terminacin, costos de desarrollo y personal involucrado son una preocupacin
solamente del desarrollo (o con propsitos histricos). Por ello su tiempo de vida es solo
tan largo como el del proyecto de desarrollo. Claramente no tiene sentido incluir esos dos
tipos de informaciones en el mismo documento.

Por qu excluir diseos del SRS? Existen varias razones para hacerlo: para ayudar a
particionar la documentacin, diferentes audiencias, y falta potencial de principios reales de
diseo. Permtanos discutir cada una de esa razones separadamente. Primero, si realmente
deseamos, se pueden empacar todos los requerimientos, todos los diseos, todo el cdigo,
todos los planes de pruebas, y toda la documentacin del usuario en una sola pasta de
argolla. Eso podra hacerse, pero por qu hacerlo?. La gran ventaja de empacarlos
separadamente es habilidad de definir lneas de base en el proceso de desarrollo que (1)
sealan cuando se completa una fase principal del proyecto y eso denota el progreso y (2)
puede ser usado para controlar el cambio al sistema. Segundo, las especificaciones de
requerimientos y de diseo tienen diferentes audiencias. La audiencia del SRS incluye a los
usuarios del sistema, probadores del sistema, los clientes, los diseadores y a los escritores
de los requerimientos mismos. La audiencia de la documentacin de diseo incluye los
probadores de unidad y de integracin, codificadores y a los diseadores mismos. Tercero,
los escritores de requerimientos son escogidos por su habilidad para analizar y especificar,
no por su habilidad para sintetizar diseos eficientes. El correcto proceso de diseo requiere
negociaciones precarias entre varios factores y puede consumir del 15 al 25% del total de
costos de desarrollo. Pocos proyectos pueden soportar gastar esa cantidad de dinero durante
la etapa de requerimientos.

Por que excluir los planes de aseguramiento de productos? Las dos razones primarias son
las mismas que las dos para excluir el diseo del SRS. En particular no hay razn para
combinar materias relativamente no relacionadas en el mismo documento, y la audiencia de
los planes de aseguramiento de producto es tambin diferente de la del SRS. Los planes de
aseguramiento debe ser documentados en el plan de aseguramiento de calidad (SQEP), el
plan de administracin de configuraciones de software (SCMP), y el plan de pruebas del
sistema (STP).

4. Atributos de un SRS bien escrito
Si un SRS perfecto pudiera escribirse, debera ser:
Correcto
No Ambigua
Completa
Verificable
Consistente
Entendible por no especialistas en computadores
Modificable
Rastreable
Anotado (con anotaciones).

Cada una de estas calidades es explicada en las siguientes secciones:

4.1. Correcto
Un SRS es correcto si y slo si cada requerimiento que est en l representa algo requerido
por el sistema a construirse. No hay una forma real de ensear esta calidad, ya que depende
totalmente en la aplicacin a desarrollar. Si el software debe responder a todos los botones
presionados durante 5 segundos y el SRS establece que el software debe responder a todos
los botones presionados durante 10 segundos, ese requerimiento es incorrecto.

4.2. No Ambiguo
Un SRS es no ambiguo si y slo si cada requerimiento establecido tiene una nica
interpretacin. Imagine que una frase es extrada de un SRS, entregndolo a diez personas
diferentes solicitando su interpretacin. Si hay ms de una interpretacin, entonces la frase
es probablemente ambigua.

Como mnimo todos los trminos con mltiples significados deben aparecer en un glosario.
Sin embargo, muchos de los problemas de ambigedad no se pueden resolver con slo un
glosario. En particular el uso de lenguaje natural invita a la ambigedad debido a que el
lenguaje natural es inherentemente ambiguo. Unos pocos ejemplos pueden demostrar eso
claramente:

Ejemplo 1. Problema de controlador de trfico areo.

Para hasta doce aviones, el formato pequeo de pantalla debe ser usado. De otra forma
el formato grande de pantalla debe ser usado.

Este requerimiento pudo haber sido extrado de un SRS para un sistema controlador
de trfico areo (ATC). Los dos formatos de pantalla fueron definidos en alguna otra
parte del SRS como se muestra: En el formato pequeo de pantalla, ATCs ve el
estado de todos los aeroplanos en su sector en el formato mostrado en la figura 1a.
Esto es, bajo cada posicin de aeroplano en la pantalla, aparece la transportadora y el
nmero de vuelo, altitud, encabezamiento y destinos. Sin embargo, cuando un gran
nmero de aeroplanos estn presentes, la pantalla se cambia a formato grande de
pantalla, mostrado en la figura 1b. En este formato la confusin es reducida
eliminando todos los datos de vuelo de la pantalla excepto por la transportadora y el
nmero de vuelo. Presumiblemente existe otro tipo de terminal cercano donde el ATC
puede realizar consultas para poder determinar otros datos concernientes a vuelos de
inters.

La ambigedad descansa en la frase de para hasta doce aviones.... Significa doce o
ms o ms de doce, excluyendo al doce. Importa? Los analistas que escriben el
SRS pueden argir que realmente no importa, ya que es difcil de creer que doce
aviones en pantalla puedan ser confusos pero once no, o trece sean muy confusos y
doce no. Sin embargo, tales ambigedades (an en el caso que cualquiera de las dos
interpretaciones pueda ser valida) pueden llevar a resultados devastadores en el
producto final.

Imagine que dos ingenieros de software tienen la responsabilidad de escribir el
software para visualizar los datos de vuelo en la pantalla. Como se muestra en la
figura 2, un ingeniero tiene la responsabilidad de generar los datos apropiados para
las pequeas ventanas y el segundo tiene la responsabilidad de mostrar los datos en
pantalla. Ms an, asumamos que el primer ingeniero cree que el lmite entre los
formatos pequeo y grande ocurre entre los once y los doce aviones y el segundo
ingeniero asume que ocurre entre el doce y el trece. Cada uno esta bien, debido a que
el limite esta en doce. Mientras que en ese caso, el generador empaqueta la
informacin en cuatro lneas de datos, y el mdulo que presenta la informacin
muestra los datos adecuadamente. Cuando doce aviones aparecen. El generador
empaqueta los datos con una sola lnea de datos, pero el mdulo presentador espera
cuatro lneas, como se observa en la figura 3. Si estamos con suerte, las otras tres
lneas contienen basura; si esto ocurre, el ATC puede ocasionalmente observar basura
en la pantalla y reportarlo en el reporte diario. Sin embargo, las otras tres lneas
pueden contener informacin de otros vuelos. Si este es el caso, cuando hallan
exactamente doce aviones, todo se va a ver normal, pero se presentaran datos
completamente incorrectos para todos los aviones. Las consecuencias de este
escenario son potencialmente desastrosas, y todo esto ocurre debido a que los
analistas que escribieron el SRS creyeron que era aceptable mantener el documento
ambiguo, ya que cada interpretacin del requerimiento ambiguo era aceptable. La
solucin correcta es agregar a la frase original incluyendo doce o excluyendo
doce.













Figura 1. Ejemplo 1. Formatos de Pantalla de Control de Trfico Areo.
(a) Formato pequeo. (b). Formato Grande.







Figura 2. Ejemplo 1. Los dos mdulos a escribir.
Generador de
datos para los
textos
Visualizador
de los textos
en pantalla
EA317
25000
270
LAX
De la base
de datos
A mostrar
en pantalla

EA317
25000
270
LAX

PA17
15000
180
LAX

UN201
27000
285
SFO

EA317

MX101

PA17

EA2

XV101

AA505

CO101

UN201

EA319

UN401

EA205

PA236

UN500
(a) (b)







Figura 3. Ejemplo 1. La transferencia errnea de datos.

Otro ejemplo:

Ejemplo 2. Problema del avin no amigable.

El avin que no es amigable y tiene una misin desconocida o con el potencial de
entrar a espacio areo restringido dentro de 5 minutos debe generar una alerta.

Este requerimiento puede haber sido extrado de un SRS para algn tipo de sistema
militar diseado para generar alertas en el evento que el espacio areo restringido sea
violado inadecuadamente. La principal pregunta es que las prioridades relativas son
del tipo y y o. En otras palabras, el requerimiento significa que:

El avin que ya sea que no es amigable y tiene una misin desconocida o tiene el
potencial de entrar a espacio areo restringido dentro de 5 minutos debe generar una
alerta.

O significa que:

El avin que no es amigable y ya sea que tiene una misin desconocida o tiene el
potencial de entrar a espacio areo restringido dentro de 5 minutos debe generar una
alerta.

Cualquiera de ellas puede ser la correcta, pero esas frases tienen significados
enteramente diferentes. Veamos dos aplicaciones en donde cada una de las frases
anteriores es correcta. En la primera aplicacin, el se tiene que monitorear el trfico
areo cerca de un rea de prueba de bombas (ver las posiciones del avin amigable F1
y el avin no amigable N1 en la figura 4). Tambin un avin no amigable esta
pasando justamente (ver posicin N2 en la figura 4) y no ha comunicado su misin
(puede ser una misin de vigilancia), una alerta debe sonar. Esto corresponde a la
primera interpretacin. En la segunda aplicacin, la intencin es tener el monitor de
trfico areo cerca de un avin transportador. Una alerta nunca deber sonar por una
nave amigable. Sin embargo, la presencia de aviones no amigables debe generar una
alerta en cualquiera de los casos: (1) si el avin est justo a entrar en el espacio areo
restringido rodeando el avin transportador (ver posicin N1 en figura 5), o (2) si el
avin est pasando justamente (ver posicin N2 en figura 5) y no ha comunicado su
misin. Esto corresponde a la segunda interpretacin. Lo interesante es que este
requerimiento puede aparecer en un SRS real para cualquiera de las dos aplicaciones
y la interpretacin incorrecta del mismo puede generar que ocurra un comportamiento
Generador de
datos para los
textos
Visualizador
de los textos
en pantalla
PA17
De la base
de datos
A mostrar
en pantalla
no esperado. En la primera aplicacin, los aviones amigables pueden permanecer
sobre el rea de pruebas de la bomba (si se usara la interpretacin equivocada). En la
segunda aplicacin, a los aviones amigables nunca se les permite aproximarse, an en
tierra, al avin transportador.












Figura 4. Ejemplo 2. Espacio Areo restringido Area de prueba de bombas.













Figura 5. Ejemplo 2. Espacio Areo restringido Avin Cargero.

4.3. Completo
Un SRS es completo si posee cuatro cualidades:

1. Todo lo que el software se supone que debe hacer esta incluido en el SRS. Este es el
atributo ms difcil de definir o detectar violaciones a l. Una violacin es difcil de
detectar debido a que implica que algo no esta en el SRS; no es sencillo encontrar algo
que no esta presente examinando que esta presente. Los nicos capaces de detectar una
omisin son aquellos que tienen el problema que debe ser resuelto por software. Una
tcnica efectiva para localizar las violaciones es utilizar un prototipo.

Espacio areo
restringido
F = Amigable
N = No Amigable
N
1

N
2

N
1

N
2
F
1

Espacio areo
restringido
F = Amigable
N = No Amigable
Es una tentacin incluir la siguiente frase en la definicin de completitud: El SRS debe
especficamente establecer aquellas cosas que el software se supone que no har. Sin
embargo, esto se torna imposible de lograr considerando el tamao del universo con el
cual se supone que el software no va a interactuar. Un ejemplo sencillo basta. Suponga
un sistema telefnico en donde establecimos el requerimiento que:

Si A llama a B y B est disponible, entonces el telfono de B debe timbrar.

Esto parece perfectamente razonable. Luego durante las pruebas, los probadores
verifican que ese requerimiento sea satisfecho por el sistema. Sin embargo, que
previene que el desarrollador, para satisfacer ese requerimiento, construya un sistema
que hace timbrar todos los telfonos en el sistema cada vez que A llama a B y esta
disponible?. Para prevenir esto, el analista se debe ver forzado a escribir:

Si A llama a B y B est disponible, entonces el telfono de B debe timbrar y ningn
otro telfono debe timbrar.

El problema aqu es que puede ser una razn vlida para que el telfono C no pueda
timbrar al tiempo de B. Una alternativa es escribir al comienzo del SRS que:

El sistema debe hacer las cosas establecidas en este SRS y nada ms.

Esto tambin es un camino sin salida, debido a que el software hace cosas que no estn
establecidas en los requerimientos, por ejemplo, induce el hardware para emitir los
patrones de interferencia electromagntica.

2. Definiciones de las respuestas del software a todos los tipos realizables de datos de
entrada en todos los tipos realizables de situaciones estn incluidas. Note que es
importante especificar las respuestas a entradas tanto vlidas como invalidas.
Estoimplica que para todoa entrada mencionada en el SRS, el SRS especifica cual es la
salida apropiada. Sin meabrgo, la salida apropiada puede no ser slo una funcin de las
entradas; puede tambin ser una funcin del estado actual del sistema. Por ejemplo, en
un sistema de conmutacin telefnica, la respuesta de software a la deteccin del
usuario presionando 9 est en funcin del estado del sistema, el cual a su vez es una
funcin de lo que el usuario hizo previamente. Por ello, si el aparato del usuario est
colgado, ninguna salida del sistema es generada (la entrada es ignorada); si el usuario
esta escuchando el tono de marcar, la salida del sistema debe ser un tono distintivo; y si
el usuario ya ha comenzado a marcar un nmero telefnico, el 9 es coleccionado como
un dgito ms del nmero telefnico. En otras palabras el SRS debe establecer una
relacin completa entre el producto cruz del dominio de entradas (I) y el dominio de
estados (S) con el producto cruz del dominio de salidas (O) y el dominio de estados 8S),
eso es:

SRS: I x S o O x S

3. Todas las pginas estn numeradas: todas las figuras y tablas estn numeradas, con
nombres y referenciadas; todos los trminos y unidades de medida son provedos; y
todos los materiales y secciones mencionados estn presentes. Esto es completitud
desde la perspectiva del procesamiento de palabras.

4. Ninguna seccin est marcada como pendiente de ser determinado (To be determined
- TBD). Insertar las letras TBD en una seccin de un SRS debe se evitado en la
medida de lo posible. Cuando se incluya, el TBD debe ser complementado con una
notacin de quien tiene la responsabilidad de determinar el contenido y cuando la
seccin ser completada. Este mecanismo asegura que el TBD no sea interpretado carta
blanca como una excusa para postergar la terminacin de un SRS indefinidamente
como si TBD significara para hacerse maana (To Be Done tomorrow), y por
supuesto, el maana nunca ocurre. Incluyendo el nombre de un responsable y una fecha,
aseguramos que el TBD expira en algn punto.

4.4. Verificable
Un SRS es verificable si y solo si cada uno de los requerimientos establecidos en l es
verificable. Un requerimiento es verificable si y solo si existe algn proceso costo efectivo
en el cual una persona o mquina puede chequear que el software actual como esta
construido satisface ese requerimiento.

Es importante darse cuenta que la verificabilidad es una funcin de la forma en como el
SRS es escrito. (varias personas creen que es tan slo una funcin del producto a ser
construido). Existen varias razones por las cuales un requerimiento puede ser no
verificable. Primero, cualquier ambigedad podra ciertamente llevar a la no
verificabilidad; obviamente no existe forma de verificar un caso si ese caso esta definido
ambiguamente. Por ejemplo, la frase el producto deber tener una interfaz fcil de usar es
ambigua, por lo tanto, tiene mltiples interpretaciones debido a que las opiniones de que es
fcil de usar varan enormemente de persona en persona y no puede ser verficada como un
atributo del producto final. Segundo, usando cantidades no mensurables como
usualmente o de vez en cuando, implica la ausencia de un proceso finito de prueba y
por ello implica la no verificabilidad. Por ejemplo, la frase El producto usualmente deber
prender la luz roja cuando el botn sea presionado es no verificable debido a que si Ud.
intenta verificar el cumplimiento de ese requerimiento presionando el botn el botn mil
veces, Ud. puede estar tentado a decir que la prueba fue exitosa si la luz roja prende
seiscientas veces. Sin embargo, puede ser que Ud. halla presionado el botn mil veces, y la
luz roja nunca prenda. En otras palabras la nica forma de probar que usualmente es el
caso puede ser presionar un infinito nmero de veces. Tercero, cualquier requerimiento que
sea equivalente a una problema de bloqueo (halting problem) no puede ser verificado. Por
ejemplo, puede demostrarse que la verificacin de la frase el programa no deber entrar en
un ciclo infinito es equivalente a un problema de bloqueo y por eso no es verificable.

4.5. Consistente
Un SRS es consistente si y solo si ningn subconjunto de los requerimientos individuales
establecidos en l tiene conflictos. Esto puede manifestarse en un nmero de formas. Por
ejemplo,

1. Trminos conflictivos: Dos trminos son usados en diferentes contextos para significar
la misma cosa. Por ejemplo, un lugar del SRSR usa el trmino prompt para denotar
un mensaje mostrado por el software para preguntar al usuario digitar alguna
informacin, mientras en otro lugar el SRS utiliza la palabra clave para denotar la
misma situacin.
2. Caracteristicas conflictivas: Dos partes del SRS demandan que el producto exhiba
comportamientos contradictorios. Por ejemplo, en un lugar del SRSR se establece que
Todas las entradas del software debern realizarse por medio de la seleccin de una
opcin de un men en pantalla, y en otro sitio se establece que El lenguaje de
comandos se compondr de los siguientes comandos que digitar el usuario....
3. Inconsistencia Temporal: Dos partes del SRS demandan del producto que presente
caractersticas temporales contradictorias. Por ejemplo, en un sitio del SRS se establece
que La entrada del sistema A ocurrir slo mientras la entrada del sistema B este
ocurriendo, y en otro sitio del SRS se establece que La entrada del sistema B puede
comenzar 15 segundos despus de una ocurrencia de la entrada del sistema A.

4.6. Entendible por No Especialistas en Computadores
En un intento de hacer un SRS menos ambiguo, ms verificable, completo y consistente,
puede verse tentado a utilizar notaciones extremadamente formales. Desafortunadamente
tales notaciones a menudo hacen imposible para no especialistas en computadores el
entender el SRS. Los principales lectores del SRS en varios casos son clientes o usuarios,
quienes tienden a ser expertos en un rea de aplicacin pero no necesariamente entrenados
en ciencia de computacin. Tal vez una forma de lograr esta meta es utilizar notacin
formal pero desarrollar una herramienta para traducir el SRS formal en una prosa
equivalente fcil de entender de manera automtica. Este es el mecanismo tomado por
Balser et al. en el proyecto GIST. Sin embargo, en ese caso porque la versin formal es
requerida. Si existe una relacin no ambigua y completa entre las representaciones formales
e informales, entonces la representacin informal satisfacer todos los atributos requeridos,
incluyendo el entendimiento por no especialistas en computadores.

4.7. Modificable
Mientras las secciones anteriores discuten atributos del contenido del SRS, esta seccin y
las dos subsecuentes discuten atributos de formato y estilo del SRS.

Un SRS es modificable si su estructura y estilo permiten que cualquier cambio necesario
pueda hacerse fcilmente, completamente y consistentemente.

La modificabilidad implica que existe una tabla de contenido, un ndice y referencias
cruzadas en donde es necesario. Por ello si un requerimiento debe ser modificado
posteriormente, es posible revisar y localizar la seccin del SRS que tiene que ser
modificado. Por ejemplo, si deseamos cambiar el tiempo de respuesta mximo requerido
para el tono de marcar de un sistema de conmutacin telefnico de 5 segundos a 3
segundos, podremos mirar en el ndice bajo el texto tono de marcar para localizar todas
las referencias que existen al tono de marcar en el documento y hacer los cambios
necesarios.

Una tcnica que puede ser usada para mejorar le legibilidad del SRS es repetir
requerimientos seleccionados en diferentes localizaciones del documento. Este atributo del
SRS es llamado redundancia. Por ejemplo, al describir la interfaz externa de un PBX,
debemos definir interconexiones entre el usuario y el switch de telfonos. Por ellos cuando
describimos la vista externa de una llamada local, el SRS puede establecer que:

Comenzando con un telfono desocupado, el usuario debe levantar el auricular, el
sistema responder con un tono de marcar, entonces el usuario deber digitar el
nmero telfonico de 7 dgitos de la persona que el usuario intenta localizar...

Cuando se describe la vista externa de una llamada a larga distancia, el SRS puede
establecer que:

Comenzando con un telfono desocupado, el usuario debe levantar el auricular, el
sistema responder con un tono de marcar, entonces el usuario deber digitar un 1
seguido del nmero telefnico de 10 dgitos de la persona que el usuario intenta
localizar...

Note que la repeticin de los tres primeros pasos hace que el documento sea
considerablemente ms legible. Sin embargo, con la legibilidad adicional viene el potencial
de una modificabilidad reducida debido a que una modificacin posterior a slo una
ocurrencia podra conducir a un SRS inconsistente. Para hacer la redundancia aceptable, un
ndice o tabla de referencias cruzadas es esencial para localizar mltiples ocurrencias de los
requerimientos. Otra opcin puede ser utilizar la capacidad automtica de revisin de
consistencia de cualquiera de las herramientas automatizadas de requerimientos disponibles
en el mercado.

4.8. Rastreable
Un SRS es rastreable (traceable) si el origen de cada uno de los requerimientos es claro y
si facilita la referencia de cada uno de los requerimientos en un desarrollo futuro o mejora
de la documentacin.

Existen cuatro tipos de rastreabilidad (ver figura 6):

1. Hacia atrs desde los requerimientos implica que podemos conocer por qu cada
requerimiento en el SRS existe. Implica que cada requerimiento referencia
explcitamente a sus fuentes en documentos previos.
2. Hacia adelante desde los requerimientos implica que podemos entender cuales
componentes del software satisfacern cada requerimiento. Demanda que cada
requerimiento del SRS hace referencia explcitamente a un componente de diseo.
3. Hacia atrs hasta los requerimientos implica que cada componente de software
referencia explcitamente aquellos requerimientos a los cuales satisface. Implica que
cada uno de los requerimientos tiene un nombre nico o nmero de refefencia.
4. Hacia adelante hasta los requerimientos implica que todos los documentos que preceden
al SRS pueden referenciar al SRS. Como en la rastreabilidad hacia atrs a los
requerimientos, esto implica que cada requerimiento en el SRS tiene un nombre nico o
un nmero de referencia.














Figura 6. Expectativas de Rastreabilidad de un SRS


Asumamos que un SRS contiene el requerimiento

El sistema debe responder a cualquier ocurrencia de peticin X dentro de 20 segundos.

Ahora una vez el software ha sido construido y se ejecutan las pruebas finales, el tiempo de
respuesta es medido consistentemente en 60 segundos. Existen dos formas de corregir el
problema: (1) redisear o recodificar el software para hacerlo ms eficiente, o (2) cambiar
el requerimiento de 20 a 60 segundos. Si no existe referencia en el SRS que indique que
esos 20 segundos no son ms que una restriccin aleatoria de tiempo, podramos estar
tentados a usar la solucin 2 (y puede ser perfectamente satisfactorio). Sin embargo, si la
aplicacin es un sistema para monitoreo de pacientes y la razn por la cual el tiempo de
respuesta es de 20 segundos es que en un documento tcnico anterior se demostr
concluyentemente que en el entorno particular de un hospital en el cual el sistema de
monitoreo de pacientes va a ser instalado y con la proporcin existente de pacientes y
enfermeras, una enfermera necesita al menos tres consultas del sistema por minuto para
asegurar la ausencia de condiciones de emergencia en cada paciente. En tal caso, la
rastreabilidad hacia atrs desde los requerimientos establecera una referencia en el SRS en
donde aparece el requerimiento de tiempo hacia el documento tcnico. Entonces, cuando la
solucin 2 sea considerada, esta va a ser rpidamente rechazada luego de revisar el
documento tcnico.

De an ms importancia es la rastreabilidad entre el SRS y el diseo, que es, rastreabilidad
hacia delante desde y hacia atrs hacia los requerimientos. La forma ms comn de
Requerimientos del
Sistema, documentos
tcnicos, etc.

SRS
Documentos de
Diseo
Hacia atrs desde
los requerimientos
Hacia atrs hasta
los requerimientos
Hacia adelante hasta
los requerimientos
Hacia adelante desde
los requerimientos
implementar esto es mediante una matriz de rastreabilidad de requerimientos (RTM). A
pesar que el RTM no es creado durante la etapa de anlisis de requerimientos, el trabajo a
realizarse en esta etapa puede ser organizar los requerimientos de manera jerrquica (o
como mnimo para colocar nmeros nicos a cada requerimiento) para facilitar la posterior
construccin del RTM. En la forma ms simple, un RTM es una tabla bi-dimensional con
una fila por cada requerimiento del SRSR y una columna por cada componente de diseo.
Una X es colocada en cada lugar en donde el componente de diseo indicado satisface al
requerimiento indicado. Cuando esta terminado, una fila que no tenga X indica que existe
un requerimiento que no ser satisfecho, debido a que ninguna parte del diseo contribuye a
su satisfaccin. Una columna que no tenga X indica un componente extrao de diseo. La
ventaja del RTM es evidente durante el mantenimiento: Reduce enormemente el esfuerzo
de localizar las causas de falla del producto (examinando las entradas en las filas
correspondientes al requerimiento insatisfecho) y para analizar todos los posibles efectos
adversos de un cambio planeado de software (examinando las entradas en la columna
correspondiente al componente siendo cambiado).

4.9. Anotado
El propsito de colocar requerimientos con anotaciones en un SRS es proveer gua a la
organizacin del desarrollo. Dos tipos de anotaciones son de mucha ayuda : necesidad
relativa y estabilidad relativa.

Ocasionalmente cuando una organizacin de desarrollo puede gastar una cantidad enotme
de tiempo intentando satisfacer un requerimiento particular, para luego descubrir que el
cliente podra haber preferido el producto a tiempo sin ese requerimiento particular
satisfecho en lugar de tener el producto seis meses despus con el requerimiento satisfecho.
Este escenario pudo haberse evitado si las necesidades relativas de los requerimientos
individuales hubiesen sido establecidas inicialmente. Una forma de hacerlo es agregando a
cada requerimiento individual en el SRS una E, D u O in parntesis para indicar que es
esencial, deseable u opcional. Por supuesto el concepto de un requerimiento opcional es
oxymoronic, pero el hecho es que son importancias relativas entre los requerimientos.
Por ejemplo, el sistema de soporte de vida a borde del transbordador espacial es esencial,y
jugos de naranja son solamente opcionales, pero ambos pueden aparecer en la
especificacin de requerimientos a nivel del sistema. Por ello anotar cada requerimiento
con una E, D u O puede decir a los desarrolladores en que orden implementar los
requerimientos y cuales requerimientos pueden evitarse para no postergar las fechas de
entrega.

Adems, anotar cada requerimiento con una indicacin de cun voltil es el requerimiento
provee a los desarrolladores una gua en donde construir flexibilidad en su diseo. Por eso
en el transbordador espacial, por ejemplo, anotar el requerimiento para un sistema de
soporte de vida como estable y el requerimiento para soportar una tripulacin de n
miembros como voltil, provee a los diseadores el conocimiento suficiente para integrar
completamente el sistema de soporte de vida con el resto de la nave espacial y tener una
variable que puede ser referenciada cada vez que el SRS habla sobre el nmero de
miembros de la tripulacin.

4.10 Resumen
Lograr todos los atributos anteriores en un SRS es imposible. Por ejemplo, a medida que
intentamos eliminar inconsistencia y ambigedad (usualmente reduciendo el lenguaje
natural del SRS), el SRS se torna menos entendible por no especialistas en computadores.
A medida que intentamos ser absolutamente completo, el costo del SRS se dispara y el
documento se torna extremadamente largo y difcil de leer. Si intentamos incrementar la
modificabilidad eliminando todas las redundancias, el SRS se torna, difcil de leer, y
ambiguo. La figura 7 muestra algunos de esos efectos. La nica conclusin que podemos
obtener es que: NO EXISTE TAL COSA COMO UN SRS PERFECTO!.



































Figura 6. Un SRS perfecto es imposible.


ambiguo
incosistente
redundante
No
entendible
por NE-en-C
incompleto
arreglo
arreglo
arreglo
arreglo
arreglo
arreglo
arreglo arreglo