Especificacin de Sistemas de Software

1 Introduccin
Lo ms difcil en la construccin de un sistema software es decidir precisamente qu
construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se
hace mal... Ninguna otra tarea es tan difcil de rectificar a posteriori...
F. P. Brooks, 1987
F. P. Brooks es el autor de The Mythical Man-Month, quiz el nico libro clsico de la
Ingeniera del Software [Br075]. Brooks fue jefe de proyecto del OS/360, el sistema
operativo del IBM/360. A lo largo de este enorme proyecto, Brooks padeci todos los
males que constituyen lo que habitualmente se conoce como "crisis del software".
Continuamente se publican nuevos datos acerca de la importancia de los requisitos en
Ingeniera del Software. Por ejemplo, segn el Chaos Report del Standish Group
(www.standishgroup.com/chaos.html) resulta que:

El gasto anual en proyectos software en EEUU es de unos 250 billones de dlares,

invertidos en aproximadamente unos 175000 proyectos.

31,1% sern cancelados

52,7% costarn un 190% ms de lo estimado

Un 16,2% ser finalizado a tiempo y dentro del presupuesto pero el producto final
poseer (aprox.) la mitad de los requisitos iniciales

Estudios anteriores a ste [Dav93] reflejan que

El 45% de los errores tienen su origen en los requisitos y en el diseo preliminar

(Boehm, 1975).

El 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala
Especificacin de Requisitos (DeMarco, 1984)

Segn el Chaos Report de 1995, de nuevo resulta que los factores principales que
conducen al fracaso en los proyectos Sw son

Falta de comunicacin con los usuarios

Requisitos incompletos

Cambios a los requisitos

Resulta evidente que no se han producido grandes mejoras en los ltimos aos
Se podran contar ms historias de horror relacionadas con los requisitos:

Uno de los estudios ms conocidos es el de la General Accounting Office (GAO)

de EEUU. Este estudio de 1919 revel que el 47% del dinero empleado en
proyectos software se destin a sistemas que no llegaron a utilizarse. Otro 29% se

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

emple en proyectos que no llegaron a finalizar. Otro 19% se emple en software
que tuvo que ser profundamente modificado tras su entrega. Finalmente tan slo
un 2% del dinero se emple en proyectos software que s cumplieron con sus
requisitos, pero se trataba de proyectos ms bien pequeos o de poca envergadura.

En 1981, Victor Basili encontr cerca de 88 errores en una ERS de 400 pginas
para el proyecto A-7E Operational Flight Program. Esta ERS haba sido escrita por
un grupo de expertos en especificacin de requisitos.

Recientemente, la NASA ha sufrido dos accidentes espectaculares cuyo origen se

atribuye a problemas durante la definicin de los requisitos

Por otro lado, la evidencia emprica [Dav93] demuestra que

Los requisitos contienen demasiados errores

Muchos de estos errores no se detectan al principio

Muchos de estos errores podran ser detectados al principio

No detectar estos errores incrementar los costes (tiempo, dinero) de forma
exponencial

y esto trae como consecuencia que

El sistema resultante no satisfar a los usuarios

Se producirn desacuerdos entre usuarios y desarrolladores
Puede ser imposible demostrar si el software cumple, o no, los requisitos
Se gastar tiempo y dinero en construir el sistema equivocado

Antes de nada, debera recordarse el hecho de que la gran mayora de los sistemas no
parten de tan solo 15 o 30 requisitos. Tambin hay sistemas de cientos de requisitos,
sistemas de miles de requisitos, sistemas de 5.000 requisitos, sistemas de ms de 10.000 e
incluso se conocen casos de sistemas que presentan unos 60.000 requisitos!
1.1 Evidencia de la importancia de los requisitos
La evidencia emprica demuestra que, cuanto ms tarde se descubran, el coste de la
reparacin de los errores introducidos en la etapa de requisitos crece exponencialmente. Si
asignamos coste 1 al coste de reparar un error de requisitos descubierto en la etapa de
requisitos, se obtendran las siguientes cifras[Dav93]:
Etapa
Requisitos
Diseo
Codificacin
Pruebas Unitarias
Pruebas sistema
Explotacin / Mantenimiento

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Coste de Reparacin
1-2
5
10
20
50
200

Especificacin de Sistemas de Software

Ante esta situacin qu se puede hacer? En primer lugar, se debe tomar conciencia del
problema y estar a la defensiva. Quiz nos se conozcan todas las soluciones, pero al menos
se conocen los problemas. Quiz no sea posible elaborar los requisitos con absoluta
perfeccin, pero se debera intentar minimizar el impacto de los errores en los requisitos y
se podra tratar de organizar mejor las tareas relacionadas con los requisitos.
Hay, o habr, soluciones definitivas para el problema de los requisitos? Claramente,
dado el estado actual del conocimiento, no se han encontrado soluciones universalmente
vlidas e incluso hay serias dudas acerca de si dicha solucin existe. Los requisitos se
sitan en la frontera socio-tcnica de los sistemas, y esta frontera es borrosa, voluble e
inconsistente. Segn M. Jackson los requisitos son donde lo formal se encuentra con lo
informal. Los requisitos estn vivos: emergen, interactan, cambian, desaparecen...
Incluso sera recomendable desconfiar de quien pretenda ofrecer una solucin definitiva a
estos problemas!!!
1.2 Qu es la Ingeniera de Requisitos
Para remediar en lo posible esta situacin, surge la Ingeniera de Requisitos (IR) [KS98]:
La IR trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir,
documentar y mantener los requisitos para sistemas basados en computadora, de forma
sistemtica y repetible.
De todas formas, la prudencia obliga a informar que, para algunos autores, la IR es una
contradiccin en s misma.
1.3 Qu son los requisitos
Hay demasiada confusin a la hora de definir lo que son realmente los requisitos, o qu se
entiende por "requisitos" en el campo de la IR. An a riesgo de aadir ms "ruido", se
proporcionar una nueva definicin (inspirada en [Jac95] y [Kov99])
En primer lugar se considerar que todo problema sw. consiste en configurar una
mquina M para que ejerza unos efectos R en un dominio D.

Los efectos R seran, propiamente hablando, los requisitos: representan necesidades,

metas y objetivos.
El dominio D es el contexto: Los requisitos R, sin contexto, no tienen sentido.
Cambiando el contexto D, un requisito de R pierde su sentido.
La mquina M es la que realizar los requisitos R, gracias a su conexin con D. En
la fase de requisitos tan slo necesitamos describir las conexiones de M con D, es
decir, el comportamiento externo de M (M-ex), sin detalles internos (M-int).
Pues bien, por extensin, en IR se denominan requisitos a los conjuntos M-ex, R y D,
aunque tan slo R sean propiamente requisitos.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

Por ejemplo: Supngase que hay que desarrollar el software pare un sistema de control de
una caldera de vapor. En este contexto, la afirmacin
Afl el agua entra en ebullicin a 100 Grados Centgrados y a 1 atm. de presin
no es un requisito, ya que no es una meta ni un objetivo. La anterior afirmacin (Afl) es
parte de la descripcin del dominio (D), y es verdadera independientemente de la
existencia o no del sistema. En cambio, la frase
Af2 El sistema evitar que el agua entre en ebullicin
es un requisito (R). Expresa un deseo u objetivo. Algo que el sistema deber realizar. Por
otro lado, las frases
Af3 El sistema leer la temperatura del agua por medio del sensor
Af4 El sistema podr subir la temperatura del agua por medio del regulador
describen la conexin del software (nuestra mquina M) con el entorno, es decir, describen
el comportamiento externo del software (M-ex). No son metas ni objetivos, pero son
necesarios para conseguir las metas y los objetivos (p.ej. para conseguir que sea verdadera
la Af2).
Pues bien: aunque propiamente hablando tan slo Af2 es un requisito, a la Ingeniera de
Requisitos le interesan todas las afirmaciones anteriores, ya que todas aportan informacin
relevante para construir el sistema y para que el sistema funcione de la manera deseada.
El siguiente ejemplo est basado en un caso real, y demuestra que los requisitos R (metas,
deseos) no son suficientes, si no se encuentran situados en un contexto: Se trata de
especificar un software para un sistema de avinica. En estos sistemas, hay un requisito
que establece que la marcha atrs puede ser habilitada si, y solo si, el avin se encuentra
sobre la pista. Es decir:
R : marcha_atras_habilitada

avion_en_pista

Para detectar si las ruedas se encuentran, o no, sobre la pista, existen unos sensores
conectados a las ruedas que generan pulsos elctricos cuando las ruedas se encuentran
girando. Para que este mecanismo funcione, se supone que, en el dominio que rodea al
software (o sea, en el mundo real) se cumple que las ruedas rotan cuando se encuentran
sobre la pista, y que el sensor enva pulsos cuando las ruedas rotan:
D1 : pulsos_sensor

ruedas_rotando

D2: ruedas_rotando

avin_en-pista

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

Obsrvese que las dos afirmaciones anteriores no son requisitos, sino descripciones.
Finalmente, la descripcin del comportamiento externo de la mquina M (en realidad, el
comportamiento externo del software, M-ex) establecera que:
M-ex: marcha_atrs_habilitada

pulsos-sensor

Puede comprobarse que, dado este comportamiento externo de la mquina, M-ex, y dadas
las descripciones D, se cumple R.
La importancia del conocimiento del dominio (D) es crucial en la IR. Si se da el caso
(como sucedi en la realidad) de que la pista est mojada, se producir aquaplanning y,
por tanto, deja de cumplirse D2 (las ruedas no rotan, a pesar de que el avin se encuentra
en la pista). Por lo tanto, un pequeo cambio en el dominio D, pese a no hallarse
(aparentemente) conectado con el software, puede conducir a una situacin en la que el
requisito R no se cumple. Para solucionar esta situacin, debera cambiarse el
comportamiento externo del software (M-ex), lo cual quiz obligue a modificar el sistema
de sensores. Lo que es imposible cambiar es D, pues son descripciones que corresponden
a la realidad (salvo error), no son metas ni son especificaciones del software.
Finalmente, repetir que en IR, a pesar de la confusin que se pueda originar, se
denominan requisitos a los tres conjuntos M-ex, R y D. La razn es que los requisitos
estn constituidos por todas aquellas informaciones necesarias para construir un sistema
que satisfaga las metas perseguidas.
Es importante, asimismo, destacar qu no son los requisitos. Los requisitos NO son
anlisis top-down, ni son la arquitectura del sistema, ni son el qu frente al cmo.
1.4 Otros contenidos relevantes
Detallando un poco ms lo expuesto en el prrafo anterior, es necesario que un documento
de requisitos contenga, en primer lugar:

Informacin acerca del problema

Propiedades y comportamiento del sistema

Restricciones de diseo y fabricacin del producto

Pero adems podra contener

Descripciones acerca de cmo el futuro sistema ayudar a sus usuarios a realizar

mejor sus tareas

Restricciones acerca de la tecnologa que ser utilizada en la construccin del

sistema (protocolos, SSOO, cJOTS, etc.)

Restricciones acerca de las propiedades emergentes del sistema (requisitos no

funcionales)

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

1.5 Cmo escribir requisitos?
Los requisitos constituyen la base de la comunicacin entre todas las partes interesadas en
el desarrollo del sistema: usuarios, clientes, desarrolladores y el equipo encargado de
realizar las pruebas. Todas estas personas forman un conjunto heterogneo, lo cual
provoca, desafortunadamente, que la mejor formade escribir requisitos no exista. Lo que
para unos puede ser un lenguaje muy preciso (p.ej. notaciones formales), para otros puede
ser un lenguaje incomprensible.
Debido a esto, en la prctica, lo ms utilizado es el lenguaje natural, a pesar de su
inherente ambigedad. Se acostumbra a especificar cada requisito como una frases corta
(el sistema har X ..., se facilitar X..., etc). Tambin se utiliza el lenguaje natural
complementado con diagramas y / o notaciones formales. La notacin utilizada depende de
quien leer o quien escribir los requisitos.
Ejemplos de requisitos podran ser:
1. El sistema mantendr la temperatura de la caldera entre 70 y 80 grados.
2. El sistema mantendr un registro de todos los materiales de la biblioteca, incluyendo
libros, peridicos, revistas, videos y CDRoms.
3. El sistema permitir a los usuarios realizar una bsqueda por ttulo, autor o ISBN.
4. La interface de usuario se implementar sobre un navegador Web.
5. El sistema deber soportar al menos 20 transacciones por segundo.
6. El sistema permitir que los nuevos usuarios se familiaricen con su uso en menos de
15 minutos.
Aqu puede verse que los requisitos son de muy distintos tipos:
Requisitos que definen efectos sobre el entorno (p.ej. el 1)
Requisitos muy generales (p.ej, el 2)
Requisitos funcionales (3)
Requisitos de implementacin (4)
Requisitos de rendimiento (5)
Requisitos de usabilidad (6)
Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma
estndar de escribirlos. Tampoco es posible decir cual es la mejor forma de
especificarlos. Todo depende mucho de quien los escribe, quien los va a leer, el dominio de
la aplicacin, etc.
1.6 Requisitos en negativo
Tan importante como decir lo que el sistema debe hacer, lo es el decir lo que el sistema
NO debe hacer. Estos requisitos en negativo limitan el mbito del sistema. Las razones
son varias:

En primer lugar, dicen donde NO se deben emplear recursos.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

Por otro lado, especificar lo que el sistema no har es fundamental para

sistemas crticos (es decir, sistemas en los que un fallo puede provocar un
accidente). Se trata de especificar cmo el sistema evitar la aparicin de
situaciones potencialmente peligrosas.

1.7 Requisitos funcionales y no funcionales

Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema.
Por ejemplo:
El sistema aceptar pagos con VISA
Los requisitos no funcionales son restricciones sobre los requisitos funcionales. Por
ejemplo:
El sistema aceptar pagos con VISA de forma segura y con un tiempo de respuesta
menor a 5 segundos
Pero esta distincin, muchas veces, resulta arbitraria. Por ejemplo:
El sistema aceptar pagos con VISA a travs del protocolo SET
En este caso, lo que aparentemente es un requisito funcional, est determinado, en el fondo,
por una serie de caractersticas no funcionales (caractersticas que hacen que el protocolo
SET sea el ms adecuado para los objetivos perseguidos).
1.8 Requisitos del software frente a requisitos del sistema
El ciclo de vida habitualmente descrito por las fases de la cascada, es decir

Elaboracin de requisitos y anlisis

Diseo

Codificacin

Pruebas

Mantenimiento

Corresponde a un ciclo de desarrollo para sistemas compuestos exclusivamente de

software, como pueden ser los Sistemas de Informacin o un software de proceso de textos.
Esto no es aplicable, en cambio, para describir el ciclo de desarrollo de sistemas
compuestos de Hardware y Software, es decir, todo tipo de sistemas empotrados y sistemas
en los que el software interacta fuertemente con el hardware (sistemas de control,
sistemas de monitorizacin, electrnica de consumo, etc.). En este caso, el software est
supeditado a un diseo del sistema y a unos requisitos de nivel superior. Este ciclo podra
describirse as:
Maestra en Informtica UNSTA
Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

Elaboracin de requisitos y anlisis del sistema

Diseo a alto nivel del sistema

Identificacin de requisitos del hardware e identificacin de requisitos del

software

Desarrollo de la arquitectura del1 hardware y desarrollo de la arquitectura del

software

etctera...

Precisamente, uno de los problemas ms difciles en Ingeniera de Sistemas (Hw+Sw) es el

problema de la asignacin (en ingls, allocation): Consiste en decidir qu partes del
sistema (o qu tareas) van a ser ejecutadas por el Hw y cuales van a ser programadas en
Sw.
1.9 Relacin de los requisitos con la arquitectura del sistema
La eleccin de una determinada arquitectura sw. debe tener en cuenta los requisitos
funcionales pero, sobre todo, los requisitos no funcionales. No hay una regla definitiva
para establecer, dados los requisitos, el tipo de arquitectura. Tan slo hay una serie de
heursticas para, dados unos requisitos, elegir la arquitectura. Se entiende por
"arquitectura" de un sistema software el diseo de alto nivel, es decir, los componentes, las
conexiones entre componentes y las propiedades que deben cumplir.

2 El proceso de requisitos
El proceso de Ingeniera de Requisitos es un conjunto estructurado de actividades que
sirven para derivar, validar y mantener los requisitos de un sistema (hardware, software o
hardware+software). Las tareas que conlleva este proceso, a grandes rasgos, se representan
en el siguiente grfico:
Educcin de
Requisitos

Anlisis y
Negociacin

Documentacin
de Requisitos

Necesidades
Informacin del Dominio
Estndares
Etc.

Educcin de
Requisitos

Documento de
Requisitos

Gestin de Requisitos

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

En el dibujo, los cuadros redondeados son tareas. Los cuadrados son productos (inputs o
outputs). En el resto de ste documento se explicar cada componente de este proceso.
Debe destacarse que la separacin que aqu se ofrece es ms conceptual que real. Las
distintas tareas que se ejecutan durante el proceso de requisitos suceden en paralelo y se
solapan unas con otras. Por ejemplo, durante un proceso de educcin de requisitos
empleando prototipado, es inevitable realizar una pequea validacin de los requisitos
que se van obteniendo, o incluso una pequea negociacin, si, por ejemplo, estamos
tratando con varios usuarios a la vez.
2.1 Variaciones en el proceso
Las variaciones dependen, sobre todo, de la naturaleza del proyecto:

Si es dirigido al mercado

Si es un sistema a medida

Segn las caractersticas de la aplicacin

Si es software empotrado. Habra que tener en cuenta, adems los factores

Riesgo
Recursos
Incertidumbre

Se sabr que tenemos un proceso de requisitos problemtico s:

El proceso de requisitos es excesivamente largo y costoso

Los implicados en el proceso se queja de falta de tiempo u otros recursos

Se reciben quejas acerca de la inteligibilidad del documento de requisitos

Los implementadores se quejan del trabajo perdido por culpa de errores en los
requisitos

Los usuarios no utilizan muchas de las capacidades del sistema

En cuanto el producto se entrega, se recibe una inmensa cantidad de solicitudes de

cambios

Lleva demasiado tiempo alcanzar un acuerdo cuando se proponen cambios a los

requisitos

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

Especificacin de Sistemas de Software

3 Educcin de Requisitos
La educcin de requisitos se refiere a la captura y descubrimiento de los requisitos. Es
una actividad ms humana que tcnica, en la que se identifica a los interesados y se
establecen las primeras relaciones entre ellos y el equipo de desarrollo.
3.1 Principales fuentes de requisitos
Los requisitos pueden proceder de:

Metas: Factores crticos de xito

Conocimiento del dominio de la aplicacin

Los interesados. Los afectados por el sistema.

El entorno fsico que rodea al sistema

El entorno organizacional. Los procesos de negocio.

3.2 Problemas de la educcin

Entre los principales problemas que pueden entorpecer la tarea de educcin de requisitos se
cuentan los siguientes:

Los usuarios no pueden / saben describir muchas de sus tareas

Mucha informacin importante no llega a verbalizarse

A veces hay que inventar los requisitos (sistemas orientados a miles de usuarios)

La educcin se afronta como un proceso pasivo, cuando debera ser un proceso

cooperativo

3.3 Tcnicas de educcin

Entrevistas: Es el mtodo tradicional

Observacin y anlisis de tareas

Escenarios: los requisitos se sitan en el contexto de uso del sistema

Prototipado: cuando la incertidumbre es total acerca del futuro sistema. Hay dos
tipos principales:
-

Evolutivo

De usar y tirar (prototipos en papel, etc.)

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

10

Especificacin de Sistemas de Software

4 Anlisis de Requisitos
El anlisis de requisitos consiste en detectar y resolver conflictos entre requisitos. Durante
la realizacin de esta tarea, se precisan los lmites del sistema y la interaccin con su
entorno, se trasladan los requisitos de usuario a requisitos del software (implementables)
y, ante todo, se realizan tres subtareas fundamentales:

Clasificacin de los requisitos

Modelizacin de requisitos

Negociacin

4.1 Clasificacin de los requisitos

En el anlisis de requisitos, stos se pueden clasificar de distintas formas y atendiendo a
distintos criterios:

En funcionales vs. No funcionales (Capacidades vs. Restricciones).Por prioridades

Por coste de implementacin

Por niveles (alto nivel, bajo nivel)

Segn su volatilidad / estabilidad

Si son requisitos sobre el proceso o sobre el producto

4.2 Modelizacin de requisitos

Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de
estados, de interaccin, de objetos, etc. La meta es entender mejor el problema, ms que
iniciar el diseo de la solucin (idealmente). El tipo de modelo elegido depende de

La naturaleza del problema

La experiencia del modelizador

La disponibilidad de herramientas

Por decreto. El cliente impone una notacin

Tradicionalmente se entenda que el anlisis se reduca a modelizar (DFDs, modelos de

objetos, etc.), pero el anlisis de requisitos NO es exclusivamente un proceso de
modelizacin. Por otro lado, no existe la mejor forma de modelizar requisitos. En
realidad, no hay evidencia emprica que demuestre, en general, la superioridad de unas
notaciones de modelizacin frente a otras.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

11

Especificacin de Sistemas de Software

4.3 Negociacin de requisitos
En todo proceso de IR intervienen distintos individuos con distintos y, a veces,
enfrentados intereses. Estos conflictos entre requisitos se descubren durante el anlisis.
Todo conflicto descubierto debera disparar un proceso de (re)negociacin, es decir, los
conflictos NUNCA se deben resolver por decreto.
Es durante el anlisis cuando muchos de los conflictos entre requisitos son descubiertos.
EL CONFLICTO NO ES RECHAZABLE y no debe resolverse por decreto, sino
mediante un proceso de negociacin. Desde este punto de vista, los conflictos son
positivos, pues SON FUENTE DE NUEVOS REQUISITOS. Los acuerdos alcanzados
deben ser convenientemente anotados, favorecindose as la trazabilidad de los requisitos
a sus orgenes (el requisito 987 surge como resultado de la reunin entre x, y z el da tal
del tal...)
Existe, incluso, un subcampo de la IR dedicada a este tipo de temas: la IR orientada a
Puntos de Vista o "Viewpoint-Based Requirements Engineering".

5 El Documento de Requisitos
El llamado "Documento de Requisitos" es el modo habitual de guardar y comunicar los
requisitos. Debe tenerse en cuenta que, al decir "documento", nos referimos a cualquier
medio electrnico de almacenamiento y distribucin de informacin como, por ejemplo:

Procesador de textos

Base de Datos

Herramienta de Gestin de Requisitos

En general, es buena prctica utilizar, al menos, dos documentos, a distinto nivel de

detalle:
1. DRU = Documento de Requisitos de Usuario (en ingls, URD)
2. ERS = Especificacin de Requisitos Software (en ingls, SRS)
La pregunta que surge es en qu se diferencian los requisitos de usuario de los requisitos
del software? A grandes rasgos se puede afirmar que:

El DRU se escribe desde el punto de vista del usuario/cliente/interesado.

Normalmente los requisitos de usuario, contenidos en la DRU, no poseen
demasiado nivel de detalle. Se incluye la descripcin del problema actual (razones
por las que el sistema de trabajo actual es insatisfactorio) y las metas que se espera
lograr con la construccin del nuevo sistema.

La ERS desarrolla mucho ms los contenidos de la DRU. Los requisitos del

software contenidos en la ERS son, por tanto, ms detallados. Contiene la

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

12

Especificacin de Sistemas de Software

respuesta a la pregunta Qu caractersticas debe poseer un sistema que nos permita
alcanzar los objetivos, y evitar los problemas, expuestos en la DRU?
5.1 Estndares
Los dos documentos estndares ms conocidos de especificacin de requisitos son:

IEEE Std. 830

PSS-05 de la Agencia Espacial Europea (ESA) Las herramientas de gestin de

requisitos permiten generar documentacin en los anteriores formatos, a partir de
una base de datos de requisitos.

5.2 Caractersticas deseables de una ERS

Una ERS de calidad debera presentar, dentro de lo posible, las siguientes caractersticas:

No ambigua: La ERS es no ambigua si todo requisito posee una sola

interpretacin.

Completa: Una ERS es completa si todo lo que se supone que el software debe
hacer est incluido en la ERS. Por completitud, deberan describirse todas las
posibles respuestas a todas las posibles entradas y en todas las situaciones
posibles. Adems, la ERS no contendr secciones de tipo por determinar....

Correcta: Todo requisito de la ERS contribuye a satisfacer una necesidad real.

Comprensible: Todo tipo de lectores (clientes, usuarios, desarrollado- res,

equipo de pruebas, gestores, etc.) entienden la ERS.

Verificable: Si para cada requisito expresado en la ERS existe un procedimiento

de prueba finito y no costoso para demostrar que el futuro sistema lo satisface.

Internamente Consistente: No existen subconjuntos de requisitos

contradictorios.

Externamente Consistente: Ninguno de los requisitos est en contradiccin con

lo expresado en documentos de nivel superior. Por ejemplo, en un sistema
(hardware+software), los requisitos del software no pueden contradecir los
requisitos del sistema.

Realizable: Si, dados los actuales recursos, la ERS es implementable.

Concisa: La ERS debe ser lo ms breve posible, sin que esto afecte al resto de
atributos de calidad.

Independiente del diseo: Existen ms de un diseo e implementacin que

realizan la ERS. Para ello la ERS debera limitarse a describir el
comportamiento externo del sistema.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

13

Especificacin de Sistemas de Software

Trazable: Cada requisito se puede referenciar de forma unvoca. Es fundamental

para precisar qu requisitos son implementados por qu componente del diseo,
lo cual es imprescindible a la hora de realizar las pruebas de dicho componente.

Modificable: Los cambios son fciles de introducir.

Electrnicamente almacenada: Se encuentra en un archivo de texto, en una base

de datos o, mejor an, ha sido creada con una herramienta de gestin de
requisitos (RequisitePro, Doors, etc.).

Ejecutable/Interpretable/Prototipable/Animable: Si existe una herramienta

software que, recibiendo como entrada la ERS, realice un modelo ejecutable de
la misma. Aplicable tan slo a ciertas notaciones como las notaciones formales
o los diagramas de transicin de estados.

Anotada por importancia relativa: Si los requisitos se clasifican segn su

importancia. Como mnimo un requisito puede ser "Obligatorio, Deseable u
Opcional". Esto sirve para no asignar demasiados recursos a la implementacin
de requisitos no esenciales.

Anotada por estabilidad relativa: Los requisitos son, en general, inestables y

voltiles. A cada requisito se le asigna una probabilidad de cambio (p.ej. "Alta,
Media o Baja"). Esto ayudar a los diseadores a diferenciar los componentes
ms flexibles de los ms estables.

Anotada por versin: Si un lector de la ERS puede determinar qu requisitos

sern satisfechos por qu versin del producto.

No redundante: Cada requisito se expresa en un solo lugar de la ERS. La

redundancia, de todas formas, no es del todo mala si aumenta la legibilidad.

Al nivel adecuado de abstraccin: Ni demasiado detallada ni demasiado vaga.

Precisa: Una ERS es precisa si hace uso de valores numricos para precisar las
caractersticas del sistema. La precisin es aplicable, ante todo, a los requisitos
no funcionales. Por ejemplo, no es til decir El tiempo de respuesta ser ms
bien rpido, sino El tiempo de respuesta ser menor a dos segundos. OJO: en
la prctica diaria, este atributo es dificilsimo de conseguir pues es fuertemente
dependiente de la tecnologa disponible, lo cual no siempre se conoce al
principio de un proyecto.

Reutilizable: Si ciertas secciones de la ERS se pueden reutilizar.

Trazada: Si est claro el origen de cada requisito (quin o qu lo pide)

Organizada: Si el lector puede fcilmente encontrar la informacin buscada.

Con referencias cruzadas: Si se utilizan referencias entre requisitos relacionados

(trazabilidad intra-ERS) o entre secciones relacionadas.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

14

Especificacin de Sistemas de Software

De todas forma, aumentar una de estas caractersticas es posible que disminuya otra (por
ejemplo, disminuir la ambigedad puede conducir a un aumento de la ininteligibilidad). La
calidad debe perseguirse como algo ideal, a pesar de que una ERS perfecta es imposible.
La calidad de la ERS es muy difcil de cuantificar y, en general, una ERS de calidad NO
garantiza la ausencia de problemas (aunque una ERS psima garantiza su presencia).

6 Validacin de Requisitos
El objetivo de la validacin de los requisitos es descubrir problemas en el Documento de
Requisitos antes de comprometer recursos a su implementacin. El documento debe
revisarse para

descubrir omisiones o falta de requisitos

Conflictos

Ambigedades

Comprobar la calidad del documento y su grado de adhesin a estndares

6.1 Revisiones (Reviews)

Las revisiones del documento de requisitos constituyen la frmula ms empleada en
validacin. En estas revisiones, un grupo de personas (incluyendo usuarios) se ocupan
de revisar el documento de requisitos. Tienen tres fases:

Bsqueda de problemas

Reunin

Establecimiento de acuerdos

Como gua para identificar problemas habituales, se pueden utilizar listas de comprobacin
(checklists). Hay checklists adaptadas a distintos tipos de sistemas. Otros mtodos de
validacin son:

Prototipado: Permite descubrir con rapidez si el usuario se encuentra

satisfecho, o no, con los requisitos

Validacin de modelos: Cuando los requisitos se expresan por medio de

modelos (de objetos, DFDs, etc.)

Validacin de la "testeabilidad". El equipo de pruebas debe revisar los

requisitos.

El 33% de los errores de requisitos en la especificacin del sistema A-7E fueron

detectados mediante revisin manual. El resto se descubrieron en posteriores fases, con
el consiguiente incremento en el coste.
Maestra en Informtica UNSTA
Ing. Ernesto Jos Rico

15

Especificacin de Sistemas de Software

Curiosamente, las revisiones parecen funcionar tambin con el cdigo ejecutable: se
descubren ms errores inspeccionando el cdigo fuente que ejecutando el programa.
Quiz radique aqu el xito de los desarrollos Open Source o de fuente abierto.
Cada organizacin, segn su experiencia y segn el dominio de las aplicaciones que
desarrolle, debera desarrollar su lista de comprobacin o checklist particular. Un
ejemplo de cuestiones que deberan figurar en una lista de comprobacin podra ser
estas:

Estn todos los requisitos convenientemente numerados?

El mismo servicio es solicitado en distintos requisitos? Existen contradicciones

entre ellos?

Los requisitos relacionados se encuentran agrupados en el documento?

Los requisitos son fcilmente comprensibles? Por todo tipo de lectores?

En general, una lista de comprobacin debera girar alrededor de los atributos de calidad
(anteriormente expuestos) que debera poseer una ERS. Para cada atributo de calidad, se
pueden plantear una serie de cuestiones que sirvan para confeccionar la lista de
comprobacin.

7 Gestin de Requisitos (Requirements Management, RM)

La gestin de Requisitos consiste, bsicamente, en gestionar los cambios a los
requisitos. Asegura la consistencia ente los requisitos y el sistema construido (o en
construccin). Esta tarea consume grandes cantidades de tiempo y esfuerzo y abarca
todo el ciclo de vida del producto.
Es necesario realizar una adecuada gestin de requisitos por una serie de razones, como:

Los requisitos son voltiles.

El entorno fsico del sistema cambia.

Trasladar un sistema de un entorno a otro requiere modificaciones.

El entorno organizacional cambia (cambian los directivos).

Las polticas cambian.

Cambios en las reglas y en los procesos del negocio provocan cambios en el

sistema.

La propia existencia del sistema va a generar nuevos requisitos por parte de los
usuarios.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

16

Especificacin de Sistemas de Software

La Gestin de Requisitos implica:

Definir procedimientos de cambios: definen los pasos y los anlisis que se

realizarn antes de aceptar los cambios propuestos.

Cambiar los atributos de los requisitos afectados

Mantener la trazabilidad: hacia atrs, hacia delante y entre requisitos

Control de versiones del documento de requisitos

Para realizar adecuadamente estas tareas, se pueden emplear herramientas de Gestin de

Requisitos, que facilitan las tareas relacionadas con la escritura, trazabilidad y gestin de
cambios. Estas herramientas organizan los requisitos en bases de datos y permiten aadir
atributos a los requisitos. Conocidas herramientas comerciales de Gestin de requisitos
seran DOORS, RequisitePro, icConcept, etc.

8 La IR en la prctica hoy
Hoy el software es parte casi imprescindible de todo tipo de dispositivos. El software se
utiliza para proporcionar valor aadido a productos tradicionales (telfonos, refrigeradores,
coches) y para diferenciarse de los productos de la competencia. Basta con decir que, hoy
da, el componente ms complejo de un coche es el software (por ejemplo, hay modelos de
Mercedes que contienen sistemas empotrados que suman casi 5 Mbytes de cdigo
ejecutable!!!).
Industrias tradicionalmente alejadas del software hoy tienen problemas de requisitos.
Introducir componentes software es distinto a introducir nuevos componentes fsicos. La
complejidad que aade el software es de varios rdenes de magnitud respecto a la
complejidad que aadira un nuevo componente fsico.
Introducir el software en industrias tradicionales est produciendo choques culturales.
Estas industrias poseen tradiciones, normas y procedimientos que no son aplicables al
desarrollo de software. El mismo concepto de prototipo posee significados muy distintos
en Ingeniera Aeronutica, por ejemplo, y en Ingeniera del Software.
Actualmente, los requisitos no funcionales (seguridad, fiabilidad, tiempo de respuesta,
disponibilidad, etc.) ocupan ms espacio en el documento de requisitos que los requisitos
puramente funcionales.
Los requisitos ya no son un problema exclusivo de la industria del software y, desde
luego, no son un problema exclusivo de los Sistemas de Informacin tradicionales. Pero
es el software, precisamente, lo que provoca los problemas de requisitos, debido al gran
potencial que posee para aumentar la complejidad de un sistema.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

17

Especificacin de Sistemas de Software

Referencias
[Br075] Andrs Silva. Documentacin Mster en Ingeniera del Software. UPM, 2000.
[Br075] F.P.Jr. Brooks. The Mythical Man-Month. Addison-Wesley, 1975.
[Dav93] A. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall,
1993.
[Jac95] M. Jackson. Software Requirements and Specifications: A Lexicon 01 Practice,
Principies and Prejudices. Addison-Wesley, 1995.
[Kov99] B.L. Kovitz. Practical Software Requirements. A Manual 01 Content and Style.
Manning, 1999.
[KS98] G. Kotonya and l. Sommerville. Requirements Engineering. Processes and
Techniques. Wiley, 1998.

Maestra en Informtica UNSTA

Ing. Ernesto Jos Rico

18