Mapa mental de recopilación de requisitos: plantilla gratis para analistas
Plantilla de mapa mental para recopilar requisitos: partes interesadas, necesidades de negocio y de usuario, requisitos funcionales y no funcionales y restricciones, en un lienzo editable.
Un mapa mental de recopilación de requisitos reúne en una página quién quiere qué, por qué y bajo qué límites, para que los huecos y los conflictos entre las partes interesadas aparezcan antes de empezar el diseño.
Mapa mental de recopilación de requisitos: plantilla gratis para analistas
El lienzo interactivo de MindMap de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este mapa mental
- Empieza por «Partes interesadas» y «Necesidades de negocio» para ver quién interviene y por qué. «Necesidades del usuario» describe la necesidad desde el lado del usuario, y «Requisitos funcionales» y «Requisitos no funcionales» la traducen en lo que el sistema debe hacer y con qué calidad.
- Las flechas discontinuas siguen el razonamiento. Por ejemplo, una capacidad de «Prioridad» se justifica con la medida de éxito de «Resultado deseado», y una necesidad de seguridad de «Seguridad y privacidad» puede chocar con un límite técnico de «Límites técnicos».
Partes interesadas
«Partes interesadas» abre el mapa porque detrás de cada requisito hay alguien. Anota en «Patrocinadores» quién paga, en «Usuarios finales» quién usará el resultado y en «Aprobadores y soporte» quién debe aprobarlo o respaldarlo.
Entrevista a todos los de «Usuarios finales», no solo a su jefe. Un error frecuente es redactar requisitos a partir de la descripción que hace el patrocinador de un trabajo que ya no realiza.
Necesidades de negocio
«Necesidades de negocio» explica por qué existe el proyecto. «Problema por resolver» es el problema o la oportunidad, «Resultado deseado» el resultado que se consideraría un éxito y «Medida de éxito» la medida que lo demuestra.
Todo requisito del resto del mapa debería remontarse a algo de aquí. Si alguno no lo hace, pregunta qué necesidad atiende o elimínalo.
Necesidades del usuario
«Necesidades del usuario» recoge lo que las personas necesitan lograr. Escribe «Tareas por completar» como tareas desde el punto de vista del usuario y anota en «Puntos de dolor actuales» los puntos de dolor de la forma actual de trabajar.
«Contexto de uso» contiene la situación en la que trabajan los usuarios, por ejemplo en el móvil, en lugares ruidosos o con presión de tiempo. Estos detalles suelen decidir el diseño más que las propias tareas.
Requisitos funcionales
«Requisitos funcionales» enumera lo que el sistema debe hacer. «Capacidades principales» son las capacidades principales, «Reglas de negocio» son las reglas que debe aplicar y «Interfaces» son las interfaces con otros sistemas o equipos.
Redacta cada uno de forma que se pueda probar, por ejemplo: el sistema envía una confirmación en menos de un minuto. Usa «Enunciado verificable» como modelo para redactar el detalle.
Requisitos no funcionales
«Requisitos no funcionales» abarca lo bien que debe funcionar el sistema. «Rendimiento» fija la velocidad y la capacidad, «Seguridad y privacidad» cubre la seguridad y la privacidad y «Usabilidad y acceso» cubre la usabilidad y la accesibilidad.
Son los requisitos que se olvida preguntar y que luego se discuten tras el lanzamiento. Asigna a cada uno un número o una norma siempre que sea posible.
Restricciones
«Restricciones» enumera los límites que la solución no puede cruzar. «Presupuesto y plazo» son el presupuesto y el plazo, «Límites técnicos» son los límites técnicos, como los sistemas existentes, y «Legal y normativa» son las obligaciones legales o de política interna.
Contrasta pronto cada requisito con «Límites técnicos». Un requisito que choca con una restricción firme es una decisión para el patrocinador, no una tarea para el equipo.
Cómo se conectan las ramas
Las necesidades fluyen hacia abajo. «Necesidades de negocio» da la razón, «Necesidades del usuario» da la visión del usuario, y «Requisitos funcionales» y «Requisitos no funcionales» son los requisitos que se derivan de ellas. Un requisito sin origen en las tres primeras ramas es candidato a eliminarse.
«Restricciones» empuja de vuelta hacia arriba. Una restricción puede hacer inasumible una necesidad, lo que te lleva de nuevo a «Necesidades de negocio» para preguntar si un resultado más pequeño es aceptable, y a «Partes interesadas» para acordarlo.
Dónde termina un mapa mental y empiezan otros diagramas
Usa el mapa mental para recopilar y organizar. Para describir cómo fluye el trabajo hoy y cómo debería fluir, dibuja un mapa de procesos o un diagrama de flujo, y usa un diagrama de carriles cuando los requisitos dependan de traspasos entre equipos.
Un organigrama puede documentar la estructura de las partes interesadas y las aprobaciones, y un diagrama de Gantt toma el relevo cuando los requisitos pasan a ser una entrega planificada.
Relaciones clave y conclusiones
- Todo requisito debería remontarse a una necesidad de negocio y a una parte interesada.
- Las necesidades del usuario se escriben como tareas, y los requisitos funcionales como comportamientos verificables.
- Los requisitos no funcionales son los que más a menudo faltan en los primeros borradores.
- Las restricciones las deciden personas, por eso también aparecen en las partes interesadas.
- Un requisito sin prioridad se tratará como igual de urgente que todos los demás.
Cuándo usar este diagrama
- Preparar entrevistas con las partes interesadas y registrar las respuestas en un mapa compartido.
- Revisar un borrador de documento de requisitos para detectar categorías ausentes antes de la aprobación.
- Definir el alcance de una pequeña herramienta interna para la que una especificación completa sería excesiva.
Cómo funciona
Identifica a las personas
Cambia el nombre de «Requisitos del proyecto», enumera las partes interesadas en «Partes interesadas» y marca con quién aún no has hablado. Entrevista antes de rellenar las demás ramas.
Recoge las necesidades según las oyes
Anota los motivos en «Necesidades de negocio», las tareas de los usuarios en «Necesidades del usuario» y el comportamiento del sistema en «Requisitos funcionales». Indica el origen en cada nodo para poder volver a comprobarlo.
Revisa límites y conflictos
Compara cada requisito con «Requisitos no funcionales» y «Restricciones», dibuja enlaces donde choquen y lleva los conflictos abiertos a las partes interesadas de «Partes interesadas».
Preguntas frecuentes
¿Qué diferencia hay entre requisitos funcionales y no funcionales?
Los requisitos funcionales dicen qué hace el sistema, como crear una factura o enviar una alerta. Los no funcionales dicen con qué calidad debe hacerlo: velocidad, seguridad, disponibilidad, accesibilidad. Se necesitan ambos, y los no funcionales suelen descubrirse tarde si no se preguntan directamente.
¿Por qué empezar por las partes interesadas y no por las funciones?
Porque cada requisito tiene un responsable que puede explicarlo y, si hace falta, cambiarlo. Empezar por las funciones da una lista que nadie puede defender ni priorizar. Empezar por las personas indica a quién entrevistar y quién debe ponerse de acuerdo cuando dos requisitos chocan.
¿Cuánto detalle deben tener los requisitos en un mapa mental?
Suficiente para reconocerlos y debatirlos, y lo bastante corto para leerlo de un vistazo. Usa la idea para un enunciado breve y la nota para el origen o la condición de prueba. Cuando una rama se sature, pásala a una especificación de requisitos o a un backlog de historias de usuario.
¿Pueden las partes interesadas revisar el mapa directamente?
Sí. Comparte el diagrama con los revisores, deja que comenten requisitos concretos y usa el historial de versiones para conservar un registro de lo que cambió entre rondas de revisión. Así la aprobación es más fiable que enviar documentos por correo de ida y vuelta.
Empezar con este mapa de requisitos
Abre la plantilla como tu propio lienzo, ponle nombre al proyecto y empieza enumerando las partes interesadas con las que necesitas hablar.