Especificacin de Requisitos Software segn el estndar IEEE 830 - F... http://wikis.fdi.ucm.es/ELP/Especificacin_de_Requisitos_Software_...

Especificacin de Requisitos Software segn el

estndar IEEE 830
De FdIwiki ELP
Especificacin de Requisitos Software segn el estndar IEEE 830

IEEE Std. 830-1998

22 de Octubre de 2008

Contenido
1 Resumen
2 Introduccin
2.1 Propsito
2.2 mbito de Sistema
2.3 Definiciones
2.4 Referencias
2.5 Visin general del documento
3 Descripcin General
3.1 Perspectiva del Producto
3.2 Funciones del Producto
3.3 Caractersticas de los Usuarios
3.4 Restricciones
3.5 Suposiciones y Dependencias
3.6 Requisitos Futuros
4 Requisitos Especficos
4.1 Interfaces Externas
4.2 Funciones
4.3 Requisitos de Rendimiento
4.4 Restricciones de Diseo
4.5 Atributos del Sistema
4.6 Otros Requisitos
5 Apndices
6 Creadores

Resumen
Este POST presenta, el formato de Especificacin de Requisitos Software (ERS) segn la ltima versin del
estndar IEEE 830. Segn IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga
estrictamente la organizacin y el formato dados en el estndar 830, s deber incluir, de una forma o de
otra, toda la informacin presentada en dicho estndar. El estndar de IEEE 830 no est libre de defectos ni
de prejuicios, y por ello ha sido justamente criticado por mltiples autores y desde mltiples puntos de vista,
llegndose a cuestionar incluso si es realmente un estndar en el sentido habitual que tiene el trmino en
otras ingenieras. El presente documento no pretende pronunciarse ni a favor ni en contra de unos u otros:
tan slo reproduce, con propsitos fundamentalmente docentes, cmo se organizara un Documento de

1 de 6 6/8/17 16:41
Especificacin de Requisitos Software segn el estndar IEEE 830 - F... http://wikis.fdi.ucm.es/ELP/Especificacin_de_Requisitos_Software_...

Requisitos segn el estndar IEEE 830.

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
Visin general del documento.

Propsito

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

mbito de Sistema

En esta subseccin:

Se podr dar un nombre al futuro sistema (p.ej. MiSistema)

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.
Se referenciarn todos aquellos documentos de nivel superior (p.e. en Ingeniera de Sistemas, que
incluyen Hardware y Software, debera mantenerse la consistencia con el documento de
especificacin de requisitos globales del sistema, si existe).

Definiciones

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

Referencias

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

Visin general del documento

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

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.

Perspectiva del Producto

2 de 6 6/8/17 16:41
Especificacin de Requisitos Software segn el estndar IEEE 830 - F... http://wikis.fdi.ucm.es/ELP/Especificacin_de_Requisitos_Software_...

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 (Especificacin de
Requisitos Software, tambin conocida con las siglas "SRS") 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.

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.

Caractersticas de los Usuarios

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

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

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.

Requisitos Futuros

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

Requisitos Especficos

3 de 6 6/8/17 16:41
Especificacin de Requisitos Software segn el estndar IEEE 830 - F... http://wikis.fdi.ucm.es/ELP/Especificacin_de_Requisitos_Software_...

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 los 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:
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.
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.
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.
Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos
contradictorio no es implementable.
Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos
pueden clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad
(cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear
excesivos recursos en implementar requisitos no esenciales.
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 25 Km no es
verificable por el alto costo que conlleva.
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 (por ejemplo RequisitePro o Doors)
facilitan enormemente esta tarea.
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 qu componentes del sistema son los que realizan el requisito R.

Interfaces Externas

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

4 de 6 6/8/17 16:41
Especificacin de Requisitos Software segn el estndar IEEE 830 - F... http://wikis.fdi.ucm.es/ELP/Especificacin_de_Requisitos_Software_...

Normalmente

Funciones

Esta subseccin (quiz la ms larga del documento) deber especificar todas aquellas acciones (funciones)
que deber llevar a cabo el software.

Normalmente (aunque no siempre), son aquellas acciones expresables como el sistema deber . . . . Si se
considera necesario, podrn utilizarse notaciones grficas y tablas, pero siempre supeditadas al lenguaje
natural, y no al revs.

Es importante tener en cuenta que, en 1983, el Estndar de IEEE 830 estableca que las funciones deberan
expresarse como una jerarqua funcional (en paralelo con los DFDs propuestos por el anlisis estructurado).
Pero el Estndar de IEEE 830, en sus ltimas versiones, ya permite organizar esta subseccin de mltiples
formas, y sugiere, entre otras, las siguientes:

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.
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.
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.
Por estmulos: Se especificarn los posibles estmulos que recibe el sistema y las funciones
relacionadas con dicho estmulo.
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.

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

Restricciones de Diseo

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

Atributos del Sistema

5 de 6 6/8/17 16:41
Especificacin de Requisitos Software segn el estndar IEEE 830 - F... http://wikis.fdi.ucm.es/ELP/Especificacin_de_Requisitos_Software_...

Se detallarn los atributos de calidad (las ilities) 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 (por ejemplo, por medio de un login y
una password).

Otros Requisitos

Cualquier otro requisito que no encaje en otra seccin.

Apndices
Pueden contener todo tipo de informacin 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 anlisis de costes.
3. Restricciones acerca del lenguaje de programacin.

Creadores
Mnica Morn Blanco - 4C - GII

Rubn Barrado Gonzlez - 4C - GIS

Obtenido de http://wikis.fdi.ucm.es
/ELP/index.php?title=Especificacin_de_Requisitos_Software_segn_el_estndar_IEEE_830&oldid=8003
Categora: Curso 2016-2017

Esta pgina fue modificada por ltima vez el 18 ene 2017, a las 19:46.
Esta pgina se ha visitado 1987 veces.
El contenido est disponible bajo una licencia de Creative Commons Reconocimiento-CompartirIgual
4.0 Internacional a menos que se indique lo contrario.

6 de 6 6/8/17 16:41