DOCUMENTOS PARA ESPECIFICACIÓN FORMAL DE REQUISITOS
La Especificación de Requisitos Software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (Como por ejemplo restricciones en el diseño o estándares de calidad).
2. Las consideraciones para producir un buen SRS.
Estas cláusulas proporcionan información a fondo que deben ser consideradas almomento 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)
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.
Los aspectos básicos que una descripción de requisitos debe cubrir son:
§ Funcionalidad. Descripción de lo que el software debe hacer.
§ Interfaces externos. Cómo debe interactuar el software con las personas, el sistema de hardware, o con otros sistemas (software y hardware).
§ Rendimiento. Indicación de la velocidad, disponibilidad, tiempos de respuesta, tiempos de recuperación, tiempos de determinadas funciones.
§ Atributos. Consideraciones de portabilidad, corrección, mantenibilidad, seguridad, etc.
§ Restricciones de diseño en la implementación. Indicación de las restricciones que puedan afectar por la necesidad de sometimiento a estándares, lenguajes, políticas de integridad de bases de datos, límites de recursos disponibles para el desarrollo, sistema operativo, etc.
Las especificaciones de requisitos de software deben evitar incluir requisitos de diseño o de proyecto.
Obtención de los requisitos
Características de las buenas descripciones de requisitos
No hay comentarios:
Publicar un comentario