Requisitos del negocio

Los requisitos empresariales (RE) , también conocidos como especificaciones de requisitos de las partes interesadas (ERPI), describen las características de un sistema propuesto desde la perspectiva del usuario final, al igual que un CONOPS . Los productos, sistemas, software y procesos son formas de entregar , satisfacer o cumplir con los requisitos empresariales. Por consiguiente, los requisitos empresariales suelen analizarse en el contexto del desarrollo o la adquisición de software u otros sistemas.

Tres razones principales para tales discusiones:

1. Una práctica común es referirse a los objetivos, o beneficios esperados, como "requisitos empresariales". ^{[ 1 ]}
2. Es común que la gente utilice el término "requisitos" para describir las características del producto, sistema o software que se espera crear.
3. Un modelo ampliamente aceptado sostiene que estos dos tipos de requisitos se diferencian únicamente en su nivel de detalle o abstracción: los "requisitos empresariales" son de alto nivel, frecuentemente vagos, y se descomponen en los requisitos detallados del producto, del sistema o del software.

Para Robin F. Goldsmith, estas confusiones pueden evitarse reconociendo que los requisitos empresariales no son objetivos, sino que, al satisfacerse, cumplen objetivos (es decir, aportan valor). Los requisitos empresariales ( qué) no se descomponen en requisitos de producto/sistema/software (cómo ). Más bien, los productos y sus requisitos representan una respuesta a los requisitos empresariales, presumiblemente, cómo satisfacer qué . Los requisitos empresariales existen dentro del entorno empresarial y deben descubrirse, mientras que los requisitos de producto son definidos (especificados) por el ser humano. Los requisitos empresariales no se limitan a una existencia de alto nivel, sino que deben desglosarse en detalles. Sin embargo, independientemente de su nivel de detalle, los requisitos empresariales siempre son entregables empresariales (qué) que aportan valor al satisfacerse; desglosarlos nunca convierte los requisitos empresariales en requisitos de producto. ^{[ 2 ]}

En los proyectos de desarrollo de sistemas o software, los requisitos empresariales suelen requerir la aprobación de las partes interesadas. Esto generalmente conlleva la creación o actualización de un producto, sistema o software. Los requisitos del producto, sistema o software suelen constar de requisitos funcionales y no funcionales . Si bien se definen habitualmente en relación con la funcionalidad del producto, sistema o software (características y uso), los requisitos no funcionales a menudo reflejan una forma de requisitos empresariales que, en ocasiones, se consideran restricciones. Estos podrían incluir aspectos necesarios de rendimiento, seguridad o protección que se aplican a nivel empresarial.

Los requisitos empresariales suelen figurar en un Documento de Requisitos Empresariales (BRD, por sus siglas en inglés). El énfasis en un BRD se centra en el proceso o la actividad de acceso preciso a la planificación y el desarrollo de los requisitos, en lugar de en cómo lograrlos; esta tarea suele delegarse a una Especificación o Documento de Requisitos del Sistema (SRS o SRD, por sus siglas en inglés), u otra variante como un Documento de Especificación Funcional. Puede surgir confusión entre un BRD y un SRD cuando se ignora la distinción entre requisitos empresariales y requisitos del sistema. En consecuencia, muchos BRD describen en realidad los requisitos de un producto, sistema o software.

En el contexto de la ingeniería de software o el ciclo de vida del desarrollo de software , los requisitos empresariales consisten en obtener y documentar las necesidades de los usuarios, como clientes, empleados y proveedores, al inicio del ciclo de desarrollo de un sistema, con el fin de guiar el diseño del sistema futuro. Estos requisitos suelen ser recopilados por analistas de negocio , quienes analizan las actividades y los procesos empresariales y, a menudo, estudian el proceso actual para definir el proceso futuro deseado.

Los requisitos empresariales a menudo incluyen:

• Contexto, alcance y antecedentes del negocio, incluyendo razones ^{[ 3 ]} para el cambio.
• Partes interesadas clave del negocio que tienen requisitos
• Factores de éxito para un estado futuro/objetivo
• Restricciones impuestas por el negocio u otros sistemas
• Modelos y análisis de procesos de negocio, a menudo utilizando notaciones de diagramas de flujo para representar los procesos de negocio "tal como están" y "tal como van a ser".
• Modelos de datos conceptuales y referencias al diccionario de datos
• Glosarios de términos comerciales y jerga local
• Diagramas de flujo de datos para ilustrar cómo fluyen los datos a través de los sistemas de información (a diferencia de los diagramas de flujo que representan el flujo algorítmico de las actividades empresariales).

Los requisitos empresariales suelen endurecerse prematuramente debido a la gran cantidad de partes interesadas involucradas en su definición, lo que puede generar conflictos de intereses. El proceso de gestión y creación de consenso puede ser delicado e incluso político. Un desafío menor, aunque común, es el de los equipos distribuidos con partes interesadas en múltiples ubicaciones geográficas. Es natural que el personal de ventas esté más cerca de sus clientes, mientras que el personal de producción esté más cerca de las plantas de fabricación; finanzas y recursos humanos , incluyendo la alta dirección, están más cerca de la sede central. Un sistema, por ejemplo, que involucre a usuarios de ventas y producción, puede presentar un conflicto de objetivos: una parte puede estar interesada en ofrecer el máximo de funcionalidades, mientras que la otra puede centrarse en el menor coste de producción . Este tipo de situaciones suelen culminar en un consenso que ofrece el máximo de funcionalidades a un coste de producción y distribución razonable y rentable.

Para abordar estos desafíos, la aceptación de las partes interesadas en la etapa inicial se logra mediante la demostración de prototipos y el trabajo conjunto. Los talleres con las partes interesadas son comunes, ya sea como sesiones facilitadas o simples discusiones informales, para ayudar a lograr el consenso, especialmente para requisitos comerciales delicados y donde existe un posible conflicto de intereses. La complejidad de un proceso comercial es un factor. Esto puede implicar conocimientos especializados necesarios para comprender los requisitos legales o reglamentarios, las directrices internas de toda la empresa, como la marca o los compromisos corporativos con la responsabilidad social. El análisis de requisitos comerciales no se trata solo de capturar el "qué" de un proceso comercial junto con el "cómo" para proporcionar su contexto. Puede ser necesario abordar la traducción al diseño y la construcción de un sistema funcional. En esta etapa, los requisitos comerciales deben considerar los detalles técnicos y la viabilidad.

No siempre se requiere una solución a medida para cada nuevo conjunto de requisitos empresariales. A menudo existen procesos y productos estandarizados que, con algunos ajustes o personalizaciones, pueden satisfacer las necesidades del negocio. El sistema empresarial objetivo suele estar condicionado por una tecnología específica, un presupuesto limitado o los productos ya implementados.

Finalmente, la estandarización del formato puede generar dificultades. Múltiples proyectos con diversos formatos, que dan lugar a variaciones en la estructura y el contenido de un documento de requisitos, los vuelven ineficaces desde la perspectiva de la trazabilidad y la gestión. De hecho, al crear una plantilla para un ejercicio de recopilación de requisitos multifuncional, diferentes roles con conocimientos complementarios pueden tener dificultades para trabajar con un formato común. Por lo tanto, es fundamental permitir que las partes interesadas no especializadas o no expertas aporten requisitos adicionales mediante apéndices y anexos para cubrir su área de especialización. Abordar los diversos matices y encontrar la solución óptima sigue siendo el mayor desafío para la eficacia de los requisitos.

Incluye los siguientes pasos:

1. Definición de negocio
2. Comprender el/los dominio(s) empresarial(es)
3. Objetivos de la organización
4. Competencia básica

• Ciclo de vida del desarrollo de sistemas
• Ingeniería de sistemas
• proceso de desarrollo de software
• analista de negocios
• Especificación de requisitos de software
• Análisis de requisitos
• Requisito
• Prototipado de software
• Análisis empresarial

• Beal, Adriana. Requisito es lo que tenemos que hacer para lograr un objetivo. www.bealprojects.com , 2012
• Goldsmith, Robin F. Descubriendo los requisitos empresariales reales para el éxito de un proyecto de software . Artech House, 2004.
• Project Management Institute (2021). Guía de los fundamentos de la gestión de proyectos (Guía PMBOK) . Project Management Institute (7.ª  ed.). Newtown Square, PA. ISBN 978-1-62825-664-2.{{cite book}}: CS1 mantenimiento: falta el editor de ubicación ( enlace )
• Robertson, Suzanne y James C. Robertson. Dominando el proceso de requisitos . 2.ª edición, Addison-Wesley, 2006.