Los requisitos comerciales , 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 comerciales. En consecuencia, los requisitos comerciales a menudo se analizan en el contexto del desarrollo o adquisición de software u otros sistemas.
Tres razones principales para tales discusiones:
Para Goldsmith, Robin F, estas son confusiones que pueden evitarse reconociendo que los requisitos de negocio no son objetivos, sino más bien cumplir objetivos (es decir, proporcionar valor) cuando se satisfacen. Los requisitos comerciales no se descomponen en requisitos de producto/sistema/software . Más bien, los productos y sus requisitos representan una respuesta a los requisitos del negocio (presumiblemente, cómo satisfacer qué) . Los requisitos comerciales existen dentro del entorno empresarial y deben descubrirse, mientras que los requisitos del producto están definidos (especificados) por humanos. Los requisitos comerciales no se limitan a la existencia de alto nivel, sino que deben reducirse al detalle. Sin embargo, independientemente de su nivel de detalle, los requisitos comerciales siempre son entregables y aportan valor cuando se satisfacen; Reducirlos al detalle nunca convierte los requisitos del negocio en requisitos del producto. [2]
En proyectos de desarrollo de sistemas o software, los requisitos comerciales generalmente requieren la autoridad de las partes interesadas. Normalmente, esto conduce a la creación o actualización de un producto, sistema o software. Los requisitos del producto/sistema/software suelen consistir tanto en requisitos funcionales como en requisitos no funcionales . Aunque normalmente se definen junto con la funcionalidad del producto/sistema/software (características y uso), los requisitos no funcionales a menudo reflejan en realidad una forma de requisitos comerciales que a veces se consideran restricciones. Estos podrían incluir aspectos necesarios de rendimiento, seguridad o protección que se apliquen a nivel empresarial.
Los requisitos comerciales a menudo se enumeran en un Documento de requisitos comerciales o BRD. El énfasis en un BRD está en el proceso o actividad de acceder con precisión a la planificación y el desarrollo de los requisitos, más que en cómo lograrlo; esto generalmente se delega a una Especificación o Documento de Requisitos del Sistema (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 no se tiene en cuenta la distinción entre requisitos comerciales y requisitos del sistema. En consecuencia, muchos BRD en realidad describen los requisitos de un producto, sistema o software.
Los requisitos comerciales 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 comerciales de los usuarios comerciales, 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 comerciales a menudo son capturados por analistas comerciales , que analizan las actividades y procesos comerciales y, a menudo, estudian el proceso "tal cual" para definir un proceso objetivo "futuro".
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 de negocios tienden a 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 etapas tempranas puede evaluar la integridad y precisión de los requisitos comerciales capturados. Las partes interesadas llegan temprano 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 implementado final. 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 comerciales no se limita necesariamente a la etapa de definición de lo que se debe construir como sistema comercial. Va más allá: prevé cómo se gestiona y mantiene un sistema empresarial en funcionamiento y garantiza su alineación con los objetivos o la estrategia empresarial. Un documento de requisitos comerciales debe revisarse constantemente de forma controlada. Tener un formato estandarizado o plantillas diseñadas para funciones y dominios comerciales específicos puede garantizar la integridad de los requisitos comerciales, además de mantener el alcance enfocado.
Aunque comúnmente se considera un medio para evaluar requisitos, la creación de prototipos generalmente desvía la atención de los requisitos comerciales al producto, sistema o software que se está construyendo. Los prototipos son software funcional, lo que significa que están separados de los requisitos comerciales en 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 el código del programa). 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 brindar comentarios más significativos sobre algunos aspectos de lo que el desarrollador está creando, que es la interpretación del desarrollador de una manera de satisfacer los requisitos del negocio, no los requisitos del negocio. Además, para crear un prototipo de manera temprana y rápida, se enfatiza la interfaz gráfica de usuario (GUI) y los "agallas" son atajos. 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 comerciales. En otras palabras, es muy poco probable que los problemas que revelan los prototipos involucren requisitos comerciales.
Es importante reconocer los cambios en los requisitos, documentarlos y mantener actualizada la definición de requisitos. Sin embargo, los requisitos empresariales tienden a no cambiar tanto como el conocimiento de ellos. Un requisito comercial puede estar presente, pero las partes interesadas, los analistas y el equipo del proyecto no lo reconocen ni lo comprenden. El cambio es más evidente con respecto a lo que normalmente se denomina "cambios de requisitos": los requisitos del producto/sistema/software. Estos tienden a reflejar las supuestas formas de satisfacer requisitos comerciales insuficientemente identificados. Gran parte de las dificultades atribuidas a la consecución de los requisitos empresariales reflejan de hecho la práctica común de dedicar casi todo el esfuerzo de los "requisitos" a lo que en realidad es un diseño de alto nivel de un producto, sistema o software. Esto se debe a que primero no se definen adecuadamente los requisitos comerciales que el producto/sistema/software debe satisfacer para proporcionar valor. Las prácticas de desarrollo comúnmente siguen revisando el producto/sistema/software hasta que eventualmente "vuelven" a una solución que parece hacer lo que se necesita, es decir, aparentemente aborda un requisito comercial. Estas costosas formas indirectas de prueba y error de identificar los requisitos empresariales son la base de gran parte del "desarrollo iterativo", incluidos los métodos populares de desarrollo ágil, que se promocionan como "mejores prácticas".
Las plantillas ayudan a generar consultas sobre temas particulares que a menudo pueden ser relevantes para los requisitos comerciales. Pueden fomentar la documentación estandarizada sobre los requisitos comerciales, lo que puede facilitar la comprensión. Las plantillas no garantizan la precisión ni la integridad de los requisitos comerciales. De hecho, las plantillas, comúnmente mal utilizadas, a menudo impactan negativamente la investigación de requisitos, ya que tienden a promover la superficialidad y principalmente la definición mecánica sin un análisis significativo.
Los requisitos comerciales a menudo se endurecen prematuramente debido a la gran base de partes interesadas involucradas en la definición de los requisitos, donde existe la posibilidad de que surjan conflictos 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 recursos humanos , incluida la alta dirección, están más cerca de la sede social. Un sistema, por ejemplo, que involucra a usuarios de ventas y producción puede tener un conflicto de propósitos: una parte puede estar interesada en ofrecer el máximo de funciones, mientras que la otra puede centrarse en el menor costo de producción . Este tipo de situaciones suelen terminar en un consenso con las máximas prestaciones por un coste de producción y distribución razonable y rentable.
Para abordar estos desafíos, la aceptación de las partes interesadas en las etapas iniciales 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 grupales, para ayudar a lograr consenso, especialmente para requisitos comerciales sensibles y donde existe un posible conflicto de intereses. La complejidad de un proceso de negocio 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 los requisitos empresariales no se trata sólo de capturar el "qué" de un proceso empresarial junto con el "cómo" proporcionar su contexto. Es posible que sea necesario abordar la traducción al diseño y construcción de un sistema que funcione. En esta etapa, los requisitos comerciales deben reconocer los detalles técnicos y la viabilidad.
No siempre se requiere una solución personalizada para cada nuevo conjunto de requisitos comerciales. A menudo existen procesos y productos estandarizados que, con algunos ajustes o personalización, pueden servir para abordar los requisitos comerciales. El sistema empresarial objetivo suele verse limitado por una elección tecnológica específica, un presupuesto o productos disponibles ya implementados.
Por último, la estandarización del formato puede causar dificultades. Múltiples proyectos con múltiples formatos que conducen a variaciones en la estructura y el contenido de un documento de requisitos los hacen ineficaces desde una perspectiva de trazabilidad y manejabilidad. De hecho, al crear una plantilla para usar en un ejercicio de recopilación de requisitos multifuncional, puede resultar difícil para diferentes roles con conocimientos complementarios trabajar dentro de un formato común. Por lo tanto, es crucial permitir que las partes interesadas no especializadas o expertas proporcionen requisitos adicionales mediante Apéndices y anexos adicionales para cubrir su área de especificación. Abordar diversos matices y llegar a la mejor solución sigue siendo el mayor desafío para lograr requisitos efectivos.
Incluye los siguientes pasos:
{{cite book}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace )