Especificación de Requisitos Software según el estándar de IEEE 830

1. Esquema de la ERS definida en el IEEE 830-1998

1.1. Introducción

1.1.1. En esta sección se proporcionará una introducción a todo el documento de Especificación de Requisitos Software

1.1.1.1. Propósito

1.1.1.1.1. Se definirá el propósito del documento ERS y se especificará a quién va dirigido el documento

1.1.1.2. Ámbito del Sistema

1.1.1.2.1. En esta subsección se pondrá nombre al futuro sistema, se explicará lo que el sistema hará y lo que no hará, se describirán los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema y se mantendrán referencias a los documentos de nivel superior que puedan existir

1.1.1.3. Definiciones, Acrónimos y Abreviaturas

1.1.1.3.1. Se definirán aquí todos los términos, acrónimos y abreviaturas utilizadas en el desarrollo de la ERS

1.1.1.4. Referencias

1.1.1.4.1. Se presentará una lista completa de todos los documentos referenciados en la ERS

1.1.1.5. Visión general del documento

1.1.1.5.1. Esta subsección describirá brevemente los contenidos y la organización del resto de la ERS

1.2. Descripción General

1.2.1. En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos

1.2.1.1. Perspectiva del Producto

1.2.1.1.1. Esta subsección debe relacionar el futuro sistema con otros productos

1.2.1.2. Funciones del Producto

1.2.1.2.1. Esta subsección debe proporcionar un resumen de las funciones principales que el software debe llevar a cabo

1.2.1.3. Características de los usuarios

1.2.1.3.1. Se indica aquí el tipo de usuario al que se dirige la aplicación, así como su experiencia técnica, nivel de conocimientos, etc

1.2.1.4. Restricciones

1.2.1.4.1. Se debe indicar aquí cualquier tipo de limitación como pueden ser políticas de la empresa, limitaciones hardware, seguridad, protocolos de comunicación, interfaces con otras aplicaciones, estándares de la empresa en cuanto a interfaces, etc

1.2.1.5. Suposiciones y Dependencias

1.2.1.5.1. En este apartado aparecerá cualquier factor, que si cambia puede afectar a los requerimientos

1.2.1.6. Requisitos Futuros

1.2.1.6.1. Se indican aquí posibles mejoras del sistema en el futuro

1.3. Requisitos Específicos

1.3.1. Esta sección de la especificación de requisitos software contiene todos los requerimientos hasta un nivel de detalle suficiente para permitir a los diseñadores diseñar un sistema que satisfaga dichos requisitos, y que permita diseñar las pruebas que ratifiquen que el sistema cumple con las necesidades requeridas

1.3.1.1. Interfaces Externas

1.3.1.1.1. En esta subsección se definirán los requisitos que afecten a la interfaz de usuario e interfaz con otros sistemas (hardware y software), así como a interfaces de comunicaciones

1.3.1.2. Funciones

1.3.1.2.1. En este subsección de deben especificar todas aquellas acciones o funciones que deberá llevar a cabo el sistema a desarrollar

1.3.1.3. Requisitos de Rendimiento

1.3.1.3.1. En esta subsección se incluyen los requisitos relacionados con la carga que se espera que tenga que soportar el sistema

1.3.1.4. Restricciones de Diseño

1.3.1.4.1. Se incluyen aquí todas las restricciones que afecten al diseño de la aplicación, como pueden ser estándares internos de la organización, limitaciones hardware, etc

1.3.1.5. Atributos del Sistema

1.3.1.5.1. Se detallarán atributos como la fiabilidad, mantenibilidad, seguridad, mecanismos de acceso restringido (password), usuarios autorizados a realizar ciertas tareas críticas

1.3.1.6. Otros Requisitos

1.3.1.6.1. Aquellos requerimientos que no se hayan podido incluir en ninguna de las secciones anteriormente especificadas

1.4. Apéndices

1.4.1. Se incluirá aquí cualquier tipo de información relacionada con la ERS, pero que no forme parte de la misma

1.5. Índice

1.5.1. Se proporciona un índice para poder tener un acceso rápido a la documentación presentada en la ERS

2. Objetivos de la ERS

2.1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software:

2.2. Servir de base para desarrollos de estándares de ERS particulares para cada organización

2.2.1. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qué es lo que quiere

3. Características de una buena ERS

3.1. Las características deseables para una buena especificación de requisitos software que se indican en el IEEE son las siguientes

3.1.1. correcta

3.1.1.1. La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real

3.1.2. no ambigua

3.1.2.1. Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación

3.1.3. completa

3.1.3.1. Una ERS es completa si

3.1.3.1.1. Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).

3.1.3.1.2. Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones

3.1.3.1.3. Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho apartado

3.1.3.1.4. Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.

3.1.4. verificable

3.1.4.1. Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por el cual una persona o una máquina pueda chequear que el software satisface dicho requerimiento

3.1.5. consistente

3.1.5.1. Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto. Se pueden dar tres casos

3.1.5.1.1. Requisitos que describen el mismo objeto real utilizando distintos términos

3.1.5.1.2. Las características especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules

3.1.5.1.3. Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos acciones serían perfectamente válidas

3.1.6. clasificada

3.1.6.1. No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios

3.1.6.1.1. Importancia

3.1.6.1.2. Estabilidad

3.1.7. modificable

3.1.7.1. Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y consistente

3.1.8. explorable

3.1.8.1. Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito).

3.1.9. Utilizable durante las tareas de mantenimiento y uso

3.1.9.1. En la ERS también se deben tener en cuenta las necesidades de mantenimiento. El personal que no ha intervenido directamente en el desarrollo debe ser capaz de encargarse de su mantenimiento