Cómo redactar un documento de requisitos de software: 7 pasos y una plantilla

Antes de encargar el desarrollo de una aplicación, hay que saber explicarla a alguien que no conoce su actividad: qué debe hacer, para quién y por qué. Esa es toda la razón de ser de un documento de requisitos de software. Bien redactado, pone de acuerdo a su equipo, permite que los proveedores presupuesten el proyecto sobre la misma base y sirve de referencia hasta la entrega.

No hace falta ser informático para redactarlo: describe su actividad, no la tecnología. Le presentamos nuestro método en siete pasos, una plantilla de índice para copiar y los errores que encontramos con más frecuencia.

Para qué sirve un documento de requisitos de software

Un documento de requisitos describe la necesidad: el «qué» y el «por qué». El «cómo» (tecnologías, arquitectura, alojamiento) corresponde al proveedor, que lo expone en sus especificaciones técnicas. También se le llama especificación de requisitos de software (ERS) o especificación funcional.

Este documento cumple tres funciones:

• Alinear a su equipo: la dirección y los usuarios se ponen de acuerdo sobre lo importante.
• Comparar las propuestas: todos los proveedores presupuestan lo mismo, y las diferencias de precio se pueden explicar.
• Verificar lo entregado: es la base de las pruebas de aceptación, que comprueban que el software hace lo que se pidió.

En un proyecto a precio cerrado, también se convierte en la base del precio: cuanto más claro es, más fiable es el presupuesto, como explicamos en nuestro artículo sobre el costo de un software a medida.

Cómo redactar un documento de requisitos en 7 pasos

1. Partir del problema, no de la solución

Empiece por lo que hoy no funciona. «Queremos una aplicación móvil» es una solución. «Nuestros técnicos completan sus informes en papel y luego alguien los vuelve a teclear en la oficina» es un problema: deja la puerta abierta a varias respuestas, algunas más sencillas.

Después, convierta cada problema en un objetivo medible: tiempo invertido, número de errores, plazos. Una vez que el software esté en servicio, sabrá si el proyecto ha cumplido su promesa.

2. Describir el funcionamiento actual

Explique cómo se trabaja hoy, paso a paso: quién hace qué, con qué herramientas y con qué archivos. Anote los puntos de fricción: datos que se vuelven a teclear, esperas, errores recurrentes.

Busque las excepciones: las frases que empiezan por «salvo cuando…» suelen esconder las reglas de negocio más importantes.

3. Identificar a los usuarios y sus roles

Enumere los tipos de usuario que utilizarán la herramienta: dirección, ventas, contabilidad, clientes, socios. Para cada uno, precise lo que puede ver o hacer, y dónde trabaja: en la oficina, en desplazamiento, sobre el terreno.

Estas respuestas pesan mucho en el diseño. En el CRM/ERP de un bufete de abogados de Sídney, un proyecto dirigido por nuestro fundador, dieron lugar a dos decisiones estructurales: accesos distintos según el rol de cada persona y aplicaciones para escritorio, iOS y Android.

4. Redactar los requisitos en forma de escenarios

Es el corazón del documento de requisitos. En lugar de una lista de funcionalidades, describa situaciones concretas con una fórmula sencilla, la historia de usuario (user story) de los métodos ágiles: «Como [rol], quiero [acción], para [beneficio]». Por ejemplo: «Como comercial, quiero convertir un presupuesto firmado en pedido con un clic, para no tener que volver a teclear nada».

Asigne a cada escenario un criterio de éxito: ¿cómo sabrá que funciona? Estos criterios alimentan directamente las pruebas de aceptación.

5. Priorizar, sin declararlo todo «imprescindible»

Clasifique cada escenario: imprescindible para la primera versión, importante, deseable o descartado por esta vez. Es el espíritu del método MoSCoW. Si todo es imprescindible, nada lo es, y la primera versión no llega nunca.

Anote también lo que queda fuera del alcance: esta breve lista evita muchos malentendidos y protege su presupuesto.

6. Enumerar las restricciones, los datos y las herramientas que hay que conectar

Reúna todo lo que delimita el proyecto:

• las herramientas existentes: las que hay que conservar, sustituir o conectar al futuro software (contabilidad, correo electrónico, CRM, pagos);
• los datos existentes: archivos, hojas de cálculo o software antiguo que migrar, con un ejemplo de cada uno;
• la seguridad y la confidencialidad: datos sensibles, permisos de acceso, registro de quién hizo qué, el RGPD europeo;
• las plataformas: equipo de escritorio, teléfono o tableta, y la posible necesidad de trabajar sin conexión;
• el calendario y el presupuesto: la fecha prevista para una primera versión y un rango orientativo.

Indicar un rango de presupuesto no es una trampa: permite al proveedor proponer una solución adaptada a su situación, en lugar de una respuesta ideal pero inalcanzable.

7. Someterlo a revisión y mantenerlo vivo

Pida que revisen el documento los usuarios clave y la persona que tomará la decisión. Después, féchelo y numere sus versiones: cambiará durante el proyecto, y es normal.

Una plantilla de documento de requisitos de software para copiar

Este es el índice que recomendamos. Unas pocas líneas por sección bastan para empezar.

1. Contexto: su empresa, su actividad, lo que motiva el proyecto.
2. Objetivos: lo que debe cambiar y cómo medirlo.
3. Situación actual: el proceso de hoy, las herramientas, los puntos de fricción.
4. Usuarios y roles: quién usa la herramienta y qué puede ver o hacer cada persona.
5. Escenarios: los requisitos ordenados por prioridad, con sus criterios de éxito.
6. Reglas de negocio: cálculos, estados, excepciones, documentos que generar.
7. Datos e integraciones: lo que hay que migrar y las herramientas que hay que conectar.
8. Restricciones: seguridad, confidencialidad, plataformas, alojamiento, accesibilidad.
9. Fuera del alcance: lo que el proyecto no hará, o todavía no.
10. Calendario y presupuesto: las fechas previstas y el presupuesto orientativo.
11. Organización: el responsable del proyecto, los usuarios clave, quién aprueba qué.

En un anexo, adjunte ejemplos reales, anonimizados si es necesario: presupuestos, facturas, formularios, capturas de pantalla de sus hojas de cálculo.

Cinco errores que evitar en un documento de requisitos

• Imponer una solución técnica sin explicar la necesidad. Así renuncia a las ideas del proveedor, que a veces son más sencillas.
• Querer abarcarlo todo. Un documento demasiado largo no se lee. Unos escenarios claros valen más que una lista interminable de funcionalidades.
• Usar palabras vagas. «Sencillo», «rápido», «intuitivo»: cada uno las entiende a su manera. Sustitúyalas por un criterio verificable, por ejemplo «un usuario nuevo crea su primera ficha sin ninguna formación».
• Redactarlo en solitario, sin los usuarios. Solo ellos conocen las excepciones y los trucos que aplican a diario.
• Olvidar lo que viene después. Precise desde el principio quién hará evolucionar el software, quién lo alojará y a quién pertenecerán el código y los datos.

Completar el documento con un taller de alcance

Incluso un documento bien redactado deja preguntas abiertas. Un taller de alcance las resuelve antes de que empiece el desarrollo: unas pocas sesiones de trabajo que reúnen al responsable del proyecto, a los usuarios clave y al proveedor. Sirven para tres cosas:

1. Plantear las preguntas que faltan: casos límite, volúmenes, reglas no escritas.
2. Sopesar cada requisito frente a su costo y buscar algo más sencillo.
3. Fijar el orden de las entregas, empezando por una primera versión útil.

Realizamos este trabajo en forma de auditoría, que proponemos al final de la llamada exploratoria y llevamos a cabo previo presupuesto. Usted sale con un alcance claro y una propuesta presupuestada para su software a medida. Y si está comparando varias ofertas, estos son nuestros consejos para elegir un proveedor informático.

Preguntas frecuentes

¿Quién debe redactar el documento de requisitos?

Usted, con sus equipos: es su actividad la que describe el documento. Designe a una persona que lleve la redacción y consulte a los usuarios. Un proveedor puede ayudarle a estructurarlo, pero la necesidad debe venir de la empresa.

¿Qué extensión debe tener un documento de requisitos de software?

Lo más breve posible, siempre que los objetivos, los escenarios y las prioridades queden claros. Para una primera versión, unas pocas páginas bien estructuradas suelen bastar.

¿Es compatible un documento de requisitos con los métodos ágiles?

Sí. Los métodos ágiles no eliminan la definición del alcance: evitan congelarlo todo al principio. El documento fija los objetivos, el alcance y las prioridades; el detalle de cada funcionalidad se precisa en cada iteración, con demostraciones periódicas para corregir el rumbo lo antes posible.

En resumen

Un buen documento de requisitos de software no describe una solución. Describe su problema, sus usuarios, sus escenarios y sus prioridades, con palabras que todos entienden. Parta de cómo se trabaja realmente, sea breve, priorice con decisión y haga de él un documento vivo.

¿Tiene un primer borrador, o solo unas notas? Es suficiente para empezar. Reserve una llamada exploratoria gratuita de 30 minutos: repasamos sus notas con usted y buscamos la respuesta más sencilla a su necesidad.