Especificación de Requisitos de Software: Claves para el Éxito

¿Qué Hace que una Especificación de Requisitos de Software Sea Excelente?

Referencias:

• IEEE STD 830-1998
• IEEE STD 1233-1998

IEEE 830 define los beneficios de un buen SRS:

• Establecer las bases para un acuerdo entre los clientes y los proveedores en lo que respecta al producto de software que se necesita desarrollar.
• Reducir el esfuerzo de desarrollo.
• Proporcionar una base para la estimación de costos y horarios.
• Proporcionar un punto de referencia para la validación y verificación.
• Facilitar la transferencia.
• Servir como base para la mejora.

Cuestiones Clave en la Elaboración de un SRS

Las cuestiones básicas que el(los) escritor(es) del SRS deberán abordar son las siguientes:

1. Funcionalidad. ¿Qué se supone que debe hacer el software?

2. Las interfaces externas. ¿Cómo interactúa el software con las personas, el hardware del sistema, otro hardware, software y otros sistemas?

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

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

5. Diseño de las limitaciones impuestas a una aplicación. ¿Existen normas exigidas, aplicación de idiomas, políticas para la base de datos de integridad, límites de recursos, entorno(s) operativo(s), etc.?

Características de un SRS de Calidad

¿Cuáles son las características de un gran SRS?

Un SRS debe ser:

1. Correcto
2. Inequívoco
3. Completo
4. De conformidad
5. Clasificado por importancia y/o estabilidad
6. Verificable
7. Modificable
8. Trazable

Consideraciones de Alto Nivel en la Especificación de Sistemas

La siguiente es una lista de alto nivel que debería tenerse en cuenta en un sistema de Especificaciones:

• Definir las funciones del sistema
• Definir la partición funcional hardware/software
• Definir el cumplimiento de especificaciones
• Definir la partición de rendimiento hardware/software
• Definir los requisitos de seguridad
• Definir la interfaz de usuario
• Proporcionar dibujos/instrucciones de instalación
• Proporcionar dibujos de interfaz de control (CIE's, E/S externa)

Considere el público objetivo para determinar qué incluir en los documentos.

Mercado / Gestión de Productos

Crea una especificación del producto y se la entrega a los Sistemas. Deben definir las necesidades de los Sistemas para especificar el producto.

Sistemas

Crea una especificación del sistema y se la entrega a los Sistemas de Informática y Mecánica y Eléctrica de diseño.

Sistemas / Software

Crea una especificación de software y se la entrega a Software. Se deben definir las necesidades de todo Software para desarrollar el software.

Normas para Cumplir con los Plazos

• Dedique tiempo a especificar bien el software y la documentación que piensa seguir.
• Mantenga la documentación al mínimo cuando el software solo será utilizado por un corto tiempo o tiene un número limitado de usuarios.
• Tenga individuos separados para escribir las especificaciones (no la persona que escribirá el código).
• La persona que escriba la especificación debe tener buenas habilidades de comunicación.
• Los diagramas bonitos pueden ayudar, pero a menudo los cuadros y gráficos son más fáciles de mantener y pueden comunicar los mismos requisitos.
• Tómese su tiempo con requisitos complicados.
• Por el contrario, preste atención a la documentación excesiva de las funciones que son bien entendidas por muchas personas, pero en las que puede crear algunas grandes necesidades.
• Mantenga el SRS actualizado cuando realice cambios.
• Aproximadamente el 20-25% de la duración de los proyectos debe asignarse a la definición de los requisitos.
• Mantenga el 5% de la duración de los proyectos para la actualización de las necesidades después de que el diseño haya comenzado.
• Utilice el documento de requisitos de prueba como base para escribir el plan de prueba.