Especificacin de

Requisitos segn el
estndar de IEEE 830

Ciclo-1
Pr

ndice
1. Introduccin.................................................................................3
1.1. Propsito................................................................................3
1.2. mbito del Sistema................................................................3
1.3. Definiciones, Acrnimos y Abreviaturas.................................3
1.4. Referencias............................................................................3
1.5. Visin General del Documento...............................................3
2. Descripcin General.....................................................................4
2.1. Perspectiva del Producto........................................................4
2.2. Funciones del Producto..........................................................4
2.3. Caractersticas de los Usuarios..............................................4
2.4. Restricciones..........................................................................5
2.5. Suposiciones y Dependencias................................................5
2.6. Requisitos Futuros..................................................................5
3. Requisitos Especficos..................................................................6
3.1. Interfaces Externas................................................................7
3.2. Funciones...............................................................................7
3.3. Requisitos de Rendimiento.....................................................8
3.4. Restricciones de Diseo.........................................................8
3.5. Atributos del Sistema.............................................................8
3.6. Otros Requisitos.....................................................................9

Pgina 2 de 9

Ciclo-1
Pr

1 Introduccin
En esta seccin se proporcionar una introduccin a todo el
documento de Especificacin de Requisitos Software (ERS). Consta de
varias subsecciones: propsito, mbito del sistema, definiciones,
referencias y visin general del documento.

1.1. Propsito
En esta subseccin se definir el propsito del documento ERS y se
especificar a quin va dirigido el documento.

1.2. mbito del Sistema

En esta subseccin:

Se podr dar un nombre al futuro sistema.

Se explicar lo que el sistema har y lo que no har.
Se describirn los beneficios, objetivos y metas que se espera
alcanzar con el futuro sistema.

1.3. Definiciones, Acrnimos y Abreviaturas

En esta subseccin se definirn todos los trminos, acrnimos y
abreviaturas utilizadas en la ERS.

1.4. Referencias
En esta subseccin se mostrar una lista completa de todos los
documentos referenciados en la ERS.

1.5. Visin General del Documento

Esta subseccin describe brevemente los contenidos y la
organizacin del resto de la ERS.
Pgina 3 de 9

Ciclo-1
Pr

2 Descripcin General
En esta seccin se describen todos aquellos factores que afectan al
producto y a sus requisitos. No se describen los requisitos, sino su
contexto. Esto permitir definir con detalle los requisitos en la seccin
3, haciendo que sean ms fciles de entender.
Normalmente, esta seccin consta de las siguientes subsecciones:
Perspectiva del producto, funciones del producto, caractersticas de
los usuarios, restricciones, factores que se asumen y futuros
requisitos.

2.1. Perspectiva del Producto

Esta subseccin debe relacionar el futuro sistema (producto
software) con otros productos. Si el producto es totalmente
independiente de otros productos, tambin debe especificarse aqu. Si
la ERS define un producto que es parte de un sistema mayor, esta
subseccin relacionar los requisitos del sistema mayor con la
funcionalidad del producto descrito en la ERS, y se identificarn las
interfaces entre el producto mayor y el producto aqu descrito. Se
recomienda utilizar diagramas de bloques.

2.2. Funciones del Producto

En esta subseccin de la ERS se mostrar un resumen, a grandes
rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS
para un programa de contabilidad, esta subseccin mostrar que el
sistema soportar el mantenimiento de cuentas, mostrar el estado
de las cuentas y facilitar la facturacin, sin mencionar el enorme
detalle que cada una de estas funciones requiere.
Las funciones debern mostrarse de forma organizada, y pueden
utilizarse grficos, siempre y cuando dichos grficos reflejen las
relaciones entre funciones y no el diseo del sistema.

Pgina 4 de 9

Ciclo-1
Pr

2.3. Caractersticas de los Usuarios

Esta subseccin describir las caractersticas generales de los
usuarios del producto, incluyendo nivel educacional, experiencia y
experiencia tcnica.

2.4. Restricciones
Esta subseccin describir aquellas limitaciones que se imponen
sobre los desarrolladores del producto:

Polticas de la empresa.
Limitaciones del hardware.
Interfaces con otras aplicaciones.
Operaciones paralelas.
Funciones de auditora.
Funciones de control.
Lenguaje(s) de programacin.
Protocolos de comunicacin.
Requisitos de habilidad.
Criticalidad de la aplicacin.
Consideraciones acerca de la seguridad.

2.5. Suposiciones y Dependencias

Esta subseccin de la ERS describir aquellos factores que, si
cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos
pueden presuponer una cierta organizacin de ciertas unidades de la
empresa, o pueden presuponer que el sistema correr sobre cierto
sistema operativo. Si cambian dichos detalles en la organizacin de la
empresa, o si cambian ciertos detalles tcnicos, como el sistema
operativo, puede ser necesario revisar y cambiar los requisitos.

2.6. Requisitos Futuros

Esta subseccin esbozar futuras mejoras al sistema, que podrn
analizarse e implementarse en un futuro.

Pgina 5 de 9

Ciclo-1
Pr

3 Requisitos Especficos
Esta seccin contiene los requisitos a un nivel de detalle suficiente
como para permitir a los diseadores disear un sistema que
satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema
satisface, o no, los requisitos. Todo requisito aqu especificado
describir comportamientos externos del sistema, perceptibles por
parte de los usuarios, operadores y otros sistemas. Esta es la seccin
ms larga e importante de la ERS. Debern aplicarse los siguientes
principios:

El documento debera ser perfectamente legible por personas

de muy distintas formaciones e intereses.
Debern referenciarse aquellos documentos relevantes que
poseen alguna influencia sobre los requisitos.
Todo requisito deber ser unvocamente identificable mediante
algn cdigo o sistema de numeracin adecuado.
Lo ideal, aunque en la prctica no siempre realizable, es que los
requisitos posean las siguientes caractersticas:
o Correccin: La ERS es correcta si y slo si todo requisito
que figura aqu (y que ser implementado en el sistema)
refleja alguna necesidad real. La correccin de la ERS
implica que el sistema implementado ser el sistema
deseado.
o No
ambiguos:
Cada
requisito
tiene
una
sola
interpretacin. Para eliminar la ambigedad inherente a
los requisitos expresados en lenguaje natural, se debern
utilizar grficos o notaciones formales. En el caso de
utilizar trminos que, habitualmente, poseen ms de una
interpretacin, se definirn con precisin en el glosario.
o 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
vlidos como no vlidos.
o Consistentes:
Los
requisitos
no
pueden
ser
contradictorios. Un conjunto de requisitos contradictorio
no es implementable.
o Clasificados: Normalmente, no todos los requisitos son
igual de importantes. Los requisitos pueden clasificarse
por importancia (esenciales, condicionales u opcionales) o
Pgina 6 de 9

Ciclo-1
Pr
por estabilidad (cambios que se espera que afecten al
requisito). Esto sirve, ante todo, para no emplear
excesivos recursos en implementar requisitos no
esenciales.
o Verificables: La ERS es verificable si y slo si todos sus
requisitos son verificables. Un requisito es verificable
(testeable) si existe un proceso finito y no costoso para
demostrar que el sistema cumple con el requisito. Un
requisito ambiguo no es, en general, verificable.
Expresiones como a veces, bien, adecuado, etc.
Introducen ambigedad en los requisitos. Requisitos como
en caso de accidente la nube txica no se extender ms
all de 25Km" no es verificable por el alto costo que
conlleva.
o Modificables: La ERS es modificable si y slo si se
encuentra estructurada de forma que los cambios a los
requisitos pueden realizarse de forma fcil, completa y
consistente. La utilizacin de herramientas automticas
de gestin de requisitos facilitan enormemente esta tarea.
o Trazables: La ERS es trazable si se conoce el origen de
cada requisito y se facilita la referencia de cada requisito
a los componentes del diseo y de la implementacin. La
trazabilidad hacia atrs indica el origen (documento,
persona, etc.) de cada requisito. La trazabilidad hacia
delante de un requisito R indica que componentes del
sistema son los que realizan el requisito R.

3.1. Interfaces Externas

Se describirn los requisitos que afecten a la interfaz de usuario,
interfaz con otros sistemas (hardware y software) e interfaces de
comunicaciones.

3.2. Funciones
Esta subseccin deber especificar todas aquellas acciones
(funciones) que debern llevarse a cabo el software. Si se considera
necesario, podrn utilizarse notaciones grficas y tablas, pero
siempre supeditadas al lenguaje natural, y no al revs.

Pgina 7 de 9

Ciclo-1
Pr
Se puede organizar esta subseccin de mltiples formas, y sugiere,
entre otras, las siguientes:
o Por tipos de usuario: Distintos usuarios poseen distintos
requisitos. Para cada clase de usuario que exista en la
organizacin, se especificarn los requisitos funcionales que le
afecten o tengan mayor relacin con sus tareas.
o Por objetos: Los objetos son entidades del mundo real que sern
reflejadas en el sistema. Para cada objeto, se detallarn sus
atributos y sus funciones. Los objetos pueden agruparse en
clases. Esta organizacin de la ERS no quiere decir que el
diseo del sistema siga el paradigma de Orientacin a Objetos.
o Por objetivos: Un objetivo es un servicio que se desea que
ofrezca el sistema y que requiere una determinada entrada para
obtener su resultado. Para cada objetivo o subobjetivo que se
persiga con el sistema, se detallarn las funciones que permitan
llevarlo a cabo.
o Por estmulos: Se especificarn los posibles estmulos que
recibe el sistema y las funciones relacionadas con dicho
estmulo.
o Por jerarqua funcional: Si ninguna de las anteriores alternativas
resulta de ayuda, la funcionalidad del sistema se especificar
como una jerarqua de funciones que comparten entradas,
salidas o datos internos. Se detallarn las funciones (entrada,
proceso, salida) y las subfunciones del sistema. Esto no implica
que el diseo del sistema deba realizarse segn el paradigma
de Diseo Estructurado.
Para organizar esta subseccin de la ERS se elegir alguna de las
anteriores alternativas, o incluso alguna otra que se considere ms
conveniente. Deber, eso s, justificarse el porqu de tal eleccin.

3.3. Requisitos de Rendimiento

Se detallarn los requisitos relacionados con la carga que se
espera tenga que soportar el sistema. Por ejemplo, el nmero de
terminales, el nmero esperado de usuarios simultneamente
conectados, nmero de transacciones por segundo que deber
soportar el sistema, etc.
Tambin, si es necesario, se especificarn lo requisitos de datos, es
decir, aquellos requisitos que afecten a la informacin que se
Pgina 8 de 9

Ciclo-1
Pr
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 Diseo

Todo aquello que restrinja las decisiones relativas al diseo de la
aplicacin: Restricciones de otros estndares, limitaciones del
hardware, etc.

3.5. Atributos del Sistema

Se detallarn los atributos de calidad del sistema: Fiabilidad,
mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber
especificarse qu tipos de usuario estn autorizados, o no, a realizar
ciertas tareas, y cmo se implementarn los mecanismos de
seguridad.

3.6. Otros Requisitos

Cualquier otro requisito que no encaje en otra seccin.

Pgina 9 de 9