Requisitos de un software: cómo escribirlos sin ser técnico
Los requisitos de un software describen qué debe hacer (funcionales) y en qué condiciones (no funcionales). Se escriben con situaciones reales y sus excepciones, perfiles, datos, integraciones y restricciones, con un criterio para comprobar cada uno, y se priorizan por fases.
Los requisitos de un software son la descripción de lo que tiene que hacer (requisitos funcionales) y de las condiciones en que tiene que hacerlo (requisitos no funcionales: quién accede, con qué seguridad, desde qué equipos, con cuántos datos). No hace falta un documento técnico para escribirlos: bastan tus casos reales, los perfiles que lo usarán, los datos que ya tienes y las restricciones que no se pueden saltar. Bien escritos, permiten comparar presupuestos y evitan la sorpresa de recibir algo que no era lo que necesitabas.
Requisitos funcionales y no funcionales, con ejemplos
Los funcionales dicen qué hace el sistema; los no funcionales, cómo tiene que comportarse mientras lo hace. Los segundos suelen ser los que más se olvidan y los que más encarecen un proyecto cuando aparecen tarde.
| Tipo | Ejemplo |
|---|---|
| Funcional | Cuando un cliente acepta un presupuesto, se crea el pedido con las mismas líneas. |
| Funcional | El conductor puede subir un gasto con una foto del ticket desde el móvil. |
| Funcional | Dirección ve cada mañana lo facturado, lo cobrado y lo pendiente. |
| No funcional: acceso | Cada comercial ve solo sus clientes; dirección ve todos. |
| No funcional: entorno | Tiene que funcionar en los ordenadores que ya hay en el almacén. |
| No funcional: continuidad | Si el sistema falla, los datos se pueden restaurar desde una copia. |
| No funcional: volumen | Debe manejar el histórico de facturas de varios años sin volverse lento. |
Un ejemplo real de requisito de entorno: un TPV que tiene que seguir funcionando en ordenadores antiguos, con Windows 7 y Chrome 109, condiciona qué tecnología puede usarse en la interfaz. Si ese dato aparece a mitad del proyecto, obliga a rehacer trabajo.
Cómo escribir los requisitos sin ser técnico
- Parte de situaciones reales, con la forma «cuando pasa esto, quiero que ocurra aquello». Cinco o seis del día a día valen más que cincuenta funciones sueltas.
- Incluye las excepciones: el cliente que paga en dos veces, el pedido que se cancela a medias, el producto sin stock. Ahí es donde un programa genérico suele fallar.
- Describe los perfiles: quién usará el sistema, qué hace cada uno y qué no debe ver.
- Cuenta qué datos tienes hoy y dónde están: hojas de cálculo, un programa antiguo, papel. Condiciona la migración.
- Nombra lo que tiene que conectarse: tu web, la pasarela de pago, el programa de tu asesor.
- Da órdenes de magnitud: cuántos usuarios, cuántos pedidos al mes, cuánto histórico.
- Apunta las restricciones que no se negocian: equipos, horarios en los que no se puede parar, requisitos legales de tu actividad.
Lo que no conviene poner en los requisitos
- Soluciones en lugar de problemas. «Quiero un botón que exporte a Excel» esconde el problema real, que quizá es «necesito enviar cada lunes el informe a mi socio». El proveedor puede resolverlo mejor si conoce el porqué.
- Palabras que no se pueden comprobar. «Rápido», «fácil» o «intuitivo» no dicen nada hasta que se concretan: «el comercial prepara un presupuesto sin salir de la ficha del cliente».
- «Todo lo que hace el programa actual». Nadie sabe qué es todo. Lista lo que se usa de verdad.
Criterios de aceptación: cómo saber que un requisito está cumplido
Cada requisito importante necesita una forma de comprobar que se ha cumplido. Para «el presupuesto aceptado pasa a pedido» podría ser: «con un presupuesto de prueba de tres líneas, al aceptarlo aparece un pedido con las mismas tres líneas, el mismo cliente y el mismo total». Sin criterios así, la entrega se discute por opiniones. Cómo se reflejan en el contrato lo explicamos en contrato de desarrollo de software a medida.
Priorizar: qué entra en la primera fase
Clasifica cada requisito en imprescindible, importante o deseable. La primera fase debería cubrir los imprescindibles del proceso que más tiempo quita, y nada más. Lo que no entra no se pierde: se decide después, con el sistema ya en marcha y datos reales. Cómo recortar sin quitar lo que no se puede quitar está en MVP en desarrollo de software, y qué recibes en cada fase, en fases de un proyecto de software.
Del papel al prototipo
Los requisitos escritos tienen un límite: cada persona se imagina una pantalla distinta. Por eso, en nuestros proyectos, el análisis termina en un diagnóstico y una propuesta cerrada, y antes de programar se enseña un prototipo navegable. Ver las pantallas con ejemplos de tu día a día descubre requisitos que nadie había escrito, cuando cambiarlos todavía es barato.
Lista para empezar
- Cinco o seis situaciones reales, con sus excepciones.
- Los perfiles de usuario y qué puede ver y hacer cada uno.
- Los datos que existen hoy y dónde están.
- Los programas con los que hay que conectarse.
- Volúmenes aproximados y crecimiento esperado.
- Restricciones: equipos, horarios, requisitos legales de tu actividad.
- Qué sería un éxito dentro de un año.
Con esa lista, pedir presupuestos comparables es mucho más fácil; qué debe traer cada uno está en presupuesto de desarrollo de software.
Preguntas frecuentes
¿Qué es un requisito no funcional?
Una condición que el sistema debe cumplir mientras hace su trabajo: quién puede acceder, desde qué equipos funciona, cuántos datos maneja sin volverse lento o cómo se recupera si algo falla. No describe una función, sino cómo debe comportarse.
¿Hace falta un documento de requisitos para pedir presupuesto?
No hace falta un documento formal, pero sí lo esencial: situaciones reales, perfiles, datos, integraciones y restricciones. Sin eso, cada proveedor presupuesta algo distinto y los precios no se pueden comparar.
¿Quién escribe los requisitos, la empresa o el proveedor?
Los dos. La empresa conoce el proceso y sus excepciones; el proveedor sabe qué preguntar y cómo convertirlo en algo que se pueda construir y comprobar. El resultado debería validarlo quien va a usar el sistema.
¿Qué pasa si los requisitos cambian durante el proyecto?
Es normal que cambien. Trabajando por fases, los cambios se incorporan en la siguiente con su coste y su plazo a la vista, en lugar de descubrirse al final.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.