¿Qué es el análisis empresarial?

El análisis comercial es el conjunto de tareas, conocimientos y técnicas necesarios para identificar las necesidades comerciales y determinar soluciones a los problemas comerciales de la empresa. Aunque la definición general es similar, las prácticas y procedimientos pueden variar en varias industrias.

En la industria de la tecnología de la información, las soluciones a menudo incluyen un componente de desarrollo de sistemas, pero también pueden consistir en mejoras de procesos o cambios organizacionales.

El análisis comercial también se puede realizar para comprender el estado actual de una organización o para servir como base para la identificación de las necesidades comerciales. Sin embargo, en la mayoría de los casos, el análisis empresarial se realiza para definir y validar soluciones que satisfagan las necesidades, metas u objetivos empresariales.

¿Quién es un analista de negocios?

Un analista de negocios es alguien que analiza una organización o dominio comercial (real o hipotético) y documenta su negocio, procesos o sistemas, evaluando el modelo comercial o su integración con la tecnología. Sin embargo, los títulos organizacionales varían, como analista, analista de negocios, analista de sistemas comerciales o quizás analista de sistemas.

¿Por qué un analista de negocios?

Las organizaciones emplean el análisis empresarial por las siguientes razones:

• Comprender la estructura y la dinámica de la organización en la que se implementará un sistema.

• Comprender los problemas actuales en la organización objetivo e identificar los potenciales de mejora.

• Asegurar que el cliente, el usuario final y los desarrolladores tengan un entendimiento común de la organización objetivo.

En la fase inicial de un proyecto, cuando los equipos de diseño y solución están interpretando los requisitos, el papel de un analista de negocios es revisar los documentos de las soluciones, trabajar en estrecha colaboración con los diseñadores de soluciones (equipo de TI) y los gerentes de proyecto para garantizar que los requisitos son claros.

En una típica organización de TI de gran tamaño, especialmente en un entorno de desarrollo, puede encontrar equipos de entrega tanto en el sitio como en el extranjero que tengan los roles mencionados anteriormente. Puede encontrar un “Analista de negocios” que actúa como una persona clave que tiene que vincular ambos equipos.

A veces, interactuaba con los usuarios comerciales y, en ocasiones, con los usuarios técnicos y, finalmente, con todos los interesados ​​en los proyectos para obtener la aprobación y el visto bueno final antes de proceder con la documentación.

Por lo tanto, el papel de BA es muy crucial en el arranque eficaz y exitoso de cualquier proyecto.

Rol de un analista de negocios de TI

El rol de un analista de negocios comienza definiendo y delimitando las áreas comerciales de la organización, luego obteniendo los requisitos, analizando y documentando los requisitos, comunicando estos requisitos a las partes interesadas apropiadas, identificando la solución correcta y luego validando la solución para encontrar si el los requisitos cumplen con los estándares esperados.

¿En qué se diferencia de otras profesiones?

El análisis empresarial es distinto del análisis financiero, la gestión de proyectos, la garantía de calidad, el desarrollo organizacional, las pruebas, la formación y el desarrollo de documentación. Sin embargo, dependiendo de la organización, un analista de negocios puede realizar algunas o todas estas funciones relacionadas.

Los analistas comerciales que trabajan únicamente en el desarrollo de sistemas de software pueden denominarse analistas comerciales de TI, analistas comerciales técnicos, analistas comerciales en línea, analistas de sistemas comerciales o analistas de sistemas.

El análisis empresarial también incluye el trabajo de enlace entre las partes interesadas, los equipos de desarrollo, los equipos de prueba, etc.

Ciclo de vida del desarrollo de programas

El ciclo de vida del desarrollo de software (SDLC) es un proceso que se sigue en un proyecto de software, dentro de una organización de software. Consiste en un plan detallado que describe cómo desarrollar, mantener, reemplazar y modificar o mejorar un software específico. Define una metodología para mejorar la calidad del software y el proceso de desarrollo en general.

• SDLC es un proceso utilizado por los analistas de TI para desarrollar o rediseñar un sistema de software de alta calidad, que cumple con los requisitos del cliente y del mundo real.

• Tiene en cuenta todos los aspectos asociados a las pruebas, el análisis y el mantenimiento posterior al proceso del software.

Las fases importantes de SDLC se describen en la siguiente ilustración:

Etapa de planificación

Toda actividad debe comenzar con un plan. No planificar es planificar el fracaso. El grado de planificación difiere de un modelo a otro, pero es muy importante tener una comprensión clara de lo que vamos a construir al crear las especificaciones del sistema.

Definición de etapa

En esta fase, analizamos y definimos la estructura del sistema. Definimos la arquitectura, los componentes y cómo estos componentes encajan para producir un sistema de trabajo.

Etapa de diseño

En el diseño de sistemas, las funciones y operaciones de diseño se describen en detalle, incluidos diseños de pantalla, reglas comerciales, diagramas de procesos y otra documentación. El resultado de esta etapa describirá el nuevo sistema como una colección de módulos o subsistemas.

Etapa de construcción

Esta es la fase de desarrollo. Comenzamos la generación de código basado en el diseño del sistema utilizando compiladores, intérpretes, depuradores para darle vida al sistema.

Implementación

La implementación es parte de la etapa de construcción. En esta fase, comenzamos la generación de código basado en el diseño del sistema utilizando compiladores, intérpretes, depuradores para darle vida al sistema.

Etapa de prueba

A medida que se completan diferentes partes del sistema; se someten a una serie de pruebas. se prueba con los requisitos para asegurarse de que el producto realmente está resolviendo las necesidades abordadas durante la fase de requisitos.

• Los planes de prueba y los casos de prueba se utilizan para identificar errores y garantizar que el sistema funcione de acuerdo con las especificaciones.

• En esta fase, se realizan diferentes tipos de pruebas como pruebas unitarias, pruebas manuales, pruebas de aceptación y pruebas del sistema.

Seguimiento de defectos en las pruebas

Los informes de prueba de software se utilizan para comunicar los resultados de los planes de prueba ejecutados. Siendo este el caso, un informe debe contener toda la información de prueba que pertenece al sistema actual que se está probando. La integridad de los informes se verificará en sesiones de guía.

La prueba de un proyecto busca lograr dos objetivos principales:

• Detecta fallas y defectos en el sistema.

• Detecte inconsistencias entre los requisitos y la implementación.

El siguiente diagrama de flujo muestra la Defect Tracking Process -

Para lograr los objetivos principales, la estrategia de prueba para el sistema propuesto generalmente constará de cuatro niveles de prueba.

Se trata de pruebas unitarias, pruebas de integración, pruebas de aceptación y pruebas de regresión. Las siguientes subsecciones describen estos niveles de prueba, qué roles del equipo de desarrollo son responsables de desarrollarlos y ejecutarlos, y los criterios para determinar su integridad.

Despliegue

Una vez finalizada la fase de prueba, el sistema se libera y entra en el entorno de producción. Una vez que el producto se prueba y está listo para implementarse, se lanza formalmente en el mercado correspondiente. En ocasiones, la implementación del producto ocurre en etapas según la estrategia comercial de la organización.

El producto puede lanzarse primero en un segmento limitado y probarse en el entorno empresarial real (prueba de aceptación del usuario UAT). Luego, según los comentarios, el producto puede lanzarse tal cual o con mejoras sugeridas en el segmento de mercado objetivo.

Proceso posterior al SDLC

Una vez que el producto se lanza al mercado, se realiza su mantenimiento para la base de clientes existente.

Una vez en el entorno de producción, el sistema sufrirá modificaciones debido a errores no detectados u otros eventos inesperados. El sistema se evalúa y el ciclo se repite para mantener el sistema.

Papel del analista empresarial durante el proceso SDLC

Como podemos ver en el diagrama a continuación, BA está involucrado en impulsar los requisitos comerciales y convertirlos en requisitos de solución.

Está involucrado en traducir las características de la solución en requisitos de software. Luego lidera la fase de análisis y diseño, dicta el desarrollo del código, luego sigue la fase de prueba durante la corrección de errores como agente de cambio en el equipo del proyecto y finalmente cumple con los requisitos del cliente.

Análisis empresarial: funciones

El rol de un analista de negocios en un proyecto de TI puede ser múltiple. Es posible que los miembros del equipo del proyecto tengan múltiples roles y responsabilidades. En algunos proyectos, el BA puede asumir las funciones de Analista de inteligencia empresarial, Diseñador de bases de datos, Especialista en garantía de calidad del software, Probador y / o Entrenador cuando hay recursos limitados disponibles.

También es posible que un coordinador de proyectos, un líder de desarrollo de aplicaciones o un desarrollador asuma el rol de analista de negocios en proyectos específicos.

El análisis comercial se superpone en gran medida con el análisis de los requisitos del negocio para funcionar como de costumbre y optimizar su funcionamiento. Algunos ejemplos de análisis empresarial son:

• Creación de arquitectura empresarial
• Preparación de un caso comercial
• Realización de una evaluación de riesgos
• Obtención de requisitos
• Análisis de procesos comerciales
• Documentación de requisitos

Funciones principales de un BA

Una función clave de la mayoría de los analistas comerciales es la de servir de enlace entre los desarrolladores comerciales y técnicos. Los analistas comerciales trabajan junto con los clientes comerciales para recopilar / definir los requisitos de un sistema o proceso para mejorar la productividad y, al mismo tiempo, trabajar con los equipos técnicos para diseñar e implementar el sistema / proceso.

Como colaborador

La principal responsabilidad de un BA es contribuir al desarrollo de los usuarios comerciales / usuarios clave en la identificación de problemas, necesidades y funciones comerciales, comprender las preocupaciones y requisitos de las partes interesadas para identificar oportunidades de mejora y contribuir con aportes comerciales para desarrollar el caso comercial para TI. proyecto de desarrollo del sistema.

Como facilitador

También se supone que un analista de negocios debe facilitar / coordinar la obtención y el análisis de requisitos, colaborar y comunicarse con las partes interesadas y gestionar sus expectativas y necesidades, y garantizar que los requisitos sean completos, inequívocos y mapearlos con las necesidades comerciales en tiempo real. de una organización.

Como analista

Otro papel importante sería evaluar el sistema propuesto y la preparación organizacional para la implementación del sistema y brindar apoyo a los usuarios y coordinar con el personal de TI.

Para ayudar a revisar y proporcionar insumos para el diseño del sistema de TI propuesto desde la perspectiva empresarial, resolver problemas / conflictos entre las partes interesadas, ayudar a organizar UAT integral y de calidad a través de la asistencia a los usuarios en el desarrollo de casos de prueba, y ayudar a organizar la capacitación con el objetivo de garantizar la implementó un sistema de TI que es capaz de satisfacer las necesidades y requisitos comerciales, así como de obtener los beneficios anticipados.

Planificar y monitorear las actividades de análisis de negocios para el desarrollo del alcance, cronograma y enfoque para realizar las actividades relacionadas con el análisis de negocios para el proyecto de desarrollo del sistema de TI, monitorear el progreso, coordinar con el gerente de proyecto interno e informar sobre ingresos, rentabilidad, riesgos y problemas donde sea apropiado.

Responsabilidades clave de un analista de negocios

El conjunto de responsabilidades de un analista de negocios le requeriría cumplir con diferentes deberes en diferentes fases de un proyecto y se aclaran a continuación:

Fase de iniciación

Esta fase marcará el comienzo de un nuevo proyecto y un analista de negocios variará las siguientes responsabilidades:

• Ayudar en la realización del análisis de costo-beneficio del proyecto.
• Comprenda el caso de negocio.
• Verificar la viabilidad de la solución / proyecto / producto.
• Ayuda en la creación de la carta del proyecto.
• Identificar a los interesados ​​en el proyecto.

Fase de planificación

Esta fase implicará recopilar los requisitos y la planificación, cómo se ejecutará y gestionará el proyecto. Sus responsabilidades incluirán las siguientes funciones:

• Obtener los requisitos
• Analizar, organizar y documentar requisitos.
• Gestione los requisitos creando casos de uso, RTM, BRD, SRS, etc.
• Evaluar las soluciones propuestas.
• Servir de enlace y mejorar las comunicaciones con las partes interesadas.
• Ayudar a formular los planes de gestión del proyecto.
• Ayuda a encontrar el alcance, las limitaciones, los supuestos y los riesgos del proyecto.
• Ayudar a diseñar la experiencia del usuario de la solución.

Fase de ejecución

Esta fase marca el desarrollo de la solución según los requisitos reunidos. Las responsabilidades incluyen:

• Explique los requisitos al equipo de desarrollo / TI.

• Aclarar dudas, inquietudes respecto a la solución propuesta a desarrollar.

• Discuta y priorice los cambios en el alcance del proyecto y obtenga un acuerdo.

• Cree scripts de pruebas beta para las pruebas iniciales.

• Compartir los módulos en desarrollo con las partes interesadas y solicitar sus comentarios.

• Cumplir con los plazos y gestionar las expectativas de las partes interesadas.

• Resolver conflictos y gestionar las comunicaciones con el equipo del proyecto.

Fase de seguimiento y control

En esta fase, el proyecto se mide y se controla para detectar cualquier desviación de los planes iniciales. Esta fase se ejecuta simultáneamente a la fase de ejecución.

• Desarrollar scripts de prueba y realizar pruebas integrales y de módulos integrales.

• Realización de UAT (prueba de aceptación de uso) y creación de informes de prueba.

• Obtenga la aceptación / aprobación de los entregables del cliente.

• Explique las solicitudes de cambio al equipo de desarrollo.

• Monitorear el desarrollo de las solicitudes de cambio y verificar su implementación según el objetivo del proyecto.

Fase de cierre

Esta fase marca el cierre del proyecto. Las responsabilidades son:

• Presentar el proyecto terminado al cliente y obtener su aceptación.

• Cree manuales de capacitación para usuarios, cualquier material funcional y otras guías instructivas.

• Realice pruebas de integración elaboradas en el entorno de producción.

• Cree documentaciones de productos finales, documente las lecciones aprendidas del proyecto.

¿Qué se espera que proporcione un BA?

Un Business Analyst sirve como puente entre los usuarios comerciales y el personal técnico de TI. Su presencia contribuirá significativamente al éxito de los proyectos de TI. Hay muchos beneficios de tener un analista de negocios dedicado. Un analista de negocios dedicado puede:

• Ofrece un alcance del proyecto claro desde un punto de vista comercial.

• Desarrolle casos comerciales sólidos y una estimación más realista de los recursos y los beneficios comerciales.

• Prepara mejores informes sobre el alcance, la planificación y la gestión del proyecto en términos de costos y cronograma, especialmente para proyectos de TI a gran escala.

• Produce requisitos claros y concisos, que a su vez, ayudan a proporcionar requisitos más claros y precisos, si el proyecto de TI se subcontrata.

• Obtenga las necesidades comerciales reales de los usuarios y administre de manera efectiva las expectativas de los usuarios.

• Mejora la calidad del diseño del sistema informático propuesto para que cumpla con los requisitos del usuario.

• Garantiza la calidad del sistema desarrollado antes de pasarlo a los usuarios finales para su revisión y aceptación.

• Organiza una prueba de calidad integral en los sistemas entregados y proporciona comentarios al personal técnico de TI.

Análisis empresarial: herramientas y técnicas

Un analista de negocios debe estar familiarizado con varias herramientas analíticas y tecnologías relacionadas cuando usa el sombrero BA. Quiero decir, si ocupa este puesto.

Como ya hemos aprendido anteriormente, el análisis de negocios es un proceso en el que intenta comprender una empresa comercial e identificar oportunidades, áreas problemáticas, problemas y conocer a una amplia gama de personas que tienen una amplia gama de roles y responsabilidades como CEO, VP, Director y comprender sus requisitos comerciales.

Básicamente, existen 3 tipos de análisis de negocio en los que podemos categorizar:

• Strategic Analysis- El análisis empresarial estratégico se ocupa del trabajo previo al proyecto. Es el método o proceso de identificación de problemas empresariales, ideando estrategias, metas y objetivos empresariales que ayudan a la alta dirección. Proporciona informes de información de gestión para un proceso de toma de decisiones eficaz.

• Tactical Analysis - Implica el conocimiento de técnicas específicas de análisis empresarial para aplicar en el momento adecuado en el proyecto adecuado.

• Operational Analysis- En este tipo de análisis de negocio, nos enfocamos en el aspecto empresarial aprovechando las tecnologías de la información. También es un proceso de estudio de sistemas operativos con el objetivo de identificar oportunidades de mejora empresarial.

Para cada tipo de análisis, hay un conjunto de herramientas que están disponibles en el mercado y en función de las necesidades y requisitos organizativos, se deben utilizar.

Sin embargo, para materializar los requisitos comerciales en información comprensible, un buen BA aprovechará las técnicas de búsqueda de hechos, entrevistas, revisión de documentación, cuestionarios, muestreo e investigación en sus actividades diarias.

Requisitos funcionales y no funcionales

Podemos dividir un requisito en dos tipos principales, como requisitos funcionales y no funcionales.

Para todos los proyectos de tecnología, los requisitos funcionales y no funcionales deben segregarse y analizarse por separado.

Definir la herramienta y la técnica adecuadas puede ser un desafío abrumador. Ya sea que esté haciendo una aplicación nueva o cambiando una aplicación existente. Considerar la técnica adecuada para el proceso funcional es un arte en sí mismo.

Una descripción general de las técnicas de análisis empresarial ampliamente utilizadas que se encuentran actualmente en el mercado:

Procesos	Técnicas	Entregables del proceso (resultados)
Para determinar los requisitos funcionales y no funcionales	Sesiones JAD Escenarios y casos de uso Modelado organizacional Modelado de alcance Descomposición funcional Interviews Observación (seguimiento de trabajos) Grupos de enfoque Aceptación y evaluación Diagramas de secuencia Historias del usuario Brainstorming Storyboarding Prototyping Recorrido estructurado Análisis de eventos Análisis de reglas comerciales Talleres de requisitos Análisis de riesgo Análisis de raíz de la causa	Business Requirements Documents - Requisitos comerciales y funcionales Requerimientos no funcionales Reglas del negocio Requerimientos de trazabilidad matriz Common Template - Documento de requisitos comerciales

Aplicabilidad de herramientas y procesos

Aunque existe una variedad de herramientas y procedimientos disponibles para los analistas de negocios, todo depende de las prácticas actuales de la organización y de cómo les gustaría usarlas.

Por ejemplo, root-cause analysis se utiliza cuando existe la necesidad de profundizar en una determinada área o función importante.

Sin embargo, el documento de requisitos comerciales es la forma más popular y aceptada de poner los requisitos en formato de documentación.

En los capítulos siguientes, analizaremos en profundidad algunas de las técnicas anteriores.

Análisis empresarial - Sesión JAD

El desarrollo de aplicaciones conjuntas (JAD) es un proceso que se utiliza para recopilar los requisitos comerciales mientras se desarrollan nuevos sistemas de información para una empresa. El proceso JAD también puede incluir enfoques para mejorar la participación de los usuarios, acelerar el desarrollo y mejorar la calidad de las especificaciones. La intención de una sesión de JAD es reunir expertos en la materia / analistas de negocios o especialistas en TI para presentar soluciones.

Un analista de negocios es quien interactúa con todo el grupo y recopila la información, la analiza y saca un documento. Juega un papel muy importante en la sesión JAD.

Uso de una sesión JAD

Las sesiones de JAD son talleres altamente estructurados y facilitados que reúnen a los tomadores de decisiones de los clientes y al personal de TI para producir entregas de alta calidad en un período corto.

En otras palabras, una sesión JAD permite a los clientes y desarrolladores llegar rápidamente a un acuerdo sobre el alcance básico, los objetivos y las especificaciones de un proyecto o, en caso de que no lleguen a un acuerdo, lo que significa que el proyecto debe ser reevaluado.

En pocas palabras, las sesiones de JAD pueden

• Simplify - Consolida meses de reuniones y llamadas telefónicas en un taller estructurado.

• Identify - Temas y participantes

• Quantify - Necesidades de información y procesamiento

• Clarify - Cristalizar y aclarar todos los requisitos acordados en la sesión.

• Unify - El resultado de una fase de desarrollo es entrada a la siguiente.

• Satisfy- Los clientes definen el sistema; por lo tanto, es su sistema. La participación compartida trae una participación en el resultado; se comprometen con el éxito de los sistemas.

Participantes en una sesión JAD

Los participantes involucrados en una sesión JAD son los siguientes:

Patrocinador ejecutivo

Un patrocinador ejecutivo es la persona que impulsa el proyecto, el propietario del sistema. Por lo general, provienen de posiciones más altas y pueden tomar decisiones y proporcionar la estrategia, planificación y dirección necesarias.

Experto en la materia

Estos son los usuarios comerciales y los expertos externos que se requieren para un taller exitoso. Los expertos en la materia son la columna vertebral de la sesión JAD. Ellos impulsarán los cambios.

Facilitador

Preside la reunión; identifica problemas que pueden resolverse como parte de la reunión. El facilitador no aporta información a la reunión.

Los usuarios clave

Los usuarios clave o también llamados superusuarios en algunos casos se han utilizado de forma intercambiable y aún difieren de una empresa a otra. Los usuarios clave son generalmente los usuarios comerciales que están más estrechamente alineados con el proyecto de TI y son responsables de la configuración de los perfiles de los miembros de su equipo durante los proyectos.

Por ejemplo: suponga que John es un usuario clave y Nancy, Evan son usuarios de un sistema SAP. En este caso, Nancy y Evan no tienen acceso para cambiar la funcionalidad y el perfil, mientras que John, que es un usuario clave, tiene acceso para editar el perfil con más autorizaciones.

Se cree que el enfoque JAD, en comparación con la práctica más tradicional, conduce a tiempos de desarrollo más rápidos y una mayor satisfacción del cliente, porque el cliente está involucrado durante todo el proceso de desarrollo. En comparación, en el enfoque tradicional para el desarrollo de sistemas, el desarrollador investiga los requisitos del sistema y desarrolla una aplicación, con la entrada del cliente que consiste en una serie de entrevistas.

Técnicas de recopilación de requisitos

Las técnicas describen cómo se realizan las tareas en circunstancias específicas. Una tarea puede tener ninguna o una o más técnicas relacionadas. Una técnica debe estar relacionada con al menos una tarea.

Las siguientes son algunas de las técnicas de recopilación de requisitos más conocidas:

Lluvia de ideas

La lluvia de ideas se utiliza en la recopilación de requisitos para obtener tantas ideas como sea posible de un grupo de personas. Generalmente se usa para identificar posibles soluciones a problemas y aclarar detalles de oportunidades.

Análisis de documentos

La revisión de la documentación de un sistema existente puede ayudar a la hora de crear un documento de proceso TAL COMO ESTÁ, así como a impulsar el análisis de brechas para el alcance de los proyectos de migración. En un mundo ideal, incluso estaríamos revisando los requisitos que impulsaron la creación del sistema existente, un punto de partida para documentar los requisitos actuales. Las pepitas de información a menudo están enterradas en documentos existentes que nos ayudan a hacer preguntas como parte de la validación de la completitud de los requisitos.

Grupo de enfoque

Un grupo de enfoque es una reunión de personas que son representativas de los usuarios o clientes de un producto para obtener comentarios. La retroalimentación se puede recopilar sobre necesidades / oportunidades / problemas para identificar los requisitos, o se puede recopilar para validar y refinar los requisitos ya obtenidos. Esta forma de investigación de mercado se diferencia de la lluvia de ideas en que es un proceso gestionado con participantes específicos.

Análisis de interfaz

Las interfaces para un producto de software pueden ser humanas o mecánicas. La integración con sistemas y dispositivos externos es solo otra interfaz. Los enfoques de diseño centrados en el usuario son muy efectivos para asegurarnos de que creamos software utilizable. Análisis de interfaz: revisar los puntos de contacto con otros sistemas externos es importante para asegurarnos de no pasar por alto los requisitos que los usuarios no pueden ver de inmediato.

Entrevista

Las entrevistas a las partes interesadas y los usuarios son fundamentales para crear el gran software. Sin comprender los objetivos y expectativas de los usuarios y las partes interesadas, es muy poco probable que los satisfagamos. También tenemos que reconocer la perspectiva de cada entrevistado, para que podamos ponderar y abordar adecuadamente sus aportes. Escuchar es la habilidad que ayuda a un gran analista a obtener más valor de una entrevista que a un analista promedio.

Observación

Al observar a los usuarios, un analista puede identificar un flujo de proceso, pasos, puntos débiles y oportunidades de mejora. Las observaciones pueden ser pasivas o activas (hacer preguntas mientras se observa). La observación pasiva es mejor para obtener comentarios sobre un prototipo (para refinar los requisitos), donde la observación activa es más eficaz para comprender un proceso empresarial existente. Se puede utilizar cualquier enfoque.

Creación de prototipos

La creación de prototipos es una técnica relativamente moderna para recopilar requisitos. En este enfoque, reúne los requisitos preliminares que utiliza para crear una versión inicial de la solución: un prototipo. Muestra esto al cliente, quien luego le da requisitos adicionales. Cambia la aplicación y vuelve a circular con el cliente. Este proceso repetitivo continúa hasta que el producto satisface la masa crítica de necesidades comerciales o durante un número acordado de iteraciones.

Talleres de requisitos

Los talleres pueden ser muy eficaces para reunir los requisitos. Más estructurado que una sesión de lluvia de ideas, las partes involucradas colaboran para documentar los requisitos. Una forma de capturar la colaboración es con la creación de artefactos de modelo de dominio (como diagramas estáticos, diagramas de actividad). Un taller será más efectivo con dos analistas que con uno.

Ingeniería inversa

Cuando un proyecto de migración no tiene acceso a documentación suficiente del sistema existente, la ingeniería inversa identificará lo que hace el sistema. No identificará lo que debe hacer el sistema y no identificará cuándo el sistema hace algo incorrecto.

Encuesta / Cuestionario

Al recopilar información de muchas personas (demasiadas para entrevistarlas con limitaciones de tiempo y presupuesto), se puede utilizar una encuesta o un cuestionario. La encuesta puede obligar a los usuarios a seleccionar entre opciones, calificar algo ("Totalmente de acuerdo, de acuerdo ...") o tener preguntas abiertas que permitan respuestas de forma libre. El diseño de la encuesta es difícil: las preguntas pueden sesgar a los encuestados.

Documento de requisitos funcionales

El documento de requisitos funcionales (FRD) es una declaración formal de los requisitos funcionales de una aplicación. Tiene el mismo propósito que un contrato. Aquí, los desarrolladores acuerdan proporcionar las capacidades especificadas. El cliente acepta encontrar el producto satisfactorio si proporciona las capacidades especificadas en el FRD.

Los requisitos funcionales capturan el comportamiento previsto del sistema. Este comportamiento puede expresarse como servicios, tareas o funciones que el sistema debe realizar. El documento debe adaptarse a las necesidades de un proyecto en particular. Definen cosas como cálculos del sistema, manipulación y procesamiento de datos, interfaz de usuario e interacción con la aplicación.

El Documento de Requisitos Funcionales (FRD) tiene las siguientes características:

• Demuestra que la aplicación proporciona valor en términos de los objetivos comerciales y los procesos comerciales en los próximos años.

• Contiene un conjunto completo de requisitos para la aplicación. No deja lugar para que nadie asuma nada que no esté establecido en el FRD.

• Es independiente de la solución. El ERD es una declaración de lo que debe hacer la aplicación, no de cómo funciona. El FRD no compromete a los desarrolladores con un diseño. Por esa razón, cualquier referencia al uso de una tecnología específica es totalmente inapropiada en un FRD.

El requisito funcional debe incluir lo siguiente:

• Descripciones de data para ser ingresado en el sistema

• Descripciones de operations realizado por cada pantalla

• Descripciones de work-flows realizado por el sistema

• Descripciones de system reports u otras salidas

• ¿Quién puede entrar al data en el sistema?

• Cómo cumple el sistema aplicable regulatory requirements?

La especificación funcional está diseñada para ser leída por una audiencia general. Los lectores deben comprender el sistema, pero no se requieren conocimientos técnicos para comprender este documento.

Requisitos funcionales Entregables

Un documento de requisitos comerciales (BRD) consta de:

• Functional Requirements- Un documento que contiene los requisitos detallados para el sistema que se está desarrollando. Estos requisitos definen las características y capacidades funcionales que debe poseer un sistema. Asegúrese de que las suposiciones y limitaciones identificadas durante el Business Case sigan siendo precisas y estén actualizadas.

• Business Process Model - Un modelo del estado actual del proceso (modelo "tal cual") o un concepto de lo que debería convertirse en el proceso (modelo "ser")

• System Context Diagram - Un diagrama de contexto muestra los límites del sistema, las entidades externas e internas que interactúan con el sistema y los flujos de datos relevantes entre estas entidades externas e internas.

• Flow Diagrams (as-is or to-be)- Los diagramas representan gráficamente la secuencia de operaciones o el movimiento de datos para un proceso empresarial. Se incluyen uno o más diagramas de flujo según la complejidad del modelo.

• Business Rules and Data Requirements - Las reglas comerciales definen o restringen algunos aspectos del negocio y se utilizan para definir restricciones de datos, valores predeterminados, rangos de valores, cardinalidad, tipos de datos, cálculos, excepciones, elementos requeridos y la integridad relacional de los datos.

• Data Models - Diagramas de relación entre entidades, descripciones de entidades, diagramas de clases

• Conceptual Model - Visualización de alto nivel de diferentes entidades para una función empresarial y cómo se relacionan entre sí.

• Logical Model - Ilustra las entidades, atributos y relaciones específicos involucrados en una función comercial y representa todas las definiciones, características y relaciones de datos en un entorno comercial, técnico o conceptual.

• Data Dictionary and Glossary - Una colección de información detallada sobre los elementos de datos, campos, tablas y otras entidades que componen el modelo de datos subyacente a una base de datos o sistema de gestión de datos similar.

• Stakeholder Map- Identifica a todas las partes interesadas que se ven afectadas por el cambio propuesto y su nivel de influencia / autoridad para los requisitos. Este documento se desarrolló en la fase de origen de la Metodología de Gestión de Proyectos (PMM) y es propiedad del Gerente de Proyecto, pero el equipo del proyecto debe actualizarlo a medida que se identifiquen Partes Interesadas nuevas o modificadas a lo largo del proceso.

• Requirements Traceability Matrix - Una tabla que ilustra los vínculos lógicos entre los requisitos funcionales individuales y otros tipos de artefactos del sistema, incluidos otros requisitos funcionales, casos de uso / historias de usuario, elementos de arquitectura y diseño, módulos de código, casos de prueba y reglas comerciales.

Especificación de Requerimientos de Software

Una Especificación de requisitos de software (SRS) es un documento que se utiliza como medio de comunicación entre los clientes. Una especificación de requisitos de software en su forma más básica es un documento formal que se utiliza para comunicar los requisitos de software entre el cliente y el desarrollador.

Un documento SRS se concentra en WHAT debe hacerse y evita cuidadosamente la solución (how to do). Sirve como un contrato entre el equipo de desarrollo y el cliente. Los requisitos en esta etapa se redactan utilizando terminología de usuario final. Si es necesario, posteriormente se desarrollará una especificación formal de requisitos a partir de ella.

SRS es una descripción completa del comportamiento de un sistema a desarrollar y puede incluir un conjunto de casos de uso que describen las interacciones que los usuarios tendrán con el software.

Propósito de SRS

SRS es una herramienta de comunicación entre Cliente / Cliente, Analista de negocios, Desarrolladores de sistemas, Equipos de mantenimiento. También puede ser un contrato entre comprador y proveedor.

• Dará una base firme para la fase de diseño.
• Apoya la gestión y el control de proyectos
• Ayuda a controlar y evolucionar el sistema.

La especificación de un requisito de software debe ser completa, coherente, rastreable, inequívoca y verificable.

Lo siguiente debe abordarse en la especificación del sistema:

• Definir las funciones de los sistemas
• Definir el particionamiento funcional de hardware / software
• Definir la especificación de rendimiento
• Definir el particionamiento de rendimiento de hardware / software
• Definir requisitos de seguridad
• Definir la interfaz de usuario (manual del usuario)
• Proporcionar dibujos / instrucciones de instalación
• Plantilla de especificación de requisitos de software

Revisión histórica

Fecha	Descripción	Autor	Comentarios
<fecha>	<Versión 1>	<Su nombre>	<Primera revisión>

Aprobación de documentos

La siguiente especificación de requisitos de software ha sido aceptada y aprobada por:

Firma	Nombre impreso	Título	Fecha
	<Su nombre>	Ingeniero jefe de software
	David	Instructor

Análisis empresarial: casos de uso

Uno de los nueve diagramas de UML es el diagrama de casos de uso. Estos no solo son requisitos importantes sino necesarios para los proyectos de software. Básicamente se utiliza en los ciclos de vida del software. Como sabemos, hay varias fases en el ciclo de desarrollo y la fase más utilizada para los casos de uso sería durante la fase de recopilación de requisitos.

¿Qué es un caso de uso?

Un caso de uso describe una secuencia de acciones, realizadas por un sistema que proporciona valor a un actor. El caso de uso describe el comportamiento del sistema bajo varias condiciones, ya que responde a una solicitud de una de las partes interesadas, llamadaprimary actor.

El actor es el Quién del sistema, es decir, el usuario final.

En la ingeniería de software y sistemas, un caso de uso es una lista de pasos, que típicamente definen interacciones entre un rol (conocido en UML como "actor") y un sistema, para lograr un objetivo. El actor puede ser un humano o un sistema externo.

Un caso de uso especifica el flujo de eventos en el sistema. Se preocupa más por lo que realiza el sistema para realizar la secuencia de acciones.

Beneficios de un caso de uso

Un caso de uso proporciona los siguientes beneficios:

• Es un medio fácil de capturar el requisito funcional con un enfoque en el valor agregado para el usuario.

• Los casos de uso son relativamente fáciles de escribir y leer en comparación con los métodos de requisitos tradicionales.

• Los casos de uso obligan a los desarrolladores a pensar desde la perspectiva del usuario final.

• El caso de uso involucra al usuario en el proceso de requisitos.

La anatomía de un caso de uso

Nombre : nombre descriptivo que ilustra el propósito del caso de uso.

Descripción : describe lo que hace el caso de uso en un par de frases.

Actor : enumere todos los actores que participan en el caso de uso.

Precondición : condiciones que deben cumplirse antes de iniciar el caso de uso.

Flujo de eventos : Descripción de la interacción entre el sistema y el actor.

Condición posterior : describa el estado del sistema después de que un caso de uso haya seguido su curso.

Orientación para la plantilla de caso de uso

Documente cada caso de uso utilizando la plantilla que se proporciona al final de este capítulo. Esta sección proporciona una descripción de cada sección en la plantilla de caso de uso.

Identificación de casos de uso

• Use-Case ID- Asigne a cada caso de uso un identificador numérico único, en forma jerárquica: XY Los casos de uso relacionados se pueden agrupar en la jerarquía. Los requisitos funcionales se pueden rastrear hasta un caso de uso etiquetado.

• Use-Case Name- Indique un nombre conciso y orientado a resultados para el caso de uso. Estos reflejan las tareas que el usuario necesita poder realizar utilizando el sistema. Incluya un verbo de acción y un sustantivo. Algunos ejemplos:

  • Vea la información del número de pieza.

  • Marque manualmente la fuente de hipertexto y establezca un enlace al destino.

  • Realice un pedido de un CD con la versión de software actualizada.

Historial de casos de uso

Aquí, mencionamos los nombres de las personas que son las partes interesadas del documento de caso de uso.

• Created By - Proporcione el nombre de la persona que documentó inicialmente este caso de uso.

• Date Created - Introduzca la fecha en la que se documentó inicialmente el caso de uso.

• Last Updated By - Proporcione el nombre de la persona que realizó la actualización más reciente a la descripción del caso de uso.

• Date Last Updated - Introduzca la fecha en la que se actualizó el caso de uso por última vez.

Definición de caso de uso

Las siguientes son las definiciones de los conceptos clave del caso de uso:

Actor

Un actor es una persona u otra entidad externa al sistema de software que se especifica que interactúa con el sistema y realiza casos de uso para realizar tareas. Los diferentes actores a menudo se corresponden con diferentes clases de usuarios, o roles, identificados en la comunidad de clientes que utilizarán el producto. Nombra los actores que realizarán este caso de uso.

Descripción

Proporcione una breve descripción del motivo y el resultado de este caso de uso, o una descripción de alto nivel de la secuencia de acciones y el resultado de la ejecución del caso de uso.

Condiciones previas

Enumere las actividades que deben realizarse, o las condiciones que deben cumplirse, antes de que se pueda iniciar el caso de uso. Numere cada condición previa.

Examples

• Se ha autenticado la identidad del usuario.
• La computadora del usuario tiene suficiente memoria libre disponible para iniciar la tarea.

Condiciones de publicación

Describa el estado del sistema al final de la ejecución del caso de uso. Numere cada condición de publicación.

Examples

• El documento contiene solo etiquetas SGML válidas.
• El precio del artículo en la base de datos se ha actualizado con un nuevo valor.

Prioridad

Indique la prioridad relativa de implementar la funcionalidad requerida para permitir que se ejecute este caso de uso. El esquema de prioridad utilizado debe ser el mismo que se utiliza en la especificación de requisitos de software.

Frecuencia de uso

Estime la cantidad de veces que los actores realizarán este caso de uso por unidad de tiempo apropiada.

Curso normal de eventos

Proporcione una descripción detallada de las acciones del usuario y las respuestas del sistema que tendrán lugar durante la ejecución del caso de uso en condiciones normales y esperadas. Esta secuencia de diálogo finalmente conducirá a lograr el objetivo establecido en el nombre y la descripción del caso de uso. Esta descripción puede escribirse como una respuesta a la pregunta hipotética: "¿Cómo <logro la tarea indicada en el nombre del caso de uso>?" Esto se hace mejor como una lista numerada de acciones realizadas por el actor, alternando con las respuestas proporcionadas por el sistema.

Cursos alternativos

Documente otros escenarios de uso legítimos que pueden tener lugar dentro de este caso de uso por separado en esta sección. Indique el curso alternativo y describa cualquier diferencia en la secuencia de pasos que se llevan a cabo. Numere cada curso alternativo utilizando el ID de caso de uso como prefijo, seguido de "AC" para indicar "Curso alternativo". Ejemplo: XYAC.1.

Excepciones

Describa cualquier condición de error anticipada que podría ocurrir durante la ejecución del caso de uso y defina cómo el sistema responderá a esas condiciones. Además, describa cómo responderá el sistema si la ejecución del caso de uso falla por alguna razón no anticipada. Numere cada excepción utilizando el ID del caso de uso como prefijo, seguido de "EX" para indicar "Excepción". Ejemplo: XYEX.1.

Incluye

Enumere cualquier otro caso de uso que esté incluido ("llamado") por este caso de uso. La funcionalidad común que aparece en múltiples casos de uso se puede dividir en un caso de uso separado que se incluye para aquellos que necesitan esa funcionalidad común.

Requisitos especiales

Identifique cualquier requisito adicional, como requisitos no funcionales, para el caso de uso que pueda necesitar ser abordado durante el diseño o la implementación. Estos pueden incluir requisitos de desempeño u otros atributos de calidad.

Supuestos

Enumere todas las suposiciones que se hicieron en el análisis que llevaron a aceptar este caso de uso en la descripción del producto y escribir la descripción del caso de uso.

Notas y problemas

Enumere cualquier comentario adicional sobre este caso de uso o cualquier problema pendiente restante o TBD (por determinar) que deba resolverse. Identifique quién resolverá cada problema, la fecha de vencimiento y cuál es la resolución en última instancia.

Gestión de cambios y control de versiones

El control de versiones es la gestión de cambios en documentos, sitios web grandes y otra recopilación de información. Los cambios generalmente se identifican mediante un código numérico o de letra, denominado número de revisión o nivel de revisión. Cada revisión está asociada con una marca de tiempo y una persona que realiza el cambio.

Diagramas de casos de uso

Una parte importante del Lenguaje de modelado unificado (UML) son las facilidades para dibujar diagramas de casos de uso. Los casos de uso se utilizan durante la fase de análisis de un proyecto para identificar y dividir la funcionalidad del sistema. Separan el sistema en actores y casos de uso. Los actores representan roles que pueden desempeñar los usuarios del sistema.

Esos usuarios pueden ser humanos, otras computadoras, piezas de hardware o incluso otros sistemas de software. El único criterio es que deben ser externos a la parte del sistema que se divide en casos de uso. Deben suministrar estímulos a esa parte del sistema y deben recibir salidas de él.

Los casos de uso representan las actividades que los actores realizan con la ayuda de su sistema en la búsqueda de un objetivo. Necesitamos definir qué necesitan esos usuarios (actores) del sistema. El caso de uso debe reflejar las necesidades y los objetivos del usuario, y debe ser iniciado por un actor. Las empresas, los actores y los clientes que participan en el caso de uso empresarial deben estar conectados al caso de uso por asociación.

Dibujar diagramas de casos de uso

La Figura siguiente muestra cómo se vería un caso de uso en la forma esquemática de UML. El caso de uso en sí parece un óvalo. Los actores están dibujados como pequeñas figuras de palitos. Los actores están conectados al caso de uso con líneas.

Use-case 1 - El vendedor revisa un artículo

• El cliente coloca el artículo en el mostrador.
• «Utiliza» Swipe UPC Reader.
• El sistema busca el código UPC en la base de datos para obtener la descripción y el precio del artículo
• El sistema emite un pitido audible.
• El sistema anuncia la descripción del artículo y el precio por voz.
• El sistema agrega el precio y el tipo de artículo a la factura actual.
• El sistema agrega precio para corregir el subtotal de impuestos

Entonces, la relación «usa» es muy parecida a una llamada a función o una subrutina.

El caso de uso que se utiliza de esta manera se denomina caso de uso abstracto porque no puede existir por sí solo, sino que debe ser utilizado por otros casos de uso.

Ejemplo: caso de uso de retirada

El objetivo de un cliente en relación con nuestra máquina expendedora de dinero (ATM) es retirar dinero. Entonces, estamos agregandoWithdrawalcaso de uso. Retirar dinero de la máquina expendedora podría involucrar a un banco para que se realicen las transacciones. Entonces, también estamos agregando otro actor:Bank. Ambos actores que participan en el caso de uso deben estar conectados al caso de uso por asociación.

La máquina expendedora de dinero proporciona un caso de uso de retiro para el cliente y los actores del banco.

Relaciones entre actores y casos de uso

Los casos de uso podrían organizarse utilizando las siguientes relaciones:

• Generalization
• Association
• Extend
• Include

Generalización entre casos de uso

Puede haber casos en los que los actores estén asociados con casos de uso similares. En tal caso, un caso de uso secundario hereda las propiedades y el comportamiento del uso principal. Por lo tanto, necesitamos generalizar el actor para mostrar la herencia de funciones. Están representados por una línea sólida con una gran punta de flecha triangular hueca.

Asociación entre casos de uso

Las asociaciones entre actores y casos de uso se indican en los diagramas de casos de uso mediante líneas continuas. Existe una asociación cuando un actor está involucrado en una interacción descrita por un caso de uso.

Ampliar

Hay algunas funciones que se activan opcionalmente. En tales casos, se utiliza la relación de extensión y se le adjunta la regla de extensión. Lo que hay que recordar es que el caso de uso base debería poder realizar una función por sí solo, incluso si no se llama al caso de uso extendido.

La relación de extensión se muestra como una línea discontinua con una punta de flecha abierta dirigida desde el caso de uso extendido al caso de uso extendido (base). La flecha está etiquetada con la palabra clave «extender».

Incluir

Se utiliza para extraer fragmentos de casos de uso que se duplican en varios casos de uso. También se utiliza para simplificar el caso de uso grande dividiéndolo en varios casos de uso y para extraer partes comunes de los comportamientos de dos o más casos de uso.

Incluya la relación entre los casos de uso, que se muestra mediante una flecha discontinua con una punta de flecha abierta desde el caso de uso básico hasta el caso de uso incluido. La flecha está etiquetada con la palabra clave «incluir».

Los casos de uso tratan solo de los requisitos funcionales de un sistema. Otros requisitos, como las reglas comerciales, los requisitos de calidad del servicio y las restricciones de implementación, deben representarse por separado.

El diagrama que se muestra a continuación es un ejemplo de un diagrama de caso de uso simple con todos los elementos marcados.

Principios básicos para la aplicación exitosa de casos de uso

• Mantenlo simple contando historias
• Sea productivo sin perfección
• Comprender el panorama general
• Identificar oportunidades de reutilización para casos de uso
• Centrarse en el valor
• Construye el sistema en porciones
• Entregue el sistema en incrementos
• Adaptarse a las necesidades del equipo

Plantilla de caso de uso

Aquí, hemos mostrado una plantilla de muestra de un caso de uso que un analista de negocios puede completar para que la información pueda ser útil para que el equipo técnico obtenga información sobre el proyecto.

ID de caso de uso:
Nombre del caso de uso:
Creado por:		Actualizado por última vez por
Fecha de creacion:		Fecha de última actualización
Actor:
Descripción:
Condiciones previas:
Condiciones de publicación:
Prioridad:
Frecuencia de uso:
Curso normal de eventos:
Cursos alternativos:
Excepciones:
Incluye:
Requisitos especiales:
Supuestos:
Notas y problemas:

Análisis de negocio - Gestión de requisitos

La recopilación de requisitos de software es la base de todo el proyecto de desarrollo de software. Solicitar y recopilar los requisitos comerciales es un primer paso fundamental para cada proyecto. Para cerrar la brecha entre los requisitos comerciales y técnicos, los analistas comerciales deben comprender completamente las necesidades comerciales dentro del contexto dado, alinear estas necesidades con los objetivos comerciales y comunicar adecuadamente las necesidades tanto a las partes interesadas como al equipo de desarrollo.

Las partes interesadas clave desean que alguien pueda explicar los requisitos del cliente / cliente en un inglés sencillo. ¿Les beneficiará esto si comprenden el valor a un alto nivel? Esta será el área de enfoque principal, ya que intentarán mapear la documentación con los requisitos y cómo BA podría comunicarse de la mejor manera posible.

Por qué fracasan los proyectos

Hay muchas razones por las que los proyectos fracasan, pero algunas de las áreas comunes incluyen las siguientes:

• Fracaso de mercado y estrategia
• Fallos organizativos y de planificación
• Fallos de calidad
• Fallos de liderazgo y gobernanza
• Fallas en habilidades, conocimientos y competencias
• Compromiso, trabajo en equipo y fallas de comunicación

El núcleo del problema es que los proyectos son cada vez más complejos, se producen cambios y la comunicación es un desafío.

Por qué los equipos exitosos realizan la gestión de requisitos

La gestión de requisitos se trata de mantener a su equipo in-sync y proporcionando visibility a lo que está sucediendo dentro de un proyecto.

Es fundamental para el éxito de sus proyectos que todo su equipo comprenda lo que está construyendo y por qué; así es como definimos la gestión de requisitos. El "por qué" es importante porque proporciona contexto a los objetivos, la retroalimentación y las decisiones que se toman sobre los requisitos.

Esto aumenta la previsibilidad del éxito futuro y los problemas potenciales, lo que permite a su equipo corregir rápidamente cualquier problema y completar con éxito su proyecto a tiempo y dentro del presupuesto. Como punto de partida, es valioso para todos los involucrados tener una comprensión básica de qué son los requisitos y cómo administrarlos.

Empecemos con lo básico

Un requisito es una condición o capacidad que necesita una parte interesada para resolver un problema o lograr un objetivo. Una condición o capacidad que debe ser cumplida o poseída por un sistema o sistema. Componente para satisfacer un contrato, estándar, especificación u otros documentos impuestos formalmente.

Un requisito puede expresarse con texto, bocetos, maquetas o modelos detallados, cualquier información que comunique mejor a un ingeniero qué construir y a un gerente de control de calidad qué probar. Dependiendo de su proceso de desarrollo, puede utilizar una terminología diferente para capturar los requisitos.

Los requisitos de alto nivel a veces se denominan simplemente needs o goals. Dentro de las prácticas de desarrollo de software, los requisitos pueden denominarse "casos de uso", "características" o "requisitos funcionales". Incluso más específicamente dentro de las metodologías de desarrollo ágil, los requisitos a menudo se capturan comoepics y stories.

Independientemente de cómo los llame su equipo o del proceso que utilice; Los requisitos son esenciales para el desarrollo de todos los productos. Sin una definición clara de los requisitos, podría producir un producto incompleto o defectuoso. A lo largo del proceso, puede haber muchas personas involucradas en la definición de requisitos.

Una parte interesada puede solicitar una característica que describa cómo el producto proporcionará valor para resolver un problema. Un diseñador puede definir un requisito basado en cómo debería verse o funcionar el producto final desde el punto de vista de la usabilidad o la interfaz de usuario.

Un analista de negocios puede crear un requisito del sistema que se adhiera a limitaciones técnicas u organizativas específicas. Para los productos sofisticados y las aplicaciones de software que se están creando en la actualidad, a menudo se necesitan cientos o miles de requisitos para definir suficientemente el alcance de un proyecto o una versión. Por lo tanto, es imperativo que el equipo pueda acceder, colaborar, actualizar y probar cada requisito hasta su finalización, ya que los requisitos cambian y evolucionan naturalmente con el tiempo durante el proceso de desarrollo.

Ahora que hemos definido el valor de la gestión de requisitos a un alto nivel, profundicemos en los cuatro fundamentos que todos los miembros del equipo y las partes interesadas pueden beneficiarse al comprender:

• Planificación de buenos requisitos: "¿Qué diablos estamos construyendo?"
• Colaboración y aceptación: "¡Simplemente apruebe la especificación, ya!"
• Trazabilidad y gestión de cambios: "Espera, ¿saben los desarrolladores que eso cambió?"
• Garantía de calidad: "Hola, ¿alguien probó esto?"

¿Todos saben lo que estamos construyendo y por qué? Ese es el valor de la gestión de requisitos.

Colaboración y aceptación de las partes interesadas

¿Están todos al tanto? ¿Tenemos aprobación sobre los requisitos para seguir adelante? Estas preguntas surgen durante los ciclos de desarrollo. Sería genial si todos pudieran ponerse de acuerdo sobre los requisitos, pero para proyectos grandes con muchas partes interesadas, esto no suele suceder. Tratar de que todos estén de acuerdo puede hacer que las decisiones se retrasen o, peor aún, que no se tomen en absoluto. No siempre es fácil lograr el consenso en todas las decisiones.

En la práctica, no necesariamente quiere "consenso", quiere "aceptación" del grupo y aprobación de quienes tienen el control para que pueda hacer avanzar el proyecto. Con consenso, está tratando de que todos se comprometan y estén de acuerdo con la decisión. Con la aceptación, está tratando de que las personas respalden la mejor solución, tomen una decisión inteligente y hagan lo necesario para seguir adelante.

No es necesario que todos estén de acuerdo en que la decisión es la mejor. Necesita que todos apoyen la decisión. La colaboración en equipo puede ayudar a recibir apoyo en las decisiones y a planificar buenos requisitos.

Los equipos colaborativos trabajan duro para asegurarse de que todos tengan interés en los proyectos y proporcionen comentarios. Los equipos colaborativos comparten ideas continuamente, por lo general tienen una mejor comunicación y tienden a apoyar las decisiones que se toman porque hay un sentido compartido de compromiso y comprensión de los objetivos del proyecto.

Es cuando los desarrolladores, evaluadores u otras partes interesadas se sienten "fuera del circuito" cuando surgen problemas de comunicación, la gente se frustra y los proyectos se retrasan. Una vez que todos hayan aceptado el alcance del trabajo, es imperativo que los requisitos sean claros y estén bien documentados. Hacer un seguimiento de todos los requisitos es donde las cosas se complican.

Imagínese tener una lista de tareas pendientes de una milla de largo que implica colaborar con varias personas para completar. ¿Cómo mantendría todos esos elementos en orden? ¿Cómo haría un seguimiento de cómo un cambio en un elemento afectaría al resto del proyecto? Aquí es donde la trazabilidad y la gestión del cambio añaden valor.

Planificación de buenos requisitos

Entonces, ¿qué hace que sea un buen requisito? Un buen requisito debe ser valioso y factible; debe definir una necesidad y proporcionar un camino hacia una solución. Todos en el equipo deben entender lo que significa. Los requisitos varían en complejidad.

• Un buen documento de requisitos puede formar parte de un grupo con requisitos de alto nivel desglosados ​​en subrequisitos.

• También pueden incluir especificaciones muy detalladas que incluyen un conjunto de requisitos funcionales que describen el comportamiento o los componentes del producto final.

• Los buenos requisitos deben ser concisos y específicos, y deben responder a la pregunta "¿qué necesitamos?" En lugar de "¿cómo satisfacemos una necesidad?"

• Los buenos requisitos garantizan que todas las partes interesadas comprendan su parte del plan; Si las piezas no están claras o se malinterpretan, el producto final podría ser defectuoso o fallar.

Se puede ayudar a prevenir fallas o malas interpretaciones de los requisitos recibiendo comentarios del equipo continuamente durante todo el proceso a medida que los requisitos evolucionan. La colaboración continua y la aceptación de todos es la clave del éxito.

Recopilación y análisis de requisitos

Un requisito es una condición o capacidad que necesita un interesado para resolver un problema o lograr un objetivo organizacional; una condición o capacidad que debe cumplir o poseer un sistema.

El análisis de requisitos en la ingeniería de software cubre aquellas tareas que entran en la determinación de las necesidades o condiciones a cumplir para un producto nuevo o alterado teniendo en cuenta los posibles requisitos conflictivos de varias partes interesadas, analizando, documentando, validando y gestionando los requisitos de software o sistema.

Los requisitos deben ser:

• Documented
• Actionable
• Measurable
• Testable
• Traceable

Los requisitos deben estar relacionados con las necesidades u oportunidades comerciales identificadas y definidas con un nivel de detalle suficiente para el diseño del sistema.

Un analista de negocios recopila información mediante la observación de los sistemas existentes, el estudio de los procedimientos existentes, las discusiones con los clientes y los usuarios finales. El analista también debe tener habilidades imaginativas y creativas en ausencia de un Sistema de trabajo. Analizar el requisito recopilado para encontrar los enlaces faltantes es un análisis de requisitos.

Enfoque de obtención

Para obtener los objetivos, pregunte al experto en negocios, al gerente de desarrollo y al patrocinador del proyecto las siguientes preguntas:

• ¿Qué objetivos comerciales de la empresa ayudará a lograr este proyecto?

• ¿Por qué estamos haciendo este proyecto ahora?

• ¿Qué pasará si lo hacemos más tarde?

• ¿Y si no lo hacemos en absoluto?

• ¿Quiénes se beneficiarán de este proyecto?

• ¿Las personas que se beneficiarán de él lo consideran la mejora más importante que posiblemente se pueda realizar en este momento?

• ¿Deberíamos estar haciendo un proyecto diferente en su lugar?

Los posibles objetivos pueden ser reducir costos, mejorar el servicio al cliente, simplificar el flujo de trabajo, reemplazar tecnología obsoleta, probar una nueva tecnología y muchos otros. Además, asegúrese de comprender exactamente cómo el proyecto propuesto ayudará a lograr el objetivo establecido.

Diferentes tipos de requisitos

Los tipos de requisitos más comunes que interesan a un analista de negocios serían los siguientes:

Requisitos comerciales

Los requisitos comerciales son las actividades críticas de una empresa que deben realizarse para cumplir con los objetivos de la organización sin dejar de ser independiente de la solución. Un documento de requisitos comerciales (BRD) detalla la solución comercial para un proyecto, incluida la documentación de las necesidades y expectativas del cliente.

Requisitos de usuario

Los requisitos del usuario deben especificar los requisitos específicos que el usuario espera / desea que el software se construya a partir del proyecto de software. Un requisito del usuario debe ser Verificable, Claro y conciso, Completo, Consistente, Trazable, Viable.

El documento de requisitos del usuario (URD) ​​o la especificación de requisitos del usuario es un documento que se utiliza normalmente en la ingeniería de software y que especifica lo que el usuario espera que el software pueda hacer.

Requisitos del sistema

Los requisitos del sistema se ocupan de definir los requisitos de recursos de software y los requisitos previos que deben instalarse en una computadora para proporcionar un funcionamiento óptimo de una aplicación.

Requerimientos funcionales

Los requisitos funcionales capturan y especifican el comportamiento previsto específico del sistema que se está desarrollando. Definen cosas como cálculos del sistema, manipulación y procesamiento de datos, interfaz de usuario e interacción con la aplicación, y otras funciones específicas que muestran cómo se satisfacen los requisitos del usuario. Asigne un número de identificación único a cada requisito.

Requerimientos no funcionales

El requisito no funcional es el que especifica criterios que se pueden utilizar para juzgar el funcionamiento de un sistema en lugar de comportamientos específicos. La arquitectura del sistema habla sobre el plan para implementar requisitos no funcionales.

Los requisitos no funcionales hablan de cómo debería verse el sistema o se puede mencionar como "el sistema será". Los requisitos no funcionales se denominan cualidades del sistema.

Requisitos de transición

Los requisitos de transición describen las capacidades que la solución debe cumplir para facilitar la transición del estado actual de la empresa a un estado futuro deseado, pero que no serán necesarias una vez que se complete la transición.

Se diferencian de otros tipos de requisitos porque siempre son de naturaleza temporal y porque no pueden desarrollarse hasta que se defina una solución nueva y una existente. Por lo general, cubren la conversión de datos de los sistemas existentes, las brechas de habilidades que deben abordarse y otros cambios relacionados para alcanzar el estado futuro deseado. Se desarrollan y definen mediante evaluación y validación de soluciones.

Gestión de cambios y trazabilidad

La trazabilidad de requisitos es una forma de organizar, documentar y realizar un seguimiento de todos sus requisitos desde la generación de la idea inicial hasta la fase de prueba.

La matriz de capacidad de rastreo de requisitos (RTM) proporciona un método para rastrear los requisitos funcionales y su implementación a través del proceso de desarrollo. Cada requisito se incluye en la matriz junto con su número de sección asociado.

A medida que avanza el proyecto, el RIM se actualiza para reflejar el estado de cada requisito. Cuando el producto está listo para la prueba del sistema, la matriz enumera cada requisito, qué componente del producto lo aborda y qué prueba verifica que se haya implementado correctamente.

Incluya columnas para cada uno de los siguientes en el RTM:

• Descripción del requisito
• Referencia de requisitos en FRD
• Método de verificación
• Referencia de requisitos en el plan de prueba

Example- Conectando los puntos para identificar las relaciones entre elementos dentro de su proyecto. Es un conector de flujo descendente común.

Requisitos de la idea Prueba de diseño Objetivos comerciales

Debería poder rastrear cada uno de sus requisitos hasta su objetivo comercial original.

Al rastrear los requisitos, puede identificar el efecto dominó que tienen los cambios, ver si se ha completado un requisito y si se está probando correctamente. La gestión de la trazabilidad y el cambio proporciona a los gerentes la tranquilidad y la visibilidad necesaria para anticipar problemas y garantizar una calidad continua.

Seguro de calidad

Obtener los requisitos correctamente a la primera puede significar una mejor calidad, ciclos de desarrollo más rápidos y una mayor satisfacción del cliente con el producto. La administración de requisitos no solo lo ayuda a hacerlo bien, sino que también ayuda a su equipo a ahorrar dinero y muchos dolores de cabeza durante el proceso de desarrollo.

Los requisitos concisos y específicos pueden ayudarlo a detectar y solucionar problemas temprano, en lugar de más tarde, cuando es mucho más costoso solucionarlos. Además, puede costar hasta100 times más para corregir un defecto más adelante en el proceso de desarrollo después de que se haya codificado, que para corregirlo al principio mientras es un requisito.

Al integrar la gestión de requisitos en su proceso de garantía de calidad, puede ayudar a su equipo a aumentar la eficiencia y eliminar el retrabajo. Además, el retrabajo es donde ocurren la mayoría de los problemas de costos.

En otras palabras, los equipos de desarrollo están desperdiciando la mayor parte de sus presupuestos en esfuerzos que no se realizan correctamente la primera vez. Por ejemplo, un desarrollador codifica una función basándose en un documento de especificación antiguo, solo para saber más tarde que los requisitos de esa función cambiaron. Este tipo de problemas se pueden evitar con las mejores prácticas de gestión de requisitos eficaces.

En resumen, la gestión de requisitos puede parecer una disciplina compleja, pero cuando se reduce a un concepto simple, se trata de ayudar a los equipos a responder la pregunta: "¿Todos comprenden lo que estamos construyendo y por qué?" Desde los analistas de negocios, gerentes de productos y líderes de proyectos hasta los desarrolladores, gerentes de control de calidad y evaluadores, junto con las partes interesadas y los clientes involucrados, a menudo la causa raíz del fracaso del proyecto es una mala comprensión del alcance del proyecto.

Cuando todos colaboran y tienen un contexto y una visibilidad completos de las discusiones, decisiones y cambios relacionados con los requisitos a lo largo del ciclo de vida del proyecto, es entonces cuando el éxito ocurre de manera constante y usted mantiene la calidad continua. Además, el proceso es más suave con menos fricción y frustración en el camino para todos los involucrados.

Note- La investigación ha demostrado que los equipos de proyectos pueden eliminar del 50 al 80% de los defectos del proyecto mediante la gestión eficaz de los requisitos. Según el instituto de ingeniería de software Carnegie Mellon, "60-80 por ciento del costo del desarrollo de software está en reelaboración".

Obtención de aprobación de requisitos

La firma de requisitos formaliza el acuerdo de las partes interesadas del proyecto de que el contenido y la presentación de los requisitos, según se documenta, son precisos y completos. El acuerdo formal reduce el riesgo de que, durante o después de la implementación, una parte interesada introduzca un nuevo requisito (no encontrado anteriormente).

La obtención de la aprobación de los requisitos generalmente implica una revisión final cara a cara de los requisitos, según se documenta, con cada parte interesada del proyecto. Al final de cada revisión, se solicita a las partes interesadas que aprueben formalmente el documento de requisitos revisado. Esta aprobación puede registrarse física o electrónicamente.

La obtención de la aprobación de los requisitos suele ser la tarea final dentro de la Comunicación de requisitos. El Analista de Negocios requerirá el resultado de la (s) Revisión (es) de Requisitos Formales, incluida la acomodación de cualquier comentario u objeción que se haya presentado durante el proceso de revisión.

Análisis de negocio: modelado

Un modelo de negocio puede definirse como una representación de un negocio o solución que a menudo incluye un componente gráfico junto con texto de apoyo y relaciones con otros componentes. Por ejemplo, si tenemos que comprender el modelo de negocio de una empresa, nos gustaría estudiar las siguientes áreas como:

• Valores fundamentales de la empresa
• Para que sirve
• ¿Qué se distingue?
• Sus recursos clave
• Relaciones importantes
• Sus canales de entrega

Con la ayuda de técnicas de modelado, podemos crear una descripción completa de las estructuras organizativas, los procesos y la información existentes y propuestos que utiliza la empresa.

El modelo de negocio es un modelo estructurado, como un anteproyecto para el producto final a desarrollar. Da estructura y dinámica a la planificación. También proporciona la base para el producto final.

Propósito del modelado empresarial

El modelado empresarial se utiliza para diseñar el estado actual y futuro de una empresa. El analista de negocios y las partes interesadas utilizan este modelo para asegurarse de que comprenden con precisión el modelo actual "tal como está" de la empresa.

Se utiliza para verificar si las partes interesadas tienen un entendimiento compartido del futuro propuesto de la solución.

El análisis de los requisitos es parte del proceso de modelado empresarial y constituye el área de enfoque central. Los requisitos funcionales se recopilan durante el "estado actual". Estos requisitos son proporcionados por las partes interesadas con respecto a los procesos comerciales, los datos y las reglas comerciales que describen la funcionalidad deseada que se diseñará en el estado futuro.

Realización de análisis GAP

Después de definir las necesidades comerciales, se debe identificar el estado actual (por ejemplo, procesos comerciales actuales, funciones comerciales, características de un sistema actual y servicios / productos ofrecidos y eventos a los que el sistema debe responder) para comprender cómo las personas, los procesos y la tecnología, la estructura y la arquitectura están respaldando el negocio al buscar información del personal de TI y otras partes interesadas relacionadas, incluidos los propietarios de negocios.

Luego, se realiza un análisis de brechas para evaluar si existe alguna brecha que impida alcanzar las necesidades comerciales comparando el estado actual identificado con los resultados deseados.

Si no hay brecha (es decir, el estado actual es adecuado para satisfacer las necesidades comerciales y los resultados deseados), probablemente no será necesario lanzar el proyecto de TI. De lo contrario, se deben identificar los problemas / cuestiones que deben abordarse para cerrar la brecha.

Se pueden utilizar técnicas como el análisis FODA (Fortalezas, Debilidades, Oportunidades y Amenazas) y el análisis de documentos.

Evaluar el sistema propuesto

BA debe ayudar al equipo del proyecto de TI a evaluar el sistema de TI propuesto para asegurarse de que satisface las necesidades comerciales y maximiza los valores entregados a las partes interesadas. BA también debe revisar la preparación de la organización para respaldar la transición al sistema de TI propuesto para garantizar una implementación del sistema sin problemas.

BA debería ayudar al equipo del proyecto de TI a determinar si la opción de sistema propuesta y el diseño del sistema de alto nivel podrían satisfacer las necesidades comerciales y ofrecer suficiente valor comercial para justificar la inversión. Si hay más de una opción de sistema, BA debe trabajar con el personal de TI para ayudar a identificar los pros y los contras de cada opción y seleccionar la opción que ofrezca el mayor valor comercial.

Principios rectores para el modelado empresarial

El papel principal del modelado de negocios es principalmente durante la etapa de inicio y las etapas de elaboración del proyecto y se desvanece durante la etapa de construcción y transición. Se trata principalmente de aspectos analíticos del negocio combinados con el mapeo técnico de la aplicación o solución de software.

• Domain and User variation- El desarrollo de un modelo de negocio revelará con frecuencia áreas de desacuerdo o confusión entre las partes interesadas. El analista de negocios deberá documentar las siguientes variaciones en el modelo tal cual.

• Multiple work units perform the same function- Documentar las variaciones en el modelo TAL CUAL. Pueden ser diferentes divisiones o geografías.

• Multiples users perform the same work- Diferentes partes interesadas pueden hacer un trabajo similar de manera diferente. La variación puede ser el resultado de diferentes conjuntos de habilidades y enfoques de diferentes unidades de negocios o el resultado de diferentes necesidades de las partes interesadas externas atendidas por la empresa. Documente las variaciones en el modelo TAL CUAL.

• Resolution Mechanism- El analista de negocios debe documentar si la solución ToBe se adaptará a las inconsistencias en el modelo comercial actual o si la solución requerirá estandarización. Las partes interesadas deben determinar qué enfoque seguir. El modelo To-Be reflejará su decisión.

Ejemplo del rol de BA en Modelado de sistemas ERP

Se supone que un analista de negocios debe definir un proceso comercial estándar y configurarlo en un sistema ERP que es de importancia clave para una implementación eficiente. También es deber de un BA definir el lenguaje de los desarrolladores en un lenguaje comprensible antes de la implementación y luego, utilizar las mejores prácticas y mapearlas según las capacidades del sistema.

Un requisito para el sistema es el análisis de ajuste GAAP, que debe equilibrar entre:

• La necesidad de los cambios técnicos, que son las mejoras para lograr la identidad con la práctica existente.

• Cambios efectivos, que están relacionados con la reingeniería de los procesos comerciales existentes para permitir la implementación de la funcionalidad estándar y la aplicación de modelos de proceso.

Analista de negocio funcional

La experiencia en el dominio generalmente se adquiere durante un período al estar en el "negocio" de hacer cosas. Por ejemplo,

• UN banking associate adquiere conocimiento de varios tipos de cuentas que un cliente (individual y comercial) puede operar junto con el flujo de procesos de negocios detallado.

• Un insurance sales representative Puede comprender las distintas etapas involucradas en la contratación de una póliza de seguro.

• UN marketing analyst tiene más posibilidades de comprender las partes interesadas clave y los procesos comerciales involucrados en un sistema de gestión de relaciones con el cliente.

• Un analista de negocios involucrado en capital marketsSe supone que el proyecto tiene experiencia en la materia y un sólido conocimiento de acciones, renta fija y derivados. Además, se espera que haya manejado back office, front office y exposición práctica en la aplicación de modelos de gestión de riesgos.

• UN Healthcare Business Analyst Se requiere tener una comprensión básica de las métricas financieras y de utilización de la atención médica de EE. UU., Experiencia técnica y comprensión de EDI 837/835/834, pautas de HIPAA, codificación ICD - 9/10 y códigos CPT, conocimiento LOINC, SNOMED.

Algunos analistas comerciales adquieren conocimientos de dominio probando aplicaciones comerciales y trabajando con los usuarios comerciales. Crean un entorno de aprendizaje propicio a través de sus habilidades interpersonales y analíticas. En algunos casos, complementan sus conocimientos de dominio con algunas certificaciones de dominio ofrecidas por AICPCU / ​​IIA y LOMA en el campo de los seguros y servicios financieros. Hay otros institutos que ofrecen certificación en otros dominios.

Otras actividades importantes

Después de un examen exhaustivo de los procesos comerciales actuales, puede ofrecer una asistencia altamente profesional para identificar el enfoque óptimo para modelar el sistema.

• Organizar la preparación de una descripción formalizada y uniforme de los procesos comerciales de manera que se asegure una automatización eficiente en el sistema.

• Asistencia a sus equipos para completar cuestionarios estándar para el sistema relevante que puedan proporcionar los desarrolladores.

• Se definen los requisitos de participación en reuniones de trabajo hacia los desarrolladores.

• Verifique y controle si los requisitos establecidos por usted se han “reproducido” y registrado correctamente en los documentos que describen el modelo futuro en el sistema (Blueprints).

• Preparación de datos y asistencia para la creación de prototipos del sistema.

• Asistencia en la elaboración de datos para migración de listas y balances en el formato requerido por el sistema.

• Revisión del prototipo de configuración para el cumplimiento de los requisitos definidos por los propietarios de procesos de negocio.

• Actuar como un recurso de soporte para sus equipos de TI en la preparación de datos y el desempeño real de las pruebas funcionales y de integración en el sistema.

En la siguiente sección, analizaremos brevemente algunas de las populares herramientas de modelado empresarial utilizadas por las grandes organizaciones en entornos de TI.

Herramienta 1: Microsoft Visio

MS-Visio es un software de dibujo y diagramación que ayuda a transformar conceptos en una representación visual. Visio le proporciona formas, símbolos, fondos y bordes predefinidos. Simplemente arrastre y suelte elementos en su diagrama para crear una herramienta de comunicación profesional.

Step 1 - Para abrir un nuevo dibujo de Visio, vaya al menú Inicio y seleccione Programas → Visio.

Step 2 - Mueva el cursor sobre "Proceso de negocio" y seleccione "Diagrama de flujo básico".

La siguiente captura de pantalla muestra las secciones principales de la aplicación MS-Visio.

Analicemos ahora la utilidad básica de cada componente:

A- las barras de herramientas en la parte superior de la pantalla son como otros programas de Microsoft como Word y PowerPoint. Si ha utilizado estos programas antes, es posible que observe algunas funcionalidades diferentes, que exploraremos más adelante.

Seleccionar la Galería de diagramas de ayuda es una buena manera de familiarizarse con los tipos de dibujos y diagramas que se pueden crear en Visio.

B- El lado izquierdo de la pantalla muestra los menús específicos del tipo de diagrama que está creando. En este caso, vemos -

• Formas de flecha
• Backgrounds
• Formas básicas de diagrama de flujo
• Fronteras y títulos

C - El centro de la pantalla muestra el espacio de trabajo del diagrama, que incluye la página del diagrama real, así como un espacio en blanco adyacente a la página.

D- El lado derecho de la pantalla muestra algunas funciones de ayuda. Algunas personas pueden optar por cerrar esta ventana para aumentar el área del espacio de trabajo del diagrama y volver a abrir las funciones de ayuda cuando sea necesario.

Herramienta 2: Arquitecto empresarial

Enterprise Architect es una herramienta de diseño y modelado visual basada en UML. La plataforma admite el diseño y la construcción de sistemas de software, modelando procesos comerciales y modelando dominios basados ​​en la industria. Es utilizado por empresas y organizaciones no solo para modelar la arquitectura de sus sistemas. Pero procesar la implementación de estos modelos a lo largo del ciclo de vida completo del desarrollo de aplicaciones.

La intención del arquitecto empresarial es determinar cómo una organización puede lograr de manera más efectiva sus objetivos actuales y futuros.

El arquitecto empresarial tiene cuatro puntos de vista que son los siguientes:

• Business perspective - La perspectiva de Negocio define los procesos y estándares por los cuales el negocio opera en el día a día.

• Application Perspective - La perspectiva de la aplicación define las interacciones entre los procesos y estándares utilizados por la organización.

• Information Perspective - Esto define y clasifica los datos sin procesar como archivos de documentos, bases de datos, imágenes, presentaciones y hojas de cálculo que la organización requiere para operar de manera eficiente.

• Technology Prospective - Define el hardware, los sistemas operativos, la programación y las soluciones de red utilizadas por la organización.

Herramienta 3: Rational Requisite Pro

El proceso de obtener, documentar, organizar el seguimiento y cambiar los Requisitos y comunicar esta información entre los equipos del proyecto para garantizar que los cambios iterativos e imprevistos se mantengan durante todo el ciclo de vida del proyecto.

Supervisar el estado y controlar los cambios en la línea base de requisitos. Los elementos primarios son el control de cambios y la trazabilidad.

Requisite Pro se utiliza para las actividades anteriores y propósitos de administración de proyectos, la herramienta se utiliza para realizar consultas y búsquedas, Ver la discusión que formaba parte del requisito.

En Requisite Pro, el usuario puede trabajar en el documento de requisitos. El documento es un archivo de MS-Word creado en la aplicación Reqpro e integrado con la base de datos del proyecto. Los requisitos creados fuera de Requisite pro se pueden importar o copiar en el documento.

En Requisite Pro también podemos trabajar con trazabilidad, aquí es una relación de dependencia entre dos requisitos. La trazabilidad es un enfoque metódico para gestionar el cambio vinculando requisitos que están relacionados entre sí.

Requisite Pro facilita el seguimiento de los cambios en un requisito a lo largo del ciclo de desarrollo, por lo que no es necesario revisar todos sus documentos individualmente para determinar qué elementos necesitan actualizarse. Puede ver y administrar relaciones sospechosas mediante una Matriz de trazabilidad o una vista de Árbol de trazabilidad.

Los proyectos Requisite Pro nos permiten crear un marco de proyecto en el que se organizan y gestionan los artefactos del proyecto. En cada proyecto se incluyen los siguientes.

• Información general del proyecto
• Packages
• Información general del documento
• Tipos de documentos
• Tipos de requisitos
• Atributos de requisitos
• Valores de atributo
• Trazabilidad entre proyectos

Requisite Pro permite que múltiples usuarios accedan a los mismos documentos del proyecto y base de datos simultáneamente, por lo que el aspecto de seguridad del proyecto es muy crucial. La seguridad evita el uso del sistema, daños potenciales o pérdida de datos debido al acceso de usuarios no autorizados a un documento del proyecto.

Se recomienda que la seguridad esté habilitada para todos los proyectos de RequisitePro. Al hacerlo, se asegura de que todos los cambios en el proyecto estén asociados con el nombre de usuario adecuado de la persona que realizó el cambio, lo que garantiza que tenga una pista de auditoría completa para todos los cambios.