Para preparar el encargo de un software, escribe un documento de requisitos de dos o tres páginas. Debe explicar el problema, quién usará el programa, qué tareas debe resolver por orden de importancia y con qué otros programas se conecta. No hace falta lenguaje técnico. Con ese documento, cada proveedor presupuesta lo mismo y puedes comparar.
Para qué sirve el documento de requisitos.
Es la base de todo lo demás. Sin él, cada proveedor imagina un proyecto distinto y los presupuestos no se pueden comparar.
También es el punto de partida del desarrollo. Las metodologías públicas, como Métrica versión 3, sitúan el análisis antes del diseño y la construcción. Tu documento alimenta ese análisis.
Y forma parte del proyecto. Para la ley, el programa de ordenador incluye también su documentación preparatoria. Conviene que quede claro de quién es, como explicamos en de quién es el código fuente.
Las secciones, una a una.
El problema. Qué pasa hoy y por qué quieres cambiarlo. Por ejemplo, que los pedidos se apuntan en tres sitios distintos y se pierden.
Los usuarios. Quién usará el programa y cuántas personas. No es lo mismo una herramienta para dos administrativos que una app para cientos de clientes.
Las tareas. Qué debe poder hacer cada usuario, ordenado por importancia. Es la parte central del documento.
Los datos. Qué información se guarda y si incluye datos personales. El RGPD pide pensar en la protección desde el momento en que se diseña el tratamiento.
Las conexiones. Con qué programas debe hablar, como el de facturación, la web o el correo.
Las condiciones. Plazos que no se pueden mover, dispositivos que se usarán y requisitos de accesibilidad. Si te piden una referencia de accesibilidad, la versión vigente de las pautas del W3C es WCAG 2.2.
Cómo escribir un buen requisito.
Un buen requisito se puede comprobar. «El programa será fácil de usar» no se puede comprobar. «Un comercial puede crear un presupuesto desde el móvil en una visita» sí.
Escribe cada requisito desde el punto de vista de quien lo usa. Quién hace qué y para qué. Así se entiende sin conocimientos técnicos.
Marca la prioridad de cada uno. Una forma sencilla es separar lo imprescindible, lo importante y lo que estaría bien tener. La primera versión debería llevar solo lo imprescindible.
Lo que no hace falta incluir.
No tienes que elegir la tecnología, el lenguaje de programación ni la base de datos. Eso lo propone el proveedor, y es una de las cosas que puedes comparar entre propuestas.
Tampoco hace falta diseñar las pantallas. Si tienes ejemplos de programas o apps que te gustan, adjúntalos. Ayudan más que un dibujo detallado.
Errores frecuentes.
Un error frecuente es describir la solución en lugar del problema. «Quiero una app con un botón rojo» limita las opciones. «Necesito que los técnicos avisen de una avería desde la obra» deja espacio a mejores ideas.
Otro error es meterlo todo en la primera versión. Un documento con cien funciones al mismo nivel no ayuda a decidir.
El tercero es olvidar a quien hace el trabajo. Habla con las personas que usarán el programa antes de escribir. Ellas saben dónde se pierde el tiempo.
Una plantilla para empezar.
| Sección | Qué escribir | Extensión orientativa |
|---|---|---|
| Problema | Qué pasa hoy y qué quieres conseguir | Un párrafo |
| Usuarios | Perfiles y número aproximado | Una lista |
| Tareas | Qué hace cada usuario, con prioridad | Una lista por perfil |
| Datos | Qué se guarda y si hay datos personales | Un párrafo |
| Conexiones | Programas con los que debe hablar | Una lista |
| Condiciones | Plazos, dispositivos, accesibilidad | Una lista |
Dos o tres páginas bastan para empezar. Con el proveedor elegido, ese documento se amplía en la fase de análisis.
Qué pasa después.
Con el documento, pide propuesta a dos o tres proveedores. Para elegir, sigue nuestra guía para elegir empresa de desarrollo de software. Y para ver cómo se convierte en un proyecto, lee las fases del desarrollo de software.
Si el proyecto es una app, tienes una lista específica en requisitos para crear una app. El documento acabará en el contrato como anexo de alcance, como contamos en qué debe incluir un contrato de desarrollo de software.
Un ejemplo de proyecto pensado desde el proceso del cliente es el CRM de Nutrivazquez, que organiza las funciones alrededor del trabajo real del centro. Puedes verlo en su ficha. Cada fase de nuestros proyectos tiene su presupuesto cerrado, y la trayectoria del fundador suma más de 100 proyectos desde 2013.
Preguntas frecuentes.
No. Basta con explicar bien tu negocio y lo que quieres conseguir. El lenguaje técnico lo pone el proveedor.
Para empezar, dos o tres páginas. Se amplía después, con el proveedor elegido.
Se parece. El pliego es más formal y se usa sobre todo en contratación pública. Para una pyme basta un documento de requisitos claro.
Sí. Puedes pedir al proveedor que lo revise contigo antes de presupuestar. Es una buena forma de ver cómo trabajan.
