Especicacin de Requisitos segn el estndar o u a de IEEE 830

IEEE Std. 830-1998 22 de Octubre de 2008

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

 INDICE

Indice
1. Introduccin o 1.1. Propsito . . . . . . . . . . . . . . . . o 1.2. Ambito del Sistema . . . . . . . . . . . 1.3. Deniciones, Acrnimos y Abreviaturas o 1.4. Referencias . . . . . . . . . . . . . . . 1.5. Visin General del Documento . . . . . o 2. Descripcin General o 2.1. Perspectiva del Producto . . . 2.2. Funciones del Producto . . . . 2.3. Caracter sticas de los Usuarios 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 Diseo . . n 3.5. Atributos del Sistema . . . 3.6. Otros Requisitos . . . . . 4. Apndices e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 3 3 4 4 4 4 5 5 5 6 6 7 7 9 9 9 9 9

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

 1 INTRODUCCION

1.

Introduccin o

En esta seccin se proporcionar una introduccin a todo el documento de o a o Especicacin de Requisitos Software(ERS). Consta de varias subsecciones: o propsito, ambito del sistema, deniciones, referencias y visin general del o o documento.

1.1.

Propsito o

En esta subseccin se denir el propsito del documento ERS y se espeo a o cicar a quin va dirigido el documento. a e

1.2.

Ambito del Sistema

Se podr dar un nombre al futuro sistema (p.ej. MiSistema) a Se explicar lo que el sistema har y lo que no har. a a a Se describirn los benecios, objetivos y metas que se espera alcanzar a con el futuro sistema. Se referenciarn todos aquellos documentos de nivel superior (p.e. en Ina genier de Sistemas, que incluyen Hardware y Software, deber mana a tenerse la consistencia con el documento de especicacin de requisitos o globales del sistema, si existe).

En esta subseccin: o

1.3.

Deniciones, Acrnimos y Abreviaturas o

En esta subseccin se denirn todos los trminos, acrnimos y abreviao a e o turas utilizadas en la ERS.

1.4.

Referencias

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

 2 DESCRIPCION GENERAL

1.5.

Visin General del Documento o

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

2.

Descripcin General o

En esta seccin se describen todos aquellos factores que afectan al proo ducto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitir denir con detalle los requisitos en la seccin 3, haciendo que sean a o ms fciles de entender. a a Normalmente, esta seccin consta de las siguientes subsecciones: Perso 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 subseccin debe relacionar el futuro sistema (producto software) con o otros productos. Si el producto es totalemente independiente de otros productos, tambin debe especicarse aqu Si la ERS dene un producto que e . es parte de un sistema mayor, esta subseccin relacionar los requisitos del o a sistema mayor con la funcionalidad del producto descrito en la ERS, y se identicarn las interfaces entre el producto mayor y el producto aqu desa crito. Se recomienda utilizar diagramas de bloques.

2.2.

Funciones del Producto

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

 2 DESCRIPCION GENERAL

2.3.

Caracter sticas de los Usuarios

Esta subseccin describir las caracter o a sticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica. e

2.4.

Restricciones

Esta subseccin describir aquellas limitaciones que se imponen sobre los o a 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 comunicacin o Requisitos de habilidad Criticalidad de la aplicacin o Consideraciones acerca de la seguridad

2.5.

Suposiciones y Dependencias

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

3 REQUISITOS ESPEC IFICOS

2.6.

Requisitos Futuros

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

3.

Requisitos Espec cos

Esta seccin contiene los requisitos a un nivel de detalle suciente como o para permitir a los diseadores disear un sistema que satisfaga estos requin n sitos, y que permita al equipo de pruebas planicar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aqu es pecicado describir comportamientos externos del sistema, perceptibles por a parte de los usuarios, operadores y otros sistemas. Esta es la seccin ms o a larga e importante de la ERS. Debern aplicarse los siguientes principios: a El documento deber ser perfectamente legible por personas de muy a distintas formaciones e intereses. Debern referenciarse aquellos documentos relevantes que poseen algua na inuencia sobre los requisitos. Todo requisito deber ser un a vocamente identicable mediante algn u cdigo o sistema de numeracin adecuado. o o Lo ideal, aunque en la prctica no siempre realizable, es que los requia sitos posean las siguientes caracter sticas: Correccion: La ERS es correcta si y slo si todo requisito que o gura aqu (y que ser implementado en el sistema) reeja alguna a necesidad real. La correccin de la ERS implica que el sistema o implementado ser el sistema deseado. a No ambiguos: Cada requisito tiene una sola interpretacin. Para o eliminar la ambigedad inherente a los requisitos expresados en u lenguaje natural, se debern utilizar grcos o notaciones formaa a les. En el caso de utilizar trminos que, habitualmente, poseen ms e a de una interpretacin, se denirn con precisin en el glosario. o a 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. a a

3 REQUISITOS ESPEC IFICOS

Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos contradictorio no es implementable. Clasicados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasicarse 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. Vericables: La ERS es vericable si y slo si todos sus requisitos o son vericables. Un requisito es vericable (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, vericable. Expresiones como a veces, bien, adecuado, etc. introducen ambigedad en los requisitos. Requisitos como en caso de acciu dente la nube txica no se extender ms all de 25Km no es o a a a vericable por el alto costo que conlleva. Modicables: La ERS es modicable si y slo si se encuentra eso tructurada de forma que los cambios a los requisitos pueden realizarse de forma fcil, completa y consistente. La utilizacin de a o herramientas automticas de gestin de requisitos (por ejemplo a o 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 n o a indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica qu compoe nentes 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 a con otros sistemas (hardware y software) e interfaces de comunicaciones.

3.2.

Funciones

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

3 REQUISITOS ESPEC IFICOS

malmente (aunque no siempre), son aquellas acciones expresables como el sistema deber . . . . Si se considera necesario, podrn utilizarse notaciones a a grcas y tablas, pero siempre supeditadas al lenguaje natural, y no al revs. a e Es importante tener en cuenta que, en 1983, el Estndar de IEEE 830 a establec que las funciones deber expresarse como una jerarqu funcional a an a (en paralelo con los DFDs propuestos por el anlisis estructurado). Pero el a Estndar de IEEE 830, en sus ultimas versiones, ya permite organizar esta a subseccin de mltiples formas, y sugiere, entre otras, las siguientes: o u Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organizacin, se especicarn o a los requisitos funcionales que le afecten o tengan mayor relacin con o sus tareas. Por objetos: Los objetos son entidades del mundo real que sern reea jadas en el sistema. Para cada objeto, se detallarn sus atributos y sus a funciones. Los objetos pueden agruparse en clases. Esta organizacin o de la ERS no quiere decir que el diseo del sistema siga el paradigma n 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. a Por est mulos: Se especicarn los posibles est a mulos que recibe el sistema y las funciones relacionadas con dicho est mulo. Por jerarqu funcional: Si ninguna de las anteriores alternativas resulta a de ayuda, la funcionalidad del sistema se especicar como una jerara qu de funciones que comparten entradas, salidas o datos internos. Se a detallarn las funciones (entrada, proceso, salida) y las subfunciones a del sistema. Esto no implica que el diseo del sistema deba realizarse n segn el paradigma de Diseo Estructurado. u n Para organizar esta subseccin de la ERS se elegir alguna de las anteo a riores alternativas, o incluso alguna otra que se considere ms conveniente. a Deber, eso s justicarse el porqu de tal eleccin. a , e o

 4 APENDICES

3.3.

Requisitos de Rendimiento

Se detallarn los requisitos relacionados con la carga que se espera tenga a que soportar el sistema. Por ejemplo, el nmero de terminales, el nmero u u esperado de usuarios simultaneamente conectados, nmero de transacciones u por segundo que deber soportar el sistema, etc. a Tambin, si es necesario, se especicarn lo requisitos de datos, es decir, e a aquellos requisitos que afecten a la informacin que se guardar en la base o a 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 o n

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

3.5.

Atributos del Sistema

Se detallarn los atributos de calidad (las ilities) del sistema: Fiabilidad, a mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber espea cicarse qu tipos de usuario estn autorizados, o no, a realizar ciertas tareas, e a y cmo se implementarn los mecanismos de seguridad (por ejemplo, por meo a dio de un login y una password ).

3.6.

Otros Requisitos

Cualquier otro requisito que no encaje en otra seccin. o

4.

Apndices e

Pueden contener todo tipo de informacin relevante para la ERS pero o 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. a 3. Restricciones acerca del lenguaje de programacin. o