Esquema de la ERS definida en el IEEE 830-1998

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

1 Introducción
1.1 Propósito
1.2 Ámbito del Sistema
1.3 Definiciones, Acrónimos y Abreviaturas
1.4 Referencias
1.5 Visión general del documento
2 Descripción General
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íficos
3.1 Interfaces Externas
3.2 Funciones
3.3 Requisitos de Rendimiento
3.4 Restricciones de Diseño
3.5 Atributos del Sistema
3.6 Otros Requisitos
4 Apéndices
5 Índice

A continuación se describirá brevemente cada uno de los apartados que se
definen en el estándar estudiado.
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.
Normalmente podemos encontrar las siguientes subsecciones: Perspectiva del
producto, funciones del producto, características de los usuarios, restricciones,
suposiciones y futuros requisitos.
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.2 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.3 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.4 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.5 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.6 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.
Los requisitos que se aquí se indiquen deben describir comportamientos externos
del sistema, observables por el usuario así como por parte de los operadores y otros
sistemas.
Puesto que deben indicarse todos los requisitos, esta sección es la más larga de la
ERS y debe cumplir los principios descritos en los primeros apartados de este informe.
Estos principios son la corrección, no ambigüedad, completitud, consistencia,
clasificación, verificabilidad, modificabilidad, explorabilidad y facilidad de
mantenimiento.
Asimismo, éste documento debe ser perfectamente legible por el cliente y por
personas de muy distinta formación. Otra de las cuestiones a tener en cuenta en esta
sección es la identificación de cada uno de los requisitos mediante algún código o
sistema de numeración.
3.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.
3.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 (véase
anexo II), puesto que es la que mejor se adaptaba a los DFDs que proponía el análisis
estructurado. Con la evolución de la programación y los nuevos métodos de análisis se
puede observar como esta estructura no se adapta, por tanto es necesaria la modificación
de los estándares.
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.
Como se puede apreciar, el estándar propone una serie de plantillas según el tipo
de sistema con el que nos enfrentemos. Pero en muchas ocasiones la elección se realiza
por eliminación, o lo que es lo mismo, se escoge aquel que mejor se adapta a lo que se
busca.
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.
Otras versiones del IEEE 830
En la fase 3 de la especificación de requisitos según el estándar IEEE (Requisitos
específicos) se ha hecho referencia a estándares más antiguos que el aquí presentado.
Así pues, se presenta un esquema de los pasos a seguir en una metodología estructurada
según el estándar IEEE 830 de 1983.
Dicha versión del estándar IEEE 830 propone tres posibles modelos para la
sección 3 de una ERS [Chalmeta, 2000].
Modelo 1
3. Requerimientos específicos
3.1. Requerimientos funcionales
3.1.1. Requerimiento funcional 1.
3.1.1.1. Introducción
3.1.1.2. Entradas
3.1.1.3. Proceso
3.1.1.4. Salidas
3.1.2. Requerimiento funcional 2.
..........
3.1.n. Requerimiento funcional n
3.2. Requerimientos de interfaces externos.
3.2.1. Interfaces de usuario
3.2.2. Interfaces hardware
3.2.3. Interfaces software
3.2.4. Interfaces de comunicaciones
3.3. Requerimientos de eficiencia
3.4. Restricciones de diseño
3.4.1. Estándares cumplidos
3.4.2. Limitaciones Hardware
.......
3.5. Atributos
3.5.1. Seguridad
3.5.2. Mantenimiento
.......
3.6. Otros requerimientos
3.6.1. Bases de Datos
3.6.2. Operaciones
3.6.3. Requerimientos de adaptación a situaciones
.......
Modelo 2
3. Requerimientos específicos
3.1. Requerimientos funcionales
3.1.1. Requerimiento funcional 1.
3.1.1.1. Especificación.
3.1.1.1.1. Introducción
3.1.1.1.2. Entradas
3.1.1.1.3. Proceso
3.1.1.1.4. Salidas
3.1.1.2. Requerimientos de interfaces externos
3.1.1.2.1. Interfaces de usuario
3.1.1.2.2. Interfaces hardware
3.1.1.2.3. Interfaces software
3.1.1.2.4. Interfaces de comunicaciones
3.1.2. Requerimiento funcional 2.
......
3.1.n . Requerimiento funcional n.
3.2. Requerimientos de eficiencia.
3.3. Restricciones de diseño.
3.3.1. Estándares cumplidos
3.3.2. Limitaciones hardware
.......
3.4. Atributos.
3.4.1. Seguridad.
3.4.2. Mantenimiento.
........
3.5. Otros requerimientos.
3.5.1. Bases de Datos.
3.5.2. Operaciones.
3.5.3. Requerimientos de adaptación a situaciones.
.......
Modelo 3
3. Requerimientos específicos.
3.1. Requerimientos funcionales.
3.1.1. Requerimiento funcional 1
3.1.1.1. Introducción
3.1.1.2. Entradas
3.1.1.3. Proceso
3.1.1.4. Salidas
3.1.1.5. Requerimientos de eficiencia
3.1.1.6. Restricciones de diseño
3.1.1.6.1. Estándares cumplidos
3.1.1.6.2. Limitaciones hardware
3.1.1.7. Atributos-
3.1.1.7.1. Seguridad
3.1.1.7.2. Mantenimiento
.........
3.1.1.8. Otros requerimientos
3.1.1.8.1. Bases de Datos
3.1.1.8.2. Operaciones
3.1.1.8.3. Requerimientos de adaptación a situaciones
........
3.1.2. Requerimiento funcional 2.
.......
3.1.n. Requerimiento funcional n.
.......
3.2. Requerimientos de interfaces externos.
3.2.1. Interfaces de usuario
3.2.1.1. Requerimientos de eficiencia.
3.2.1.2. Restricciones de dis eño.
3.2.1.2.1. Estándares cumplidos
3.2.1.2.2. Limitaciones hardware
3.2.1.3. Atributos.
3.2.1.3.1. Seguridad
3.2.1.3.2. Mantenimiento
.......
3.2.1.4. Otros requerimientos
3.2.1.4.1. Bases de datos
3.2.1.4.2. Operaciones
3.2.1.4.3. Requerimientos de adaptación a situaciones
.......
3.2.2. Interfaces hardware.
3.2.3. Interfaces software.
3.2.4. Interfaces de comunicaciones.
Características de una buena ERS
Las características deseables para una buena especificación de requisitos software que
se indican en el IEEE son las siguientes [Chalmeta, 2000][Piattini, 1996]:
·  Correcta
·  No ambigua
·  Completa
·  Verificable
·  Consistente
·  Clasificada
·  Modificable
·  Explorable
·  Utilizable durante las tareas de mantenimiento y uso
3.1 Corrección
La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad
real. La corrección de la ERS implica que el sistema implementado será el sistema
deseado.
3.2 Ambigüedad
Un documento es no ambiguo si y solo si cada requisito descrito tiene una única
interpretación. Cada característica del producto final debe ser descrita utilizando un
término único y, en caso de que se utilicen términos similares en distintos contextos, se
deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario
en el que indicar cada significado específicamente.
Los analistas deben poner un cuidado especial a la hora de especificar los
requisitos. El hecho de utilizar el lenguaje natural para hacer la ERS comprensible a los
usuarios supone un riesgo muy elevado, porque el lenguaje natural puede llegar a ser
muy ambiguo.
Ejemplo:
Todos los clientes tienen el mismo campo de control
1.- ¿Todos tienen el mismo valor en el campo de control?
2.- ¿Todos los campos de control tienen el mismo formato?
3.- ¿Un campo de control se usa para todos los clientes?
En términos generales, el lenguaje natural es de los más ambiguos. Por el
contrario existen los lenguajes formales que no son ambiguos, pero son más difíciles de
aprender y menos comprensibles para el que no los conoce.
3.3 Completitud
Una ERS es completa si:
·  Incluye todos los requisitos significativos del software (relacionados con la
funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).
·  Existe una definición de respuestas a todas las posibles entradas, tanto válidas
como inválidas, en todas las posibles situaciones.
·  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.
·  Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como
definidos todos los términos y unidades de medida empleados.
La ERS debe ser siempre completa, aunque en ocasiones esto no será posible. Por
ejemplo si todavía no se han determinado los formatos de los informes finales o por
cualquier razón se esta esperando la publicación de un Real Decreto o un reglamento
sobre impuestos.
3.4 Verificabilidad
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.
Ejemplo
No verificables:
El producto debería funcionar bien
El producto debería tener una buena interfaz de usuario
Verificable:
La salida se suministra dentro de los 20 segundos siguientes al evento E el
60% de las veces, y en los 30 segundos siguientes en el 100%
3.5 Consistencia
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:
·  Requisitos que describen el mismo objeto real utilizando distintos términos.
·  Las características especificadas de objetos reales. Un requisito establece que
todas las luces son verdes y otro que son azules.
·  Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un
punto en el que dos acciones serían perfectamente válidas (¿sumar o
multiplicar?)
3.6 Clasificación
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por
diversos criterios:
·  Importancia: Pueden ser esenciales, condicionales u opcionales.
·  Estabilidad: Cambios que pueden afectar al requisito.
Lo ideal es el establecimiento de prioridades, de modo que la implementación de
un requisito de menor prioridad no emplee excesivos recursos.
3.7 Modificabilidad
Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa
y consistente. Para ello, es deseable tener una organización coherente y fácil de usar en
la que aparezca el índice o una tabla de contenidos fácilmente accesible.
También es deseable evitar la redundancia, es decir que no aparezca un mismo
requisito en más de un lugar de la ERS. No es un error, pero si se tiene que modificar
alguna cosa será mucho más cómodo si no tenemos que buscar el mismo requisito en
varios lugares.
3.8 Explorabilidad (traceability)
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).
Cuando un requisito de la ERS representa un desglose o una derivación de otro
requisito, se debe facilitar tanto las referencias hacia atrás como hacia adelante en el
ciclo de vida.
Las referencias hacia delante de la ERS son especialmente importantes para el
mantenimiento del software. Cuando el código y los documentos son modificados, es
esencial poder comparar el conjunto total de requisitos que puedan verse afectados por
estas modificaciones.
3.9 Utilizable durante las tareas de mantenimiento y uso
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. Así, dicha ERS actúa a modo de plano de la
aplicación, permitiendo incluso modificaciones que no requieran un cambio en el
diseño.
En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal
que se encargue del mantenimiento no tiene por qué tener. Por esta razón es necesaria
una correcta documentación de las funciones, ya que si no se conoce en detalle su
origen, difícilmente podrán ser modificadas.