Cómo organizar los requisitos como analista de negocios

Un requisito empresarial es un documento formal que recoge las necesidades de las partes interesadas para un proyecto o producto. No existe un formato estándar único para presentar los requisitos empresariales, pero cada versión debe abarcar el producto o proyecto con suficiente detalle para poder discutirlo, analizarlo, documentarlo y validarlo.

Un requisito comercial puede presentarse de cualquiera de las siguientes maneras:

• Una tabla o una hoja de cálculo.
• Un diagrama (flujo de trabajo)
• Un gráfico
• Un modelo (diagrama entidad-relación)
• Un prototipo o simulación.
• Una oración estructurada o una plantilla de texto.

Cómo organizar y presentar un requisito comercial

A continuación se detallan los pasos para escribir y organizar los requisitos como un Business Analyst.

Paso 1) Clasifique los requisitos.

• Coloca cada requisito en la categoría a la que pertenece.
• Las partes interesadas con conocimientos técnicos deben ver una categoría de requisito técnico, y las partes interesadas sin conocimientos técnicos deben ver una categoría de requisito empresarial o genérico.
• Cada organización debe decidir qué categorías se ajustan a sus propios estándares.
• La categorización también puede basarse en el tipo de requisito —funcional frente a empresarial—, aunque esta división no se ajusta a todos los proyectos.

Paso 2) Organizar requisitos.
Recopile y organice los requisitos en un orden lógico para que las partes interesadas puedan navegar fácilmente por el documento e identificar los elementos que faltan.

Paso 3) Prepara una lista.
Prepare una lista de revisión de los requisitos, agrupados por las partes interesadas que deben aprobarlos.

Por ejemplo, a una persona interesada con formación técnica solo le importará el aspecto técnico del producto.

Paso 4) Utilice identificadores únicos.
If traces difícil cumplir con los requisitos entre sí, utilice identificadores únicos para hacerlo tracfacilidad.

Paso 5) Presentar los requisitos utilizando el método preferido por la parte interesada.
Es posible que deba presentar el mismo requisito en diferentes formatos para diferentes partes interesadas: una prefiere una vista gráfica, mientras que otra prefiere oraciones estructuradas.

Paso 6) Prepare una tabla de contenido.
Crea una tabla de contenido para todos los requisitos. Esto ayuda a las partes interesadas. track y localizarlos rápidamente.

Paso 7) Utilice herramientas de análisis empresarial.
Usar Herramientas de análisis empresarial que ayudan a presentar y categorizar los requisitos de forma coherente en todas las versiones.

Paso 8) Organice los documentos de requisitos por flujo de proceso.
Elimine los requisitos innecesarios del documento y organice los restantes según el flujo de procesos al que dan soporte.

Paso 9) Mapear los requisitos.
Asigne a cada requisito recopilado un paso específico en el flujo del proceso para que los revisores puedan relacionar el requisito con el flujo de trabajo al que da soporte.

Paso 10) Utilice tablas y viñetas.
Utilice tablas para presentar requisitos complejos y viñetas para resaltar los aspectos clave de cada uno.

Consejos útiles para redactar y presentar un documento de requisitos empresariales.

Para una mejor presentación y tracEn cuanto a los requisitos empresariales, los siguientes consejos son útiles para cualquier analista de negocios (BA).

• La categorización de los requisitos consume mucho tiempo, por lo que conviene definir un conjunto estándar de categorías que los analistas de negocio, las partes interesadas, los expertos en la materia y los equipos técnicos puedan reutilizar en diferentes proyectos, en lugar de inventar nuevas categorías cada vez.
• Prepare cada requisito teniendo en cuenta su público objetivo. Comprenda a los actores clave, las personas influyentes y los responsables de la toma de decisiones (partes interesadas, personal técnico, desarrolladores, etc.).
• Defina un requisito a la vez. Cada requisito debe ser un elemento atómico.
• Evite la ambigüedad: no utilice calificadores vagos como "etc." o "aprox." en una declaración de requisitos.
• No haga referencia a un requisito que aún no se haya definido.
• Elimine del documento las declaraciones duplicadas y contradictorias.
• Divide los requisitos complejos en puntos más pequeños, manejables y revisables.
• Describir Lo que El sistema lo hará, no cómo Lo hará; la implementación pertenece a la fase de diseño.

Técnicas populares para visualizar los requisitos empresariales

Un texto extenso es la forma más rápida de perder a un interesado. Los analistas de negocio combinan cada requisito textual con una representación visual para que la intención quede clara de un vistazo. Las siguientes técnicas aparecen en la Guía BABOK y en la mayoría de las prácticas de análisis de negocio empresariales.

• Modelo y Notación de Procesos de Negocio (BPMN): Diagrama procesos de negocio de principio a fin con grupos, carriles, puertas de enlace y eventos. BPMN es ideal para mostrar quién hace qué y cuándo.
• Diagramas de casos de uso y Descriptiones: Captura las interacciones entre actores y sistemas, así como los resultados que espera cada actor. Ideal para listas de tareas pendientes basadas en funcionalidades.
• Historias de usuario con criterios de aceptación: Declaraciones breves del tipo “Como… quiero… para que…” combinadas con criterios de tipo Dado-Cuando-Entonces. El formato predeterminado en los equipos ágiles.
• Estructuras y maquetas: Pantallas de baja o media fidelidad producidas en Figma, Balsamiq o Axure que hacen que los requisitos de la interfaz de usuario sean tangibles para las partes interesadas no técnicas.
• Diagramas de Entidad-Relación (DER): Muestre las entidades de datos que la solución debe almacenar y las relaciones entre ellas, algo fundamental para los requisitos de informes e integración.
• Diagramas de flujo de datos (DFD): Tracy cómo se mueven los datos a través de procesos, almacenes y agentes externos, especialmente en proyectos de análisis o integración.

Adapta la técnica al público objetivo: los ejecutivos responden mejor a los mapas de procesos y diagramas de recorrido del usuario, los desarrolladores responden mejor a los diagramas entidad-relación (DER) y las historias de usuario, y los usuarios finales responden mejor a los wireframes y prototipos.

Herramientas comunes para organizar documentos de requisitos empresariales

Una vez que el número de requisitos supera las dos docenas, un documento de Word deja de ser escalable. Los analistas de negocios pasan a herramientas diseñadas específicamente para ello que admiten la definición de líneas base, la revisión, traccapacidad y control de cambios. Los siguientes son los más utilizados en la industria.

• Jira con Confluence: La combinación predeterminada para equipos ágiles. Los requisitos se gestionan como épicas e historias en Jira, respaldadas por páginas de Confluence que contienen la narrativa y los diagramas del BRD (Derecho de Negocio).
• Jama Connect: Plataforma empresarial centrada en la gestión de requisitos, la definición de líneas base y la gestión en tiempo real. tracCapacidad para sectores regulados como los dispositivos médicos y la industria aeroespacial.
• IBM Engineering Requirements PUERTAS de administración: Herramienta de larga tradición utilizada en sistemas de defensa, automoción y sistemas críticos de seguridad donde se debe cumplir cada requisito. traccapaz.
• Modern Requirements por la Azure DevOps: Se extiende Azure DevOps con revisión, aprobación, definición de líneas base y exportación de BRD en formato Word directamente desde los elementos de trabajo.
• Miro or Lucidchart: Se utilizan pizarras blancas y herramientas de diagramación para elaborar diagramas BPMN, diagramas entidad-relación (DER), mapas de experiencia del usuario y notas de talleres que posteriormente sirven de base para el documento formal de requisitos de negocio (BRD).
• Balsamiq y Figma: Herramientas de wireframing y prototipado que mantienen los requisitos de la interfaz de usuario visuales en lugar de textuales.

Elija el conjunto de herramientas que se ajuste a la escala del proyecto y a las necesidades de auditoría. Los proyectos más pequeños pueden comenzar con Confluence y Jira, mientras que los programas regulados generalmente necesitan Jama o DOORS para satisfacer tracauditorías de accesibilidad.

Errores comunes al presentar los requisitos empresariales

Incluso un requisito bien fundamentado puede ser rechazado si se presenta de forma deficiente. Los siguientes errores son comunes en la mayoría de los análisis posteriores a la implementación de proyectos y son los que se deben evitar durante la revisión.

• Mezclar qué y cómo: Resbalónping Incluir detalles de implementación en la declaración de requisitos obliga al equipo de diseño a adoptar una solución antes de que finalice el análisis.
• Redacción ambigua: Palabras como «rápido», «fácil de usar» o «flexible» no son verificables. Sustitúyalas por criterios de aceptación medibles.
• Un formato para cada parte interesada: Presentar la misma visión a ejecutivos, desarrolladores y usuarios finales generalmente no satisface a ninguno. Adapte el formato a la audiencia.
• Desaparecido traccapacidad: Los requisitos que no estén vinculados a los objetivos comerciales, los elementos de diseño y los casos de prueba no pueden justificarse cuando llega una solicitud de cambio.
• Sin priorización: Presentar cientos de requisitos sin utilizar MoSCoW, puntuación ponderada o un marco similar obliga a las partes interesadas a debatir sobre el alcance en lugar del valor.
• Documentos sobrecargados: Incluir todos los diagramas, registros y justificaciones en un único PDF de 200 páginas oculta los requisitos importantes. Divida el documento de requisitos de negocio (BRD) en secciones lógicas con un índice claro.
• omitirping cerrar sesión: Presentar el documento de requisitos comerciales sin un paso de aprobación formal deja la puerta abierta a la ampliación del alcance y a la búsqueda de culpables más adelante durante la entrega.

RevComparar el documento de requisitos comerciales (BRD) con esta lista antes de cada sesión con las partes interesadas permite detectar la mayoría de los problemas que provocan reelaboración en fases posteriores.

Preguntas Frecuentes