PDF de programación - IEEE830 ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE

IEEE-STD-830-1998 : ESPECIFICACIONES DE LOS REQUISITOS DEL
SOFTWARE


1. Definiciones


En general las definiciones de los términos usados en estas especificaciones están
conforme a las definiciones proporcionadas en IEEE Std 610.12-1990.

1.1 Contrato:

Un documento es legalmente obligatorio y en el estarán de acuerdo las partes del cliente
y proveedor. Esto incluye los requisitos técnicos y requerimientos de la organización,
costo y tiempo para un producto. Un contrato también puede contener la información
informal pero útil como los compromisos o expectativas de las partes involucradas.

1.2 Cliente:

La persona (s) que pagan por el producto y normalmente (pero no necesariamente)
definen los requisitos. En la práctica el cliente y el proveedor pueden ser miembros de
la misma organización.

1.3 Proveedor:

La persona (s) que producen un producto para un cliente.

1.4 Usuario:

La persona (s) que operan o actúan recíprocamente directamente con el producto. El
usuario (s) y el cliente (s) no es (son) a menudo las mismas persona(s).

2. Las consideraciones para producir un buen SRS.

Estas cláusulas proporcionan información a fondo que deben ser consideradas al
momento de producir un SRS. Esto incluye lo siguiente:

a) la Naturaleza del SRS;
b) el Ambiente del SRS;
c) las Características de un buen SRS ;
d) la preparación de los Joins del SRS;
e) la evolución de SRS;
f) Prototipos;
g) Generando el diseño en el SRS;
h) Generando los requisitos del proyecto en el SRS.

2.1 Naturaleza del SRS

El SRS son especificaciones para un producto del software en particular, programa, o
juego de programas que realizan ciertas funciones en un ambiente específico. El SRS
puede escribirse por uno o más representantes del proveedor, uno o más representantes
del cliente, o por ambos. La Subclausula 2.4 recomienda ambos.

Los problemas básicos que se presentan al escribir un SRS van dirigidos a lo siguiente:

a) La Funcionalidad.

¿Qué se supone va hacer el software ?

b) Las interfaces Externas.

¿Cómo el software actúa recíprocamente con las personas, el hardware de los sistemas,
otro hardware, y otro software?

c) La Actuación.

¿Cuál es la velocidad, la disponibilidad, tiempo de la contestación, tiempo de la
recuperación de varias funciones del software, etc.?

d) Los Atributos.

¿Qué portabilidad tiene, exactitud, el mantenimiento, la seguridad, las consideraciones
etc.?

e) Las restricciones del diseño que impusieron en una aplicación.

¿Hay algún requerimiento Standard, idioma de aplicación, las políticas para la
integridad del banco de datos, los límites de los recursos, operando en que ambiente (s)
etc.?

2.2 Ambiente del SRS

Es importante considerar la parte que el SRS representa en el diseño del proyecto total
que se define en IEEE Std 610.12-1990. El software puede contener toda la
funcionalidad del proyecto esencialmente o puede ser parte de un sistema más grande.
En el último caso habrá un SRS que declarará las interfaces entre el sistema y su
software modular, y pondrá que función externa y requisitos de funcionalidad tiene con
el software modular.

Otras normas, relacionan a otras partes del ciclo de vida de software para que pueda
complementar los requisitos del software.

Desde que el SRS tiene un papel específico en el proceso de desarrollo de software, el
que define el SRS debe tener el cuidado para no ir más allá de los límites de ese papel.
Esto significa que:

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

b) no debe describir cualquier plan o detalles de aplicación. Éstos deben describirse en
la fase del diseño del proyecto.

c) no debe imponer las restricciones adicionales en el software. Éstos se especifican
propiamente en otros documentos.

2.3 Características de un buen SRS.

Un SRS debe ser:

a) Correcto;
b) Inequívoco;
c) Completo;
d) Consistente;
e) Delinear que tiene importancia y/o estabilidad;
f) Comprobable;
g) Modificable;
h) Identificable.

2.3.1 Correcto

Un SRS es correcto si, y sólo si, cada requisito declarado se encuentra en el software.
No hay ninguna herramienta o procedimiento que aseguran
la exactitud.
Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las
necesidades reales correctamente. Identificando los requerimientos
hace este
procedimiento más fácil y hay menos probabilidad al error.

2.3.2 Inequívoco

Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo una
interpretación. Como un mínimo, se requiere que cada característica de la última versión
del producto se describa usando un único término.

En casos dónde un término en un contexto particular tenga significados múltiples, el
término debe ser incluido en un glosario dónde su significado es hecho más específico.

Un SRS es una parte importante del proceso de requisitos del ciclo de vida de software
y se usa en el diseño, aplicación, supervisión, comprobación, aprobación y pruebas
como está descrito en IEEE Std 1074-1997.

El SRS debe ser inequívoco para aquéllos que lo crean y para aquéllos que lo usan. Sin
embargo, estos grupos no tienen a menudo el mismo fondo y por consiguiente no
tienden a describir los requisitos del software de la misma manera.

Las Subclauses 2.3.2.1 a través de 2.3.2.3 recomiendan cómo evitar la ambigüedad.

2.3.2.1 Trampas del idioma natural.

Los requisitos son a menudo escritos en el idioma natural (por ejemplo, inglés) el
idioma natural es inherentemente ambiguo. Un idioma natural que SRS podría ser
revisado por una parte independiente para identificar el uso ambiguo del idioma para
que pueda corregirse.


2.3.2.2 Idiomas de especificación de requisitos

Una manera de evitar la ambigüedad inherente en el idioma natural es escribir el SRS en
un idioma de especificación de requisitos particular. Sus procesadores del idioma
descubren muchos errores léxicos, sintácticos, y semánticos automáticamente.
Una desventaja en el uso de tales idiomas es que la premura de tiempo exigió
aprenderlos. También, muchos usuarios no-técnicos los encuentran ininteligible. Es
más, estos idiomas tienden a ser buenos a expresar ciertos tipos de requisitos y dirigirse
a ciertos tipos de sistemas. Así, ellos pueden influir en los requisitos de las maneras
sutiles.

2.3.2.3 Representación hecha con herramientas

En general, los métodos de requisitos e idiomas y las herramientas que los apoyan
entran en tres categorías generales - el objeto, procesos y conductual.
El término objetos-orientados organizan los requisitos en lo que se refiere a los objetos
en el mundo real , sus atributos, y los servicios realizados por esos objetos.
El término procesos organizan los requisitos en las jerarquías de funciones que
comunican vía el flujo de datos.
El términos conductuales describen conducta externa del sistema por lo que se refiere a
alguna noción de lo abstracto, las funciones matemáticas o el estado de las máquinas.

El grado en que se usan estas herramientas y los métodos pueden ser útiles preparando
un SRS pero depende del tamaño y complejidad del programa. Aún usando cualquiera
de estos términos es mejor retener las descripciones del idioma natural. Así, clientes
poco familiar con las anotaciones el SRS puede entender todavía.

2.3.3 Completo

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

a) Los requisitos están relacionados a la funcionalidad, el desarrollo, las restricciones
del diseño, los atributos y las interfaces externas. En particular debe reconocerse
cualquier requisito externo impuesto por una especificación del sistema y debe tratarse.

b) La definición de las respuestas del software a todos los posibles datos de la entrada
del sistema y a toda clase de situaciones. Una nota que es importante especificar son las
contestaciones a las entradas válidas e inválidas a ciertos valores.

c) Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en
el SRS y definición de todas las condiciones y unidades de medida.

2.3.3.1 Uso de TBDs

Cualquier SRS que usa la frase "para ser determinado" (TBD) no es un SRS completo.
El TBD es, sin embargo, ocasionalmente necesario y debe acompañarse por:

a) Una descripción de las condiciones que causan el TBD (por ejemplo, por qué una
respuesta no es conocida) para que la situación pueda resolverse;

b) Una descripción de lo que debe hacerse para eliminar el TBD que es responsable para
su eliminación y por como debe eliminarse.

2.3.4 Consistente

La consistencia se refiere a la consistencia interior. Si un SRS no está de acuerdo con
algún documento del superior-nivel, como una especificación de requisitos de sistema,
entonces no es correcto.

2.3.4.1 Consistencia interior

Un SRS es internamente consistente si, y sólo si, ningún subconjunto de requisitos
individuales genero conflicto en él.
Los tres tipos de conflictos probables en un S