Plantillas · Requisitos y análisis
Plantilla de documento de requisitos de negocio (BRD)
Esta plantilla gratuita de documento de requisitos de negocio le ofrece un BRD estructurado en dos partes: una visión general del BRD para los objetivos, el alcance, los interesados y la aprobación, y un registro de requisitos en el que cada requisito tiene un ID, un tipo, una justificación, una prioridad MoSCoW, un origen, unos criterios de aceptación y un estado. Descárguela para Google Sheets, Excel o PDF, en versión de principiante, avanzado o experto.
Puntos clave
- Un documento de requisitos de negocio (BRD) recoge lo que la empresa necesita de un proyecto y por qué, y cómo sabrá que se ha satisfecho cada necesidad. Describe la necesidad, no la solución.
- La plantilla tiene dos pestañas: una visión general del BRD en diez secciones y un registro de requisitos con ocho columnas y desplegables para el tipo, la prioridad y el estado.
- Los buenos requisitos no prescriben la solución, son comprobables, van uno por fila y se vinculan a un objetivo de negocio y a un origen.
- Priorice con MoSCoW y sea estricto: si todo es Must, nada lo es.
- Obtenga la aprobación antes de que empiecen el diseño o la contratación, y después controle los cambios mediante un proceso de solicitudes de cambio.
Descarga gratuita · sin registro
Obtenga la plantilla de documento de requisitos de negocio
Elija su nivel y formato: Google Sheets, Excel o un PDF listo para imprimir. Las hojas de cálculo incluyen listas desplegables, fórmulas y filas de ejemplo que puede sobrescribir.
La plantilla completa con todas las pestañas, listas desplegables y fórmulas.
¿Qué es un documento de requisitos de negocio?
A documento de requisitos de negocio (BRD) es un documento que establece lo que una empresa necesita de un proyecto o una solución, por qué lo necesita y cómo se medirá el éxito. Abarca los objetivos, el alcance, los interesados, las restricciones y una lista de requisitos priorizados con criterios de aceptación. Describe qué se necesita, no cómo se construirá.
Un BRD suele redactarse al principio de un proyecto, después de que la idea se haya aprobado en un caso de negocio o acta de constitución del proyecto y antes de que empiecen el diseño, el desarrollo o la contratación. Ofrece a quienes van a construir o comprar la solución un objetivo claro y acordado, y al patrocinador una base para aceptar el resultado al final.
Los BRD suelen redactarlos los analistas de negocio, pero en los proyectos más pequeños a menudo lo hace el director de proyecto o el product owner. Lo redacte quien lo redacte, el contenido procede de los interesados: el BRD es un registro de lo que necesitan, comprobado y acordado.
Para una visión más amplia de los requisitos de alto nivel y detallados, consulte nuestra guía de requisitos del proyecto.
Vista previa de la plantilla de BRD
La primera pestaña es la visión general del BRD. Cada sección tiene una breve indicación en la columna Orientaciones; sus respuestas van en Su contenido.
| Sección | Orientación | Su contenido |
|---|---|---|
| Nombre del proyecto y responsable | ||
| Resumen ejecutivo | La necesidad y el resultado propuesto, en resumen. | |
| Objetivos de negocio | Objetivos medibles a los que contribuye el proyecto. | |
| Antecedentes / situación actual | Cómo funcionan hoy las cosas y cuáles son los problemas. | |
| Alcance | Dentro y fuera del alcance. | |
| Interesados | A quién afecta y quién aprueba. |
Las filas de ejemplo son ilustrativas: sustitúyalas por las suyas.
Qué contiene la plantilla de BRD
La plantilla es una hoja de cálculo con dos pestañas que funcionan juntas. La visión general del BRD establece el contexto en diez secciones breves; la pestaña Requisitos enumera cada requisito en un registro estructurado y filtrable.
- visión general del BRD: Sección, Orientación, Su contenido
- Requisitos: ID, Requisito, Tipo, Justificación, Prioridad (MoSCoW), Origen, Criterios de aceptación, Estado
Pestaña de visión general del BRD
Tres columnas (Sección, Orientación, Su contenido) y diez secciones: nombre del proyecto y responsable, resumen ejecutivo, objetivos de negocio, antecedentes / situación actual, alcance, interesados, supuestos y restricciones, requisitos (que remite a la pestaña Requisitos), indicadores de éxito y aprobación.
Pestaña Requisitos
Ocho columnas: ID, Requisito, Tipo, Justificación, Prioridad (MoSCoW), Origen, Criterios de aceptación y Estado. En las versiones avanzada y de experto, tres columnas tienen desplegables:
- Tipo: Funcional, No funcional, Restricción, Datos, Informes.
- Prioridad (MoSCoW): Must, Should, Could, Won't.
- Estado: Borrador, En revisión, Aprobado, Rechazado, Aplazado.
Cuatro requisitos de ejemplo de un proyecto de portal de clientes muestran cómo rellenar cada columna; sobrescríbalos con los suyos.
¿Qué versión debería descargar?
| Versión | Qué incluye | Ideal para |
|---|---|---|
| Principiante | Solo la pestaña de visión general del BRD: diez secciones con orientaciones, más filas en blanco | Proyectos pequeños cuyos requisitos caben en unos pocos párrafos |
| Avanzado | Las dos pestañas: la visión general del BRD y el registro de requisitos completo de ocho columnas con los desplegables de Tipo, Prioridad (MoSCoW) y Estado | La mayoría de los proyectos con un analista de negocio o varios grupos de interesados |
| Experto | Todo lo de la versión avanzada, más una pestaña de instrucciones, un panel que cuenta automáticamente los requisitos por tipo, prioridad MoSCoW y estado, estados con códigos de colores (aprobado, en revisión, rechazado) y una pestaña de historial de revisiones | Proyectos más grandes, procesos de contratación y PMO que informan del avance de los requisitos |
Qué incluir en un documento de requisitos de negocio
Las diez secciones de la visión general dan a los lectores el contexto que necesitan antes de llegar a los propios requisitos. Esto es lo que debe escribir en cada una.
| Sección | Qué escribir | Ejemplo |
|---|---|---|
| Nombre del proyecto y responsable | El proyecto y el responsable de negocio que rinde cuentas de los requisitos | Portal de clientes; Director de Atención al Cliente |
| Resumen ejecutivo | La necesidad y el resultado propuesto en unas pocas frases. Redáctelo al final | Los clientes no pueden ver sus facturas ni restablecer su contraseña por sí mismos, así que llaman al soporte. Un portal de autoservicio reducirá las llamadas. |
| Objetivos de negocio | Objetivos medibles a los que contribuye el proyecto | Reducir un 30% las llamadas relacionadas con la cuenta en los 6 meses siguientes al lanzamiento |
| Antecedentes / situación actual | Cómo funcionan hoy las cosas y cuáles son los problemas | Todos los cambios en la cuenta pasan por el equipo de soporte por teléfono o correo electrónico |
| Alcance | Qué está dentro y fuera del alcance | Dentro: vista de la cuenta, facturas, restablecimiento de contraseña. Fuera: app móvil, pagos |
| Interesados | A quién afecta y quién aprueba | Atención al cliente, TI, Finanzas, Asesoría jurídica, clientes |
| Supuestos y restricciones | Lo que supone y los límites dentro de los que debe trabajar | API de facturación disponible en febrero; los datos deben permanecer en la UE |
| Requisitos | Una referencia a la pestaña Requisitos | Consulte la pestaña Requisitos (BR-01 a BR-04) |
| Indicadores de éxito | Cómo juzgará el éxito tras la entrega | Volumen de llamadas, adopción del portal, satisfacción de los clientes |
| Aprobación | Nombres, cargos y fechas de los aprobadores | Patrocinador, Director de TI, Delegado de Protección de Datos |
Muchos formatos de BRD publicados también incluyen un análisis de costo-beneficio. Si su proyecto ya tiene un caso de negocio, enlácelo en lugar de repetir las cifras; el BRD debe seguir centrado en las necesidades. Nuestra guía de análisis de costo-beneficio explica el método si lo necesita.
Cómo redactar buenos requisitos de negocio
El registro de requisitos es el núcleo del BRD. Un buen requisito es:
- Necesario: contribuye a un objetivo de negocio. Si no puede decir a cuál, cuestiónelo.
- Sin prescribir la solución: indica lo que se necesita, no cómo construirlo. «Los clientes deben poder restablecer su contraseña sin ponerse en contacto con el soporte» deja abierto el diseño.
- Claro: admite una sola lectura razonable. Evite palabras como «fácil de usar», «rápido» o «flexible» sin una medida.
- Comprobable: alguien puede comprobar que se ha cumplido. Para eso sirve la columna de criterios de aceptación.
- Atómico: un requisito por fila. Divida todo lo que esté unido por una «y».
- Trazable: tiene un ID, un origen (una persona, un documento, una normativa o unos datos) y una justificación.
| Requisito débil | Requisito mejor | Por qué es mejor |
|---|---|---|
| El portal debe ser rápido | Las páginas deben cargarse en menos de 2 segundos (percentil 95) | Medible y comprobable |
| Usar un enlace de restablecimiento de contraseña enviado por correo a través del CRM | Los clientes deben poder restablecer su contraseña sin ponerse en contacto con el soporte | Expresa la necesidad, no la solución |
| Los clientes pueden ver sus facturas y actualizar su dirección | Dos filas: una para ver las facturas y otra para actualizar la dirección | Un requisito por fila, para que cada uno pueda priorizarse y probarse |
| Cumplir las normas de datos | Los datos de los clientes deben almacenarse en la UE | Concreto, con un origen claro (Asesoría jurídica / política de RGPD) |
Tipos de requisitos
El desplegable Tipo de la plantilla facilita el filtrado del registro: Funcionales (lo que debe hacer la solución), No funcionales (con qué calidad debe hacerlo, como el rendimiento, la disponibilidad, la seguridad o la usabilidad), Restricción (límites como la normativa, la tecnología o el presupuesto), Datos y Informes.
Si su organización sigue la Guía BABOK del IIBA, verá una clasificación más amplia: requisitos de negocio (los objetivos y resultados), requisitos de los interesados (las necesidades de grupos concretos), requisitos de la solución (divididos en funcionales y no funcionales) y requisitos de transición (lo necesario para pasar de la situación actual a la futura, como la migración de datos o la formación). Puede añadirlos como opciones adicionales en la lista Tipo.
Priorizar con MoSCoW
MoSCoW clasifica los requisitos en cuatro grupos, y la columna Prioridad de la plantilla los utiliza:
| Prioridad | Significado | Probar |
|---|---|---|
| Must | Sin él, la solución fracasa o no es legal o segura | ¿Cancelaría el lanzamiento si faltara? |
| Should | Importante, pero existe una solución alternativa | Doloroso dejarlo fuera, pero la solución sigue funcionando |
| Could | Deseable si el plazo y el presupuesto lo permiten | Estaría bien tenerlo; es lo primero que se elimina bajo presión |
| Won't (esta vez) | Acordado como fuera del alcance por ahora | Se registra para que la decisión sea visible |
El error habitual es marcar casi todo como Must. Plantee la pregunta «¿cancelaría el lanzamiento?» para cada uno. Registrar los elementos Won't es igual de útil: evita que la misma solicitud vuelva cada mes.
Cómo redactar los criterios de aceptación
Los criterios de aceptación describen cómo confirmará que se ha cumplido un requisito. Manténgalos concretos y observables: «restablecimiento completado en menos de 2 minutos», «visibles todas las facturas desde 2024», «región de alojamiento confirmada en la UE». Se convierten en la base de las pruebas y de la aceptación del patrocinador al final del proyecto, y se vinculan de forma natural con su enfoque de gestión de la calidad .
Cómo rellenar la plantilla de BRD paso a paso
- Parta del acta de constitución o del caso de negocio. Copie los objetivos y el alcance para que el BRD sea coherente con lo aprobado.
- Identifique a los interesados. Enumere a todos los que usan, gestionan, pagan o regulan la solución. Nuestra guía de gestión de los interesados muestra cómo analizarlos.
- Describa la situación actual. Registre cómo funcionan hoy las cosas y qué falla. Las evidencias, como los datos de llamadas o los resultados de encuestas, ayudan.
- Recopile los requisitos. Utilice entrevistas, talleres, observación, revisión documental y datos. Anote el origen de cada requisito a medida que avanza; las notas de reunión de los talleres son un registro útil.
- Redacte cada requisito en su propia fila. Asígnele un ID, una declaración clara, un tipo y una justificación vinculada a un objetivo.
- Priorice y añada criterios de aceptación. Acuerde las prioridades MoSCoW con el responsable de negocio y redacte una prueba para cada requisito.
- Revise con los interesados. Repase el registro, resuelva los conflictos y actualice los estados de Borrador a En revisión y a Aprobado.
- Obtenga la aprobación y fije la línea base. Pida a los aprobadores designados que firmen la visión general. A partir de entonces, los cambios pasan por el control de cambios mediante una solicitud de cambio.
Ejemplo de documento de requisitos de negocio
Las filas de ejemplo de la plantilla describen un proyecto de portal de clientes. Este es el registro de requisitos tal como viene, con una nota sobre por qué cada fila está redactada así.
| ID | Requisito | Tipo | Prioridad | Criterios de aceptación | Estado |
|---|---|---|---|---|---|
| BR-01 | Los clientes deben poder restablecer su contraseña sin ponerse en contacto con el soporte | Funcionales | Must | Restablecimiento completado en menos de 2 minutos | Aprobado |
| BR-02 | El portal debe mostrar las facturas de los últimos 24 meses | Funcionales | Must | Visibles todas las facturas desde 2024 | Aprobado |
| BR-03 | Las páginas deben cargarse en menos de 2 segundos | No funcionales | Should | Percentil 95 inferior a 2 s | Borrador |
| BR-04 | Los datos deben almacenarse en la UE | Restricción | Must | Región de alojamiento confirmada | Aprobado |
- BR-01 procede de los datos de soporte y sirve directamente al objetivo de reducir las llamadas, por lo que es Must.
- BR-02 procede de una encuesta a clientes y tiene un límite claro (24 meses), lo que evita una migración de datos sin fin.
- BR-03 es un requisito no funcional procedente de la investigación de UX. Sigue en Borrador porque el objetivo de 2 segundos aún no se ha acordado con TI.
- BR-04 es una restricción de la Asesoría jurídica basada en la política de RGPD. Es Must porque la solución no podría ponerse en marcha sin ella.
Cada fila remite a un objetivo (menos llamadas), un origen y una justificación. Esa trazabilidad es lo que le permite responder a «¿por qué estamos construyendo esto?» seis meses después, y le permite eliminar primero los requisitos adecuados si falta tiempo.
BRD frente a FRD, SRS, PRD e historias de usuario
Los documentos de requisitos se solapan y sus nombres varían entre organizaciones. Esta tabla muestra las distinciones habituales.
| Documento | Enfoque | Autor habitual | Lectores principales |
|---|---|---|---|
| Documento de requisitos de negocio (BRD) | Lo que necesita la empresa y por qué; objetivos, alcance, requisitos de alto nivel | Analista de negocio | Patrocinador, interesados del negocio, equipo de entrega |
| Documento de requisitos funcionales (FRD) / especificación funcional | Cómo se comportará la solución para cumplir los requisitos de negocio | Analista de negocio o de sistemas | Diseñadores, desarrolladores, testers |
| Especificación de requisitos de software (SRS) | Requisitos funcionales y no funcionales detallados de un sistema de software | Analista de sistemas o arquitecto | Desarrolladores, testers, proveedores |
| Documento de requisitos de producto (PRD) | Lo que debe hacer un producto o una versión para sus usuarios, a menudo funcionalidad por funcionalidad | Gerente de producto | Equipos de producto, diseño e ingeniería |
| Historias de usuario | Pequeñas porciones de funcionalidad centradas en el usuario, con criterios de aceptación | El Product Owner con el equipo | Equipo Scrum o ágil |
| Declaración de trabajo (SOW) | Lo que entregará un proveedor y en qué condiciones | El comprador, a menudo con el departamento de compras | Proveedores |
Un BRD suele alimentar una RFQ o un declaración de trabajo cuando la solución se va a comprar en lugar de construir, y alimenta la declaración del alcance del proyecto en todos los proyectos.
Usar un BRD en proyectos ágiles
Los equipos ágiles rara vez redactan un BRD extenso desde el principio, pero el razonamiento que hay detrás sigue siendo útil. Un BRD breve que recoja los objetivos, los límites del alcance, las restricciones y los principales requisitos de negocio da al Product Owner y al equipo un objetivo compartido.
El detalle pasa después al Product Backlog como historias de usuario, cada una vinculada a un ID de requisito de negocio. Los requisitos no funcionales y las restricciones suelen pasar a formar parte de la Definición de Terminadodel equipo. La versión de principiante de la plantilla, solo con la pestaña de visión general, suele bastar para ello; combínela con nuestra plantilla de historia de usuario o plantilla de product backlog.
Errores habituales en el BRD
- Diseñar la solución. Los diseños de pantalla y las decisiones tecnológicas corresponden al diseño, no al BRD.
- Palabras vagas. «Fácil», «rápido» y «seguro» necesitan una medida o no podrán probarse.
- Todo es Must. Sin prioridades reales, el equipo no puede hacer concesiones cuando falta tiempo.
- Interesados que faltan. Los requisitos de la Asesoría jurídica, Finanzas, Seguridad u operaciones suelen aparecer tarde y obligan a rehacer trabajo.
- Sin origen ni justificación. Los requisitos que nadie sabe explicar son difíciles de defender y fáciles de inflar con extras innecesarios.
- Saltarse la aprobación. Sin aprobación, el BRD es un borrador y el alcance sigue abierto. Consulte corrupción del alcance.
- Tratarlo como algo fijo para siempre. Los requisitos cambian. Fije la línea base del BRD aprobado y gestione los cambios de forma abierta en lugar de editarlo discretamente.
Plantillas y guías relacionadas
Un BRD forma parte de una cadena de documentos. Antes de él van el plantilla de caso de negocio y plantilla de acta de constitución del proyecto; junto a él, la plantilla de planteamiento del problema y plantilla de análisis de brechas enmarcan la necesidad; después de él, las plantilla de alcance del proyecto, plantilla de historia de usuario y plantilla de solicitud de cambio trasladan los requisitos a la ejecución. Una plantilla de matriz RACI le ayuda a acordar quién los redacta, los revisa y los aprueba.
Plantilla de enunciado del alcance del proyectoPlantilla gratuita de alcance del proyecto: objetivos, entregables, dentro del alcance, fuera del alcance, aceptación…Principiante · Avanzado · Experto
Plantilla de historia de usuarioPlantilla gratuita de historia de usuario: Como / quiero / para, criterios de aceptación, épica, estimación…Principiante · Avanzado · Experto
Plantilla de análisis de brechasPlantilla gratuita de análisis de brechas que compara el estado actual y el futuro, puntúa cada brecha y…Principiante · Avanzado · Experto
Plantilla de enunciado del problemaPlantilla gratuita de enunciado del problema: a quién afecta, qué, dónde y cuándo, impacto, evidencia,…Principiante · Avanzado · Experto
Plantilla de análisis de causa raíz (5 porqués)Plantilla gratuita de análisis de causa raíz con los 5 porqués: enunciado del problema, cadena de porqués, causa…Principiante · Avanzado · Experto- Requisitos del proyecto: requisitos de alto nivel y técnicos
- Gestión de los interesados del proyecto: identificar, analizar, involucrar
- Alcance del proyecto: definición, enunciado del alcance y ejemplos
- Historias de usuario: cómo escribirlas, con ejemplos
Para saber cómo encajan los requisitos de alto nivel y los detallados, lea nuestra guía de requisitos del proyecto.
Preguntas frecuentes
¿Qué es una plantilla de documento de requisitos de negocio?
Una plantilla de documento de requisitos de negocio es una estructura lista para usar con la que registrar los objetivos de negocio, el alcance, los interesados, las restricciones y los requisitos de un proyecto, cada uno con una prioridad y criterios de aceptación. Esta tiene una pestaña de visión general del BRD y un registro de requisitos.
¿Es gratuita esta plantilla de BRD?
Sí. La plantilla de documento de requisitos de negocio se descarga gratis en Google Sheets, Excel y PDF, sin necesidad de registrarse.
¿Qué debe incluir un documento de requisitos de negocio?
Un resumen ejecutivo, los objetivos de negocio, los antecedentes y la situación actual, el alcance, los interesados, los supuestos y las restricciones, los propios requisitos con su prioridad y sus criterios de aceptación, los indicadores de éxito y la aprobación.
¿Quién redacta un documento de requisitos de negocio?
Normalmente un analista de negocio, en colaboración con los interesados, el patrocinador y el director de proyecto. En los proyectos más pequeños, a menudo lo redacta el director de proyecto o el product owner.
¿Quién aprueba el BRD?
Lo aprueba el patrocinador o el responsable de negocio, normalmente con los responsables de los principales grupos de interesados y de cualquier especialidad, como la Asesoría jurídica o Seguridad, cuyos requisitos contenga.
¿Cuál es la diferencia entre un BRD y un FRD?
Un BRD indica lo que necesita la empresa y por qué. Un documento de requisitos funcionales (FRD) describe cómo se comportará la solución para satisfacer esas necesidades, con el detalle suficiente para los diseñadores, los desarrolladores y los testers.
¿Cuáles son los tipos de requisitos de negocio?
Esta plantilla utiliza funcional, no funcional, restricción, datos e informes. La Guía BABOK del IIBA clasifica los requisitos en requisitos de negocio, de los interesados, de la solución (funcionales y no funcionales) y de transición.
¿Qué extensión debe tener un BRD?
Lo más breve posible sin dejar de ser claro. Un proyecto pequeño puede necesitar unas pocas páginas; un gran sistema o un proceso de contratación puede necesitar muchas más. Mantenga el contexto en la visión general y ponga cada requisito en su propia fila del registro.
¿Cuándo debe redactarse un BRD?
Después de que el proyecto se haya aprobado en principio mediante un caso de negocio o un acta de constitución, y antes de que empiecen el diseño, el desarrollo o la contratación.
¿Cómo se priorizan los requisitos de negocio?
Utilice MoSCoW: Must, Should, Could y Won't have this time. Acuerde las prioridades con el responsable de negocio y ponga a prueba cada Must preguntándose si cancelaría el lanzamiento sin él.
¿Pueden los equipos ágiles utilizar un documento de requisitos de negocio?
Sí, a alto nivel. Utilice un BRD breve para los objetivos, el alcance, las restricciones y los requisitos de negocio clave, y recoja después el detalle como historias de usuario en el product backlog.
¿Qué ocurre si los requisitos cambian después de la aprobación?
Presente una solicitud de cambio, evalúe el impacto en el alcance, el cronograma y el coste, y obtenga la aprobación antes de actualizar el BRD. Registre el cambio y su decisión para que la línea base siga siendo clara.
¿Puedo usar la plantilla de BRD en Word?
La descarga es una hoja de cálculo y un PDF. Puede copiar las secciones de la visión general en un documento de Word si su organización lo prefiere y mantener el registro de requisitos en la hoja de cálculo, donde es más fácil filtrarlo y ordenarlo.