Documento de requisitos de software: la guía del founder no técnico para hacer uno que reciba cotización
Qué entra, qué se queda fuera, y la prueba para saber cuándo el documento está listo para mandar a un software studio.
Un martes por la tarde, una founder de una fintech en Ciudad de México abrió el correo y leyó tres cotizaciones que había pedido a tres software studios distintos, todas sobre el mismo documento de 14 páginas que había pasado un fin de semana entero escribiendo. La primera cotización decía 950 mil pesos en cuatro meses. La segunda decía 2,2 millones de pesos en siete meses. La tercera no llegó como cotización. Llegó como una lista de 27 preguntas y una frase: “antes de cotizar necesitamos entender más.”
Los tres studios leyeron el mismo documento y llegaron a tres decisiones diferentes. No porque uno tuviera razón y los otros no. Porque el documento no estaba decidiendo nada por ellos.
Ese es el problema central que un documento de requisitos resuelve cuando funciona, y el problema que crea cuando se escribe como si fuera una redacción de secundaria, o peor, como si fuera la especificación de un sistema bancario de 1998. Para el founder no técnico que está a punto de contratar la primera versión de un producto, el documento de requisitos no es un ejercicio académico. Es la pieza que define cuánto cuesta, cuánto tarda y qué llega.
Esta guía cubre qué incluir, qué dejar fuera y cómo saber cuándo el documento está listo para salir por la puerta.
Qué es un documento de requisitos de software, en una frase
Un documento de requisitos de software describe lo que un software necesita hacer (y lo que no necesita hacer) con suficiente nivel de detalle para que un equipo de desarrollo pueda estimarlo, contratarlo y construirlo sin rondas infinitas de aclaración.
Es una definición modesta a propósito. El documento no es la especificación completa del producto. No es el contrato. No es el roadmap. Es el instrumento que une el problema que tú describes con claridad (porque es tu negocio) con el sistema que otra persona va a construir (porque ese es su oficio). Todo lo que el documento tiene que hacer es que ese puente sea barato de cruzar.
Cuando funciona, tres studios leen el documento y vuelven con cotizaciones próximas en plazo, alcance y precio, con preguntas puntuales en lugar de listas de 27 ítems. Cuando no funciona, recibes tres planes para tres productos distintos.
Por qué el modelo SRS de la universidad no te sirve
El término técnico es SRS: Software Requirements Specification. Es el documento que los programas de ingeniería de software llevan enseñando a escribir desde los años 80. La mayoría de las plantillas que aparecen en la primera página de Google cuando buscas “documento de requisitos de software” son variaciones de ese patrón: índice de 14 secciones, requisitos funcionales y no funcionales separados, diagrama de casos de uso, glosario, matriz de trazabilidad.
Ese modelo se diseñó para una realidad que no es la tuya. Se hizo para proyectos contratados por grandes empresas, con plazos de dos a cinco años, equipos internos de QA que van a probar contra la especificación y auditorías regulatorias después de la entrega. Para una fintech early-stage, una clínica que está armando el back office o un marketplace de nicho que lanza la primera versión, ese formato falla por tres motivos.
Es demasiado largo. Un SRS bien hecho tiene 40 a 120 páginas. Ningún software studio va a leer 80 páginas antes de cotizar. Van a hacer skim de las primeras diez, identificar tres puntos confusos y mandarte la lista de preguntas. Pasaste un fin de semana y estás en el mismo lugar.
Está hecho para validar la entrega, no para vender el proyecto internamente. El SRS tradicional documenta “qué va a hacer el sistema” para que después alguien pueda probar si lo hizo. Eso todavía no te hace falta. Lo que te hace falta es que tres studios se pongan de acuerdo en cuánto cuesta lo que quieres.
Pide precisión técnica que no tienes. Requisitos no funcionales, restricciones de arquitectura, modelo de datos conceptual. Si supieras escribir eso bien, no estarías contratando un studio. El intento de sonar técnica produce documentos que están equivocados (un studio se da cuenta) o demasiado vagos (todos se dan cuenta).
La alternativa no es no escribir nada. Es escribir un documento más corto, más opinado y dirigido a un lector específico: la persona que va a cotizar tu proyecto.
Los 5 bloques que caben en 8 páginas
El documento que funciona para una founder no técnica tiene cinco bloques. Cabe en seis a ocho páginas. Se escribe en prosa, con listas donde la lista ayuda. Cada bloque tiene un propósito declarado.
Bloque 1: El problema, en una página como mucho. Quién es el usuario, cuál es el dolor real y por qué el dolor existe ahora. No es el pitch deck. Es la descripción honesta de la situación: la operación manual que estás reemplazando, la hoja de cálculo que se rompió, el proceso que vive en WhatsApp y necesita volverse producto. Quien va a cotizar usa esa página para calibrar todo lo que viene después. Si el dolor parece pequeño, el presupuesto parece grande. Si el dolor es obvio, el resto del documento recibe el beneficio de la duda.
Bloque 2: El usuario, en una página o menos. Un párrafo por persona, máximo tres personas. Para cada una: qué hace hoy, qué necesita que el producto haga y dónde lo usa (mobile, desktop, en el mostrador, en casa). Aquí se responden preguntas como “¿tiene que funcionar en el celular?” y “¿necesita acceso offline?” sin convertirse en requisitos no funcionales. Se vuelven hechos de uso.
Bloque 3: El alcance, en forma “entra/queda fuera”, en dos a tres páginas. Esta es la parte más valiosa del documento y la que más founders subestiman. En vez de listar todo lo que el sistema va a hacer, divide en dos columnas: qué entra en la primera versión y qué queda fuera (pero sabes que existe). La columna “fuera” es lo que le da seguridad al studio para cotizar la columna “dentro”. Sin ella, cada studio cotiza como si el alcance fuera infinito, porque es lo que los founders normalmente hacen con el alcance. Ítems típicos de la columna “dentro” son funcionalidades concretas: alta de cliente, generación de presupuesto, exportación a PDF, integración con Stripe. Ítems típicos de la columna “fuera” son funcionalidades que existirán algún día pero no ahora: app nativa, dashboard de BI, integración con el ERP contable, plan gratuito.
Bloque 4: Los criterios de listo, en una página. Para la primera versión, tres a cinco frases que describen lo que tiene que ser verdad el día del lanzamiento. “Un agente inmobiliario puede dar de alta un inmueble, generar una propuesta en PDF y enviársela a un cliente en menos de cinco minutos.” “La dirección puede ver, a fin de mes, cuántas propuestas se convirtieron en contrato.” Estos criterios funcionan como contrato silencioso: no estás aceptando el producto si alguno todavía no pasa. También ayudan a cotizar, porque le dicen al studio dónde está el listón. Una frase de criterio como “el sistema necesita 99,99% de uptime” es cara. “El sistema no puede caerse en horario comercial de Ciudad de México” es más barato y dice casi lo mismo para tu negocio.
Bloque 5: Restricciones reales, en media página. Tiempo, dinero, regulación. Cuándo necesitas estar en el aire (y por qué). Cuál es el techo de presupuesto (prepárate para responder honestamente; las cotizaciones llegan más cerca de la realidad cuando el techo está sobre la mesa). Qué regulación aplica (GDPR si operas en Europa; PCI si vas a guardar tarjetas; HIPAA si es salud en EE. UU.; regulación de la CNBV o la SBS si es fintech regulada). Es el bloque más corto y el que más retrabajo ahorra. Un studio que sabe que tienes tres meses hasta la próxima ronda va a cotizar diferente que uno que piensa que tienes un año.
Cinco bloques. Seis a ocho páginas. Escrito un fin de semana sin estrés, o dos tardes con foco. Ese es el documento que recibe cotización.
Cómo documentar requisitos de forma simple
La respuesta corta: describes cada bloque en una reunión de 15 minutos contigo mismo antes de escribir. Abres un documento en blanco, pones el nombre del bloque arriba y respondes en voz alta, grabando o escribiendo en la forma que salga. El texto pulido viene después.
La trampa de la escritura “técnica” es lo que mata la mayoría de los documentos. Los founders no técnicos intentan sonar como ingenieros porque asumen que ese es el idioma que el studio espera. No lo es. Los software studios buenos leen el documento en voz alta como si fuera una reunión comercial. Confían más en una descripción clara del problema que en un diagrama de UML mal dibujado. Si te quedas entre “sonar profesional” y “ser literal sobre lo que está pasando”, elige siempre lo segundo.
La segunda trampa es querer cubrir todo. No vas a poder. No se puede. El documento de requisitos de la primera versión es, por diseño, un instrumento incompleto. Describe la primera versión, no el producto final. Cada decisión que no tomaste ahora se convierte después en una pregunta del studio, y eso es normal. Lo que quieres evitar es el documento que parece completo pero es vago, porque ese genera preguntas peores: preguntas que parecen detalle y en realidad son alcance.
La tercera trampa es dejar el documento parado semanas porque está “casi listo”. La versión 0.9 de quien es dueña del problema le gana siempre a la versión 1.0 imaginaria. Si el documento cumple los cinco bloques, está listo.
La prueba de cotización: tres señales de que el documento está listo
No hay checklist objetiva para “documento listo”, pero hay tres señales empíricas que aparecen una y otra vez.
Señal 1: Puedes leer el documento en voz alta sin abrir paréntesis. Si tienes que explicar una frase mientras la lees, la frase no está lista. Reescríbela. La regla aplica a cualquier párrafo.
Señal 2: Un amigo de tu sector, sin conocimiento técnico, puede leer el documento y decir “entiendo qué va a hacer este producto”. Si no puede, el studio tampoco. La prueba aplica a los Bloques 1 a 3 (problema, usuario, alcance).
Señal 3: Puedes listar tres cosas que quedaron fuera intencionalmente. Si no puedes, no decidiste lo suficiente. Vuelve al Bloque 3 y saca más cosas. “Todo entra en la primera versión” es lo que produce cotizaciones infladas y cronogramas que se escurren.
Cuando aparecen las tres señales, el documento está listo para salir. Mándalo a dos a cuatro studios al mismo tiempo. Vas a aprender más de la diferencia entre las cotizaciones que de cualquier cotización individual.
Dónde termina el documento de requisitos y empieza el contrato
Confundir el documento de requisitos con el contrato es la versión más cara de este error. El documento de requisitos es un instrumento de comunicación. No obliga a nadie a nada. Describe el producto que quieres y el problema que resuelve.
El contrato de desarrollo de software es el instrumento legal que regula la relación. Cubre plazo, precio, condiciones de pago, propiedad del código, garantía y qué pasa si una de las partes rompe la promesa. Generalmente el contrato anexa el documento de requisitos por referencia, pero el contrato gobierna, no el requisito.
La separación importa porque los dos documentos tienen lectores distintos. El documento de requisitos lo lee el equipo técnico que va a construir. El contrato lo lee el área legal (tuya y de ellos) y tú, en el momento de firmar. Si intentas meter una cláusula contractual dentro del documento de requisitos, confundes al studio. Si intentas describir funcionalidad dentro del contrato, creas un documento legal que envejece en dos semanas.
La regla práctica: el documento de requisitos describe el producto. El contrato describe la relación. El alcance vive en el requisito. El precio, en el contrato. Los cambios que ocurren durante la construcción viven en un tercer documento (normalmente una minuta de reunión o un ticket en el sistema del studio), y periódicamente disparan adendas al contrato.
Ese trío (requisito, contrato, minuta) es lo que sostiene un proyecto sin ruido. Y también es donde el análisis de fit con el studio realmente sucede: la forma en que el studio responde a tu documento de requisitos te dice más sobre cómo va a trabajar contigo que cualquier presentación comercial.
Preguntas frecuentes
¿Qué significa “requisitos”?
En contexto de software, los requisitos son descripciones de lo que el sistema necesita hacer (requisitos funcionales) y de las condiciones bajo las que tiene que hacerlo (requisitos no funcionales, como desempeño, seguridad, disponibilidad). Para un founder no técnico, la traducción práctica es: “qué entrega el producto” y “bajo qué límites lo entrega”.
¿Cómo se documentan requisitos de forma simple?
En cinco bloques cortos: el problema, el usuario, el alcance (entra/fuera), los criterios de listo y las restricciones reales (tiempo, dinero, regulación). Seis a ocho páginas en total. En prosa, no en diagramas. Escrito para un lector específico: el studio que va a cotizar. Detalle en “Los 5 bloques que caben en 8 páginas” arriba.
¿El documento de requisitos es lo mismo que un PRD o una especificación funcional?
Son primos cercanos, no la misma cosa. El documento de requisitos describe lo que el sistema necesita hacer. El PRD (Product Requirements Document) es más común dentro de empresas con equipo interno de producto y describe qué resuelve el producto y para quién, normalmente sin detalle técnico. La especificación funcional profundiza en pantallas, flujos y reglas de negocio. Para la primera contratación con un studio, el documento de requisitos corto descrito aquí normalmente es suficiente; el PRD y la especificación funcional aparecen después, cuando el producto ya está corriendo y tú o el studio necesitan coordinar más detalle.
¿Cuáles son los 4 tipos de documentos que aparecen en una compra de software?
En una compra típica de software a la medida: el brief (una o dos páginas que usas para presentarte a studios y descubrir quién vale la pena platicar), el documento de requisitos (este, seis a ocho páginas), el contrato (instrumento legal entre tú y el studio elegido) y el SOW (Statement of Work, que en algunas estructuras contractuales reemplaza o complementa al documento de requisitos como anexo del contrato). Los cuatro tienen lectores diferentes y propósitos diferentes; mezclarlos es el error más caro del proceso.
¿Puedo pedirle al studio que escriba el documento de requisitos por mí?
Puedes, y a veces es lo correcto (especialmente si ya tienes un studio de confianza y vas a contratar un discovery formal). Pero el resultado suele ser mejor cuando el documento sale de tu cabeza primero, aunque sea en forma cruda. Eres la única persona que conoce el problema con profundidad. El studio va a mejorar la forma. No puede inventar el problema.
¿Cuándo el documento de requisitos necesita volverse una especificación detallada?
Cuando el proyecto pasa de la primera versión. Para la primera versión, el documento corto alcanza porque la mayor parte del detalle se descubre durante la construcción en conversaciones con el studio. A partir de la segunda versión (o de un pivote significativo), los bloques del documento se separan en artefactos mayores: el alcance se vuelve backlog, los criterios de listo se vuelven tests, las restricciones se vuelven política técnica documentada.