Plantilla de recopilación de requisitos: 7 trucos que uso en mis proyectos

Una plantilla de recopilación de requisitos se gana su lugar solo si obliga a tener pronto las conversaciones difíciles: quién firma, quién puede bloquear, cómo se ve el éxito y con qué rapidez debe responder el sistema. Esta guía es para directores de proyecto, analistas de negocio y responsables de SAP que necesitan una plantilla que aguante más allá del primer comité directivo. A continuación está el esquema completo que uso, con un responsable para cada sección, las cinco secciones que nunca me salto y siete trucos para entrevistas, priorización y cambios. Copie el esquema en su propio documento y complételo antes de que empiece el diseño.

Una vez vi cómo se venía abajo un proyecto de seis cifras porque nadie hizo bien los requisitos. El cliente esperaba una cosa. El equipo de desarrollo construyó otra. Todos acabaron cargando con la culpa, y ahí fue cuando me llamaron.

El patrón no es inusual. El informe Pulse of the Profession 2014 del PMI sobre la gestión de requisitos descubrió que el 47 % de los proyectos fallidos no alcanzó sus objetivos por una mala gestión de los requisitos. Lo he visto repetirse decenas de veces.

Yo mismo estuve a punto de meterme en la misma situación en un despliegue de sistema de gran tamaño. Las partes interesadas iban cada una por su lado. Los desarrolladores adivinaban. Nos detuvimos, armamos una plantilla de requisitos decente y entregamos lo que el negocio necesitaba, a tiempo y dentro del presupuesto.

La empresa de un amigo gastó 350 000 USD en un CRM a medida que nadie usa. Ventas necesitaba una cosa, marketing quería otra, y los desarrolladores construyeron lo que creían que todos querían.

Un cliente mío del sector sanitario desperdició 18 meses en la implementación de una historia clínica electrónica (EMR) que los médicos se negaron a usar. Nadie les había preguntado qué necesitaban en su trabajo diario. El proyecto se descartó y se volvió a empezar.

Descubrir tarde sale caro. Un estudio de la NASA sobre la escalada del costo de los errores encontró que un error de requisitos detectado en la integración y las pruebas costaba de 21 a 78 veces más de corregir que uno detectado durante los requisitos. Detectado en operaciones, el múltiplo iba de 29 a más de 1500. En un programa empresarial, esa es la diferencia entre un taller y una solicitud de cambio que vale cientos de miles.

1. RequisitosEl costo base de corregirloDetectado mientras los requisitos aún se están escribiendo
2. Integración y pruebasDe 21 a 78 veces el costoDetectado cuando el sistema ya está construido y en pruebas
3. OperacionesDe 29 a más de 1,500 veces el costoDetectado cuando el sistema ya está en producción

Fuente: Estudio de la NASA sobre la escalada del costo de los errores

Después de aprenderlo por las malas, estas son las cinco secciones que ninguna plantilla de requisitos debería omitir.

1. Resumen ejecutivo con bloque de firmas

Los ejecutivos ocupados no leerán un documento de requisitos de 30 páginas. Una vez tuve a un patrocinador que aprobó un proyecto sin entender lo que firmaba y luego perdió los estribos al ver el resultado. Manténgalo en una página: impacto en el negocio, calendario, recursos, beneficio esperado y un bloque de firmas en esa misma página, para que quienes aprueban no puedan alegar que se les escaparon los detalles críticos.

2. Mapa de roles e influencia

Una lista de nombres no basta. Necesita un mapa de poder: quién puede hundir el proyecto, a quién hay que consultar, a quién solo hay que mantener informado. En un trabajo anterior, llevábamos seis meses de desarrollo cuando llegó el área jurídica con requisitos que obligaron a rediseñar. A nadie se le había ocurrido incluirlos. Mapee todos los departamentos afectados, a su representante y su influencia.

3. Objetivos de negocio, no requisitos técnicos

¿Qué problema estamos resolviendo y cómo mediremos el éxito? Un cliente de manufactura implementó un software de inventario exactamente como se especificó, y ralentizó las operaciones del almacén en un 20 %. La plantilla debe obligar a las partes interesadas a definir el éxito del negocio con una línea base actual, no con una lista de funcionalidades.

4. Requisitos funcionales que los desarrolladores puedan usar

Deje la jerga. Haga que cada requisito sea específico y comprobable. «El sistema debe mejorar la experiencia del cliente» no sirve de nada. «Los usuarios deben poder procesar una devolución y emitir un reembolso en menos de 3 minutos» sí es un requisito. Si no puede verificar que se hizo, reescríbalo.

5. Requisitos no funcionales

Rendimiento, seguridad, cumplimiento, disponibilidad, escalabilidad. Es la sección que casi todos se saltan, y luego el sistema se cae bajo carga o no supera una auditoría de seguridad. Supe de un proyecto de retail en el que el sistema funcionó perfectamente hasta el Black Friday, cuando colapsó bajo la carga porque nadie había especificado requisitos de rendimiento. Escriba en cifras los tiempos de respuesta, la disponibilidad, los picos de usuarios y las obligaciones de cumplimiento.

Aquí está el esquema completo. Las cinco secciones anteriores están dentro de él, junto con los registros que lo mantienen vivo después de la firma.

Sección	Qué incluye	Responsable	Aprobado por
1. Resumen ejecutivo	Problema, impacto en el negocio, calendario, recursos, beneficio esperado. Una página con bloque de firmas	Patrocinador, redactado por el líder de análisis de negocio	Patrocinador y finanzas
2. Alcance y línea base de despliegue	Qué entra y qué no en el alcance, restricciones. Para SAP: Public Edition, Private Edition u on-premise	Director del programa	Comité directivo
3. Mapa de roles e influencia	Departamentos, representantes, nivel de influencia, consultar o informar	Líder de análisis de negocio	Patrocinador
4. Objetivos de negocio	Cada objetivo con un KPI, su línea base actual y una meta	Responsables de proceso	Patrocinador
5. Requisitos funcionales	ID (p. ej., REQ-FUN-023), descripción, origen, prioridad, criterios de aceptación, decisión de fit-to-standard	Líderes funcionales	Responsables de proceso
6. Requisitos no funcionales	Rendimiento, seguridad, cumplimiento, disponibilidad; para SAP, el enfoque de extensión para cada brecha	Arquitecto de soluciones	TI, seguridad y cumplimiento
7. Parking lot	Peticiones aplazadas, quién las hizo, fecha de la próxima revisión	Líder de análisis de negocio	Ninguno hasta que se promuevan
8. Registro de rechazados	Qué se rechazó, por qué, cuándo y quién	Líder de análisis de negocio	Patrocinador
9. Registro de cambios	Cada cambio posterior a la firma con su impacto en tiempo y costo	PMO	Comité de control de cambios

1. Use los cinco porqués en las entrevistas con las partes interesadas

Pregunte «¿qué necesita?» y obtendrá una lista de deseos. Pregunte mejor por el dolor: «¿Qué le dan ganas de tirar la computadora por la ventana?». Después pregunte por qué, y otra vez por qué, cinco veces. El requisito real suele ser distinto de la primera petición.

Tuve a una parte interesada que insistía en capacidades complejas de informes. Después de recorrer sus casos de uso reales, necesitaba tres paneles sencillos.

2. Cree un parking lot de requisitos

Buena parte de lo que piden las partes interesadas nunca se usará. Cuando alguien insiste en algo cuestionable, no discuto. Lo dejo en el parking lot y envío un recordatorio mensual preguntando si debe pasar a los requisitos activos. La mayoría se queda ahí para siempre.

3. Aplique la regla de tres con quienes cambian de opinión sin parar

Pueden cambiar de rumbo dos veces sin consecuencias. En el tercer cambio, le envían un correo a su jefe explicando el cambio y su impacto. Nadie quiere enviar ese correo. Los cambios se detienen.

4. Use la técnica de asignación de fondos para forzar la priorización

Dé a cada parte interesada 100 dólares virtuales para repartir entre todos los requisitos. No pueden tenerlo todo, así que ponen el dinero donde importa. Lo hice con un cliente de servicios financieros que tenía más de 200 requisitos «críticos». En una hora teníamos el top 20 real.

5. Numere cada requisito

Use un formato coherente, como REQ-FUN-023. Acaba con la confusión de «¿de qué requisito estamos hablando?» que hace perder tiempo en las reuniones. Registre el origen, quién lo pidió y por qué, para saber a quién llamar cuando haya que recortar elementos.

6. Repita los requisitos con el lenguaje de la parte interesada

Después de documentar, lea los requisitos a las partes interesadas con sus propias palabras. Construya un prototipo o un wireframe rápido para todo lo complejo antes de que empiece el desarrollo. Los malentendidos salen a la luz cuando todavía son baratos.

7. Documente lo que se rechazó

Alguien traerá de vuelta un requisito rechazado en el quinto mes. «Lo discutimos en abril, y esta es la razón por la que decidimos no hacerlo» termina esa conversación enseguida. Sin el registro, vuelve a tener la misma discusión.

Los siete trucos funcionan en cualquier proyecto. Los programas SAP necesitan tres cosas más en la plantilla.

El modelo de despliegue va en la línea base

Defina el modelo de despliegue antes de recopilar los requisitos funcionales: S/4HANA Cloud Public Edition (mediante GROW with SAP o RISE), Private Edition (normalmente mediante RISE) u on-premise. Condiciona lo que es posible. Public Edition no permite modificar el core, así que los requisitos que dependen de procesos no estándar deben replantearse o rechazarse. Private Edition y on-premise permiten más, a costa de un mayor esfuerzo de actualización.

Si recopila requisitos antes de esa decisión, reescribirá muchos de ellos cuando llegue.

Una decisión de extensión para cada brecha

El enfoque de Clean Core de SAP implica que cada brecha necesita una decisión registrada: configurarla, extenderla con APIs liberadas (on-stack con ABAP Cloud o side-by-side en SAP BTP) o rechazarla. En Public Edition lo impone el producto. En Private Edition y on-premise es una recomendación firme de SAP, y cada modificación que permita se convierte después en trabajo de actualización. Ponga la decisión en la sección 6 de la plantilla, junto al rendimiento y la seguridad, y dé a un arquitecto la autoridad para aprobarla. Mi guía de Clean Core explica los niveles.

La IA redacta, las personas deciden

La IA ya ayuda con el papeleo. SAP Cloud ALM ofrece una función de generación de requisitos que redacta requisitos a partir de las transcripciones de los talleres de fit-to-standard y los vuelca en una plantilla, y se paga mediante unidades de IA. Asistentes generales como Microsoft Copilot redactan resúmenes y actas a partir de las notas de las reuniones.

Las herramientas de redacción con IA ahorran tiempo real en el papeleo cuando el material de origen está limpio. No cambian la entrevista. Una persona sigue haciendo los cinco porqués. Y ninguna herramienta consigue que un jefe de departamento firme el resumen ejecutivo. La validación, la priorización y la aprobación siguen siendo trabajo humano.

Desarrollo de software. Añada restricciones técnicas, puntos de integración, flujos de usuario (los pasos reales que siguen los usuarios, no solo las funcionalidades) y criterios de aceptación de aprobado o suspendido. Lo pasamos por alto en un proyecto de portal de clientes y nos pasamos tres meses discutiendo si las funcionalidades «funcionaban bien».

Mejora de procesos. Mapee el estado actual con todas las soluciones provisionales desordenadas de las que la gente no habla en las reuniones, evalúe el impacto por rol y registre líneas base de rendimiento concretas. Un cliente de manufactura rehízo por completo su proceso de almacén sin líneas base. Seis meses después no podía demostrar la mejora ni justificar el gasto.

Selección de proveedores. Separe lo imprescindible de lo deseable, pondere los criterios de puntuación y detalle con minuciosidad casi dolorosa las expectativas de soporte e implementación. Vi a una empresa elegir un proveedor casi solo por las funcionalidades y las impresiones de la demo. Ignoró los requisitos de soporte y acabó con un sistema que no podía implementar sin pagar grandes honorarios adicionales de consultoría.

Para proyectos pequeños: Trello para mover los requisitos por las etapas de aprobación, Google Docs con comentarios para la revisión y Miro para el mapeo de procesos en los talleres.

Para programas empresariales: Jira con un complemento de gestión de requisitos, Confluence para documentos vivos (sus funciones de IA ahora van bajo la marca Rovo de Atlassian) y Modern Requirements si trabaja con Azure DevOps. En los programas SAP, SAP Cloud ALM reúne en un solo lugar los requisitos, las historias de usuario y los casos de prueba, vinculados a la hoja de ruta de SAP Activate.

La herramienta importa menos que la conexión. Vincule los requisitos con el plan del proyecto y los casos de prueba, y envíe notificaciones automáticas cuando un requisito cambie. «No sabía que eso había cambiado» acaba con más proyectos que unas herramientas deficientes. Una vez firmados los requisitos, mi guía para evitar el scope creep en las implementaciones de SAP explica cómo mantenerlos así, y las puertas de calidad de SAP muestran dónde encaja la aprobación de requisitos en el ciclo de gobierno.

Una plantilla que nadie abre después de la firma es puro teatro. Las que funcionan son cortas, tienen un responsable por sección y se actualizan cada vez que alguien cambia de opinión, que, en cualquier programa que merezca la pena, es cada semana.

¿Cuáles son las 5 etapas de la recopilación de requisitos?

1. Obtención: recopilar información mediante entrevistas, talleres y observación
2. Análisis: organizar, priorizar y resolver los conflictos entre requisitos
3. Documentación: redactar la especificación (BRD, FRD o historias de usuario, según el método)
4. Validación: confirmar que los requisitos reflejan necesidades reales y que pueden probarse
5. Gestión: hacer seguimiento de los cambios durante el resto del proyecto

Cada etapa se apoya en la anterior. Apresurar la obtención, como hace la mayoría de los equipos, genera problemas en todas las etapas siguientes.

¿Cuál es la diferencia entre un BRD y un FRD?

Un documento de requisitos de negocio (BRD) cubre las necesidades del negocio: antecedentes, objetivos, partes interesadas, restricciones y requisitos de alto nivel. Responde a «¿qué necesita el negocio?».

Un documento de requisitos funcionales (FRD) cubre cómo se comportará el sistema: historias de usuario, comportamiento del sistema, interfaces y criterios de aceptación. Responde a «¿qué debe hacer el sistema?».

Siempre empiezo por el BRD para lograr la alineación con el negocio antes del FRD. Los equipos que saltan directamente al FRD suelen construir un sistema técnicamente correcto que resuelve el problema equivocado.

¿Cuáles son los 3 tipos de requisitos?

1. Requisitos de negocio: por qué existe el proyecto, sus objetivos y sus medidas de éxito
2. Requisitos funcionales: lo que debe hacer el sistema
3. Requisitos no funcionales: lo bien que debe hacerlo (rendimiento, seguridad, escalabilidad, cumplimiento)

La mayoría de los fracasos de proyecto que he visto se deben a la falta de requisitos no funcionales. El sistema hace lo que se pidió y luego se cae con la carga real o no supera una auditoría de cumplimiento.

¿Cómo cambia el modelo de despliegue de SAP la recopilación de requisitos?

Defínalo primero. S/4HANA Cloud Public Edition no permite modificar el core, así que los requisitos basados en procesos no estándar tienen que replantearse o rechazarse. Private Edition y on-premise permiten más flexibilidad, pero cada modificación suma esfuerzo de actualización.

Si recopila requisitos funcionales antes de la decisión, rehará muchos de ellos. Añada una decisión de extensión registrada (configurar, extender mediante APIs liberadas o rechazar) para cada brecha.

¿Qué hace que un requisito sea comprobable?

Una condición clara y medible de aprobado o suspendido. «El sistema debe ser rápido» no es comprobable. «Los resultados de búsqueda deben devolverse en menos de 2 segundos para el 95 % de las consultas con carga estándar» sí lo es.

Mi prueba: ¿puede escribir el caso de prueba ahora mismo, con criterios claros de aprobado o suspendido? Si no, reescriba el requisito. Los requisitos no comprobables causan más disputas en el go-live que cualquier otra cosa que yo vea.

¿Cómo se evita que los requisitos cambien constantemente?

1. Control de cambios: cualquier cambio posterior a la firma documenta su impacto en tiempo, presupuesto y recursos antes de que nadie lo apruebe. Haga visible el costo del cambio.
2. Parking lot: las nuevas peticiones van al parking lot, no directamente al alcance. Revíselo cada mes. La mayoría de las peticiones que parecen urgentes no sobreviven a la espera.
3. Puertas de calidad: defina qué significa «requisitos completos» y no empiece el diseño hasta que se cumpla.

En los programas SAP, la decisión de extensión añade una comprobación técnica adicional: una petición que necesita una modificación del core debe pasar por el arquitecto antes de poder aprobarse.