Estandares IEEE 830

Documento de Requisitos
Un buen Documento de Requisitos, pese a no ser obligatorio que siga estrictamente la organizacin y el formato dados en el estndar 830, si debera incluir, de una forma o de otra, toda la informacin presentada en dicho estndar.

1. Introduccin
En esta seccin se proporcionara una introduccin a todo el documento de Especiacin 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 especificara a quien va dirigido el documento. 1.2 mbito del Sistema: Dar un nombre al futuro sistema, saber lo que el sistema har y lo que no har, describirn los beneficios, objetivos y metas que se espera alcanzar, Se referenciaran todos aquellos documentos de nivel superior

 1.3 Definiciones, Acrnimos y Abreviaturas: se definirn todos los trminos, acrnimos y abreviaturas utilizadas en la ERS. 1.4 Referencias: se mostrara 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.

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 mas fciles de entender.

 2. 1 Perspectiva del Producto: se debe relacionar el futuro sistema (producto software) con otros productos. 2. 2 Funciones del Producto: se mostrara un resumen, a grandes rasgos, de las funciones del futuro sistema. Las funciones debern mostrarse de forma organizada, y pueden utilizarse grficos.

 2. 3 Caractersticas de los Usuarios: describir las caractersticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica. 2. 4 Suposiciones y Dependencias: describir aquellos factores que, si cambian, pueden afectar a los requisitos. 2. 5 Requisitos Futuros: esbozara futuras mejoras al sistema, que podrn analizarse e implementarse en un futuro.

2. 6 Restricciones
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

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.

3. Requisitos Especficos

 El documento debera ser perfectamente legible por personas de muy distintas formaciones e intereses. Deberan referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos. Todo requisito debera ser unvocamente identificable mediante algn cdigo o sistema de numeracin adecuado. Lo ideal, aunque en la practica no siempre realizable, es que los requisitos posean las siguientes caractersticas:

 Correccin: La ERS es correcta si y solo si todo requisito que figura aqu refleja alguna necesidad real No ambiguos: Cada requisito tiene una sola interpretacin en caso de que no se representaran 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.

 Consistentes: Los requisitos no pueden ser contradictorios.. Clasificados: Normalmente, no todos los requisitos son igual de Importantes: Los requisitos pueden clasificarse por importancia o por estabilidad. Verificables: La ERS es verificable si y solo si todos sus requisitos son verificables. Un requisito es verificable (testeable) si existe un proceso nito y no costoso para demostrar que el sistema cumple con el requisito. Modificables: La ERS es modificable si y solo si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fcil, completa y consistente. Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes

 3. 1 Interfaces Externas: se definirn los requisitos que afecten a la interfaz de usuario e interfaz con otros sistemas (hardware y software), as como a interfaces de comunicaciones. 3. 2 Funciones : especificar todas aquellas acciones o funciones que deber llevar a cabo el sistema a desarrollar. Las acciones que se indican como el sistema deber ... son las que deben incluirse en este apartado.

 3.3. Requisitos de Rendimiento: Se detallaran los requisitos relacionados con la carga que se espera tenga que soportar el sistema. 3.3. 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 detallaran los atributos de calidad del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber especificarse que tipos de usuario estn autorizados, o no, a realizar ciertas tareas, y como se implementaran los mecanismos de seguridad(por ejemplo, por medio de un login y una password). 3.6. Otros Requisitos :Cualquier otro requisito que no encaje en otra seccin.

4. Apndices Se incluir aqu cualquier tipo de informacin relacionada con la ERS, pero que no forme parte de la misma. Por ejemplo, se incluiran los resultados del anlisis de costes, restricciones especiales acerca del lenguaje de programacin... 5. ndice Se proporciona un ndice para poder tener un acceso rpido a la documentacin presentada en la ERS.