Cómo escribir los requerimientos de tu sistema sin ser técnico (plantilla incluida)

En este artículo

1. ¿Qué son los requerimientos de un sistema?
2. Paso 1: escribe el objetivo en una frase
3. Paso 2: lista quién va a usar el sistema
4. Paso 3: describe las funciones como historias de usuario
5. Paso 4: escribe las reglas del negocio
6. Paso 5: define reportes e integraciones
7. Paso 6: di qué queda fuera
8. Errores comunes al escribir requerimientos
9. Plantilla de requerimientos para copiar
10. En resumen
11. Preguntas frecuentes

«Quiero un sistema para controlar mis ventas». Con esa frase empiezan muchas conversaciones, y está bien como punto de partida. El problema es que diez programadores la entenderían de diez maneras distintas, y cada uno te daría un precio diferente por algo diferente.

Los requerimientos son la forma de convertir esa idea en algo que todos entiendan igual. No necesitas ser técnico para escribirlos: necesitas conocer tu negocio, que es justamente lo que tú sabes mejor que nadie. Esta guía te explica qué incluir, cómo escribirlo con ejemplos y qué errores evitar, y al final te deja una plantilla lista para copiar. Es la misma estructura que usamos en CONIT para ordenar los proyectos que nos piden.

¿Qué son los requerimientos de un sistema?

Los requerimientos son la lista de lo que el sistema debe hacer, quién lo va a usar y qué reglas debe seguir. Sirven para tres cosas: para cotizar, para construir y para comprobar al final que te entregaron lo que pediste.

Se dividen en dos grupos:

• Funcionales: lo que el sistema hace. «Registrar un pedido», «emitir una boleta electrónica», «enviar un recordatorio de pago dos días antes del vencimiento».
• No funcionales: cómo lo hace. «Debe funcionar en el celular», «cada vendedor ve solo sus clientes», «copias de seguridad diarias», «la búsqueda de un cliente debe responder en segundos».

El estándar internacional sobre ingeniería de requerimientos, ISO/IEC/IEEE 29148, pide que cada requerimiento sea necesario, claro, verificable y sin ambigüedades. Traducido a lenguaje de negocio: si no puedes comprobar si se cumple, no está bien escrito.

Paso 1: escribe el objetivo en una frase

Antes de listar funciones, escribe qué problema quieres resolver y cómo sabrás que se resolvió. Esa frase guía todas las decisiones que vienen después.

Compara:

• Vago: «Quiero un sistema para mi distribuidora».
• Útil: «Quiero que los vendedores registren los pedidos desde el celular para que el almacén los despache el mismo día sin pedirlos por WhatsApp, y saber cada lunes cuánto vendió cada uno».

La segunda frase ya dice quién usa el sistema, qué hace, qué problema elimina y qué reporte necesitas. Con eso un proveedor puede proponerte una primera versión.

Paso 2: lista quién va a usar el sistema

Cada perfil de usuario tiene necesidades y permisos distintos, y eso cambia mucho el sistema. Haz una lista de quiénes lo usarán y qué deben poder hacer.

La columna de lo que no debe poder hacer es tan importante como la otra. Si tu sistema maneja datos personales, el reglamento de la Ley 29733 exige documentar el control de acceso y los privilegios de cada usuario (DS 016-2024-JUS, artículo 46, revisado el 10 de octubre de 2026). Lo explicamos en roles y permisos en un sistema.

Paso 3: describe las funciones como historias de usuario

La forma más clara de escribir una función es como historia de usuario: «Como [perfil], quiero [acción] para [beneficio]». Obliga a pensar en quién la usa y por qué la necesita.

Ejemplos para una distribuidora:

1. Como vendedor, quiero registrar un pedido eligiendo productos de una lista con su stock, para no vender lo que no hay.
2. Como almacén, quiero ver los pedidos del día ordenados por hora, para despachar primero los más antiguos.
3. Como caja, quiero registrar un pago con Yape o transferencia, para que el pedido quede como pagado.
4. Como gerente, quiero un reporte de ventas por vendedor y por mes exportable a Excel, para calcular comisiones.

Cada historia necesita criterios de aceptación: las condiciones para darla por terminada. Para la primera: «El vendedor solo ve productos con stock mayor a cero; si pide más unidades de las que hay, el sistema le avisa y no deja guardar». Así, cuando revises el sistema, sabrás exactamente qué probar. Esta forma de trabajar viene de los métodos ágiles, donde la lista ordenada de lo que hay que construir se llama product backlog (Guía de Scrum).

Paso 4: escribe las reglas del negocio

Las reglas son lo que hace único a tu sistema. Escríbelas una por una, con ejemplos y números.

• «Si un cliente tiene facturas vencidas por más de 30 días, no se le puede registrar un pedido nuevo sin aprobación del gerente».
• «Los pedidos de más de S/ 5,000 necesitan aprobación».
• «El descuento máximo que puede dar un vendedor es 5 %».
• «Un pedido solo se puede anular antes de despacharse».

Las reglas que no se escriben se descubren tarde, cuando el sistema ya está programado, y corregirlas cuesta más.

Paso 5: define reportes e integraciones

Los reportes y las integraciones son lo que más se olvida y lo que más mueve el presupuesto. Escribe qué información quieres ver y con qué otros servicios debe conectarse el sistema.

Para los reportes, indica qué datos, agrupados cómo, con qué filtros y en qué formato. «Ventas por vendedor, por mes, con filtro de fechas, exportable a Excel» es un buen requerimiento.

Para las integraciones, lista cada servicio: pasarela de pagos (Culqi, Izipay, Mercado Pago), facturación electrónica, WhatsApp, correo automático, un sistema contable que ya usas. Cada integración tiene sus propias tarifas, que pagas al proveedor del servicio y no al desarrollador; por ejemplo, Culqi publica sus comisiones por venta en su página de precios. Pídele al desarrollador que te diga cuáles conviene incluir en la primera versión.

Lo que hacemos en CONIT

Construimos sistemas a medida y páginas web para empresas de todo el Perú, y antes de cotizar te ayudamos a ordenar los requerimientos con tus propios ejemplos. Así nacieron el catálogo técnico con cotización de Representaciones 88 y la consulta de cuotas por DNI de ESEIT. Conoce el servicio de sistemas a medida.

Paso 6: di qué queda fuera

Tan importante como lo que el sistema hace es lo que no hace, al menos en la primera versión. Una sección de «fuera de alcance» evita malentendidos y discusiones al final.

Ejemplos: «La primera versión no incluye app para celular; se usará desde el navegador», «No incluye facturación electrónica; se emitirá desde el sistema actual», «No incluye la carga de pedidos anteriores a 2025». Si después decides incluir algo, se cotiza como una etapa nueva. Empezar con poco es una buena estrategia: lo explicamos en qué es un MVP.

Errores comunes al escribir requerimientos

Los errores más caros son los que dejan espacio a interpretaciones. Estos son los que más vemos:

1. Palabras vagas. «Fácil de usar», «rápido», «completo». No se pueden verificar.
2. Describir la solución en lugar del problema. «Quiero un botón verde» en vez de «quiero aprobar pedidos con un clic».
3. Olvidar los casos difíciles. ¿Qué pasa si el cliente paga de más? ¿Si se anula un pedido ya facturado?
4. No incluir a quienes usarán el sistema. El vendedor y el almacenero saben cosas que el gerente no ve.
5. Cambiar requerimientos de palabra. Todo cambio va por escrito, con su impacto en plazo y costo.

Plantilla de requerimientos para copiar

Copia esta estructura en un documento y llénala con tus ejemplos. Para una primera versión, dos a cinco páginas suelen ser suficientes.

Cuando tengas el documento, úsalo para pedir cotizaciones a varios proveedores: si todos cotizan sobre el mismo texto, podrás compararlas de verdad. Luego, el mismo documento se anexa al contrato, como explicamos en contrato de desarrollo de software.

En resumen

• Los requerimientos describen qué hace el sistema, quién lo usa y qué reglas sigue; sirven para cotizar, construir y verificar.
• Empieza por el objetivo en una frase y por la lista de perfiles, incluyendo lo que cada uno no debe poder hacer.
• Escribe las funciones como historias de usuario con criterios de aceptación verificables.
• Anota las reglas del negocio con números, y lista reportes e integraciones, que son lo que más mueve el presupuesto.
• Incluye una sección de lo que queda fuera y prioriza lo indispensable para la primera versión.
• Usa la plantilla para que varios proveedores coticen sobre el mismo texto y anéxala al contrato.

Preguntas frecuentes

¿Qué son los requerimientos de un sistema?

Son la descripción de lo que el sistema debe hacer y de las condiciones que debe cumplir: funciones, usuarios, reglas, reportes, integraciones, seguridad y rendimiento. Sirven para cotizar, para construir y, al final, para verificar si el sistema entregado es el que se pidió.

¿Cuál es la diferencia entre requerimientos funcionales y no funcionales?

Los funcionales dicen qué hace el sistema: registrar un pedido, emitir una boleta, enviar un recordatorio. Los no funcionales dicen cómo debe hacerlo: que funcione en el celular, que cargue rápido, que guarde copias diarias, que cada usuario vea solo lo suyo.

¿Qué es una historia de usuario?

Es una forma sencilla de escribir un requerimiento desde el punto de vista de quien lo usa: «Como [perfil], quiero [acción] para [beneficio]». Por ejemplo: «Como cajero, quiero registrar un pago con Yape para que la cuota del alumno quede pagada». Cada historia viene con criterios para saber cuándo está terminada.

¿Tengo que saber programar para escribir requerimientos?

No. Quien mejor conoce los requerimientos es quien conoce el negocio. Tu trabajo es describir el proceso, las reglas y los casos difíciles con ejemplos; el del proveedor es traducirlo a decisiones técnicas y avisarte si algo es caro o complicado.

¿Qué tan detallado debe ser el documento de requerimientos?

Lo suficiente para que dos proveedores coticen lo mismo. Si una función se puede entender de dos maneras, falta detalle. Para una primera versión pequeña, dos a cinco páginas bien escritas suelen bastar.

¿Qué pasa si un requerimiento cambia durante el desarrollo?

Se registra como un cambio: se evalúa cuánto tiempo y costo suma y se decide si entra en la etapa actual o en la siguiente. Lo que no conviene es cambiar requerimientos de palabra, porque luego nadie recuerda qué se acordó.