La Especificacion de Requerimientos de Software

8/3/2019 La Especificacion de Requerimientos de Software

1/15

/D(VSHFLILFDFLyQGH5HTXHULPLHQWRVGH6RIWZDUH

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.

,QWURGXFFLyQAntes 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 elSRS. 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 deenfrentar 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:

1Tomado de DAVIS, Alan. Software Requirements: Analisys and Specification. Prentice-Hall. 1990.


2/15

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 tieneun 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 UNAAYUDA AL ENTENDIMIENTO DEL COMPORTAMIENTO EXTERNO NICAMENTE, LOSDISEADORES PUEDEN SELECCIONAR CUALQUIER DISEO QUE DESEE MIENTRASSE 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 msentendibles; 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


3/15

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 trabajaefectivamente durante las etapas de mantenimiento y mejoras as como en las etapas

iniciales del desarrollo.

4XpGHEHLQFOXLUVHHQXQ656"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 todaslas 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 decmo 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.

4XHQRGHEHLQFOXLUVHHQXQ656"

Dado el propsito del SRS definido previamente, se torna claro que lo siguiente no haceparte 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 creenque 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 manualesdel 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 preocupacinsolamente del desarrollo (o con propsitos histricos). Por ello su tiempo de vida es solo


4/15

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 realmentedeseamos, 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 empacarlosseparadamente 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 losusuarios 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 decostos 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 sonlas 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 deaseguramiento 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).

$WULEXWRVGHXQ656ELHQHVFULWR

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:


5/15

&RUUHFWR

Un SRS es FRUUHFWRsi y slo si cada requerimiento que est en l representa algo requeridopor 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 todoslos botones presionados durante 10 segundos, ese requerimiento es incorrecto.

1R$PELJXRUn SRS es QR DPELJXR 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 unglosario. 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:

(MHPSOR3UREOHPDGHFRQWURODGRUGHWUiILFRDpUHR

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


6/15

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

)LJXUD(MHPSOR)RUPDWRVGH3DQWDOODGH&RQWUROGH7UiILFR$pUHR

D)RUPDWRSHTXHxRE)RUPDWR*UDQGH

)LJXUD(MHPSOR/RVGRVPyGXORVDHVFULELU

Generador de

datos para los

textos

Visualizador

de los textos

en pantalla

EA317

25000

270

LAX

De la basede datos

A mostraren pantalla

EA317

25000

270

LAX

PA17

15000

180

LAX

UN20127000

285

SFO

EA317

MX101

PA17

EA2

XV101AA505

CO101

UN201 EA319

UN401

EA205

PA236

UN500

(a) (b)


7/15

)LJXUD(MHPSOR/DWUDQVIHUHQFLDHUUyQHDGHGDWRV

Otro ejemplo:

(MHPSOR3UREOHPDGHODYLyQQRDPLJDEOH

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 \DVHDTXHno es amigable y tiene una misin desconocida R 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 \DVHDTXH tiene una misin desconocida R tiene el

potencial de entrar a espacio areo restringido dentro de 5 minutos debe generar unaalerta.

Cualquiera de ellas puede ser la correcta, pero esas frases tienen significadosenteramente 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 F1y 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 unanave 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 areorestringido 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 esterequerimiento 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

PA17De la base

de datos

A mostrar

en pantalla


8/15

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.

)LJXUD(MHPSOR(VSDFLR$pUHRUHVWULQJLGR$UHDGHSUXHEDGHERPEDV

)LJXUD(MHPSOR(VSDFLR$pUHRUHVWULQJLGR$YLyQ&DUJHUR

&RPSOHWR

Un SRS es FRPSOHWRsi posee cuatro cualidades:

1. Todo lo que el software se supone que debe hacer esta incluido en el SRS. Este es elatributo 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

N1

N2

N1

N2F1

Espacio areo

restringido

F = Amigable

N = No Amigable


9/15

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 puedatimbrar 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 deentrada 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 deestados (S) con el producto cruz del dominio de salidas (O) y el dominio de estados 8S),

eso es:

656,[6o2[6


10/15

3. Todas las pginas estn numeradas: todas las figuras y tablas estn numeradas, connombres 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.

9HULILFDEOH

Un SRS es YHULILFDEOHsi 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.


11/15

&RQVLVWHQWH

Un SRS es FRQVLVWHQWHsi y solo si ningn subconjunto de los requerimientos individualesestablecidos en l tiene conflictos. Esto puede manifestarse en un nmero de formas. Por

ejemplo,

1. 7pUPLQRVFRQIOLFWLYRVDos trminos son usados en diferentes contextos para significarla 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 algunainformacin, mientras en otro lugar el SRS utiliza la palabra clave para denotar la

misma situacin.

2. &DUDFWHUtVWLFDV FRQIOLFWLYDVDos partes del SRS demandan que el producto exhibacomportamientos contradictorios. Por ejemplo, en un lugar del SRSR se establece queTodas 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. ,QFRQVLVWHQFLD7HPSRUDODos 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 esteocurriendo, 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.

(QWHQGLEOHSRU1R(VSHFLDOLVWDVHQ&RPSXWDGRUHVEn 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 elentender 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 notacinformal 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 esrequerida. 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.

0RGLILFDEOHMientras 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 PRGLILFDEOHsi 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 sermodificado. Por ejemplo, si deseamos cambiar el tiempo de respuesta mximo requerido


12/15

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

Una tcnica que puede ser usada para mejorar le legibilidad del SRS es repetirrequerimientos seleccionados en diferentes localizaciones del documento. Este atributo del

SRS es llamado UHGXQGDQFLD. Por ejemplo, al describir la interfaz externa de un PBX,

debemos definir interconexiones entre el usuario y el switch de telfonos. Por ellos cuandodescribimos 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 deconsistencia de cualquiera de las herramientas automatizadas de requerimientos disponibles

en el mercado.

5DVWUHDEOHUn SRS es UDVWUHDEOH (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 cadarequerimiento en el SRS existe. Implica que cada requerimiento referenciaexplcitamente a sus fuentes en documentos previos.

2. Hacia adelante desde los requerimientos implica que podemos entender cualescomponentes del software satisfacern cada requerimiento. Demanda que cada

requerimiento del SRS hace referencia explcitamente a un componente de diseo.


13/15

3. Hacia atrs hasta los requerimientos implica que cada componente de softwarereferencia 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 precedenal 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 oun nmero de referencia.

)LJXUD([SHFWDWLYDVGH5DVWUHDELOLGDGGHXQ656

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 derespuesta 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, larastreabilidad 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


14/15

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

$QRWDGR

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.


15/15

5HVXPHQ

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 lamodificabilidad 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!.

)LJXUD8Q656SHUIHFWRHVLPSRVLEOH

ambiguo

incosistente

redundante

Noentendible

por NE-en-C

incompleto

arreglo

arregloarreglo

arreglo

arreglo

arreglo

arreglo arreglo

La Especificacion de Requerimientos de Software

Documents

Transcript of La Especificacion de Requerimientos de Software