Esquema de la ERS definida en el IEEE 830-1998

La estructura de la ERS propuesta por el IEEE en su estándar 830 [IEEE, 1998] [upm, 2000].

1   Introducción

En esta sección se proporcionará una introducción a todo el documento de Especificación de Requisitos Software. Consta de varias subsecciones, las cuales son propósito, ámbito del sistema, definiciones, referencias y visión general del documento.

1.1  Propósito

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

1.2   Ámbito del Sistema

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.3   Definiciones, Acrónimos y Abreviaturas.

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

1.4  Referencias

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

1.5   Visión General del Producto

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

 

2   Descripción General

En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos. En esta sección no se describen los requisitos, sino su contexto. Los detalles de los requisitos de describen en la sección 3, detallándolos y haciendo más fácil su comprensión.

2.1   Perspectiva del Producto

Esta subsección debe relacionar el futuro sistema con otros productos. Así pues, podríamos dividir ésta en pequeñas subsecciones indicando cada uno de los puntos a tener en cuenta:
 
2.1.1.  Indicar si es un producto independiente o parte de un sistema mayor
2.1.2.   Interfaces de sistema
2.1.3.   Interfaces de usuario
2.1.3.1.  Características lógicas del interfaz
2.1.3.2.  Cuestiones de optimización del interfaz de usuario
2.1.4.   Interfaces hardware
2.1.5.    Interfaces software
2.1.5.1.  Descripción del producto software utilizado
2.1.5.2.    Propósito del interfaz
2.1.5.3.    Definición del interfaz: contenido y formato
2.1.6.  Interfaces de comunicaciones
2.1.7.  Limitaciones de memoria
2.1.8.   Operaciones
2.1.8.1.   Modos de operación de los distintos grupos de usuarios
2.1.8.2.    Periodos de operaciones interactivas y automáticas
2.1.8.3.   Funciones respaldo del procesamiento de datos
2.1.8.4.   Operaciones de backup y recuperación
2.1.9.  Requerimientos para adaptarse a la ubicación
2.1.9.1.  Indicar cualquier dato o secuencia de inicialización específico de cualquier lugar, modo de operación.

2.1.9.2.  Características que deben ser modificadas para una instalación en particular.

2.1   Funciones del Producto

Esta subsección debe proporcionar un resumen de las funciones principales que el software debe llevar a cabo. Las funciones deben estar organizadas de manera que el cliente o cualquier otra persona lo entienda perfectamente. Para ello se pueden utilizar métodos textuales o gráficos, siempre que dichos gráficos reflejen las relaciones entre funciones y no el diseño del sistema.

En la metodología estructurada se podrían utilizar los DFDs y en una metodología orientada a objetos, el funcionamiento y las relaciones del futuro sistema se modelarían a través de los Casos de Uso. En ellos se representa lo que el usuario ve del sistema, así pues facilitará en gran medida su comprensión, siempre y cuando en los diagramas se eviten las ambigüedades.

2.2  Características de los usuarios

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

2.3  Restricciones

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. Serán las limitaciones que se imponen sobre los desarrolladores del producto.

2.4   Suposiciones y Dependencias

En este apartado aparecerá cualquier factor, que si cambia puede afectar a los requerimientos. No son restricciones de diseño, por ejemplo, asumir que un determinado sistema operativo estará disponible, presuponer una cierta organización de las unidades de la empresa. Si cambian ciertos detalles puede ser necesario revisar los requisitos.

2.5   Requisitos Futuros

Se indican aquí posibles mejoras del sistema en el futuro. Estas mejoras deben estudiarse y analizarse una vez concluido y puesto en marcha el sistema. Son modificaciones a realizar en un futuro incierto.

 

3   Requisitos Específicos

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.1   Interfaces Externas
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.2   Funciones
En este subsección de deben 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.

La estructuración de las funciones a desarrollar por el nuevo sistema no está del todo claro. Se debe tener en cuenta que en el estándar de IEEE 830 de 1983 se establecía que las funciones de deberían expresar como una jerarquía funcional

El estándar IEEE 830, en sus últimas versiones, permite la organización de esta subsección de múltiples formas y simplemente sugiere alguna manera para hacerlo, dejando la oportunidad de utilizar cualquier otra justificando suficientemente la utilización de ésta.

Alguna de las formas sugeridas por el estándar son:

·     Por tipo de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organización, se especifican los requisitos funcionales que le afecten o tengan mayor relación con sus tareas.

·     Por objetos: Los objetos son entidades del mundo real que son reflejadas en el sistema. Por tanto, para cada objeto se detallan sus atributos y sus funciones. Los objetos se pueden agrupar en clases. A pesar de realizar el análisis con objetos no obliga a que el diseño del sistema siga el paradigma Orientado a Objetos, aunque lo facilita en gran medida.

·     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 requerido al sistema, se detallarán las funciones que permitan llevarlo a cabo.

·     Por jerarquía funcional: La funcionalidad del sistema se especifica como una jerarquía de funciones que comparten entradas, salidas o datos del propio sistema. Para cada función y subfunción del sistema se detallará la entrada, el proceso en el que interviene y la salida. Normalmente este tipo de análisis implica que el diseño siga el paradigma de diseño estructurado. Por lo general éste sistema se utiliza cuando ninguno de los anteriores se puede aplicar.

3.3   Requisitos de Rendimiento

En esta subsección se incluyen los requisitos relacionados con la carga que se espera que tenga que soportar el sistema (número de usuarios simultáneos, número de terminales ...). Asimismo, se pueden incluir los requisitos que afecten a la información que se vaya a guardar en la base de datos (cantidad de registros en una base de datos, frecuencia de uso...)

3.4   Restricciones de Diseño

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.

3.5   Atributos del Sistema

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

3.6  Otros requisitos

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

4   Apéndices
Se incluirá aquí cualquier tipo de información relacionada con la ERS, pero que no forme parte de la misma. Por ejemplo, se incluirían los resultados del análisis de costes, restricciones especiales acerca del lenguaje de programación...
5   Índice

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