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 cómo entregar, satisfacer o cumplir con los requisitos comerciales. En consecuencia, los requisitos comerciales a menudo se analizan en el contexto del desarrollo o la adquisición de software u otros sistemas.
La confusión surge por tres razones principales.
- Una práctica común es referirse a los objetivos o beneficios esperados como "requisitos comerciales". [1]
- La gente suele utilizar el término "requisitos" para describir las características del producto, sistema y software que se espera crear.
- Un modelo ampliamente aceptado afirma que estos dos tipos de requisitos difieren solo en su nivel de detalle o abstracción, en el que los 'requisitos comerciales' son de alto nivel, con frecuencia vagos y se descomponen en requisitos detallados de producto, sistema o software.
Esta confusión puede evitarse reconociendo que los requisitos comerciales no son objetivos, sino que cumplen con los objetivos (es decir, proporcionan valor) cuando se satisfacen. Los requisitos de negocio cuál no se descomponen en el requisito del producto / sistema / software cómos . Más bien, los productos y sus requisitos representan una respuesta a los requisitos comerciales, presumiblemente, cómo satisfacer qué . Los requisitos comerciales existen dentro del entorno comercial y deben descubrirse, mientras que los requisitos del producto son definidos por el ser humano (especificados). Los requisitos comerciales no se limitan a la existencia de alto nivel, sino que deben reducirse a los detalles. Independientemente de su nivel de detalle, sin embargo, los requisitos comerciales son siempre entregables comerciales, lo que proporciona valor cuando se satisfacen; llevarlos hasta el último detalle nunca convierte los requisitos comerciales en requisitos de 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 generalmente consisten en requisitos funcionales y 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 una forma de requisitos comerciales que a veces se consideran restricciones. Estos podrían incluir aspectos necesarios de desempeño, seguridad o protección que se aplican 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 la 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 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 comerciales y requisitos del sistema. En consecuencia, muchos BRD realmente describen los requisitos de un producto, sistema o software.
Descripción general
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 los capturan los analistas comerciales , que analizan las actividades y los procesos comerciales y, a menudo, estudian el proceso "tal cual" para definir un proceso "futuro" objetivo.
Los requisitos comerciales a menudo incluyen
- Contexto, alcance y antecedentes comerciales, incluidas las razones del cambio
- Partes interesadas clave del negocio que tienen requisitos
- Factores de éxito para un estado futuro / objetivo
- Restricciones impuestas por la empresa u otros sistemas
- Modelos y análisis de procesos de negocio , que a menudo utilizan notaciones de diagrama de flujo para representar los procesos de negocio 'tal cual' y 'futuros'
- Modelos de datos conceptuales y referencias de diccionarios 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 (diferente de los diagramas de flujo que representan el flujo algorítmico de las actividades comerciales)
Temas de requisitos comerciales
Beneficios
DescripciónReducir el fracaso del proyecto | La explicación estructurada de un proceso o método empresarial definido al principio del ciclo de vida ayuda a reducir las fallas del proyecto que ocurren debido a requisitos mal alineados o mal representados que conducen al incumplimiento de las expectativas del usuario. |
Se conecta a objetivos comerciales más amplios | Los requisitos comerciales bien definidos ayudan a diseñar un estatuto del proyecto, un paso crítico en la ejecución de la estrategia comercial o los objetivos comerciales, y llevarlo al siguiente paso lógico de desarrollarlo en un sistema de TI. Esto ayuda a monitorear el estado general del proyecto y proporciona una tracción positiva con las partes interesadas clave del proyecto, incluidos los patrocinadores. |
Creación de consenso y colaboración | El beneficio de un formato estructurado típico de la documentación de requisitos comerciales ayuda a crear un consenso positivo y una mejor colaboración donde el grupo de partes interesadas del negocio puede ser un gran equipo multifuncional, distribuido geográficamente. |
Ahorra costos | La buena calidad de los requisitos comerciales cuando se capturan desde el principio no solo mejora el éxito de un proyecto, sino que también ahorra los costos generales asociados con las solicitudes de cambio y las inversiones relacionadas en capacitación, infraestructura, etc. |
Roles
Los requisitos comerciales los definen normalmente 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 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.
Formato
El formato más popular para registrar los requisitos comerciales es el documento de requisitos comerciales (BRD). La intención detrás del BRD es definir qué resultados se esperarían de un sistema, sin embargo, eventualmente podría diseñarse. Por lo tanto, los documentos BRD se complementan con un documento de referencia de sistemas (SRD) O un documento de diseño técnico (TDD) que detalla el diseño, el rendimiento tecnológico y las expectativas de infraestructura, incluidos los requisitos tecnológicos (no funcionales) relacionados con la calidad del servicio, como el rendimiento. , mantenibilidad, adaptabilidad, confiabilidad, disponibilidad, seguridad y escalabilidad.Estructura tradicional de BRD - [3] - Título
- Versión
- Descripción de Cambio
- Autor
- Fecha
- Contenido
- Introducción
- Propósito
- Alcance
- Fondo
- Referencias
- Suposiciones y Restricciones
- Resumen del documento
- Metodología
- Requerimientos funcionales
- Contexto
- Requisitos de usuario
- Diagramas de flujo de datos
- Modelo de datos lógicos / diccionario de datos
- Otros requerimientos
- Requisitos de interfaz
- Requisitos de conversión de datos
- Requisitos de hardware / software
- Requerimientos operacionales
- Introducción
- Apéndice A -
Lo completo
La creación de prototipos con pruebas en las primeras etapas 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 apropiado de la plantilla . El alcance de los requisitos comerciales no se limita necesariamente a la etapa de definición de lo que se necesita construir como un sistema comercial. Va más allá, para visualizar cómo se gestiona y mantiene un sistema empresarial en funcionamiento, y para garantizar su alineación mantenida con los objetivos o la estrategia empresarial. Un documento de requisitos comerciales debe revisarse constantemente de manera controlada. Tener un formato estandarizado, o plantillas diseñadas para dominios y funciones comerciales específicas, puede garantizar la integridad de los requisitos comerciales, además de mantener el alcance enfocado.
Aunque comúnmente se considera un medio para evaluar los requisitos, la creación de prototipos en realidad suele desviar la atención de los requisitos comerciales al producto, sistema o software que se está construyendo. Los prototipos son software que funcionan, lo que significa que son tres pasos (requisitos de 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) eliminados de los requisitos comerciales. 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 está creando el desarrollador, que es la interpretación del desarrollador de una forma de satisfacer los requisitos comerciales, no los requisitos comerciales. Además, para crear un prototipo pronto y rápidamente, se enfatiza la interfaz gráfica de usuario (GUI) y las "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 comerciales tienden a no cambiar tanto como la conciencia 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 generalmente se denomina "cambios de requisitos": los requisitos del producto / sistema / software. Éstos tienden a reflejar las supuestas formas de satisfacer los requisitos comerciales identificados de manera inadecuada. Muchas de las dificultades atribuidas al logro de los requisitos comerciales reflejan de hecho la práctica común de dedicar casi todo el esfuerzo de los "requisitos" a lo que en realidad es el diseño de alto nivel de un producto, sistema o software. Esto se debe a no definir primero adecuadamente los requisitos comerciales 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 comercial. Estas costosas formas indirectas de prueba y error para identificar los requisitos comerciales 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 particulares que a menudo pueden ser relevantes para los requisitos comerciales. Pueden fomentar la documentación estandarizada con respecto a 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 que se utilizan habitualmente de forma incorrecta a menudo tienen un impacto negativo en la investigación de requisitos, ya que tienden a promover la superficialidad y principalmente la definición mecánica sin un análisis significativo.
Dificultades
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 un potencial de conflicto de intereses. El proceso de gestión y construcción de consensos 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 registrada. Por ejemplo, un sistema que involucra a los usuarios de ventas y producción puede ver un conflicto de propósitos: un lado puede estar interesado en ofrecer las máximas características, mientras que el otro puede enfocarse en el costo de producción más bajo . Este tipo de situaciones a menudo terminan en un consenso con características máximas para un costo de producción y distribución razonable y rentable.
Para abordar estos desafíos, la participación de las partes interesadas en la etapa inicial 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 como simples discusiones agrupadas, para ayudar a lograr el consenso, especialmente para los requisitos comerciales delicados y donde existe un posible conflicto de intereses. La complejidad de un proceso empresarial 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 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 de trabajo. 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 de destino se ve con frecuencia limitado por una elección de tecnología específica, un presupuesto o productos disponibles ya implementados.
Finalmente, la estandarización del formato puede causar dificultades. Múltiples proyectos con múltiples formatos que dan lugar a variaciones en la estructura y el contenido de un documento de requisitos los hace ineficaces desde una perspectiva de trazabilidad y capacidad de gestión. De hecho, al crear una plantilla para usar en un ejercicio de recopilación de requisitos multifuncionales, los diferentes roles con conocimientos complementarios pueden tener dificultades para trabajar dentro de un formato común. Por lo tanto, es crucial 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 varios matices y lograr el mejor ajuste sigue siendo el mayor desafío para los requisitos efectivos.
Identificar las necesidades comerciales
Incluye los siguientes pasos:
- Definición de negocio
- Comprender los dominios comerciales
- Objetivos de la organización
- Competencia central
Ver también
Bibliografía
- Beal, Adrinana. Requisito es lo que tenemos que hacer para lograr un objetivo www.bealprojects.com , 2012
- Goldsmith, Robin F. Descubriendo los requisitos comerciales reales para el éxito de un proyecto de software . Casa Artech, 2004.
- Robertson, Suzanne y James C. Robertson. Dominar el proceso de requisitos . 2da edición, Addison-Wesley, 2006.
Referencias
- ^ Beal, 2012. página 1
- ^ Goldsmith, 2004. páginas 2-6
- ^ "Plantilla BRD para documentar los requisitos funcionales del cliente" .
4. https://anjanikthakur.blogspot.com/2013/04/how-to-write-good-business-requirement.html?m=1