Explicación

13.1 Documento de requerimientos

En los temas anteriores has analizado algunos modelos y técnicas para detallar los requerimientos. El resultado de todo ese trabajo debe ser incluido en un documento al que se le llama especificación de requerimientos de software o SRS (Software Requirements Specifications) o simplemente documento de requerimientos.

Este documento contendrá todo el trabajo del análisis del sistema: los modelos, las descripciones de los requerimientos, reglas de negocio, prioridades del usuario. Más adelante podrás conocer un formato con las partes que lo componen.

El SRS constituye el alcance del proyecto y será la base de trabajo para las siguientes etapas del desarrollo. En algunos modelos ágiles, como el XP, el documento de especificaciones es sustituido por tarjetas que contienen escenarios del usuario, ya que permiten documentar especificaciones de una forma muy sencilla y rápida, evitando un documento formal que pudiera alargar el desarrollo y hacerse obsoleto por la rapidez que se necesita.

En opinión de Sommerville (2011) el documento de especificaciones es indispensable para proyectos de sistemas para negocios donde los requerimientos son inestables.

El documento de requerimientos debe ser escrito para un grupo muy diverso de usuarios, desde el dueño de la empresa que está aceptando financiar el proyecto, hasta los ingenieros responsables del desarrollo del sistema.

Usos del documento de requerimientos.
Fuente: Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson.

Dada la diversidad de usuarios, el lenguaje debe ser entendido tanto por el personal que no reconoce términos de software como por técnicos que esperan obtener todo el detalle posible. El ingeniero de requerimientos debe elegir el conjunto de modelos y técnicas de descripción más apropiados, sobre todo cuando el desarrollo será realizado por un tercero, ya que el mismo documento de requerimientos es parte del contrato del sistema por desarrollar.

Según la guía SWEBOK V3 (2014), la especificación de requerimientos de software permite lo siguiente:

Realizar una evaluación rigurosa de los requerimientos antes que pueda empezar el diseño.
Reducir el rediseño posterior.
Hacer una estimación más realista de costos, riesgos y calendarización de actividades.
Proveer de una base informada para la transferencia de un producto de software a nuevos usuarios o plataformas.
Establecer una base para realizar mejoras al software.

13.2 Tipos de documentación

Haz clic en cada uno de los actores para revisar su descripción

13.3 Formato de especificaciones de requerimientos

Utilizar un formato de especificaciones de requerimiento permite establecer una estructura muy completa al proyecto de desarrollo; su contenido dependerá del tipo de software y su enfoque.
Cada equipo de ingeniería de software debe plantear los apartados necesarios antes de iniciar el proyecto. Por ejemplo, si se estima que el desarrollo equivale a 3 meses de trabajo y se utilizará un modelo ágil de desarrollo, generar un documento muy detallado sería una carga excesiva. En ese caso se podrían omitir ciertos apartados o bien sólo describir a grosso modo los requerimientos, esperando que en las siguientes iteraciones se describan con mayor detalle.

Por otro lado, cuando el software es parte de un proyecto que estima un mayor esfuerzo horas-hombre, el documento de especificaciones de requerimientos es fundamental, sobre todo cuando existe un proveedor que se hará cargo de todo el desarrollo.

A continuación, puedes ver las partes de un formato de especificaciones de requerimientos tomando en consideración la opinión de Pressman (2010), Sommerville (2011) y Wiegers (1999)

Haz clic en cada uno de los actores para revisar su descripción

Incluye el título “Especificaciones de requerimientos de software”, Nombre del sistema o proyecto, fecha de elaboración, la versión del documento, autor, nombre de la organización.

Se incluyen los títulos y subtítulos de todo el documento. Como recomendación, pueden utilizarse hipervínculos que lleven al lector directamente al apartado indicado.

Se incluye la siguiente tabla describiendo los cambios que ha sufrido el documento. Las modificaciones leves se indican en el decimal de la versión, por ejemplo, 1.1 a 1.2; mientras que nuevos requerimientos, eliminaciones o cambios fuertes al documento, provocan se indican en la versión, por ejemplo 2.0 a 3.0

Autor	Fecha	Razones del cambio	Versión
Persona responsable del cambio	Fecha del cambio	Descripción de los cambios realizados	Versión del documento.

Incluye la definición de los términos técnicos que contiene el documento.

Es una descripción breve de las funciones del sistema y la forma en la que cumple con los objetivos estratégicos de la organización que solicita el software.

1.1 Propósito: Se define la razón fundamental del documento, el objetivo y sus intenciones.

1.2 Convenciones del documento: Se describen los estándares de documentación, el método de priorización de requerimientos, y cualquier otra convención tipográfica utilizada.

1.3 Destinatarios y sugerencias de lectura: se listan las personas a las que está dirigido el documento: usuarios, programadores, arquitectos, u otros.

1.4 Alcance del producto. Se describe el marco de referencia en el que se desarrollará el sistema, así una breve descripción de los beneficios esperados y alineación con la estrategia del negocio.

1.5 Referencias: Cualquier documento que se deba tomar en cuenta para el trabajo de desarrollo: guías de estilo de interfaz, estándares, contratos, políticas, procesos. Es importante que se incluya la versión del documento y su ubicación.

2.1 Producto Perspectiva: Se describe si el producto de software tiene relación con algún software existente, o se trata de un producto nuevo, independiente.

2.2 Funciones del producto. Se hace una descripción general de los requerimientos funcionales y no funcionales del sistema, los detalles se añaden más adelante. Es posible, además de hacer una descripción en lenguaje natural, incluir diagramas y anotaciones que puedan ser útiles para comprender el requerimiento al cliente. En esta sección también se describen los estándares del producto y procedimientos a seguir.

2.3 Arquitectura del sistema: Incluye una arquitectura de alto nivel prevista para el sistema. Aquí es donde se pueden describir detalles de la arquitectura actual y cómo se espera que se integre una posible nueva arquitectura.

2.4 Diseño e implementación de restricciones: Se describen detalles que pudieran limitar las opciones del diseño o construcción del sistema como políticas corporativas de desarrollo de software, idioma, seguridad, protocolos de comunicación y uso de tecnología específica.

2.5 Documentación del usuario: Cualquier manual de usuario, tutorial, material de capacitación, información de sistemas existentes y estándares de documentación.

2.6 Supuestos y dependencias: Descripción de factores o hechos conocidos que podrían afectar el desarrollo del sistema. Por ejemplo una posible integración con otro sistema que se esté desarrollando en paralelo, infraestructura con capacidad suficiente o personal técnico capacitado.

3.1 Interfaces de usuario: algunas organizaciones tienen un estándar para las interfaces gráficas del usuario que deben considerarse para el desarrollo del nuevo sistema, por ejemplo, colores, íconos, botones y administración de ventanas.

3.2 Interfaces de hardware: En este caso se pudieran incluir características de las interfaces que deben existir entre componentes del hardware. Este apartado es muy importante ya que es posible que el cliente utilice equipo de arquitectura cerrada o poco común que trae consigo problemas de compatibilidad e interoperabilidad.

3.3 Software interfaces: Se describen posibles requerimientos de conexiones con productos de software existentes. Por ejemplo, una integración con un sistema de contabilidad o un sistema ERP.

3.4 Comunicaciones Interfaces: Se incluye la descripción de necesidades de comunicación, como el uso de correo electrónico, mensajes de notificaciones SMS, protocolos de intercambio de archivos (FTP) o cualquier necesidad de cifrado (SSH).

En este apartado se hace una descripción detallada de cada uno de los requerimientos
4.1. Requerimientos funcionales
4.2. Requerimientos no funcionales

Este apartado servirá para incluir cualquier modelo del sistema (basados en escenarios de clases, flujo de datos o comportamiento)

Se describe como se prevé que el sistema pueda irse adaptando a cambios en el hardware o nuevas necesidades del cliente.

Información detallada relacionada con la aplicación.

En el índice se incluyen los listados de los diagramas, funciones, figuras, tablas y otros elementos.

Observa que este formato establece claramente toda la información relevante para desarrollar un sistema. Su contenido permite que el usuario valide todos sus requerimientos y sea una guía para el resto del equipo de desarrollo.