Cómo redactar un documento de requisitos de software (incluye una plantilla)

¿Recuerdas cuando leías novelas del siglo XIX en el colegio y pensabas, “No parece estar escrito siquiera en el mismo idioma”? Bueno, es la misma sensación de cuando trabajas en la oficina con desarrolladores de IA, con su mentalidad tecnológica, o con analistas SEO expertos en la web. Qué bueno sería que hubiese una versión adaptada de lo que dicen, para sus colegas.

A veces, es esencial que los departamentos de extremos opuestos de una organización trabajen juntos, incluso aunque usen distintos lenguajes técnicos. Si alguna vez trabajaste en un equipo interdisciplinario, sabrás lo complicado que puede resultar hacer que todos estén alineados.

Los documentos de especificación de requisitos de software pueden ser útiles para que los gerentes de proyectos o de producto y los analistas de negocios desglosen los conceptos de alto nivel y los transformen en acciones concretas que cualquier miembro del equipo pueda seguir durante el proceso de desarrollo.

¿Qué es un documento de especificación de requisitos de software?

En un documento de especificación de requisitos de software (SRS, por sus siglas en inglés, o ERS, por sus siglas en español) se enumeran los requisitos, las expectativas, el diseño y los estándares de un proyecto futuro. Incluye los requerimientos comerciales generales que rigen al objetivo del proyecto, los requisitos y necesidades de los usuario finales, y la funcionalidad del producto en términos técnicos. Para hacerlo más simple, una especificación de requisitos de software ofrece una descripción detallada de cómo debería funcionar un producto de software y qué debería hacer tu equipo de desarrollo para hacerlo funcionar.

Imagina que se te ha ocurrido una idea genial para una aplicación. Has visualizado lo que quieres hacer y qué aspecto deseas que tenga, pero sabes que no bastará con describírselo verbalmente a un desarrollador y esperar que cumpla con las expectativas. Aquí es donde la especificación de requisitos de software cobra importancia.

¿Por qué conviene usar una especificación de requisitos de software?

Si los desarrolladores no tienen instrucciones claras con respecto a cuándo crear un producto nuevo, probablemente termines dedicando más tiempo y dinero del previsto, solamente, para producir un software que coincida con lo que tienes en mente.

La composición de este documento sirve para poner las ideas en papel y organizar una lista clara de los requerimientos. El documento se transforma en la fuente única de referencias, para que todos los equipos, desde marketing a mantenimiento, estén en la misma sintonía.

Dado que la especificación de requisitos de software es un documento dinámico, también puede funcionar como centro para las comunicaciones entre las diferentes partes interesadas de un proceso de desarrollo de productos. Indefectiblemente, en todo proyecto de desarrollo de software habrá iteraciones del producto. Si anotas los cambios en la especificación de requisitos de software, todas las partes podrán validarlos en el documento. De este modo, no habrá confusiones con respecto a cuáles son los requisitos.

Qué incluir en una especificación de requisitos de software

La estructura de una especificación de requisitos de software básica cuenta con cuatro partes: una introducción, los requisitos funcionales y los del sistema, los de la interfaz externa y los no funcionales.

1. Introducción

La introducción en esta especificación es exactamente lo que esperas, un panorama global del proyecto en general. Cuando redactes la introducción, describe el propósito de la creación del producto, el público que pretendes cautivar y cómo crees que ese público usará el software. En la introducción no olvides incluir lo siguiente:

• El alcance del producto: El alcance debería estar vinculado a los objetivos generales y comerciales del producto, un dato que resultará particularmente importante en caso de que varios equipos o contratistas tengan acceso al documento. Enumera los beneficios, las metas y los objetivos previstos para el producto.

• El valor del producto: ¿Por qué tu producto es importante? ¿Qué beneficio le aportará a la audiencia prevista? ¿Qué función tendrá o qué problema resolverá? Pregúntate qué valor encontrará el público en tu producto.

• El público objetivo: Describe a tu público ideal. Serán ellos quienes dicten el aspecto que tendrá el producto y cómo deberás comercializarlo.

• El uso previsto: Imagina de qué manera tu público usará el producto. Enumera las funciones que brindarás y todas las formas posibles en que la audiencia podrá usar el producto dependiendo del rol. También resultará una buena práctica incluir casos de uso para ilustrar tu visión.

• Las definiciones y los acrónimos: Cada sector o negocio tiene sus propios acrónimos y su jerga particular. Dispón las definiciones de los términos que usarás en el documento para asegurarte de que todos entiendan lo que quieres decir.

• El índice: Si el documento es exhaustivo, es probable que sea bastante largo. Incluye un índice para ayudar a que los participantes encuentren exactamente lo que buscan.

Verifica que tu introducción sea clara y concisa. Recuerda que será la guía para el resto de la estructura de la especificación de requisitos de software, y te convendrá que todos interpreten lo mismo cuando usen el documento.

2. Requisitos funcionales y del sistema

Una vez que hayas terminado la introducción, será hora de volverse más específico. En los requisitos funcionales se desglosan las características y funciones que permiten que el sistema se comporte como ha sido previsto.

Usa el resumen general como referencia para controlar que los requisitos cumplan con las necesidades básicas de los usuarios a medida que completas los datos. Dependiendo del producto, puede haber cientos de requisitos funcionales por incluir. Algunos de los más comunes son los siguientes:

• Funciones “If/then” (si/o)

• Lógica de manejo de datos

• Flujos de trabajo del sistema

• Gestión de las transacciones

• Funciones administrativas

• Deberes regulatorios y de cumplimiento de normas

• Requisitos de desempeño

• Detalles sobre las operaciones llevadas a cabo en cada pantalla

Si parece mucho, intenta con un requisito a la vez. Mientras más detalles incluyas en la especificación de requisitos de software, menos problemas deberás detectar y resolver más adelante.

3. Requisitos de la interfaz externa

Los requisitos de la interfaz externa son tipos de requisitos funcionales con los que se garantiza que el sistema se comunicará correctamente con los componentes externos como:

• Las interfaces de usuarios: Son la clave de la facilidad de uso de una aplicación. Incluyen la presentación del contenido, las opciones de navegación de la aplicación y asistencia para los usuarios, entre otros componentes.

• Las interfaces de hardware: Son las características de cada interfaz que interactúa entre los componentes del software y del hardware del sistema; como los tipos de dispositivos compatibles y los protocolos de comunicación.

• Las interfaces de software: Incluyen las conexiones entre tu producto y otros componentes de software, como las bases de datos, las bibliotecas y los sistemas operativos.

• Las interfaces para comunicaciones: Los requerimientos de las funciones que se usarán en tu producto para comunicación, como los emails o los formularios integrados.

Los sistemas embebidos dependen de los requisitos de las interfaces externas. Deberías incluir cosas como los diseños de pantalla, las funciones de los botones y una descripción de en qué medida tu producto dependerá de otros sistemas.

4. Requisitos no funcionales (NRF)

La sección final de los detalles de la especificación de requisitos de software incluye los requisitos no funcionales. Mientras que con los requisitos funcionales se le indica al sistema cómo debe comportarse, con los no funcionales (NFR) se determina de qué manera el sistema implementará estas funciones. Por ejemplo, con un requisito funcional se puede determinar que el sistema imprimirá una etiqueta de empaque cada vez que un cliente pida un producto. Con una NFR se garantizará que las impresiones de las etiquetas se harán en papel blanco de 4” × 6”, el tamaño estándar para este tipo de etiquetas.

Si bien es cierto que el sistema podría funcionar incluso aunque no cumpliera con los NFR, estarías poniendo en riesgo la participación de los usuarios o las partes interesadas. Este tipo de requerimientos sirven para controlar los requisitos funcionales, de modo que se conserven los atributos como la asequibilidad del producto o su facilidad de uso.

Estos son los tipos más comunes de NFR:

• La seguridad: Qué se necesita para garantizar que cualquier información sensible de los usuarios que recopile tu software estará protegida. 

• La capacidad: Lo que se necesita para satisfacer la demanda de almacenamiento ahora y lo que se necesitará más adelante. Incluye un plan para determinar cómo se adaptará el sistema a escala a medida que aumente la demanda.

• La compatibilidad: Los requisitos mínimos de hardware para el software, como la compatibilidad con los sistemas operativos y sus versiones.

• La fiabilidad y disponibilidad: Con qué frecuencia esperas que los usuarios utilicen el software y cuál es el tiempo de fallo crítico esperado con relación a un uso normal.

• La escalabilidad: La cantidad máxima de trabajo con la que el sistema se comportará como se ha previsto.

• La mantenibilidad: Cómo se debería usar la integración continua en tu aplicación para implementar funciones o reparar errores rápidamente.

• La facilidad de uso: Cuán fácil resulta usar el producto.

Entre los tipos más comunes de requisitos no funcionales se encuentran los de desempeño, los regulatorios y los requisitos medioambientales.

Plantilla para documentos de requisitos de software

¿Todo listo para aventurarte al propio desarrollo de un software? En nuestra plantilla para especificación de requisitos de software se detallan los cuatro componentes clave de un documento de primer nivel. Ofrece detalles muy valiosos, tanto a tu equipo como a ti, sobre el producto que desarrollarán. Recuerda que los requerimientos deben ser detallados, claros y concisos, para que todas las partes tengan la misma visión en mente.

Mejores prácticas para redactar una especificación de requisitos de software

El propósito de contar con este documento es mantener a los equipos de todos los departamentos trabajando orientados a un objetivo claro. Dicho esto, compartimos algunas mejores prácticas que te servirán para garantizar que esta especificación cumpla su propósito.

Optimiza tu especificación de requisitos de software con material visual

Incluye material visual como diagramas, esquemas o modelos. Ayudarán a los miembros del equipo a entender mejor el proceso. Es más, resultarán particularmente útiles para ilustrar las funciones principales del software y su operatividad.

Una de las técnicas útiles para las lluvias de ideas de un proyecto es la aplicación de mapas mentales. Con ellos se organizan las ideas, las funciones, los posibles escenarios y se determinan las conexiones. Crea un mapa mental para estructurar las ideas dispersas y empezar a consolidarlas. No es estrictamente necesario que el material visual tenga muchísimos detalles, para eso está la especificación de requisitos de software. En cambio, céntrate en las funciones clave del software y en cómo se vinculan entre sí.

Sé claro y conciso

Lo último que quieres es que los desarrolladores hagan sus propias suposiciones cuando deban construir el producto. Intenta no dar lugar a que los miembros del equipo se vuelvan demasiado creativos y completen ellos la información que falta con lo que se les ocurra. Incluye tantos detalles como te sea posible en la descripción de los requisitos del software y evita lo siguiente:

• Usar palabras imprecisas como generalmente o aproximadamente.

• Combinar términos con “/”, que se podrían interpretar como “y” u “o”.

• Usar valores límite complicados.

• Usar negaciones dobles o triples.

Una buena manera de detectar ambigüedades en la especificación de requisitos de software es mediante la revisión formal de un compañero. Planifica hacer que cada participante lo revise para comparar cómo han entendido los requerimientos y, en función de esa información, haz los cambios que sean necesarios.

Conoce bien a tu usuario final

Suma a la especificación de requisitos de software tu propia investigación de campo y entrevistas de usuarios para entender con claridad los requisitos, las expectativas y las necesidades de tus usuarios finales. Te ayudará a visualizar las operaciones que realizarán los usuarios con el software. Ten en cuenta todos los escenarios posibles y sus matices e inclúyelos en el documento. Recuerda que los desarrolladores implementarán exactamente lo que incluyas en el documento; ni más, ni menos.

Deja margen para la flexibilidad

La especificación de requisitos de software es un documento dinámico. Es decir, deberás agregar funciones y modificaciones a cada iteración. Permítelo con requisitos flexibles, para los casos en que los resultados no cumplan con las expectativas. También es una buena práctica conservar los registros de los cambios efectuados al documento para evitar malentendidos. Los participantes deberían poder rastrear cada requisito a su versión original y ver quién ha hecho cambios, cuándo y por qué.

Usa la especificación de requisitos de software para aclarar tu visión

No es sencillo redactar este documento, pero tampoco lo es trabajar constantemente resolviendo problemas o tener que lidiar con conflictos entre los miembros del equipo. El trabajo que describas en una especificación de requisitos de software habrá valido la pena cuando veas el magnífico producto que habrás obtenido con el esfuerzo conjunto de todas las partes interesadas.