Práctica recomendada del IEEE Std 830-1998 para las especificaciones de los requisitos de software

Visión general

En esta práctica se describen los enfoques recomendados para la especificación de los requisitos de software. Se
divide en cláusulas.

La cláusula 1 explica el alcance de esta práctica recomendada. En la cláusula 2 se enumeran las referencias a otras
normas. La cláusula 3 proporciona las denegaciones de los términos específicos utilizados. La Cláusula 4 proporciona
información de fondo para escribir un buen SRS. La Cláusula 5 discute cada una de las partes esenciales de un SRS.
Esta práctica recomendada también tiene dos anexos, uno que proporciona plantillas de formatos alternativos, y
otro que proporciona directrices para el cumplimiento de la norma IEEE/EIA 12207.1-1997.

1.1 Alcance

Esta es una práctica recomendada para la redacción de las especificaciones de los requisitos de los programas
informáticos. Describe el contenido y las cualidades de una buena especificación de los requisitos de software (SRS) y
presenta varios ejemplos de esquemas de SRS.

Esta práctica recomendada tiene por objeto especificar los requisitos del software que se va a desarrollar, pero
también puede aplicarse para ayudar a la selección de productos de software internos y comerciales. Sin embargo, la
aplicación a los programas informáticos ya desarrollados podría ser contraproducente.

Cuando el software está incorporado en algún sistema más grande, como el equipo médico, es posible que haya que
abordar cuestiones que van más allá de las identificadas en esta práctica recomendada.

Esta práctica recomendada describe el proceso de creación de un producto y el contenido de este. El producto es un
SRS. Esta práctica recomendada se puede utilizar para crear dicho SRS directamente o se puede utilizar como
modelo para un estándar más específico.

Esta práctica recomendada no identifica ningún método, nomenclatura o herramienta específica para preparar un
SRS.

2. Referencias

This recommended practice shall be used in conjunction with the following publications.

ASTM E1340-96, Standard Guide for Rapid Prototyping of Computerized Systems.

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.

IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.

IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning.

IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans.

IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software.

IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software.

3. Definiciones

En general, las denegaciones de los términos utilizados en esta práctica recomendada se ajustan a las denegaciones
previstas en la norma IEEE Std 610.12-1990. Las denegaciones que figuran a continuación son términos clave tal
como se utilizan en esta práctica recomendada.

3.1 contrato:

Un documento legalmente vinculante acordado por el cliente y el proveedor. Incluye los requisitos técnicos y
organizativos, el coste y el calendario de un producto. Un contrato también puede contener información informal
pero útil, como los compromisos o expectativas de las partes involucradas.
3.2 cliente:

La persona o personas que pagan por el producto y normalmente (pero no necesariamente) deciden los requisitos.
En el contexto de esta práctica recomendada, el cliente y el proveedor pueden ser miembros de la misma
organización.

3.3 proveedor:

La persona o personas que producen un producto para un cliente. En el contexto de esta práctica recomendada, el
cliente y el proveedor pueden ser miembros de la misma organización.

3.4 usuario:

La persona o personas que operan o interactúan directamente con el producto. El usuario o usuarios y el cliente o
clientes no suelen ser la misma persona o personas.

4. Consideraciones para producir un buen SRS

Esta cláusula proporciona información de fondo que debe ser considerada cuando se escribe un SRS. Esto incluye lo
siguiente:

a) Naturaleza del SRS;

b) Entorno del SRS;

c) Características de un buen SRS;

d) Preparación conjunta del SRS;

e) Evolución del SRS;

f) Prototipos;

g) Diseño de la inserción en el SRS;

h) Inserción de los requisitos del proyecto en el SRS.

4.1 Naturaleza del SRS

El SRS es una especificación para un producto de software particular, programa o conjunto de programas que realiza
ciertas funciones en un entorno específico. El SRS puede ser escrito por uno o más representantes del proveedor,
uno o más representantes del cliente, o por ambos. En la subcláusula 4.4 se recomiendan ambos.

Los temas básicos que el escritor o los escritores del SRS deberán abordar son los siguientes:

a) Funcionalidad.

¿Qué se supone que hace el software?

b) Interfaces externas.

¿Cómo interactúa el software con la gente, el hardware del sistema, otro hardware y otro software?

c)La actuación.

¿Cuál es la velocidad, la disponibilidad, el tiempo de respuesta, el tiempo de recuperación de las diversas funciones
del software, etc.?

d)Atributos.

¿Cuáles son las consideraciones de portabilidad, corrección, mantenimiento, seguridad, etc.?

e) Las limitaciones de diseño impuestas a una aplicación.

 ¿Existen normas vigentes, lenguaje de aplicación, políticas para la integridad de la base de datos, límites de
recursos, entorno(s) operativo(s), etc.?

El (los) redactor(es) del SRS debe(n) evitar poner requisitos de diseño o de proyecto en el SRS.

Para el contenido recomendado de un SRS véase la Cláusula 5.

4.2 Medio ambiente del SRS

Es importante considerar el papel que juega el SRS en el plan total del proyecto, que está diseñado en IEEE Std
610.12-1990. El software puede contener esencialmente toda la funcionalidad del proyecto o puede ser parte de un
sistema más grande. En este último caso, típicamente habrá un SRS que establecerá las interfaces entre el sistema y
su porción de software, y pondrá requisitos externos de rendimiento y funcionalidad sobre la porción de software.
Por supuesto, el SRS debería entonces estar de acuerdo con estos requisitos del sistema y ampliarlos.

El IEEE Std 1074-1997 describe los pasos en el ciclo de vida del software y las entradas aplicables para cada paso.
Otros estándares, como los enumerados en la Cláusula 2, se relacionan con otras partes del ciclo de vida del
software y por lo tanto pueden complementar los requisitos del software.

Dado que el SRS tiene un papel específico que desempeñar en el proceso de desarrollo del software, los redactores
del SRS deben tener cuidado de no ir más allá de los límites de ese papel. Esto significa que el SRS

a) Debe definir correctamente todos los requisitos de software. Un requisito de software puede existir debido a la
naturaleza de la tarea a resolver o a una característica especial del proyecto.

b) No debería describir ningún detalle de diseño o implementación. Éstos deberían describirse en la etapa de diseño
del proyecto.

c) No debería imponer restricciones adicionales al software. Éstas se especifican adecuadamente en otros

documentos, como el plan de garantía de calidad del software.

Por lo tanto, un SRS debidamente redactado limita la gama de diseños válidos, pero no especifica ningún diseño en
particular.

4.3 Características de un buen SRS

Un SRS debería ser

a) Correcto;

b) Sin ambigüedades;

c) Completo;

d) Consistente;

e) Clasificado por importancia y/o estabilidad;

f) Verificable; g) Modificable; h) Rastreable.

4.3.1 Correcto

Un SRS es correcto si, y sólo si, todos los requisitos establecidos en él son los que el software debe cumplir.

No hay ninguna herramienta o procedimiento que asegure la corrección. El SRS debe compararse con cualquier
especificación superior aplicable, como la especificación de los requisitos del sistema, con otra documentación del
proyecto y con otras normas aplicables, para asegurarse de que está de acuerdo. Alternativamente, el cliente o
usuario puede determinar si el SRS recoge correctamente las necesidades reales. La trazabilidad hace que este
procedimiento sea más fácil y menos propenso a errores (véase 4.3.8).
4.3.2 Sin ambigüedades

Un SRS no es ambiguo si, y sólo si, cada requisito establecido en él tiene sólo una interpretación. Como mínimo, esto
requiere que cada característica del producto se describa utilizando un único término.

ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE IEEE Std 830-1998

Copyright ' 1998 IEEE. Todos los derechos reservados.

En los casos en que un término utilizado en un contexto particular pueda tener múltiples significados, el término
debe incluirse en un glosario en el que su significado sea más específico.

Un SRS es una parte importante del proceso de requerimientos del ciclo de vida del software y se utiliza en el diseño,
implementación, monitoreo de proyectos, verificación y validación, y en la capacitación como se describe en IEEE Std
1074-1997. El SRS debe ser inequívoco tanto para quienes lo crean como para quienes lo utilizan. Sin embargo, estos
grupos a menudo no tienen los mismos antecedentes y, por lo tanto, no tienden a describir los requisitos de
software de la misma manera. Las representaciones que mejoran la especificación de los requisitos para el
desarrollador pueden ser contraproducentes en la medida en que disminuyen la comprensión para el usuario y
viceversa.

4.3.2.1 Los escollos del lenguaje natural

Los requisitos suelen estar escritos en lenguaje natural (por ejemplo, en inglés). El lenguaje natural es
inherentemente ambiguo. Un SRS de lenguaje natural debe ser revisado por una parte independiente para
identificar el uso ambiguo del lenguaje para que pueda ser corregido.

4.3.2.2 Lenguajes de especificación de requisitos

Una forma de evitar la ambigüedad inherente al lenguaje natural es escribir el SRS en un lenguaje de especificación
de requisitos particulares. Sus procesadores de lenguaje detectan automáticamente muchos errores léxicos,
sintácticos y semánticos.

Una desventaja en el uso de tales lenguajes es el tiempo requerido para aprenderlos. Además, muchos usuarios no
técnicos los hacen ininteligibles. Además, esos idiomas tienden a ser mejores para expresar ciertos tipos de
requisitos y abordar determinados tipos de sistemas. Así pues, pueden inducir los requisitos de manera sutil.

4.3.2.3 Instrumentos de representación

En general, los métodos y lenguajes de los requisitos y las herramientas que los apoyan se dividen en tres categorías
generales: objeto, proceso y comportamiento. Los enfoques orientados a los objetos organizan los requisitos en
términos de objetos del mundo real, sus atributos y los servicios que realizan esos objetos. Los enfoques basados en
procesos organizan los requisitos en jerarquías de funciones que se comunican a través de los datos. Los enfoques
basados en el comportamiento describen el comportamiento externo del sistema en términos de alguna noción
abstracta (como el cálculo de predicados), funciones matemáticas o máquinas de estado.

El grado en que tales herramientas y métodos pueden ser útiles en la preparación de un SRS depende del tamaño y
la complejidad del programa. No se intenta aquí describir o respaldar ninguna herramienta en particular.

Al utilizar cualquiera de estos enfoques es mejor mantener las descripciones en lenguaje natural. De esa manera, los
clientes que no estén familiarizados con las notaciones podrán seguir entendiendo el SRS.

4.3.3 Completo

Un SRS está completo si, y sólo si, incluye los siguientes elementos:

a) Todos los requisitos del firmante, ya sea en relación con la funcionalidad, el rendimiento, las restricciones de
diseño, los atributos o las interfaces externas. En particular, se deben reconocer y tratar todos los requisitos
externos impuestos por una especificación del sistema.
b) Denegación de las respuestas del software a todas las clases realizables de datos de entrada en todas las clases
realizables de situaciones. Nótese que es importante especificar las respuestas a los valores de entrada tanto válidos
como inválidos. c) Etiquetas completas y referencias a todos los gurús, tablas y diagramas del SRS y la negación de
todos los términos y unidades de medida.

4.3.3.1 Utilización de los TBD

Cualquier SRS que use la frase “por determinar” (TBD) no es un SRS completo. La TBD es, sin embargo,
ocasionalmente necesaria y debe ir acompañada de

a) Una descripción de las condiciones causantes de la TBD (por ejemplo, por qué no se conoce una respuesta) para
que se pueda resolver la situación;

b) Una descripción de lo que se debe hacer para eliminar la TBD, quién es responsable de su eliminación, y para
cuándo se debe eliminar.

4.3.4 Consecuente

La consistencia se refiere a la consistencia interna. Si un SRS no está de acuerdo con algún documento de nivel
superior, como la especificación de los requisitos del sistema, entonces no es correcto (véase 4.3.1).

4.3.4.1 Coherencia interna

Un SRS es internamente consistente si, y sólo si, no hay un subconjunto de requisitos individuales descritos en él
concuerdan. Los tres tipos de cónicos probables en un SRS son los siguientes:

a) Las características específicas de los objetos del mundo real pueden conectarse. Por ejemplo,

1) El formato de un informe de salida puede describirse en un requisito como tabular, pero en otro como textual.

2) Un requisito puede establecer que todas las luces sean verdes mientras que otro puede establecer que todas las
luces sean azules.

b) Puede haber una congruencia lógica o temporal entre dos acciones especificadas. Por ejemplo,

1) Un requisito puede especificar que el programa añadirá dos entradas y otro puede especificar que el programa las
multiplicará.

2) Un requisito puede establecer que A debe seguir siempre a B, mientras que otro puede exigir que A y B se
produzcan simultáneamente.

c) Dos o más requisitos pueden describir el mismo objeto del mundo real, pero utilizar términos diferentes para ese
objeto. Por ejemplo, la solicitud de un programa para una entrada de usuario puede llamarse un aviso en un
requisito y una entrada en otro. El uso de terminología y definiciones estándar promueve la coherencia.

4.3.5 Clasificación por importancia y/o estabilidad

Un SRS se clasifica por su importancia y/o estabilidad si cada requisito en él tiene un identificador para indicar ya sea
la importancia o la estabilidad de ese requisito en particular.

Típicamente, todos los requisitos que se relacionan con un producto de software no son igualmente importantes.
Algunos requisitos pueden ser esenciales, especialmente para las aplicaciones esenciales para la vida, mientras que
otros pueden ser deseables.

Cada requisito en el SRS debe ser identificado para hacer estas diferencias claras y explícitas. Identificar los requisitos
de la siguiente manera ayuda:

a) Hacer que los clientes consideren más cuidadosamente cada requisito, lo que a menudo aclara cualquier
suposición oculta que puedan tener. b) Hacer que los desarrolladores tomen decisiones de diseño correctas y
dediquen los niveles de esfuerzo apropiados a las diferentes partes del producto de software.
4.3.5.1 Grado de estabilidad

Un método para identificar los requisitos utiliza la dimensión de la estabilidad. La estabilidad puede expresarse en
términos del número de cambios previstos en cualquier requisito sobre la base de la experiencia o el conocimiento
de los próximos acontecimientos que afecten a la organización, las funciones y las personas apoyadas por el sistema
informático.

4.3.5.2 Grado de necesidad

Otra forma de clasificar los requisitos es distinguir las clases de requisitos como esenciales, condicionales y
opcionales.

a) Esencial. Implica que el software no será aceptable a menos que estos requisitos se proporcionen de manera
acordada.

b) Condicional. Implica que se trata de requisitos que mejorarían el producto de software, pero que no lo harían
inaceptable si están ausentes.

c)Opcional. Implica una clase de funciones que pueden o no valer la pena. Esto le da al proveedor la oportunidad de
proponer algo que exceda al SRS.

4.3.6 Verificable

Un SRS es verificable si, y sólo si, todos los requisitos establecidos en él son verificables. Un requisito es verificable si,
y sólo si, existe algún proceso nítido y rentable con el que una persona o máquina pueda comprobar que el producto
de software cumple el requisito. En general, cualquier requisito ambiguo no es verificable.

Los requisitos no verificables incluyen declaraciones tales como funciona bien, buena interfaz humana, y
normalmente sucederá. Estos requisitos no pueden verificarse porque es imposible define los términos bien, bien, o
usualmente. La declaración de que el programa nunca entrará en un bucle de inicio no es verificable porque la
comprobación de esta calidad es teóricamente imposible.

Un ejemplo de una declaración verificable es

La salida del programa se producirá dentro de los 20 s del evento 60% del tiempo; y se producirá dentro de los 30 s
del evento * El 100% de las veces.

Esta afirmación puede ser verificada porque utiliza términos concretos y cantidades medibles.

Si no se puede concebir un método para determinar si el software cumple un requisito concreto, entonces ese
requisito debe ser eliminado o revisado.

4.3.7 Modificable

Un SRS es modificable si, y sólo si, su estructura y estilo son tales que cualquier cambio en los requisitos puede ser
hecho fácil, completa y consistentemente mientras se mantiene la estructura y el estilo. La modificabilidad
generalmente requiere que un SRS

a) Tener una organización coherente y fácil de utilizar, con un índice y referencias cruzadas explícitas;

b) No ser redundante (es decir, el mismo requisito no debe aparecer en más de un lugar en el SRS); c) Expresar cada
requisito por separado, en lugar de entremezclarlo con otros requisitos.

La redundancia en sí misma no es un error, pero puede dar lugar fácilmente a errores. La redundancia puede ayudar
ocasionalmente a hacer más legible un SRS, pero puede surgir un problema cuando se actualiza el documento
redundante. Por ejemplo, un requisito puede ser alterado sólo en uno de los lugares donde aparece. El SRS entonces
se vuelve inconsistente. Siempre que sea necesaria la redundancia, el SRS debe incluir referencias cruzadas explícitas
para hacerlo modificable.
4.3.8 Trazabilidad

Un SRS es trazable si el origen de cada uno de sus requisitos es claro y si facilita la referencia de cada requisito en la
documentación de desarrollo o mejora futura. Se recomiendan los dos tipos de rastreabilidad siguientes:

a) Rastreo hacia atrás (es decir, a etapas anteriores de desarrollo). Esto depende de que cada requisito haga
referencia explícita a su fuente en documentos anteriores.

b) La rastreabilidad (es decir, a todos los documentos generados por el SRS). Esto depende de que cada requisito del
SRS tenga un nombre o número de referencia único.

La rastreabilidad a futuro del SRS es especialmente importante cuando el producto de software entra en la fase de
operación y mantenimiento. A medida que se modifican los documentos de código y diseño, es esencial poder
determinar el conjunto completo de requisitos que pueden verse afectados por esas modificaciones.

4.4 Preparación conjunta del SRS

El proceso de desarrollo de software debe comenzar con un acuerdo entre el proveedor y el cliente sobre lo que
debe hacer el software terminado. Este acuerdo, en forma de un SRS, debe ser preparado conjuntamente. Esto es
importante porque normalmente ni el cliente ni el proveedor están calificados para escribir un buen SRS por sí solos.

a) Por lo general, los clientes no entienden el proceso de diseño y desarrollo del software lo suficientemente bien
como para escribir un SRS utilizable.

b) Los proveedores generalmente no entienden el problema del cliente y se esfuerzan lo suficiente como para
especificar los requisitos de un sistema satisfactorio.

Por lo tanto, el cliente y el proveedor deben trabajar juntos para producir un SRS bien escrito y completamente
comprendido.

Existe una situación especial cuando un sistema y su software están siendo denegados simultáneamente. Entonces la
funcionalidad, las interfaces, el rendimiento y otros atributos y limitaciones del software no están predestinados,
sino que se deniegan conjuntamente y están sujetos a negociación y cambio. Esto hace que sea más difícil, pero no
menos importante, cumplir con las características indicadas en 4.3. En particular, un SRS que no cumpla los
requisitos de la especificación de su sistema principal es incorrecto.

Esta práctica recomendada no discute específicamente el estilo, el uso del lenguaje o las técnicas de buena escritura.
Sin embargo, es muy importante que un SRS esté bien escrito. Se pueden utilizar como guía libros de escritura
técnica general.

4.5 Evolución del SRS

El SRS puede necesitar evolucionar a medida que el desarrollo del producto de software progresa. Puede ser
imposible especificar algunos detalles en el momento en que se inicia el proyecto (por ejemplo, puede ser imposible
penetrar todos los formatos de pantalla de un programa interactivo durante la fase de requisitos). Pueden
producirse cambios adicionales a medida que se descubren en el SRS las decisiones, deficiencias e inexactitudes.

Dos consideraciones importantes en este proceso son las siguientes:

a) Los requisitos deben especificarse de manera tan completa y exhaustiva como se conozca en ese momento,
aunque se puedan prever revisiones evolutivas como inevitables. Debe señalarse el hecho de que son incompletos.

b) Debe iniciarse un proceso oficial de cambio para identificar, controlar, rastrear e informar sobre los cambios
proyectados. Los cambios aprobados en los requisitos deben incorporarse en el SRS de tal manera que

1) Proporcione una pista de auditoría precisa y completa de los cambios;

2) Permita la revisión de las partes actuales y sustituidas del SRS.

4.6 Creación de prototipos

La creación de prototipos se utiliza con frecuencia durante la parte de las necesidades de un proyecto. Existen
muchos instrumentos que permiten crear un prototipo, que presenta algunas características de un sistema, de
manera muy rápida y fácil. Véase también ASTM E1340-96.

Los prototipos son útiles por las siguientes razones:

a) Es más probable que el cliente vea el prototipo y reaccione a él que lea el SRS y reaccione a él. Por lo tanto, el
prototipo proporciona una rápida retroalimentación.

b) El prototipo muestra aspectos imprevistos del comportamiento del sistema. Así, produce no sólo respuestas sino
también nuevas preguntas. Esto ayuda a alcanzar el cierre del SRS.

c) Un SRS basado en un prototipo tiende a sufrir menos cambios durante el desarrollo, acortando así el tiempo de
desarrollo.

Un prototipo debe ser usado como una forma de obtener los requerimientos de software. Se pueden extraer algunas
características como los formatos de pantalla o de informe directamente del prototipo. Se pueden inferir otros
requisitos realizando experimentos con el prototipo.

4.7 Diseño de incrustación en el SRS

Un requisito especifica una función o atributo visible externamente de un sistema. Un diseño describe un
subcomponente particular de un sistema y/o sus interfaces con otros subcomponentes. El (los) redactor(es) del SRS
debe(n) distinguir claramente entre la identificación de las restricciones de diseño requeridas y la proyección de un
diseño específico. Tenga en cuenta que todos los requisitos del SRS limitan las alternativas de diseño. Sin embargo,
esto no significa que todos los requisitos sean de diseño.

El SRS debe especificar qué funciones deben realizarse en qué datos para producir qué resultados en qué lugar para
quién. El SRS debe centrarse en los servicios que se van a realizar. El SRS normalmente no debe especificar
elementos de diseño como los siguientes:

a) Partición del software en módulos; b) Asignación de funciones a los módulos; c) Descripción de la deuda de
información o control entre los módulos; d) Elección de las estructuras de datos.

4.7.1 Requisitos de diseño necesarios

En casos especiales algunos requisitos pueden restringir severamente el diseño. Por ejemplo, los requisitos de
seguridad o protección pueden repercutir directamente en el diseño, como la necesidad de

a) Mantener ciertas funciones en módulos separados;

b) Permitir sólo una comunicación limitada entre algunas áreas del programa;

c) Comprobar la integridad de los datos en busca de variables críticas.

Ejemplos de limitaciones de diseño válidas son los requisitos físicos, los requisitos de rendimiento, las normas de
desarrollo del software y las normas de garantía de calidad del software.

Por lo tanto, los requisitos deberían establecerse desde un punto de vista puramente externo. Cuando se utilicen
modelos para ilustrar los requisitos, recuerde que el modelo sólo indica el comportamiento externo y no especifica
un diseño.

4.8 Incorporación de los requisitos del proyecto en el SRS

El SRS debe ocuparse del producto de software, no del proceso de producción del producto de software.
Los requisitos del proyecto representan un entendimiento entre el cliente y el proveedor acerca de los asuntos
contractuales relacionados con la producción del software y, por lo tanto, no deben incluirse en el SRS.
Normalmente incluyen elementos como

a) Costo;

b) Plazos de entrega;

c) Procedimientos de presentación de informes;

d) Métodos de desarrollo de programas informáticos;

e) Garantía de calidad;

f) Criterios de validación y verificación;

g) Procedimientos de aceptación.

Los requisitos del proyecto se especifican en otros documentos, normalmente en un plan de desarrollo de software,
un plan de garantía de calidad del software o una declaración de trabajo.

5. Las partes de un SRS

Esta cláusula discute cada una de las partes esenciales del SRS. Estas partes están dispuestas en la figura 1 en un
esquema que puede servir como ejemplo para escribir un SRS.

Si bien un SRS no tiene que seguir este esquema ni usar los nombres que se dan aquí para sus partes, un buen SRS
debe incluir toda la información que se discute aquí.

1. Introducción

En esta sección se proporcionará una introducción a todo el documento de Especiación de Requisitos Software (ERS).
Consta de varias subsecciones: propósito, ámbito del sistema, denticiones, referencias y visión general del
documento.

1.1. Propósito

En esta subsección se definira el propósito del documento ERS y se especificara a quien va dirigido el documento.
1.2. Ámbito del Sistema

En esta subsección:

Se podrá dar un nombre al futuro sistema (p.ej. MiSistema)

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.

Se referenciarán todos aquellos documentos de nivel superior (p.e. en Ingeniería de Sistemas, que incluyen
Hardware y Software, debería mantenerse la consistencia con el documento de especiación de requisitos globales
del sistema, si existe).

1.3. Definiciones, Acrónimos y Abreviaturas

En esta subsección se definira todos los términos, acrónimos y abreviaturas utilizadas en la ERS.

1.4. Referencias

En esta subsección se mostrará una lista completa de todos los documentos referenciados en la ERS.

1.5. Visión General del Documento

Esta subsección describe 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. No se describen los
requisitos, sino su contexto. Esto permitirá definira con detalle los requisitos en la sección 3, haciendo que sean más
fáciles de entender. Normalmente, esta sección consta de las siguientes subsecciones: Perspectiva del producto,
funciones del producto, características de los usuarios, restricciones, factores que se asumen y futuros requisitos.

2.1. Perspectiva del Producto

Esta subsección debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es
totalmente independiente de otros productos, también debe especiarse aquí. Si la ERS define un producto que es
parte de un sistema mayor, esta subsección relacionara los requisitos del sistema mayor con la funcionalidad del
producto descrito en la ERS, y se identificaran las interfaces entre el producto mayor y el producto aquí descrito. Se
recomienda utilizar diagramas de bloques.

2.2. Funciones del Producto

En esta subsección de la ERS se mostrará un resumen, a grandes rasgos, de las funciones del futuro sistema. Por
ejemplo, en una ERS para un programa de contabilidad, esta subsección mostrara que el sistema soportara´ el
mantenimiento de cuentas mostrara´ el estado de las cuentas y facilitara la facturación, sin mencionar el enorme
detalle que cada una de estas funciones requiere. Las funciones deberán mostrarse de forma organizada, y pueden
utilizarse graficos, siempre y cuando dichos graficos reflejen las relaciones entre funciones y no el diceño del sistema.

2.3. Características de los Usuarios

Esta subsección describirá las características generales de los usuarios del producto, incluyendo nivel educacional,
experiencia y experiencia técnica.

2.4. Restricciones

Esta subsección describirá aquellas limitaciones que se imponen sobre los desarrolladores del producto

Políticas de la empresa

Limitaciones del hardware

Interfaces con otras aplicaciones

Operaciones paralelas

Funciones de auditoria

Funciones de control

Lenguaje(s) de programación

Protocolos de comunicación

Requisitos de habilidad

Criticalidad de la aplicación

Consideraciones acerca de la seguridad

2.5. Suposiciones y Dependencias

Esta subsección de la ERS describirá aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo,
los requisitos pueden presuponer una cierta organización de ciertas unidades de la empresa, o pueden presuponer
que el sistema correrá sobre cierto sistema operativo. Si cambian dichos detalles en la organización de la empresa, o
si cambian ciertos detalles técnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.

2.6. Requisitos Futuros

Esta subsección esbozara´ futuras mejoras al sistema, que podrán analizarse e implementarse en un futuro.

3. Requisitos Específicos

Esta sección contiene los requisitos a un nivel de detalle luciente como para permitir a los diseñadores diseñar un
sistema que satisfaga estos requisitos, y que permita al equipo de pruebas platicar 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. Esta es la sección más
larga e importante de la ERS. Deberán aplicarse los siguientes principios:

El documento debería ser perfectamente legible por personas de muy distintas formaciones e intereses.

Deberán referenciarse aquellos documentos relevantes que poseen alguna anuencia sobre los requisitos.

Todo requisito debería ser unívocamente identificable mediante algún código o sistema de numeración adecuado.

Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las siguientes características:

• Corrección: La ERS es correcta si y solo si todo requisito que figura aqui (y que será implementado en el sistema)
reflejen alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.
• No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad inherente a los requisitos
expresados en lenguaje natural, se deberán utilizar graficos o notaciones formales. En el caso de utilizar términos
que, habitualmente, poseen más de una interpretación, se definira con precisión 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 válidos.

• Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos contradictorio no es

implementable.

• Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasificarse 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.

• Verificables: La ERS es Verificables si y solo si todos sus requisitos son Verificables. Un requisito es Verificables
(testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un
requisito ambiguo no es, en general, Verificables. Expresiones como a veces, bien, adecuado, etc. introducen
ambigüedad en los requisitos. Requisitos como “en caso de accidente la nube toxica no se extenderá más allá de
25Km” no es Verificables por el alto costo que conlleva.

• Modificables: La ERS es modificable si y solo si se encuentra estructurada de forma que los cambios a los requisitos
pueden realizarse de forma fácil, completa y consistente. La utilización de herramientas automáticas de gestión de
requisitos (por ejemplo, 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 diseño y de la implementación. La trazabilidad hacia atrás indica el origen (documento,
persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica que componentes del sistema
son los que realizan el requisito R.

3.1. Interfaces Externas

Se describirán los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e
interfaces de comunicaciones.

3.2. Funciones

Esta subsección (quizá la más larga del documento) deberá especificar todas aquellas acciones (funciones) que
deberá llevar a cabo el software. Normalmente (aunque no siempre), son aquellas acciones expresables como “el
sistema deberá ...”. Si se considera necesario, podrán utilizarse notaciones graficas y tablas, pero siempre
supeditadas al lenguaje natural, y no al revés. Es importante tener en cuenta que, en 1983, el Estándar de IEEE 830
establecía que las funciones deberían expresarse como una jerarquía funcional (en paralelo con los DFDs propuestos
por el análisis estructurado). Pero el Estándar de IEEE 830, en sus últimas versiones, ya permite organizar esta
subsección de múltiples formas, y sugiere, entre otras, las siguientes:

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

*Por objetos: Los objetos son entidades del mundo real que serán reflejadas en el sistema. Para cada objeto, se
detallarán sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organización de la ERS no
quiere decir que el diseño del sistema siga el paradigma de Orientación a Objetos.

*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 detallaran las
funciones que permitan llevarlo a cabo.

*Por estímulos: Se especificara los posibles estímulos que recibe el sistema y las funciones relacionadas con dicho
estimulo.

*Por jerarquía funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del sistema se
especificara como una jerarquía de funciones que comparten entradas, salidas o datos internos. Se detallarán las
funciones (entrada, proceso, salida) y las subfunciones del sistema. Esto no implica que el diseño del sistema deba
realizarse según el paradigma de Diseño Estructurado.

Para organizar esta subsección de la ERS se elegirá alguna de las anteriores alternativas, o incluso alguna otra que se
considere más conveniente. Deberá, eso sí, justificarse el porqué de tal elección

3.3. Requisitos de Rendimiento

Se detallarán los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el
número de terminales, el numero esperado de usuarios simultáneamente conectados, número de transacciones por
segundo que deberá soportar el sistema, etc. También, si es necesario, se especificara los requisitos de datos, es
decir, aquellos requisitos que afecten a la información que se guardara´ en la base 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

Todo aquello que restrinja las decisiones relativas al diseño de la aplicación: Restricciones de otros estándares,
limitaciones del hardware, etc.

3.5. Atributos del Sistema

Se detallarán los atributos de calidad (las “ilities”) del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy
importante, la seguridad. Deberá especiarse que tipos de usuario están autorizados, o no, a realizar ciertas tareas, y
como se implementaran los mecanismos de seguridad (por ejemplo, por medio de un login y una contraseña).

3.6. Otros Requisitos

Cualquier otro requisito que no encaje en otra sección.

4. Apéndices

Pueden contener todo tipo de información relevante para la ERS pero 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 análisis de costes.

3. Restricciones acerca del lenguaje de programación.