Decidimos en papel, mientras todavía es barato

Cada proyecto que diseña mi equipo pasa por tres documentos: qué necesita el negocio, qué debe hacer el sistema y cómo lo va a entregar el diseño. Escribirlos temprano es la decisión más barata de todo el proyecto.

  • BRSBusiness Requirements Specification
  • SRSSystem Requirements Specification
  • SDDSoftware Design Description
Ver los tres documentos Escríbeme

Por qué lo escribimos

El precio de una decisión lo define cuánto ya se construyó encima de la respuesta que falta.

De The Price of Not Deciding, mi ensayo sobre requisitos, 2026
Cuánto cuesta corregir un defecto de requisito
  1. 1×mientras todavía está en papel
  2. 10×durante el desarrollo
  3. 100×con el sistema en producción

Datos de Barry Boehm de los años ochenta, confirmados muchas veces desde entonces. Los multiplicadores cambian de un estudio a otro; la forma de la curva nunca cambia.

Un arquitecto sabe que el lugar de una ventana decide la luz y el calor de cada habitación detrás de ella. El lugar de una pantalla en un embudo hace lo mismo con toda la vida del software. Por eso nuestro diseño empieza por los requisitos, no por las pantallas.

Tres documentos, un mismo hilo

El discovery termina en entregables compartidos, escritos para quienes construyen después. Cada documento responde una pregunta y le pasa su respuesta al siguiente.

Business Requirements Specification

¿Qué necesita el negocio?

La Business Requirements Specification, la especificación de requisitos de negocio, describe el negocio antes que el producto: sus objetivos, cómo funciona hoy, las personas involucradas y los límites dentro de los que opera. Separa los procesos internos del cliente de lo que la plataforma tiene que hacer, para que uno no se confunda con el otro.

Qué incluye

  • Objetivos del negocio y cómo se medirá el éxito
  • Cómo funciona el negocio hoy, paso a paso
  • Stakeholders, sus roles y las decisiones de cada uno
  • Restricciones: presupuesto, plazos, plataformas y regulación
  • Qué entra en el alcance y qué no
  • Requisitos de negocio, en orden de prioridad
Quién lo lee
La dirección del cliente, el gerente de proyecto y diseño
Listo cuando
El cliente aprueba los objetivos, el alcance y las prioridades.

Construida a partir de talleres de discovery, benchmarking y un registro de brechas con cada pregunta abierta.

System Requirements Specification

¿Qué debe hacer el sistema?

La System Requirements Specification, la especificación de requisitos de sistema, convierte las necesidades del negocio en comportamiento que el equipo puede construir y probar. Cada requisito tiene un tipo, un responsable y una forma de probar que funciona, para que desarrollo y QA lean la misma promesa.

Qué incluye

  • Propósito, alcance y definiciones
  • Usuarios, sus roles y sus permisos
  • Requisitos funcionales, cada uno en una frase que se pueda probar
  • Requisitos de calidad: rendimiento, seguridad y accesibilidad
  • Interfaces con otros sistemas y sus datos
  • Tipos de requisito y el responsable de cada uno
  • Criterios de aceptación
Quién lo lee
Desarrollo, QA, diseño y el gerente de proyecto
Listo cuando
Cada requisito de negocio lleva al menos a un requisito de sistema, y cada requisito de sistema se puede probar.

Basada en IEEE 830 e IEEE 1233.

Software Design Description

¿Cómo lo va a entregar el diseño?

La Software Design Description, la descripción del diseño de software, es donde el diseño se encuentra con la especificación. Muestra cómo se arma el producto para quienes no viven dentro del desarrollo de software: los flujos, las pantallas y sus estados, los casos límite y las decisiones detrás de ellos, con palabras que producto, QA y desarrollo comparten.

Qué incluye

  • Objetivos y entregables de cada área de diseño
  • Flujos de usuario y arquitectura de información
  • Pantallas, componentes y todos sus estados posibles
  • Casos límite y caminos de falla
  • Decisiones de diseño, cada una con su motivo
  • Un glosario, para que todos los equipos usen las mismas palabras
Quién lo lee
Diseñadores, desarrolladores, QA y gerentes de producto
Listo cuando
Un desarrollador puede construir una pantalla y un tester puede revisarla sin preguntarle al diseñador qué quiso decir.

Sigue la IEEE 1016. Nuestra plantilla viene con una guía interactiva que acompaña a quien llega, sección por sección.

Cómo funciona en la práctica

Los documentos están vivos. Empiezan en el sprint de discovery de dos semanas y se afinan en cada sprint, a medida que el trabajo nos enseña. Cuatro reglas los mantienen honestos.

  • Escríbelo la semana en que aparece

    Cada decisión abierta va al papel la semana en que surge, con un responsable y una fecha.

  • Un borrador ahora vale más que algo pulido después

    Una frase se puede refinar. Una página en blanco, no.

  • Prioriza antes de detallar

    El tiempo de análisis va a los requisitos que sostienen el negocio, no a los que llegaron primero.

  • Cada decisión tiene un plazo

    Una decisión reversible tomada en este sprint vale más que una perfecta tomada cuando la base de datos ya está en producción.

Qué cambia

63 preguntas abiertas
Anotadas en el registro de brechas de un discovery de dos semanas para una plataforma de eventos y membresías, antes de diseñar la primera pantalla.
2 entregables
Dividir el discovery en requisitos de negocio y requisitos de sistema le dio al diseño una entrega clara para los otros equipos. El equipo lo adoptó en septiembre de 2026.
13 a 1 herramientas
Un concepto de operaciones unió tres portales administrativos en un solo CRM para Container Alliance. Según mi inventario, reemplazó 13 herramientas separadas.

  • Quien llega aprende con el trabajo real

    Los diseñadores nuevos estudian los tipos de requisito y los roles en nuestra SRS, con tres capas de apoyo alrededor, hasta que pueden conducir el discovery por su cuenta.

  • Un solo vocabulario

    El glosario de la SDD les da a producto, QA, desarrollo y diseño las mismas palabras para las mismas cosas.

  • El diseño deja de ser opcional

    Cuando cada pantalla lleva a un requisito escrito, los otros equipos pueden ver por qué está ahí.

¿Empiezas un proyecto? Empieza por los requisitos.

Cada proyecto empieza con un sprint de discovery de dos semanas. Termina con los requisitos de negocio en papel, para especificar el sistema antes de que alguien dibuje una pantalla.

EscríbemeVer los trabajos