Requisitos del Software: Documentación, Estructura y Validación

Requerimientos del Dominio

Los requerimientos del dominio pueden ser:

• Nuevos requerimientos funcionales.
• Restricciones a funcionalidades existentes.
• Establecer la forma en que se debe realizar un cálculo específico.

Corresponden al dominio propio de la aplicación, por lo que requieren un esfuerzo por parte del ingeniero de software para entenderlos en relación con el resto de los requerimientos. Eventualmente, los expertos del dominio pueden dejarlos fuera de los requerimientos porque les parecen "obvios".

Documento de Requerimientos del Software (DRS)

Es un documento oficial que incluye los requerimientos del usuario y los requerimientos del sistema:

• DRS (Documento de Requerimientos del Sistema): plasma los requerimientos del cliente y/o usuario.
• FRS (Especificación de Requerimientos del Sistema): plasma los requerimientos del sistema, más específicos.

Se estructura de tal forma que puedan utilizarlo tanto los clientes del sistema como los desarrolladores del software. Debe evitar lenguaje y conceptos técnicos de programación.

Usuarios del Documento de Requerimientos

• Clientes del sistema.
• Administradores del proyecto.
• Ingenieros de sistemas.
• Testing QA.
• Mantenedores del sistema.

Características de un Buen Documento de Requerimientos

• Correcto: representa la visión del cliente del sistema.
• Completo: describe todos los escenarios posibles en el sistema, incluyendo el comportamiento excepcional.
• Consistente: no se contradice a sí mismo.
• Claro: no es posible interpretar una especificación en más de una forma.
• Realista: el sistema puede implementarse.

Estructura Sugerida por IEEE

1. Introducción
   1. Propósito del documento de requerimientos.
   2. Alcance del producto.
   3. Definiciones, acrónimos y abreviaturas.
   4. Referencias.
   5. Resumen del resto del documento.
2. Descripción general
   1. Perspectiva del producto.
   2. Funciones del producto.
   3. Características del usuario.
   4. Restricciones generales.
   5. Suposiciones y dependencias.
3. Requerimientos específicos: es la parte más sustancial del documento, que cubre los requerimientos funcionales y no funcionales.
4. Apéndice.
5. Índice.

Actividades Genéricas

• Estudio de factibilidad.
• Obtención y análisis de requerimientos.
• Especificación y documentación de requerimientos.
• Validación de requerimientos.

Estudio de Factibilidad

Técnica

• ¿Contamos con el RRHH capacitado y con experiencia?
• ¿Contamos con el equipamiento necesario (redes, servidores, equipos)?
• ¿Existen las tecnologías necesarias? (existencia, disponibilidad).

Económica

• ¿Contamos con el presupuesto ajustado?
• ¿Qué nos aconsejan los instrumentos de análisis (VAN, TIR)?
• ¿Se ajusta a la rentabilidad exigida al resto de los proyectos de la empresa? (ej: 10% anual).

Operativa

• ¿Cómo se integra a lo que tenemos actualmente (software actual, equipamiento)?
• ¿Nuestro RRHH está capacitado? ¿Cuál es su reacción histórica al cambio?

Legal

• ¿Cuáles son las leyes del dominio de la aplicación que nos afectan? (sistemas de facturación, sistemas de cálculo y retención de impuestos).
• ¿Cuáles son las leyes que afectan cualquier desarrollo de software? (derechos de autor).