CONSIDERACIONES PARA PRODUCIR UN BUEN SRS

1. DEFINICIONES PRELIMINARES

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. Elusuario (s) y el cliente (s) no es (son) a menudo las mismas persona(s).

2. 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:

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.

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

Funcionalidad ¿Qué se supone va hacer el software?

Las interfases Externas.

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

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.?

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

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

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 interfases entre el sistema y su software modular y pondrá que función externa y requisitos de funcionalidad tiene con el software modular.

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

• 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.

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

• No debe imponer las restricciones adicionales en el software. Éstos se especifican propiamente en otros documentos.

2.3 Características de un buen SRS

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; esto hace el procedimiento más fácil y con menor probabilidad de 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

...