Los requisitos de negocio , también conocidos como especificaciones de requisitos de las partes interesadas (StRS), describen las características de un sistema propuesto desde el punto de vista del usuario final del sistema, como un CONOPS . Los productos, sistemas, software y procesos son formas de entregar , satisfacer o cumplir con los requisitos de negocio. En consecuencia, los requisitos de negocio a menudo se discuten en el contexto del desarrollo o adquisición de software u otros sistemas.
Hay tres razones principales para tales discusiones:
Para Goldsmith, Robin F, estas son confusiones que se pueden evitar reconociendo que los requisitos de negocio no son objetivos, sino que cumplen objetivos (es decir, proporcionan valor) cuando se satisfacen. Los requisitos de negocio 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 de negocio, presumiblemente, cómo satisfacer qué . Los requisitos de negocio existen dentro del entorno empresarial y deben descubrirse, mientras que los requisitos de producto son definidos por humanos (especificados). Los requisitos de negocio no se limitan a la existencia de alto nivel, sino que deben ser detallados. Sin embargo, independientemente de su nivel de detalle, los requisitos de negocio siempre son entregables de negocio qué que proporcionan valor cuando se satisfacen; llevarlos al detalle nunca convierte los requisitos de negocio en requisitos de producto. [2]
En los proyectos de desarrollo de sistemas o software, los requisitos empresariales suelen requerir la autorización de las partes interesadas. Esto suele conducir a la creación o actualización de un producto, sistema o software. Los requisitos de producto/sistema/software suelen constar de requisitos funcionales y no funcionales . Aunque normalmente se definen junto con la funcionalidad del producto/sistema/software (características y uso), los requisitos no funcionales suelen reflejar en realidad una forma de requisitos empresariales que a veces se consideran limitaciones. Estos pueden incluir aspectos necesarios de rendimiento, seguridad o protección que se aplican a nivel empresarial.
Los requisitos de negocio suelen estar incluidos en un Documento de Requisitos de Negocio o BRD. El énfasis en un BRD está en el proceso o actividad de acceder con precisión a la planificación y desarrollo de los requisitos, en lugar de en cómo lograrlo; esto suele delegarse en una Especificación o Documento de Requisitos de Sistemas (SRS o SRD), u otra variación 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 de negocio y requisitos de sistema. En consecuencia, muchos BRD en realidad describen los requisitos de un producto, sistema o software.
Los requisitos de negocio en el contexto de la ingeniería de software o el ciclo de vida del desarrollo de software , es el concepto de obtener y documentar los requisitos de negocio de los usuarios de negocio, como clientes, empleados y proveedores, en las primeras etapas del ciclo de desarrollo de un sistema para guiar el diseño del futuro sistema. Los requisitos de negocio suelen ser capturados por analistas de negocio , que analizan las actividades y los procesos de negocio y, a menudo, estudian el proceso "tal como está" para definir un proceso "futuro" objetivo.
Los requisitos comerciales a menudo incluyen:
Los requisitos comerciales generalmente los definen los analistas comerciales en colaboración con otras partes interesadas del proyecto .
Ambas partes pueden ser responsables de determinar los requisitos comerciales y desarrollar soluciones técnicas. Los analistas comerciales suelen participar en el desarrollo del enfoque de implementación y en la gestión del impacto en todas las áreas comerciales, incluida la participación de las partes interesadas y la gestión de riesgos.
La creación de prototipos con pruebas en las primeras etapas permite evaluar la integridad y precisión de los requisitos empresariales capturados. Las partes interesadas intervienen desde el principio para ayudar a definir los requisitos y el resultado se envía a los equipos de desarrollo del proyecto que construyen el sistema empresarial; otras partes interesadas prueban y evalúan el sistema final implementado. La claridad requiere realizar un seguimiento de los requisitos y su solución, con un proceso formal para determinar el uso adecuado de la plantilla . El alcance de los requisitos empresariales no se limita necesariamente a la etapa de definición de lo que se debe construir como sistema empresarial. Va más allá, para prever cómo se gestiona y mantiene un sistema empresarial en funcionamiento y para garantizar que se mantenga alineado con los objetivos o la estrategia empresariales. Un documento de requisitos empresariales debe revisarse constantemente de forma controlada. Tener un formato estandarizado o plantillas diseñadas para funciones y dominios empresariales específicos puede garantizar la integridad de los requisitos empresariales, además de mantener el alcance en foco.
Aunque se considera comúnmente un medio para evaluar los requisitos, la creación de prototipos en realidad suele desviar la atención de los requisitos empresariales al producto, sistema o software que se está construyendo. Los prototipos son software funcional, lo que significa que están a tres pasos (requisitos del producto/sistema/software, diseño técnico/de ingeniería de dicho producto/sistema/software e implementación del diseño en código de programa) de los requisitos empresariales. Los prototipos son versiones preliminares del software que el desarrollador pretende implementar. Debido a que los prototipos son bastante concretos, las partes interesadas que prueban el prototipo pueden dar una retroalimentación más significativa sobre algunos aspectos de lo que el desarrollador está creando, que es la interpretación del desarrollador de una forma de satisfacer los requisitos empresariales, no los requisitos empresariales. Además, para crear un prototipo de manera temprana y rápida, se hace hincapié en la interfaz gráfica de usuario (GUI) y se toman como atajos las "entrañas". Las entrañas son la mayor parte de la lógica del programa y es donde se abordarían la mayoría de los requisitos empresariales. En otras palabras, es muy poco probable que los problemas que revelan los prototipos involucren requisitos empresariales.
Es importante reconocer los cambios en los requisitos, documentarlos y mantener actualizada la definición de los mismos. Sin embargo, los requisitos de negocio tienden a no cambiar tanto como el conocimiento de los mismos. Un requisito de negocio puede estar presente, pero no ser reconocido o comprendido por las partes interesadas, los analistas y el equipo del proyecto. El cambio es más evidente en lo que se refiere a lo que se suele denominar "cambios de requisitos": los requisitos del producto/sistema/software. Estos tienden a reflejar las supuestas formas de satisfacer los requisitos de negocio identificados de forma inadecuada. Gran parte de las dificultades atribuidas al logro de los requisitos de negocio reflejan de hecho la práctica común de dedicar casi todo el esfuerzo de "requisitos" a lo que en realidad es el diseño de alto nivel de un producto, sistema o software. Esto se debe a que no se definen adecuadamente primero los requisitos de negocio que el producto/sistema/software debe satisfacer para proporcionar valor. Las prácticas de desarrollo suelen seguir revisando el producto/sistema/software hasta que finalmente "vuelven" a una solución que parece hacer lo que se necesita, es decir, aparentemente aborda un requisito de negocio. Estas costosas formas indirectas de prueba y error para identificar los requisitos del negocio son la base de gran parte del "desarrollo iterativo", incluidos los populares métodos de desarrollo ágil, que se promocionan como "mejores prácticas".
Las plantillas ayudan a generar consultas sobre temas específicos que a menudo pueden ser relevantes para los requisitos empresariales. Pueden fomentar la documentación estandarizada sobre los requisitos empresariales, lo que puede facilitar la comprensión. Las plantillas no garantizan la precisión ni la integridad de los requisitos empresariales. De hecho, las plantillas, que suelen utilizarse de forma incorrecta, suelen tener un impacto negativo en la investigación de los requisitos, ya que tienden a promover la superficialidad y la definición principalmente mecánica sin un análisis significativo.
Los requisitos empresariales suelen endurecerse prematuramente debido a la gran base de partes interesadas implicadas en la definición de los requisitos, donde existe un potencial de conflicto de intereses. El proceso de gestión y creación de consenso puede ser delicado e incluso político por naturaleza. 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 unidades de fabricación; finanzas y RR.HH. , incluida la alta dirección, están más cerca de la sede registrada. Un sistema, por ejemplo, que involucra a usuarios de ventas y producción puede ver un conflicto de propósitos: una parte puede estar interesada en ofrecer la máxima cantidad de características, mientras que la otra puede centrarse en el menor costo de producción . Este tipo de situaciones a menudo terminan en un consenso con la máxima cantidad de características por un costo de producción y distribución razonable y rentable.
Para abordar estos desafíos, la aceptación de las partes interesadas en una etapa temprana se logra mediante la demostración de prototipos y el trabajo conjunto. Los talleres para las partes interesadas son comunes, ya sea como sesiones facilitadas o simples debates en grupo, para ayudar a lograr el consenso, especialmente para requisitos comerciales sensibles y donde existe un potencial 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 pautas internas de toda la empresa, como la marca o los compromisos corporativos con la responsabilidad social. El análisis de los requisitos comerciales no se trata solo de capturar el "qué" de un proceso comercial junto con el "cómo" para proporcionar su contexto. Es posible que sea necesario abordar la traducción al diseño y la construcción de un sistema funcional. En esta etapa, los requisitos comerciales deben reconocer los detalles técnicos y la viabilidad.
No siempre se necesita una solución personalizada para cada nuevo conjunto de requisitos empresariales. A menudo existen procesos y productos estandarizados que, con algunos ajustes o personalizaciones, pueden servir para abordar los requisitos empresariales. El sistema empresarial de destino suele estar limitado por una elección de tecnología específica, un presupuesto o productos disponibles ya implementados.
Por último, la estandarización del formato puede causar dificultades. La existencia de múltiples proyectos con múltiples formatos que dan lugar a variaciones en la estructura y el contenido de un documento de requisitos hace que estos sean ineficaces desde una perspectiva de trazabilidad y manejabilidad. De hecho, al crear una plantilla para su uso en un ejercicio de recopilación de requisitos multifuncional, puede resultar difícil para diferentes funciones con conocimientos complementarios trabajar dentro de un formato común. Por lo tanto, es fundamental permitir que las partes interesadas no especializadas o no expertas proporcionen requisitos adicionales mediante apéndices y anexos adicionales para cubrir su área de especificación. Abordar los diversos matices y llegar a un ajuste óptimo sigue siendo el mayor desafío para unos requisitos eficaces.
Incluye los siguientes pasos:
{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )