Usa esta plantilla
Un documento de requisitos del negocio (BRD) es el puente entre los responsables del negocio y los equipos técnicos: recoge lo que necesita el negocio y lo traduce en requisitos que los desarrolladores pueden construir. Con Trupeer, puedes ahorrar horas en la redacción de BRD empezando con una plantilla gratuita de documento de requisitos del negocio, personalizándola con tus directrices de marca y convirtiendo los BRD largos en recorridos en vídeo que todo el mundo puede consumir de verdad.
Los proyectos rara vez fallan porque nadie haya escrito los requisitos. Fallan porque lo que se escribió era demasiado ambiguo como para no estar en desacuerdo. Todo el mundo firmó un documento diciendo que el sistema debía ser "amigable y rápido", y cuatro meses después descubren que querían decir tres cosas distintas.
Un documento de requisitos del negocio merece la pena redactarlo cuando permite el desacuerdo antes de que empiece la construcción, en lugar de después. Esta plantilla está hecha para eso: cada requisito está numerado, priorizado y acompañado de criterios de aceptación lo bastante específicos como para debatirlos ahora.
Descarga la plantilla de documento de requisitos del negocio
Formato | Ideal para |
|---|---|
Word (.docx) | El propio BRD. Descarga gratuita, sin registro. El formato que la mayoría de los equipos usan para escribir y compartir |
Google Docs | Revisión colaborativa con las partes interesadas, donde los comentarios y el historial de versiones importan |
La línea base firmada y aprobada | |
Excel (.xlsx) | La tabla de requisitos y la matriz de trazabilidad, donde el filtrado y la ordenación ayudan |
.doc | Sistemas de documentos antiguos y bibliotecas heredadas |
Gratis, editable, sin marca de agua. La mayoría de los equipos usan Word para el documento y Excel para la tabla de requisitos una vez que el recuento supera aproximadamente las treinta páginas.
¿Qué es un documento de requisitos del negocio?
Un documento de requisitos del negocio, o BRD, indica lo que el negocio necesita de un proyecto y por qué, antes de que nadie decida cómo construirlo. Define el problema, el alcance, las partes interesadas, los propios requisitos y los criterios con los que se juzgará el resultado.
Su función real es el acuerdo. Un BRD es el documento que todos firman para confirmar que entienden lo mismo, por eso la prueba útil de un BRD no es si se lee bien, sino si es lo bastante específico como para que alguien pueda objetarlo.
Cómo personalizar esta plantilla en Trupeer
Paso 1: Abre la sección Plantillas
Ve a la sección Plantillas desde la navegación principal.
Paso 2: Selecciona y abre una plantilla
Haz clic en cualquier plantilla con la que quieras trabajar para abrirla.
Paso 3: Amplía la vista de la plantilla
Si es necesario, amplía la vista de la plantilla para ver el diseño completo y los detalles con claridad.
Paso 4: Edita la plantilla
Haz clic en Editar para empezar a modificar la plantilla seleccionada.
Dentro del editor, puedes:
Añadir secciones nuevas
Definir o actualizar reglas de formato
Añadir un logotipo y ajustar su posición y la configuración relacionada
Paso 5: Guarda tu plantilla personalizada
Después de realizar todos los cambios necesarios, haz clic en Guardar para almacenar la plantilla actualizada como tuya.
Paso 6: Previsualiza y ajusta la plantilla
Cuando quieras ver cómo se ve tu plantilla personalizada, abre la Previsualización.
Desde la pantalla de previsualización, puedes seguir haciendo ajustes directamente si es necesario, asegurándote de que la plantilla aparezca exactamente como la quieres.
Con una plantilla de documento de requisitos del negocio puedes:
Ahorra horas en la redacción: Omite la página en blanco con una estructura usada por BAs y PMs con experiencia.
Alinea negocio y tecnología: Secciones integradas que conectan los objetivos del negocio con los requisitos funcionales.
Mantén la coherencia de marca: Aplica tu logotipo, tipografías y colores usando el kit de marca de Trupeer.
Comunica con claridad: Convierte BRD densos en recorridos en vídeo para revisiones de las partes interesadas.
Estandariza en todos los proyectos: Usa la misma plantilla de BRD para cada iniciativa.
Llega a equipos globales: Traduce BRD a 65+ idiomas con un solo clic.
Por qué necesitas un documento de requisitos del negocio
El alcance se convierte en algo que puedes señalar en lugar de recordar. La mayoría de las disputas sobre el alcance son fallos de documentación, no mala fe.
Los requisitos tienen prioridades, así que cuando el tiempo se acorta, recortas con intención en lugar de recortar lo que quede.
Las suposiciones se escriben, que es cuando alguien detecta la incorrecta.
Los criterios de aceptación existen antes de la construcción, así que "hecho" no lo decide quien sea más ruidoso al final.
La entrega resiste la marcha de las personas. Los proyectos que pierden a su analista de negocio a mitad de camino son los que hacen que un BRD se pague por sí solo de inmediato.
Los proveedores pueden cotizar sobre algo real. Un BRD ambiguo genera una cotización amplia y un proyecto con muchas solicitudes de cambio.
Qué incluye un documento de requisitos del negocio
Control del documento: versión, autor, fecha, distribución y estado de aprobación.
Resumen ejecutivo: qué es el proyecto y por qué, en un párrafo.
Objetivos del negocio, expresados como resultados medibles en lugar de actividades.
Contexto y declaración del problema: qué está ocurriendo ahora y cuánto cuesta.
Alcance: qué está dentro y, de forma explícita, qué está fuera.
Partes interesadas: quién se ve afectado, quién decide y quién firma.
Estado actual, tal como es realmente.
Requisitos del negocio, numerados, priorizados, con criterios de aceptación para cada uno.
Suposiciones, restricciones y dependencias.
Riesgos, con responsables.
Resumen de coste y beneficio, y el retorno esperado.
Calendario y hitos clave.
Criterios de éxito para el proyecto en su conjunto.
Glosario, porque la mitad de las disputas sobre requisitos son disputas de vocabulario.
Bloque de conformidad.
Anexos: mapas de procesos, datos, pantallas y análisis de apoyo.
La estructura de la plantilla
Sección | Qué incluye | Duración |
|---|---|---|
Control del documento | Versión, autor, aprobadores, historial de revisiones | Media página |
Resumen ejecutivo | El proyecto en un solo párrafo, escrito al final | Media página |
Objetivos del negocio | Dos a cinco resultados medibles | Media página |
Declaración del problema | Situación actual y su coste | 1 página |
Alcance | Dentro del alcance, fuera del alcance, explícitamente | 1 página |
Partes interesadas | Rol, interés, derechos de decisión | Media página |
Estado actual | Cómo funciona hoy | De 1 a 2 páginas |
Requisitos | La tabla numerada | De 2 a 6 páginas |
Suposiciones y restricciones | Expresadas con claridad | Media página |
Riesgos | Con responsables y mitigación | Media página |
Coste y beneficio | Inversión y retorno esperado | 1 página |
Calendario | Hitos y dependencias | Media página |
Criterios de éxito | Cómo se juzga el proyecto | Media página |
Glosario | Cada término que podría leerse de dos maneras | Según sea necesario |
Conformidad | Nombres, roles, fechas | Media página |
Diez a veinte páginas es lo normal para un proyecto de tamaño medio. Más de treinta, la tabla de requisitos normalmente ya ha absorbido decisiones de diseño que pertenecen a una especificación funcional.
Cómo redactar un requisito que resista la revisión
Esta es la habilidad completa. Un requisito está bien redactado cuando dos personas que no están de acuerdo saben, al leerlo, que no están de acuerdo.
Débil: El sistema debe ser fácil de usar.
Mejor: Un usuario nuevo debe poder enviar una reclamación sin formación, medido por 8 de 10 usuarios de prueba completando el envío de una reclamación de 3 líneas con recibos en el móvil sin ayuda en menos de 3 minutos.
Débil: Los informes deben cargarse rápido.
Mejor: El informe mensual de resumen debe renderizarse en 4 segundos para un conjunto de datos de hasta 50.000 filas.
Débil: Los responsables necesitan visibilidad de las aprobaciones.
Mejor: Un responsable debe poder ver todas las reclamaciones pendientes de su aprobación, ordenadas por fecha de envío, en una sola pantalla sin filtrar.
Débil: El sistema debe integrarse con finanzas.
Mejor: Las reclamaciones aprobadas deben publicarse en el sistema de contabilidad en 15 minutos, incluyendo el centro de coste y el código de IVA, con fallos registrados y reintentados automáticamente.
El patrón en cada mejora es el mismo. Nombra quién lo necesita, qué específicamente, y la condición bajo la cual estarías de acuerdo en que se ha logrado. Palabras en las que no confíes en tus propios borradores: fácil de usar, sólido, fluido, intuitivo, rápido, flexible, escalable, sencillo. Cada una oculta una decisión que alguien tomará más adelante sin ti.
Priorizar requisitos con MoSCoW
Los requisitos sin prioridades se convierten en obligatorios por defecto y, después, la primera presión del calendario obliga a recortes arbitrarios.
Prioridad | Significado | Prueba |
|---|---|---|
Imprescindible | No hay lanzamiento sin ello | ¿Retrasarías el lanzamiento para esto? Si no, no es un Imprescindible |
Debería tener | Importante, doloroso de omitir, asumible | Hay una solución alternativa, incluso una fea |
Podría tener | Deseable si la capacidad lo permite | Nadie notaría su ausencia en la primera semana |
No lo tendrá este tiempo | Expresamente fuera de este lanzamiento | Registrado para que deje de volver a plantearse |
La disciplina que hace que MoSCoW funcione: no más de aproximadamente el 60% de los requisitos deberían ser Imprescindibles. Si todo es Imprescindible, tienes una lista de deseos con una columna de prioridad. Y la lista de No lo tendrá es la más valiosa, porque es el registro escrito de lo que se pospuso conscientemente en lugar de olvidarse.
La tabla de requisitos
ID | Requisito | Prioridad | Origen | Criterios de aceptación | Responsable |
|---|---|---|---|---|---|
BR-01 | Imprescindible | ||||
BR-02 | Debería |
Cada requisito necesita un ID, porque "el requisito de reporting" es ambiguo en el momento en que hay dos. El origen importa porque en el mes cuatro alguien preguntará quién lo pidió, y "el negocio" no es una respuesta.
Matriz de trazabilidad
La comprobación de que nada se ha eliminado en silencio y de que no se está construyendo nada sin motivo.
ID del requisito | Objetivo del negocio | Referencia de la especificación funcional | Caso de prueba | Estado |
|---|---|---|---|---|
BR-01 | OBJ-1 | FS-3.2 | TC-14 | Verificado |
BR-02 | OBJ-1 | FS-3.5 | TC-18 | En prueba |
BR-03 | OBJ-2 | Aún no especificado | Ninguno | Brecha |
Dos fallos aparecen de inmediato. Un requisito sin caso de prueba no se verificará, y un elemento de la especificación funcional que no se traza a ningún requisito es algo que se está construyendo que nadie pidió. Ambos son habituales y ambos son baratos de detectar de esta forma.
Ejemplo de documento de requisitos del negocio
Un ejemplo abreviado y trabajado para que puedas ver el nivel de especificidad.
Proyecto: Sustitución del sistema de reclamaciones de gastos. Versión: 1.2. Autor: Analista de negocio. Aprobadores: Director de Finanzas, Director de TI, Director de RR. HH.
Objetivos del negocio. Reducir el tiempo medio de reembolso de reclamaciones de 24 días laborables a 10. Reducir el tiempo del equipo de finanzas dedicado al procesamiento de reclamaciones en un 50%, actualmente 14 horas semanales. Lograr un 95% de cumplimiento de la política en las reclamaciones presentadas, actualmente 71%.
Declaración del problema. Las reclamaciones se envían en una hoja de cálculo y se envían por correo electrónico. La ruta de aprobación es manual, los recibos llegan por separado y el 29% de las reclamaciones incumplen la política sin detectarse antes del pago. Finanzas dedica aproximadamente 14 horas a la semana a perseguirlas y el reembolso promedia 24 días laborables frente al compromiso de 10 días del manual del personal.
Dentro del alcance. Envío de reclamaciones, captura de recibos, validación de la política, ruta de aprobación, publicación en el sistema de contabilidad, notificación al empleado.
Fuera del alcance. Conciliación de tarjetas corporativas, configuración del tipo de kilometraje, integración con nóminas, migración de reclamaciones históricas más allá de 12 meses.
Requisitos.
ID | Requisito | Prioridad | Origen | Criterios de aceptación |
|---|---|---|---|---|
BR-01 | Los empleados deben enviar una reclamación desde un dispositivo móvil, incluyendo la fotografía de los recibos | Imprescindible | Encuesta al personal, 2026 | 8 de 10 usuarios de prueba completan una reclamación de 3 líneas con recibos en el móvil en menos de 4 minutos, sin ayuda |
BR-02 | El sistema debe validar cada línea frente a los límites de la política en el momento del envío | Imprescindible | Director de Finanzas | Las reclamaciones que incumplen un límite no pueden alcanzar el estado Enviado sin que se complete un campo de justificación marcado |
BR-03 | Las reclamaciones deben dirigirse al aprobador correcto según la línea de reporting | Imprescindible | Director de RR. HH. | El 100% de las reclamaciones de prueba se dirige correctamente en 12 escenarios de estructura organizativa, incluidas vacantes |
BR-04 | Las reclamaciones superiores a £500 deben requerir una segunda aprobación | Imprescindible | Matriz de autoridad delegada | Ninguna reclamación superior a £500 llega a Aprobado con una sola aprobación registrada |
BR-05 | Las reclamaciones aprobadas deben publicarse en el sistema de contabilidad con el centro de coste y el código de IVA | Imprescindible | Responsable de Finanzas | El 100% de las reclamaciones aprobadas aparecen correctamente codificadas en 15 minutos; los fallos se registran y se reintentan |
BR-06 | Los aprobadores deben ver todas las reclamaciones pendientes de su aprobación en una sola pantalla, de la más antigua a la más reciente | Debería | Entrevistas a aprobadores | Un responsable con 20 reclamaciones pendientes ve las 20 sin tener que paginar ni filtrar |
BR-07 | Los empleados deben recibir notificación en el envío, la aprobación y el pago | Debería | Encuesta al personal | Las notificaciones se entregan en un plazo de 5 minutos desde cada cambio de estado |
BR-08 | Finanzas debe exportar un informe mensual de reclamaciones por centro de coste | Debería | Responsable de Finanzas | El informe se genera en menos de 30 segundos para 5.000 reclamaciones |
BR-09 | El sistema debe admitir la aprobación delegada durante una ausencia | Podría | Entrevistas a aprobadores | Un aprobador puede nominar a un delegado para un rango de fechas |
BR-10 | Reclamaciones en múltiples divisas | No lo tendrá este lanzamiento | Responsables regionales | Pospuesto para la fase 2, registrado para la hoja de ruta |
Suposiciones. La estructura organizativa actual en el sistema de RR. HH. es correcta y se mantiene. El sistema de contabilidad expone una API compatible. Los límites de la política no cambiarán durante la implementación.
Restricciones. Presupuesto de £85.000. Debe ponerse en marcha antes del nuevo año fiscal. Sin contratación adicional de personal de finanzas.
Riesgos. Los datos de la línea de reporting de RR. HH. resultan poco fiables, responsabilidad del Director de RR. HH., mitigado con una auditoría antes de la construcción. La adopción por parte de los aprobadores es lenta, responsabilidad del Director de Finanzas, mitigado con formación a responsables y una ejecución paralela de dos semanas.
Criterios de éxito. Reembolso medio en 10 días laborables o menos dentro de un trimestre desde el lanzamiento. Tiempo de procesamiento de Finanzas en 7 horas semanales o menos. Cumplimiento de la política en 95% o más.
Requisitos del negocio vs requisitos funcionales vs requisitos técnicos
La fuente de confusión más común en este tema, y la razón por la que muchos BRD en realidad son especificaciones con el título equivocado.
Requisito del negocio | Requisito funcional | Requisito técnico | |
|---|---|---|---|
Responde a | Qué necesita el negocio y por qué | Qué debe hacer el sistema | Cómo se construirá |
Lo redacta | Analista de negocio, con las partes interesadas | Analista de negocio o responsable de producto | Arquitecto de soluciones o ingeniero |
Audiencia | Patrocinadores, partes interesadas, proveedores | Diseñadores, desarrolladores, testers | Ingenieros |
Ejemplo | Las reclamaciones deben reembolsarse en 10 días laborables | El sistema dirige las reclamaciones al aprobador indicado en la línea de reporting de RR. HH. | La ruta de aprobación llama a la API de RR. HH., en caché durante 24 horas, con un respaldo al último responsable conocido |
Cambia cuando | Cambia la necesidad del negocio | Cambia el diseño de la solución | Cambia la arquitectura |
Vive en | BRD | FRD o especificación funcional | Documento de diseño técnico |
La prueba: si un requisito menciona una pantalla, un campo, un botón o un componente del sistema, se ha desplazado hacia el territorio funcional. Los requisitos del negocio deberían resistir un cambio completo de solución. Si cambiaste de proveedor y la mitad de tu BRD quedó invalidada, esa mitad nunca fue un requisito del negocio.
Quién prepara un documento de requisitos del negocio y quién lo firma
Lo prepara el analista de negocio, o el responsable de producto o el gestor de proyecto cuando no hay analista. Se redacta con las partes interesadas, no para ellas, porque un BRD producido en aislamiento se firma sin leerse, lo cual es peor que no tener ningún BRD.
Lo firman las personas a las que se les puede exigir responsabilidad: el patrocinador del negocio, quien gestiona el presupuesto y los responsables de cada función cuyo trabajo cambia. Añade al responsable de TI o de la entrega, confirmando que los requisitos se entienden, no solo que son alcanzables.
La firma que más importa es la de la persona a la que se le preguntará en el mes cuatro si esto se acordó.
Cómo redactar un documento de requisitos del negocio
Establece primero el objetivo del negocio, como un número. Si nadie puede expresar el resultado medible, la recopilación de requisitos generará una lista de funcionalidades en lugar de un documento.
Identifica las partes interesadas y los derechos de decisión antes de recopilar cualquier cosa. Saber quién puede decir que sí evita la mayoría de las revisiones tardías.
Documenta el estado actual con honestidad, incluyendo las soluciones alternativas. Aquí es donde se esconden los requisitos reales.
Recopila requisitos mediante entrevistas y observación, no solo con un taller. Los talleres sacan a la luz lo que la gente dice que necesita. Observar saca a la luz lo que hacen.
Redacta cada requisito con criterios de aceptación adjuntos, en la misma sesión. Añadir criterios más tarde significa escribirlos de memoria.
Prioriza con MoSCoW y mantén la línea en la proporción de Imprescindible.
Registra suposiciones, restricciones y dependencias de forma explícita. Las suposiciones no escritas se convierten en disputas.
Construye la matriz de trazabilidad a medida que avanzas, en lugar de al final.
Distribuye para revisión con una fecha límite y un revisor nombrado por sección. "¿Algún comentario?" a una lista de distribución produce silencio.
Lleva a las partes interesadas por el documento en una sesión antes de pedir firmas, y luego establece como línea base la versión y gestiona los cambios de forma formal a partir de ese momento.
Variantes de la plantilla de documento de requisitos del negocio
Variante | Úsala cuando | Qué cambia |
|---|---|---|
BRD sencillo | Proyectos pequeños, un solo equipo | Objetivos, alcance, tabla de requisitos, solo conformidad |
BRD ágil | Entrega iterativa | Requisitos como épicas e historias de usuario, prioridades revisadas por sprint, línea base más ligera |
BRD de desarrollo de software | Construir o comprar software | Más peso en integraciones, datos y requisitos no funcionales |
BRD de TI | Cambio de infraestructura y sistemas | Seguridad, acceso, disponibilidad, migración y puesta en marcha |
BRD técnico | Cuando la audiencia es ingeniería | Requisitos no funcionales explícitos, interfaces, estándares |
BRD de análisis de negocio | Práctica formal de BA | Trazabilidad completa, análisis de partes interesadas, modelos de proceso tal como está y a futuro |
BRD de gestión de proyectos | Cuando el BRD alimenta el plan del proyecto | Hitos, dependencias, implicaciones de recursos |
Lista de comprobación de requisitos | Revisar un BRD antes de la conformidad | Comprobación de exhaustividad en lugar de contenido |
Una nota sobre la versión ágil: un BRD y un backlog no compiten. El BRD recoge el porqué y lo que necesita el negocio, que cambia lentamente. El backlog recoge lo que se construye a continuación, que cambia constantemente. Los equipos que abandonan el BRD por completo suelen perder el hilo del porqué y redescubrirlo como un argumento.
Buenas prácticas
Redacta requisitos que alguien podría rechazar. La ambigüedad se lee como acuerdo y genera disputas más adelante.
Un requisito por fila. Cualquier cosa que contenga "y" probablemente son dos.
Adjunta criterios de aceptación de inmediato, nunca después.
Numera todo y nunca vuelvas a numerar. Retira los IDs en su lugar.
Registra el origen de cada requisito.
Mantén las soluciones fuera de él. En el momento en que nombras una pantalla o un campo, has empezado a diseñar.
Define cada término ambiguo en el glosario. Palabras como "reclamación", "usuario" y "aprobado" significan cosas distintas para distintos departamentos.
Establece como línea base la versión en la conformidad y gestiona los cambios de forma formal después.
Mantén visible la lista de fuera del alcance. Evita más el creep de alcance que cualquier otra sección.
Errores comunes
Requisitos imposibles de verificar. "Intuitivo" y "sólido" no se pueden probar, así que se interpretan en el momento de la construcción por quien esté más cerca.
Sin prioridades, así que todo es obligatorio hasta que la fecha límite obliga a recortes arbitrarios.
Soluciones disfrazadas de requisitos. Restringen el diseño antes de que nadie haya evaluado las opciones.
Sin criterios de aceptación, así que "hecho" se convierte en una negociación.
Falta la sección de fuera del alcance. La prevención de creep de alcance más barata que existe.
Redactado para las partes interesadas en lugar de con ellas. Se firma sin leerse.
Suposiciones dejadas sin escribir. Todo proyecto las tiene, y las no registradas son las que lo rompen.
Nunca se actualiza después de la conformidad. Los requisitos cambian y una línea base no mantenida deja de ser la referencia en la que cualquiera confía.
Sin trazabilidad, así que las caídas silenciosas se descubren en las pruebas de aceptación de usuario.
Captura el estado actual registrándolo
Abre la plantilla en Trupeer AI, aplica tu kit de marca para que el BRD coincida con el resto de documentos de tu proyecto y edita cualquier sección directamente. La configuración está en la guía de la plantilla.
La sección de estado actual es donde los BRD son más débiles, porque escribir cómo funciona algo hoy lleva más tiempo del que nadie presupuestó y siempre se pierden las soluciones alternativas. Registra el proceso existente una sola vez y Trupeer AI genera la documentación escrita del estado actual con capturas de pantalla capturadas automáticamente, además de un recorrido en vídeo narrado que puedes adjuntar como anexo. Los proveedores que cotizan basándose en tu BRD entienden una grabación de dos minutos más rápido que cuatro páginas de prosa.
Regístralo. Documenta. Traduce a 65+ idiomas para equipos de entrega offshore. Guárdalo en tu base de conocimiento. Trupeer it.
Preguntas frecuentes
¿Hay una plantilla gratuita de documento de requisitos del negocio en Word?
Sí. Word es el formato principal, con notas de guía en cada sección que eliminas mientras escribes, además de la tabla de requisitos y el bloque de conformidad preconstruidos. Descarga gratuita, sin registro, sin marca de agua.
¿Puedo descargar una plantilla de documento de requisitos del negocio en Word gratis?
Sí. Cada formato se puede descargar gratis sin necesidad de cuenta. Úsala en tantos proyectos como quieras.
¿Hay una plantilla de documento de requisitos del negocio en formato Word doc?
Sí, se incluye una versión .doc para sistemas de documentos y bibliotecas antiguas que no gestionan .docx correctamente.
¿Hay una plantilla gratuita de documento de requisitos del negocio en PDF?
Sí. El PDF es el formato de línea base de solo lectura, que es lo que compartes después de la conformidad para que la versión aprobada no se pueda editar por accidente.
¿Hay una muestra de documento de requisitos del negocio en PDF?
Sí. El ejemplo trabajado del sistema de gastos incluido arriba se proporciona como una muestra completa en PDF, con diez requisitos, criterios de aceptación, prioridades MoSCoW, suposiciones y riesgos. Leer un BRD finalizado es la forma más rápida de calibrar qué tan específico debe ser el tuyo.
¿Dónde puedo descargar una plantilla de documento de requisitos en Word?
En esta página, en Word, .doc, Google Docs, Excel y PDF. Todo es gratis. Si necesitas la especificación funcional en lugar de los requisitos del negocio, es un documento aparte y la diferencia se explica arriba.
¿Qué es un BRD?
Un documento de requisitos del negocio. Indica lo que necesita el negocio de un proyecto y por qué, antes de que se tomen decisiones sobre cómo construirlo, y sirve como el documento que las partes interesadas firman para confirmar la comprensión compartida.
¿Qué debe incluir un documento de requisitos del negocio?
Control del documento, resumen ejecutivo, objetivos del negocio medibles, declaración del problema, alcance con exclusiones explícitas, partes interesadas, estado actual, requisitos numerados con prioridades y criterios de aceptación, suposiciones, restricciones, dependencias, riesgos, coste y beneficio, calendario, criterios de éxito, glosario y conformidad.
¿Cuál es la diferencia entre requisitos del negocio y requisitos funcionales?
Los requisitos del negocio indican lo que necesita el negocio y por qué, independientemente de cualquier solución. Los requisitos funcionales indican lo que el sistema debe hacer para cumplirlos. "Las reclamaciones deben reembolsarse en 10 días laborables" es un requisito del negocio. "El sistema dirige las reclamaciones al aprobador indicado en la línea de reporting de RR. HH." es funcional. Un requisito del negocio debería resistir el cambio de proveedores.
¿Cuánto tiempo debe tener un documento de requisitos del negocio?
Diez a veinte páginas para un proyecto de tamaño medio. Los proyectos pequeños se pueden hacer en cinco. Pasadas las treinta, la sección de requisitos normalmente ya ha absorbido el diseño funcional que pertenece a otro lugar.
¿Quién redacta el documento de requisitos del negocio?
El analista de negocio, o el responsable de producto o el gestor de proyecto cuando no hay analista. Debe redactarse con las partes interesadas, no para ellas, ya que un BRD producido en aislamiento se firma sin leerse.
¿Quién da el visto bueno a un BRD?
El patrocinador del negocio, quien gestiona el presupuesto y el responsable de cada función cuyo trabajo cambia, además del responsable de entrega o de TI confirmando que se entienden los requisitos. La conformidad debería seguir a una sesión de recorrido, no a un correo de distribución.
¿Cuántos requisitos debe tener un BRD?
Los que el alcance necesite de verdad, pero si estás por encima de unas ochenta, revisa si el detalle funcional se ha colado. Una señal útil es la proporción de Imprescindible: por encima de aproximadamente el 60%, la priorización no se ha hecho correctamente.
¿Qué es una matriz de trazabilidad?
Una tabla que vincula cada requisito con el objetivo del negocio al que sirve, la especificación funcional que lo aborda y el caso de prueba que lo verifica. Detecta los requisitos que nunca se probarán y el trabajo que se construye sin trazarse a ningún requisito.
¿Puedo personalizar esta plantilla de documento de requisitos del negocio?
Sí, cada versión se puede editar completamente. Elimina las secciones que no apliquen en lugar de dejar encabezados vacíos y adapta la tabla de requisitos a tu propio esquema de prioridad si no usas MoSCoW. En Trupeer AI también puedes aplicar tu kit de marca para que el BRD coincida con el resto de documentación de tu proyecto.
