[Software y apps para empresas](https://sieteymedia.cl/category/software-a-medida/)

# Requerimientos de software: cómo escribirlos sin ambigüedad

> Cómo escribir requerimientos de software sin ambigüedad con el formato EARS: cinco patrones, un ejemplo paso a paso y qué debe incluir el documento.

Por Alessandro Massoni 2 de octubre de 2026 4 min de lectura

![Hoja arrugada que se transforma en tarjetas ordenadas, metáfora de requerimientos de software escritos sin ambigüedad](https://sieteymedia.cl/assets/noticias/requerimientos-de-software.jpg)

La mayoría de los requerimientos de software no fallan por el código, fallan por una frase como "que avise cuando falte stock". ¿Avise a quién, por qué medio, cuando falte cuánto y qué pasa si nadie lo lee? Cada pregunta sin responder es una decisión que alguien va a tomar por ti, y hoy ese alguien suele ser una IA.

En este artículo verás por qué la ambigüedad sale cara, cómo escribir requerimientos con un formato simple que nació en la industria aeronáutica, un ejemplo paso a paso y qué no debe faltar en el documento que le entregas a tu proveedor.

## Por qué los requerimientos de software ambiguos salen caros

Un requerimiento ambiguo no desaparece: se resuelve más tarde y en el peor momento. Si se descubre en la especificación, cambiarlo cuesta una conversación. Si se descubre con el sistema funcionando, cuesta rehacer pantallas, migrar datos y volver a capacitar al equipo.

Con IA el problema se agrava de una forma silenciosa. Un programador que no entiende algo suele preguntar; un modelo de lenguaje rellena el vacío con el supuesto más probable y sigue adelante. El resultado se ve correcto, compila y pasa la demo, pero responde a una regla que nadie definió. Por eso en el [desarrollo de software con IA](https://sieteymedia.cl/desarrollo-de-software-con-ia/) la especificación pasó a ser la pieza más importante del proyecto.

Cuando construimos [sistemas a medida para empresas](https://sieteymedia.cl/apps-para-empresas/), la mitad del valor está en esta etapa: convertir lo que tu equipo hace todos los días en reglas que no admitan dos lecturas.

## El formato EARS: cinco patrones para escribir requerimientos

EARS (Easy Approach to Requirements Syntax) es un método que [desarrolló Alistair Mavin en Rolls-Royce](https://en.wikipedia.org/wiki/Easy_Approach_to_Requirements_Syntax) para redactar requisitos de sistemas de control de motores de avión. Su idea es simple: casi todo requerimiento bien escrito sigue uno de cinco patrones, y cada patrón obliga a decir lo que suele quedar implícito.

- **Siempre**: "El sistema debe registrar el usuario que crea cada cotización".
- Cuando ocurre algo: "Cuando una cotización se aprueba, el sistema debe generar la orden de trabajo".
- Mientras se mantiene un estado: "Mientras una orden esté abierta, el sistema debe impedir modificar su precio".
- Si pasa algo no deseado: "Si el stock de un producto baja del mínimo, entonces el sistema debe notificar por correo al encargado de bodega".
- Donde aplique una opción: "Donde el cliente tenga crédito aprobado, el sistema debe permitir la venta sin pago anticipado".

El método no requiere herramientas ni capacitación larga, y por eso funciona bien con equipos de operaciones. Además, su estructura es fácil de leer tanto para personas como para modelos de lenguaje, lo que lo volvió un estándar práctico para especificar sistemas que se construyen con IA.

## De la frase suelta al requerimiento: un ejemplo paso a paso

Tomemos la frase del principio, "que avise cuando falte stock", y hagámosle las preguntas que la IA no va a hacer:

1. ¿Qué significa faltar? Bajar de un mínimo definido por producto.
2. ¿A quién se avisa? Al encargado de la bodega donde está el producto.
3. ¿Por qué medio? Correo y aviso dentro del sistema.
4. ¿Cada cuánto? Una sola vez hasta que el stock se reponga.
5. ¿Qué pasa si no hay encargado asignado? Se avisa al jefe de operaciones.

El requerimiento final queda así: "Si el stock de un producto baja de su mínimo, entonces el sistema debe enviar un único aviso por correo y en el panel al encargado de esa bodega, y si la bodega no tiene encargado, al jefe de operaciones". Es más largo, pero ya no hay nada que adivinar, y cualquiera puede comprobar si el sistema lo cumple.

## Qué debe tener un documento de requerimientos de software

No necesitas un documento de cien páginas. Necesitas que cubra lo que una persona nueva tendría que preguntar para hacer el trabajo sin equivocarse:

- **Los datos**: qué información se guarda y cómo se relaciona.
- Los roles: quién usa el sistema y qué puede ver o modificar cada uno.
- Las reglas: los requerimientos escritos con los patrones anteriores.
- Las excepciones: qué pasa cuando algo sale del camino normal.
- Lo que queda fuera: lo que el sistema no hará en esta etapa.

El primer punto es el que más se omite y el que más problemas evita después; lo desarrollamos en [por qué conviene empezar por la base de datos](https://sieteymedia.cl/data-first-empieza-por-la-base-de-datos-no-por-el-diseno/). Otra forma útil de llegar a buenos requerimientos es partir desde los reportes que necesitas, como proponemos en [diseñar tu sistema partiendo de las preguntas que necesitas responder](https://sieteymedia.cl/y-si-disenaras-tu-proximo-sistema-partiendo-de-las-preguntas-que-necesitas-responder/).

¿Cuántas reglas de tu operación viven hoy solo en la cabeza de alguien? [Agenda una reunión de levantamiento](https://sieteymedia.cl/contacto-agencia-de-marketing-digital/) y las convertimos juntos en requerimientos listos para construir.

## Preguntas frecuentes

### ¿Qué es un requerimiento de software?

Es una descripción de algo que el sistema debe hacer o cumplir, escrita de forma que se pueda verificar. Un buen requerimiento dice qué ocurre, en qué condición y a quién afecta, sin dejar decisiones implícitas.

### ¿Qué es el formato EARS?

Es un método para redactar requerimientos desarrollado por Alistair Mavin en Rolls-Royce. Propone cinco patrones: siempre, cuando ocurre algo, mientras se mantiene un estado, si pasa algo no deseado y donde aplica una opción.

### ¿Qué debe incluir un documento de requerimientos de software?

Los datos que se guardan, los roles y sus permisos, las reglas escritas con patrones claros, las excepciones y lo que queda fuera del alcance. No necesita ser largo, necesita responder lo que una persona nueva preguntaría.

¿Conversamos sobre tu proyecto?

[Aplicaciones a medida para empresas](https://sieteymedia.cl/apps-para-empresas/)

Alessandro Massoni

Fundador y director general de [Siete y Media](https://sieteymedia.cl/agencia-de-marketing-digital-en-chile/)

## Artículos relacionados

[Ver el blog](https://sieteymedia.cl/blog-de-marketing-digital/)

![Estructura con forma de teléfono hecha de bloques sueltos e inclinados, representa una app hecha con vibe coding](https://sieteymedia.cl/assets/noticias/vibe-coding-empresas.jpg)

Software y apps para empresas

### [Vibe coding: por qué tu app hecha con IA no llega a producción](https://sieteymedia.cl/vibe-coding-empresas/)

El vibe coding permite armar una app conversando con una IA, pero lo que funciona en la demo suele romperse con datos y usuarios reales. Qué es, por qué falla y qué hacer con tu prototipo.

2 de octubre de 2026

![Balanza con un cubo pequeño y uno grande, representa qué baja y qué no en el costo del software con IA](https://sieteymedia.cl/assets/noticias/costo-software-con-ia.jpg)

Software y apps para empresas

### [Costo del software con IA: qué baja y qué no](https://sieteymedia.cl/costo-software-con-ia/)

Si la IA escribe el código, el software debería costar la mitad. El supuesto falla porque el código nunca fue lo caro: lo caro es entender el negocio, decidir y responder por el resultado.

2 de octubre de 2026

![Lupa sobre bloques de una interfaz abstracta con un candado, representa la revisión del código generado por IA](https://sieteymedia.cl/assets/noticias/codigo-generado-por-ia-seguridad.jpg)

Software y apps para empresas

### [Código generado por IA: ¿es seguro y quién responde?](https://sieteymedia.cl/codigo-generado-por-ia-seguridad/)

El código generado por IA compila y se ve ordenado, pero los riesgos están en permisos, librerías y datos que nadie revisó. Qué controles exigir y quién responde cuando algo falla.

2 de octubre de 2026

---

Fuente: https://sieteymedia.cl/requerimientos-de-software/
