Especi cacion de Requisitos segun el estandar
de IEEE 830
IEEE Std. 830-1998
22 de Octubre de 2008
Resumen
Este documento presenta, en castellano, el formato de Especi ca-
cion de Requisitos Software (ERS) segun la ultima version del estandar
IEEE 830. Segun IEEE, un buen Documento de Requisitos, pese a no ser
obligatorio que siga estrictamente la organizacion y el formato da-
dos en el estandar 830, s debera incluir, de una forma o de otra, toda
la informacion presentada en dicho estandar. El estandar de IEEE
830 no esta libre de defectos ni de prejuicios, y por ello ha sido jus-
tamente criticado por multiples autores y desde multiples puntos de
vista, llegandose a cuestionar incluso si es realmente un estandar en el
sentido habitual que tiene el termino en otras ingenier as. El presente
documento no pretende pronunciarse ni a favor ni en contra de unos u
otros: tan solo reproduce, con propositos fundamentalmente
docentes, como se organizar a un Documento de Requisitos segun
el estandar IEEE 830.
INDICE
Indice
1. Introduccion
1.1. Proposito
1.2. Ambito del Sistema . . . . . . . . . . . . . . . .
1.3. De niciones, Acronimos
1.4. Referencias . . . . . . . . . . . . . .
1.5. Vision General del Documento
2. Descripcion General
2.1. Perspectiva del Producto . . . .
2.2. Funciones del Producto . . . . .
2.3. Caracter sticas de los Usuario
2.4. Restricciones . . . . . . . . . . . . .
2.5. Suposiciones y Dependencias
2.6. Requisitos Futuros . . . . . . . .
3. Requisitos Espec cos
3.1. Interfaces Externas . . . . . . . .
3.2. Funciones . . . . . . . . . . . . . . .
3.3. Requisitos de Rendimiento . .
3.4. Restricciones de Dise~no . . .
3.5. Atributos del Sistema . . . . . . .
3.6. Otros Requisitos . . . . . . . . . .
4. Apendices
1 INTRODUCCION
1. Introduccion
En esta seccion se proporcionar una introduccion a todo el documento de
Especi cacion de Requisitos Software(ERS). Consta de varias subsecciones:
proposito, ambito del sistema, de niciones, referencias y vision general
del documento.
1.1. Proposito
En esta subseccion se de nira el proposito del documento ERS y se
espe-ci car a quien va dirigido el documento.
1.2. Ambito del Sistema
En esta subseccion:
Se podra dar un nombre al futuro sistema ([Link]. MiSistema)
Se explicar lo que el sistema har y lo que no har .
Se describiran los bene cios, objetivos y metas que se espera
alcanzar con el futuro sistema.
Se referenciaran todos aquellos documentos de nivel superior (p.e.
en In-genier a de Sistemas, que incluyen Hardware y Software,
deber a man-tenerse la consistencia con el documento de especi
cacion de requisitos globales del sistema, si existe).
1.3. De niciones, Acronimos y Abreviaturas
En esta subseccion se de niran todos los terminos, acronimos y
abrevia-turas utilizadas en la ERS.
1.4. Referencias
En esta subseccion se mostrar una lista completa de todos los
documen-tos referenciados en la ERS.
2 DESCRIPCION GENERAL
1.5. Vision General del Documento
Esta subseccion describe brevemente los contenidos y la
organizacion del resto de la ERS.
2. Descripcion General
En esta seccion se describen todos aquellos factores que afectan al
pro-ducto y a sus requisitos. No se describen los requisitos, sino su
contexto. Esto permitira de nir con detalle los requisitos en la seccion 3,
haciendo que sean mas faciles de entender.
Normalmente, esta seccion consta de las siguientes subsecciones:
Pers-pectiva del producto, funciones del producto, caracter sticas de los
usuarios, restricciones, factores que se asumen y futuros requisitos.
2.1. Perspectiva del Producto
Esta subseccion debe relacionar el futuro sistema (producto software)
con otros productos. Si el producto es totalemente independiente de otros
pro-ductos, tambien debe especi carse aqu . Si la ERS de ne un producto
que es parte de un sistema mayor, esta subseccion relacionar los requisitos
del sistema mayor con la funcionalidad del producto descrito en la ERS, y
se identi caran las interfaces entre el producto mayor y el producto aqu des-
crito. Se recomienda utilizar diagramas de bloques.
2.2. Funciones del Producto
En esta subseccion de la ERS se mostrar un resumen, a grandes
rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS
para un pro-grama de contabilidad, esta subseccion mostrar que el
sistema soportar el mantenimiento de cuentas, mostrar el estado de las
cuentas y facilitar la facturacion, sin mencionar el enorme detalle que
cada una de estas funciones requiere.
Las funciones deberan mostrarse de forma organizada, y pueden
utili-zarse gra cos, siempre y cuando dichos gra cos re ejen las
relaciones entre funciones y no el dise~no del sistema.
2 DESCRIPCION GENERAL
2.3. Caracter sticas de los Usuarios
Esta subseccion describira las caracter sticas generales de los usuarios del
producto, incluyendo nivel educacional, experiencia y experiencia tecnica.
2.4. Restricciones
Esta subseccion describira aquellas limitaciones que se imponen
sobre los desarrolladores del producto
Pol ticas de la empresa
Limitaciones del hardware
Interfaces con otras aplicaciones
Operaciones paralelas
Funciones de auditor a
Funciones de control
Lenguaje(s) de programacion
Protocolos de comunicacion
Requisitos de habilidad
Criticalidad de la aplicacion
Consideraciones acerca de la seguridad
2.5. Suposiciones y Dependencias
Esta subseccion de la ERS describira aquellos factores que, si
cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos
pueden presu-poner una cierta organizacion de ciertas unidades de la
empresa, o pueden presuponer que el sistema correra sobre cierto
sistema operativo. Si cambian dichos detalles en la organizacion de la
empresa, o si cambian ciertos detalles tecnicos, como el sistema
operativo, puede ser necesario revisar y cambiar los requisitos.
3 REQUISITOS ESPECIFICOS
2.6. Requisitos Futuros
Esta subseccion esbozar futuras mejoras al sistema, que podran
anali-zarse e implementarse en un futuro.
3. Requisitos Espec cos
Esta seccion contiene los requisitos a un nivel de detalle su ciente como
para permitir a los dise~nadores dise~nar un sistema que satisfaga estos
requi-sitos, y que permita al equipo de pruebas plani car y realizar las pruebas
que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aqu
es-peci cado describira comportamientos externos del sistema, perceptibles
por parte de los usuarios, operadores y otros sistemas. Esta es la seccion mas
larga e importante de la ERS. Deberan aplicarse los siguientes principios:
El documento deber a ser perfectamente legible por personas de
muy distintas formaciones e intereses.
Deberan referenciarse aquellos documentos relevantes que
poseen algu-na in uencia sobre los requisitos.
Todo requisito debera ser un vocamente identi cable mediante
algun codigo o sistema de numeracion adecuado.
Lo ideal, aunque en la practica no siempre realizable, es que los
requi-sitos posean las siguientes caracter sticas:
Correccion: La ERS es correcta si y solo si todo requisito que
gura aqu (y que sera implementado en el sistema) re eja
alguna necesidad real. La correccion de la ERS implica que el
sistema implementado sera el sistema deseado.
No ambiguos: Cada requisito tiene una sola interpretacion. Para
eliminar la ambiguedad inherente a los requisitos expresados en
lenguaje natural, se deberan utilizar gra cos o notaciones forma-les.
En el caso de utilizar terminos que, habitualmente, poseen mas de
una interpretacion, se de niran con precision en el glosario.
Completos: Todos los requisitos relevantes han sido incluidos
en la ERS. Conviene incluir todas las posibles respuestas del
sistema a los datos de entrada, tanto validos como no validos.
3 REQUISITOS ESPECIFICOS
Consistentes: Los requisitos no pueden ser contradictorios.
Un con-junto de requisitos contradictorio no es implementable.
Clasi cados: Normalmente, no todos los requisitos son igual
de importantes. Los requisitos pueden clasi carse por
importancia (esenciales, condicionales u opcionales) o por
estabilidad (cam-bios que se espera que afecten al requisito).
Esto sirve, ante todo, para no emplear excesivos recursos en
implementar requisitos no esenciales.
Veri cables: La ERS es veri cable si y solo si todos sus requisitos
son veri cables. Un requisito es veri cable (testeable) si existe un
proceso nito y no costoso para demostrar que el sistema cumple
con el requisito. Un requisito ambiguo no es, en general, veri -
cable. Expresiones como a veces, bien, adecuado, etc.
introducen ambiguedad en los requisitos. Requisitos como \en
caso de acci-dente la nube toxica no se extendera mas all de
25Km" no es veri cable por el alto costo que conlleva.
Modi cables: La ERS es modi cable si y solo si se encuentra es-
tructurada de forma que los cambios a los requisitos pueden rea-
lizarse de forma facil, completa y consistente. La utilizacion de
herramientas automaticas de gestion de requisitos (por ejemplo
RequisitePro o Doors) facilitan enormemente esta tarea.
Trazables: La ERS es trazable si se conoce el origen de cada requi-
sito y se facilita la referencia de cada requisito a los componentes
del dise~no y de la implementacion. La trazabilidad hacia atras
indica el origen (documento, persona, etc.) de cada requisito. La
trazabilidad hacia delante de un requisito R indica que compo-
nentes del sistema son los que realizan el requisito R.
3.1. Interfaces Externas
Se describiran los requisitos que afecten a la interfaz de usuario, interfaz
con otros sistemas (hardware y software) e interfaces de comunicaciones.
3.2. Funciones
Esta subseccion (quiza la mas larga del documento) debera especi car
todas aquellas acciones (funciones) que debera llevar a cabo el software. Nor-
3 REQUISITOS ESPECIFICOS
malmente (aunque no siempre), son aquellas acciones expresables como \el
sistema debera . . . ". Si se considera necesario, podran utilizarse notaciones
gra cas y tablas, pero siempre supeditadas al lenguaje natural, y no al reves.
Es importante tener en cuenta que, en 1983, el Estandar de IEEE 830
establec a que las funciones deber an expresarse como una jerarqu a funcional
(en paralelo con los DFDs propuestos por el analisis estructurado). Pero el
Estandar de IEEE 830, en sus ultimas versiones, ya permite organizar esta
subseccion de multiples formas, y sugiere, entre otras, las siguientes:
Por tipos de usuario: Distintos usuarios poseen distintos requisitos.
Pa-ra cada clase de usuario que exista en la organizacion, se
especi caran los requisitos funcionales que le afecten o tengan
mayor relacion con sus tareas.
Por objetos: Los objetos son entidades del mundo real que seran
re e-jadas en el sistema. Para cada objeto, se detallaran sus
atributos y sus funciones. Los objetos pueden agruparse en clases.
Esta organizacion de la ERS no quiere decir que el dise~no del
sistema siga el paradigma de Orientacion a Objetos.
Por objetivos: Un objetivo es un servicio que se desea que ofrezca
el sistema y que requiere una determinada entrada para obtener su
resul-tado. Para cada objetivo o subobjetivo que se persiga con el
sistema, se detallaran las funciones que permitan llevarlo a cabo.
Por est mulos: Se especi caran los posibles est mulos que recibe el
sis-tema y las funciones relacionadas con dicho est mulo.
Por jerarqu a funcional: Si ninguna de las anteriores alternativas
resulta de ayuda, la funcionalidad del sistema se especi car como una
jerar-qu a de funciones que comparten entradas, salidas o datos
internos. Se detallaran las funciones (entrada, proceso, salida) y las
subfunciones del sistema. Esto no implica que el dise~no del sistema
deba realizarse segun el paradigma de Dise~no Estructurado.
Para organizar esta subseccion de la ERS se elegira alguna de las
ante-riores alternativas, o incluso alguna otra que se considere mas
conveniente. Debera, eso s , justi carse el porque de tal eleccion.
4 APENDICES
3.3. Requisitos de Rendimiento
Se detallaran los requisitos relacionados con la carga que se espera tenga
que soportar el sistema. Por ejemplo, el numero de terminales, el numero
esperado de usuarios simultaneamente conectados, numero de
transacciones por segundo que debera soportar el sistema, etc.
Tambien, si es necesario, se especi caran lo requisitos de datos, es
decir, aquellos requisitos que afecten a la informacion que se guardar en
la base de datos. Por ejemplo, la frecuencia de uso, las capacidades de
acceso y la cantidad de registros que se espera almacenar (decenas,
cientos, miles o millones).
3.4. Restricciones de Dise~no
Todo aquello que restrinja las decisiones relativas al dise~no de la aplica-
cion: Restricciones de otros estandares, limitaciones del hardware, etc.
3.5. Atributos del Sistema
Se detallaran los atributos de calidad (las \ilities") del sistema:
Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad.
Debera espe-ci carse que tipos de usuario estan autorizados, o no, a
realizar ciertas tareas, y como se implementaran los mecanismos de
seguridad (por ejemplo, por me-dio de un login y una password ).
3.6. Otros Requisitos
Cualquier otro requisito que no encaje en otra seccion.
4. Apendices
Pueden contener todo tipo de informacion relevante para la ERS
pero que, propiamente, no forme parte de la ERS. Por ejemplo:
1. Formatos de entrada/salida de datos, por pantalla o en listados.
2. Resultados de analisis de costes.
3. Restricciones acerca del lenguaje de programacion.
