Introducción
Las técnicas influyen en la manera de realizar el Análisis de Negocio o describen la forma específica que puede tomar la salida de una tarea. Las técnicas incluidas son sólo un subconjunto de las técnicas que los profesionales del Análisis de Negocio utilizamos. Las que aquí se describen son aplicables a una cantidad suficiente de diversas situaciones y dominios de negocio, y han sido adoptadas por una cantidad suficiente de profesionales del Análisis de Negocio de modo que se esperaría que un generalista calificado debiera estar razonablemente familiarizado con la existencia y propósito de la técnica. Los Analistas de Negocio especializados en una metodología o dominio de negocio específico pueden necesitar comprender un grupo menor de técnicas en mayor profundidad, o pueden necesitar desarrollar pericia en técnicas no incluidas aquí.
En ciertos casos, hemos agrupado un conjunto de técnicas conceptualmente similares dentro de una sola entrada. Esto se hizo para indicar que cada una de las variantes técnicas que son enumeradas en esa entrada (o inclusive otras variantes que no están específicamente mencionadas) pueden ser usadas para ese propósito. Si bien ciertamente existen diferencias teóricas y prácticas importantes entre estas variantes, la mayoría de los profesionales encontrarán que el tener habilidad en una sola variante es suficiente para cualquier ambiente específico.
Definición de los criterios de aceptación y evaluación
Determinar cuáles requerimientos pueden ser utilizados más eficazmente como criterios de aceptación y evaluación.
- Los ‘criterios de aceptación’ describen el conjunto mínimo de requerimientos que deben satisfacerse para que valga la pena implementar una solución en particular.
- Los ‘criterios de evaluación’ son el conjunto de requerimientos que serán utilizados para elegir entre soluciones múltiples.
Tanto los criterios de aceptación como de evaluación pueden ser utilizados para determinar si una solución, o componente de solución, puede demostrar que satisface objetivamente con un requerimiento. Los ‘criterios de aceptación’ son utilizados habitualmente cuando sólo una solución posible está siendo evaluada, y están generalmente expresados como ‘aprobada’ o ‘reprobada’. Los ‘criterios de evaluación’ son utilizados para comparar múltiples soluciones o componentes de solución y permitir un rango de puntuaciones posibles.
Estudio comparativo
Los ‘estudios comparativos’ son llevados a cabo para comparar prácticas de la organización, en relación con las ‘mejores de su clase’ que existen dentro de empresas de la competencia, en el gobierno o en la industria. El objetivo de estos estudios es determinar cómo las empresas logran sus niveles superiores de desempeño y usar esa información para diseñar proyectos que mejoren las operaciones de la empresa.
El ‘estudio comparativo’ está habitualmente centrado en estrategias, operaciones y procesos.
Tormenta de ideas
La ‘tormenta de ideas’ es una técnica destinada a producir un conjunto de opciones
amplio y diverso. La técnica ayuda (pero no está limitada) a contestar preguntas
específicas tales como:
- ¿Qué opciones existen para resolver el problema en cuestión?
- ¿Qué factores inhiben al grupo para avanzar con un enfoque u opción?
- ¿Que podría estar causando un retraso en la actividad “A”?
- ¿Qué puede hacer el grupo para resolver el problema “B”?
La ‘tormenta de ideas’ funciona centrándose en un tema o problema, y generando luego muchas posibles soluciones a éste. Esta técnica se aplica mejor en un grupo ya que se basa en la experiencia y creatividad de todos los miembros del grupo. En la ausencia de un grupo, se puede usar la técnica en uno mismo para precipitar nuevas ideas. Para acrecentar la creatividad se estimula a los participantes para que usen formas nuevas de ver las cosas y asociarlas libremente en cualquier dirección. La ‘tormenta de ideas’, cuando está facilitada adecuadamente, puede resultar productiva, atractiva y divertida.
Análisis de las reglas de negocio
Las políticas y reglas dirigen y limitan a una organización y operación de una organización.
Una política de negocio es una directiva no-recurrible que apoya una meta de negocio. Una regla de negocio es una directiva específica, recurrible, verificable que está bajo el control de la organización, y que apoya una política de negocio. Las reglas que son particularmente complejas o que contienen una serie de dependencias relacionadas entre sí, pueden ser representadas en una tabla o árbol de decisión, como se describe en la sección Análisis de decisiones.
Un conjunto de principios básicos guían al Analista de Negocio cuando declara y
administra las reglas de negocio. Las reglas de negocio deberían ser:
- Declaradas en una terminología de negocios apropiada para que los expertos enla materia puedan validarlas.
- Documentadas independientemente de cómo estas serán impuestas.
- Descritas al nivel más detallado posible y de forma declarativa.
- Separadas de aquellos procesos que la regla apoya o limita.
- Mantenidas de una manera que habilite a la organización a monitorear y adaptarlas reglas cuando cambian las políticas de negocio.
Diccionario de datos y glosario
Los ‘diccionarios de datos o glosarios’ se emplean para definir e identificar formalmente toda la terminología utilizada por una organización o unidad de la organización.
Por ejemplo, una unidad de la organización puede hacer la distinción entre un cliente y un comprador, donde cliente es con quien el negocio tiene un acuerdo de servicio profesional obligante, y un comprador es quien puede tener una relación mucho más casual y basada en las transacciones con el negocio. En una organización de salud, tal como un hospital, puede utilizarse el término “paciente”, junto con su definición específica, en lugar de cliente o comprador.
Diagramas de flujo de datos
El Diagrama de Flujo de Datos (DFD) proporciona una representación visual de cómo fluye la información a través de un sistema. Muestra:
- Las entidades externas que aportan al o reciben datos del sistema.
- Los procesos del sistema que transforman los datos.
- Los almacenes de datos donde se recopilan los datos por un cierto periodo de tiempo.
- El flujo de datos por los cuales los datos se mueven entre entidades externas, procesos y almacenes de datos.
Modelado de datos
Un ‘modelo de datos’ por lo general toma la forma de un diagrama apoyado por descripciones textuales. Representa visualmente los tipos de personas, sitios, cosas y conceptos que son importantes para el negocio, los atributos asociados con ellos, y las relaciones de negocio significativas entre ellos. Los modelos de datos a menudo son apoyados por un Diccionario de datos y glosario y por el Análisis de las reglas de negocio.
Los dos tipos de modelos de datos más extensamente usados son el ‘Diagrama de Entidades-Relaciones (DER) y el Diagrama de Clases, aunque aún permanecen en uso otros modelos de notaciones. La notación usada es a menudo determinada por la plataforma de tecnología de la organización. Los DERs son preferidos generalmente cuando el modelo será usado como fundamento para una base de datos relacional,
mientras que los diagramas de clases son preferidos para apoyar el desarrollo orientado a objetos. Los Analistas de Negocio que usen estos modelos deberían entender las características únicas de cada tipo de modelo de datos, que responden a objetivos
similares, pero tienen algunas diferencias conceptuales importantes que surgen en la práctica.
Análisis de decisiones
El ‘análisis de decisiones’ es un enfoque de la toma de decisiones que examina y modela las consecuencias posibles de diferentes decisiones. El ‘análisis de decisiones’ ayuda a tomar una decisión óptima en condiciones de incertidumbre. La incertidumbre puede existir debido a factores desconocidos que son relevantes para el problema de decisión, porque hay demasiados factores posibles interrelacionados a considerar, por perspectivas en conflicto en una situación, o por las soluciones de compromiso que ofrecen las diferentes opciones disponibles.
Un análisis eficaz de las decisiones requiere que el analista entienda:
- Los valores, metas y objetivos que son relevantes para el problema de decisión;
- La naturaleza de la decisión que se debe tomar;
- Las áreas de incertidumbre que afectan a la decisión; y
- Las consecuencias de cada decisión posible.
Las tareas en el área de conocimiento Análisis empresarial describen mucho de lo
que se requiere para estructurar eficazmente un problema de decisión. Esta técnica describe las herramientas específicas usadas para analizar resultados, incertidumbre
y, soluciones de compromiso. El ‘análisis de decisiones’ puede implicar el uso de
modelos y aplicaciones de software especializadas muy complejas.
Análisis de documentos
El ‘análisis de documentos’ puede incluir análisis de planes de negocio, estudios de mercado, contratos, solicitudes de propuesta, declaraciones de trabajo, memorándums,
pautas existentes, procedimientos, guías de capacitación, literatura sobre el producto en competencia, revisiones comparativas publicadas del producto, reportes de problemas, registros de sugerencias de clientes y especificaciones existentes del sistema, entre otros. Identificar y consultar todas las fuentes probables de requerimientos resultará en una mejor cobertura de requerimientos, suponiendo que la documentación esté actualizada.
El ‘análisis de documentos’ se usa si el objetivo es reunir detalles de soluciones existentes, incluso reglas de negocio, entidades y atributos que tienen que ser incluidos en una solución nueva o que necesitan ser actualizados para la solución actual. Esta técnica también se aplica en situaciones donde los expertos en la materia para las soluciones existentes ya no están con la organización, o no van a estar disponibles durante todo el proceso de ‘elicitación’.
Estimación
Las ‘técnicas de estimación’ son usadas para desarrollar un mejor entendimiento del rango posible de gastos y esfuerzo asociado con cualquier iniciativa. La estimación es usada cuando es imposible determinar costos exactos. La estimación no puede y no elimina la incertidumbre; sino que el objetivo de la estimación es conseguir una evaluación razonable del costo y esfuerzo probables requeridos.
Mientras menos información está disponible para el analista, mayor será el rango de incertidumbre. Las estimaciones deberían ser revisadas nuevamente en la medida que más información se encuentre disponible. Muchas técnicas de estimación confían en registros históricos de desempeño de la organización para calibrarlos en comparación con el desempeño real. Las estimaciones deberían incluir una evaluación del rango de incertidumbre asociada con esa estimación.
Grupos de opinión
Un ‘grupo de opinión’ está formado por individuos precalificados cuyo objetivo es discutir y comentar sobre un tema. Es una oportunidad para los individuos de compartir sus propias perspectivas y discutirlas en un contexto grupal. Esto podría llevar a los participantes a revaluar sus propias perspectivas a la luz de las experiencias de otros. Un moderador entrenado se encarga del trabajo administrativo previo, facilita la sesión y produce el reporte. Los observadores pueden registrar o supervisar el ‘grupo de opinión’, pero sin participar en él.
En la medida que esta técnica de ‘elicitación’ está considerada como una forma de investigación cualitativa, los resultados de la sesión son analizados y reportados como temas y perspectivas, en lugar de hallazgos numéricos. El reporte también puede incluir citas seleccionadas para apoyar los temas.
Un ‘grupo de opinión’ tradicional se reúne físicamente en el mismo lugar. Un grupo de opinión en línea permite que miembros que estén ubicados remotamente participen vía la conexión de red. Cada enfoque tiene pros y contras en términos de logística y gastos.
Un ‘grupo de opinión’ puede ser utilizado durante cualquier estado de un ciclo de vida: exploratorio, en desarrollo, listo para ser lanzado o en producción. Si el tema del grupo es un producto en desarrollo, las ideas del grupo son analizadas con relación a los requerimientos declarados. Esto puede ocasionar la actualización de los requerimientos existentes o el descubrir nuevos requerimientos. Si el tema es un producto terminado que está listo para ser lanzado, el reporte del grupo podría influir en cómo colocar el producto en el mercado. Si el tema es un producto en producción, el reporte del grupo puede proporcionar la dirección en las revisiones de la versión siguiente de los requerimientos. Un grupo de opinión también puede servir como un medio de evaluar la satisfacción del cliente por un producto o servicio.
El trabajo en un ‘grupo de opinión’ puede ser similar a aquel que se realiza en una sesión de ‘tormenta de ideas’. Una diferencia es que un grupo de opinión está generalmente
más estructurado. Otra diferencia es que la meta de la sesión de ‘tormenta de ideas’ es buscar activamente ideas amplias, creativas e incluso exageradas.
Descomposición funcional
La ‘descomposición funcional’ implica el desglose de un problema grande en funciones
o entregables más pequeños. El objetivo principal de la ‘descomposición funcional’ es asegurar que el problema sea dividido en subproblemas que sean tan independientes como sea posible, de modo que el trabajo pueda ser asignado a grupos diferentes. Esto proporciona la capacidad de graduar y administrar proyectos más grandes.
Análisis de interfaces
Una interfaz es una conexión entre dos componentes. La mayor parte de las aplicaciones de software requieren una o varias interfaces. Los tipos de interfaz incluyen:
- La interfaz de usuario, incluye a personas que directamente se relacionan con el sistema, así como también reportes proporcionados al usuario.
- Interfaces para y desde aplicaciones externas.
- Interfaces para y desde dispositivos de hardware externos.
El ‘análisis de las interfaces’ ayuda a aclarar las fronteras de las aplicaciones participantes de la interfaz. Distingue cuáles aplicaciones proporcionan funcionalidad específica junto con las necesidades de entrada y salida de datos. Al separar clara y cuidadosamente los requerimientos para cada aplicación mientras se definen los requerimientos de las interfaces compartidas, se establecen las bases de una interoperabilidad exitosa.
Identificando qué interfaces son necesarias para apoyar una aplicación, se establece el escenario para ‘elicitar’ una amplia variedad de requerimientos. La identificación
temprana de interfaces descubre y confirma los stakeholders que participan en la interfaz y proporciona un marco para el análisis subsiguiente de los requerimientos detallados para cada interfaz. El ‘análisis de interfaces’ es por cierto necesario para un componente de solución o una solución de software, pero también puede ser útil para una solución que no sea de software, tal como definir requerimientos para entregables que serán producidos por terceros.
Entrevistas
En una entrevista, el entrevistador formal o informalmente dirige preguntas al stakeholder con el fin de obtener respuestas que serán usadas para crear requerimientos formales. Una entrevista “uno a uno” es la más común. En una entrevista de grupo (con más de un entrevistado al mismo tiempo) el entrevistador debe ser cauteloso para ‘elicitar’ respuestas de todos los asistentes.
Con el fin de obtener requerimientos, las entrevistas son de dos tipos básicamente:
- Entrevista estructurada: donde el entrevistador tiene un grupo de preguntas predefinidas y busca respuestas.
- Entrevista no-estructurada: donde, sin cualquier pregunta predefinida, el entrevistador y el entrevistado hablan de temas de discusión de interés de un modo abierto.
Una entrevista exitosa depende de varios factores, incluye pero no se limita a:
- Nivel de entendimiento del tema por el entrevistador.
- Experiencia del entrevistador en la realización de entrevistas.
- Habilidad del entrevistador en documentar discusiones.
- Preparación del entrevistado para proporcionar la información relevante.
- El grado de claridad en la mente del entrevistado sobre lo que el negocio requiere del sistema del que se trate.
- Compenetración del entrevistador con el entrevistado.
Proceso de lecciones aprendidas
El objetivo del ‘proceso de lecciones aprendidas’ es el de compilar y documentar los éxitos obtenidos, oportunidades de mejora, fracasos y recomendaciones para mejorar la realización de proyectos o fases del proyecto futuros.
Las sesiones de lecciones aprendidas pueden incluir cualquier formato o instalación que sea adecuado para los stakeholders clave identificados como participantes en estas sesiones.
Métricas e indicadores clave de desempeño
El objetivo de las ‘métricas e indicadores clave de desempeño’ es medir el desempeño de las soluciones, de los componentes de la solución y otros asuntos de interés para los stakeholders.
Una métrica es un nivel cuantificable de un indicador que una organización usa para medir el progreso. Un indicador identifica una medida numérica específica que representa el grado de progreso para alcanzar una meta, un objetivo, un resultado, una
actividad o una entrada adicional. Un indicador clave de desempeño es el que mide el progreso hacia una meta u objetivo estratégicos. La presentación de reportes es el proceso de informar a los stakeholders de las métricas de los indicadores en formatos específicos a intervalos especificados.
Las métricas y la presentación de reportes son componentes clave de monitoreo y evaluación. El monitoreo es un proceso continuo de recopilación de datos para determinar qué tan bien ha sido implementada una solución comparada con los resultados esperados. La evaluación es la valoración sistemática y objetiva de una solución para determinar su estado y eficacia en alcanzar sus objetivos en el correr del tiempo, e identificar maneras de mejorar la solución para satisfacerlos mejor. Las prioridades principales de un sistema de evaluación y monitoreo son las metas y efectos previstos de una solución, así como también entradas, actividades y salidas.
Análisis de los requerimientos no-funcionales
Los requerimientos no-funcionales documentan las cualidades de un sistema que son importantes para:
- La comunidad de usuarios, como usabilidad, confiabilidad, facilidad de aprendizaje, etc.
- La comunidad de programadores, como escalabilidad, mantenimiento, reusabilidad, etc.
En sentido estricto, el término “requerimientos no-funcionales” sólo se utiliza para describir una aplicación de software. Sin embargo, las varias categorías de requerimientos no-funcionales pueden ser aplicables a otros componentes de la solución para los cuales se pueden desarrollar requerimientos. Por ejemplo, los requerimientos de confiabilidad para una unidad de la organización podrían incluir horas específicas de servicio, o los requerimientos de eficiencia en el desempeño de un proceso de negocio podrían incluir un tiempo de ciclo para tratar con una solicitud del cliente y podrían ser capturados en un acuerdo de nivel de servicio. En estos casos, puede preferirse el uso de un término alternativo, por ejemplo, requerimientos de “calidad del servicio”
Observación
La ‘observación’ es un medio de ‘elicitar’ requerimientos a través de realizar una evaluación del ambiente de trabajo de los stakeholders. Esta técnica es apropiada cuando se documentan los detalles sobre un proceso actual o si el proyecto está destinado a mejorar o cambiar un proceso existente.
La observación se apoya en el estudio de las personas realizando su trabajo, y es a veces llamada “aprendizaje por observación del trabajo”, o “siguiendo a las personas de cerca”. Por ejemplo, algunas personas tienen su rutina de trabajo con tal hábito que tienen dificultad de explicar qué hacen o por qué. El observador puede observar realizar su trabajo con el fin de entender el flujo de trabajo. En ciertos proyectos, es importante entender los procesos actuales para evaluar mejor las modificaciones que puedan ser necesarias de dichos procesos.
Hay dos enfoques básicos para la técnica de observación:
- Pasivo o invisible: En este enfoque, el observador observa al usuario trabajando en su rutina de trabajo, pero no hace preguntas. El observador registra lo que ha observado, pero por lo demás se queda al margen de lo que pasa. El observador espera hasta que el proceso entero haya terminado antes de hacer cualquier pregunta. El observador debería observar el proceso de negocio varias veces para asegurase de que entiende cómo el proceso funciona hoy y por qué funciona del modo en que lo hace.
- Activo o visible: En este enfoque, mientras el observador observa el proceso actual y toma notas puede dialogar con el usuario. Cuando el observador tiene preguntas en cuanto a por qué algo está siendo hecho de cierta forma, hace las preguntas de inmediato, aun cuando interrumpan la rutina de trabajo del usuario.
Variaciones de la técnica de observación:
- En algunos casos, el observador podría participar en el trabajo real para llegar a sentir cómo el proceso de negocio funciona en la actualidad. Necesariamente esto estaría limitado a actividades que sean apropiadas para ser realizadas por una persona no experta y cuyos resultados no afectarían negativamente el negocio.
- El observador se convierte en un aprendiz temporal.
- El observador observa una demostración de cómo son desempeñados un proceso y/o una tarea específicos.
Modelado de la organización
El ‘modelado de la organización’ es usado para describir los roles, responsabilidades y estructuras de reporte que existen dentro de una organización y alinear esas estructuras con las metas de la organización.
Un ‘modelo de la organización’ define cómo está estructurada una organización o unidad de la organización. Las unidades de la organización reúnen a un grupo de personas para cumplir con un objetivo o una meta común. Este objetivo puede ser funcional, lo que significa que las personas en cuestión comparten un conjunto común de habilidades y conocimientos, o sirve a un mercado en particular. Un ‘modelo de la organización’ definirá el alcance de la unidad de la organización, las relaciones formales entre las personas que son miembros de esa unidad, los roles que esas personas tienen, y las interfaces entre esa unidad y otras unidades o stakeholders.
Seguimiento de problemas
El ‘seguimiento de problemas’ proporciona un enfoque organizado al rastreo, administración y resolución de defectos, asuntos, problemas y riesgos a través de las actividades del Análisis de Negocio. La administración de estos asuntos es importante para que se puedan resolver de una manera oportuna y asegurar así su éxito.
Los problemas pueden incluir asuntos, cuestiones, riesgos, defectos, conflictos u otras preocupaciones a los que se necesitan dar seguimiento para su resolución. Un sistema de seguimiento de problemas asegura que los asuntos no sean simplemente perdidos o descuidados. Para cada problema, la herramienta de seguimiento puede incluir una identificación del problema, actualización del estado, asignación de acciones relacionadas que son requeridas por los miembros del equipo y seguimiento de las fechas esperadas de resolución, resultados de la resolución, acciones y decisiones tomadas, prioridad e impactos. El estado actual de los problemas debería ser comunicado a todas los stakeholders relevantes. Asegurar que el seguimiento de problemas conduzca a:
- La resolución de problemas en una manera oportuna para eliminar o minimizar impactos negativos.
- La asignación de recursos para resolver problemas.
- La identificación de la causa raíz de los problemas.
Modelado de procesos
Un proceso describe cómo varias personas o grupos de personas colaboran por un período de tiempo para realizar un trabajo. Los procesos implican una serie de actividades que están vinculadas por un flujo secuencial. Un proceso es repetible y puede tener múltiples rutas para su terminación.
Un proceso es iniciado por un evento en el dominio del negocio, tal como la venta de un producto a un cliente, una solicitud de información por un alto ejecutivo, o fracaso para cerrar una transacción. Los eventos pueden ser acciones ejecutadas por una persona, o reglas que ocasionan que se ejecute una acción, o simplemente el paso de un período de tiempo. El ‘modelo del proceso’ puede implicar actividades manuales, estar completamente automatizado o una combinación de estos. El proceso está completo cuando la meta o el objetivo del proceso son alcanzados.
Un ‘modelo de procesos’ es una representación visual del flujo secuencial y la lógica de control de un conjunto de actividades o acciones relacionadas. El ‘modelado de procesos’ es usado para obtener una representación gráfica de un proceso actual o futuro dentro de una organización. Un modelo puede ser usado a su más alto nivel para obtener un conocimiento general de un proceso o a un nivel inferior como base para la simulación de modo que el proceso pueda ser llevado a cabo tan eficientemente
como sea posible.
Prototipos
Los ‘prototipos’ detallan los requerimientos de la interfaz de usuario y los integra con otros requerimientos, tales como casos de uso, escenarios, datos y reglas de negocio.
Los stakeholders a menudo encuentran que los prototipos son un medio concreto de identificación, descripción y validación de sus necesidades de interfaz.
El generar prototipos puede ser clasificado de dos modos:
Alcance funcional. Un prototipo horizontal modela superficialmente, y posiblemente
desde una visión amplia, la funcionalidad del sistema. Habitualmente no
existe ninguna lógica de negocio detrás de la visualización. Un prototipo vertical
modela una porción profunda y, por lo general angosta de la funcionalidad del sistema
entero.
El uso a través del ciclo de vida del desarrollo del sistema. Un prototipo “desechable”
procura rápidamente descubrir y aclarar los requerimientos de interfaz usando
herramientas simples, a veces sólo papel y lápiz. Como el nombre lo sugiere, tal prototipo
es por lo general desechado cuando el sistema final ha sido desarrollado. El
foco está en la funcionalidad, la que no es fácilmente ‘elicitada’ por otras técnicas,
tiene puntos de vista conflictivos o es difícil de entender. Un prototipo “evolutivo o
funcional” amplía los requerimientos de interfaz iniciales en un sistema totalmente
funcional y requiere de una herramienta o lenguaje especializado para generar prototipos.
Este prototipo produce una aplicación de software en funcionamiento.
Talleres de requerimientos
Los ‘talleres de requerimientos’ son un modo estructurado de capturar requerimientos. Un taller puede ser usado para delimitar el alcance, descubrir, definir, dar prioridades y llegar a la conclusión de requerimientos para el sistema de destino.
Los talleres bien coordinados se consideran uno de los modos más eficaces de entregar rápidamente requerimientos de alta calidad. Pueden promover entendimiento, confianza mutua y comunicaciones fuertes entre los stakeholders y el equipo del proyecto y producir entregables que estructuren y guíen el análisis futuro.
Un ‘taller de requerimientos’ es un evento enfocado altamente productivo, con la asistencia de los stakeholders clave seleccionados cuidadosamente y expertos en la materia durante un período breve e intensivo (habitualmente uno a pocos días).
El taller es facilitado por un miembro del equipo o idealmente, por un moderador neutro con experiencia. Además, de alguien que registre (también conocido como un escribano) que documente los requerimientos ‘elicitados’ así como también cualquier cuestión pendiente. Un Analista de Negocio puede ser el moderador o el que lleve el registro en estos talleres. En situaciones donde el Analista de Negocio es un experto en el tema, puede ser un participante más del taller. Sin embargo, se debe ser cauteloso al abordar esto, ya que puede confundir a otros en cuanto al rol del Analista de Negocio. Además, puede existir la sospecha de que el Analista de Negocio, que también es un participante, pueda influir indebidamente en la documentación de requerimientos con sus propios puntos de vista y prioridades.
Se puede usar un taller para generar ideas para características o productos nuevos, alcanzar el consenso en un tema, o revisar requerimientos. Otros resultados son a menudo requerimientos detallados capturados en modelos.
Análisis de los riesgos
Un riesgo describe un evento o acontecimiento incierto que puede tener un efecto en la capacidad del Analista de Negocio, del equipo del proyecto o de la organización para alcanzar un objetivo. Los riesgos por naturaleza pueden ser positivos o negativos. El ‘análisis de riesgo’ implica entender los niveles de tolerancia al riesgo de la organización, evaluando riesgos e identificando respuestas.
Análisis de causa raíz
El ‘análisis de causa raíz’ es un examen estructurado de los aspectos de una situación para establecer las causas primordiales y los efectos resultantes de un problema. Un elemento crítico del ‘análisis de causa raíz’ es asegurar que el pensamiento y proceso de negocio actuales sean cuestionados. Es decir ¿todavía tienen sentido o proporcionan un buen valor de negocio a la luz de la realidad actual?
Escenarios y casos de uso
Los ‘escenarios y los casos de uso’ son escritos para describir cómo un actor interactúa con una solución para alcanzar una o varias de las metas de ese actor, o responder a un evento.
Mientras los términos de escenario y caso de uso a menudo son usados vagamente, un escenario es generalmente entendido para describir sólo la forma en que un actor puede alcanzar una meta en particular. Un caso de uso describe, en cambio, todos los resultados posibles de un intento de alcanzar una meta en particular que la solución apoyará.
Los escenarios son escritos como una serie de pasos realizados por actores o por la solución que permite a un actor alcanzar una meta. Un caso de uso describe varios escenarios en la forma de flujos primarios y alternos. El flujo primario o básico representa el modo más simple de alcanzar la meta del caso de uso. Las circunstancias especiales y las excepciones que resultan en fracaso de alcanzar la meta del caso de uso son documentadas en flujos alternos.
Modelado del alcance
El ‘modelado del alcance’ es usado para describir el alcance del análisis o el alcance de una solución.
Sirve como una base para definir y delimitar el alcance del Análisis de Negocio y el trabajo del proyecto. El ‘modelado del alcance’ permite la definición de un alcance “completo”, esto es, las fronteras del alcance corresponden a las fronteras naturales de un dominio de negocio. Hay muchos estándares diferentes para el ‘modelado del alcance’. En general, el modelado del alcance dependerá de las técnicas de análisis seleccionadas para explorar adicionalmente dicho alcance.
Diagramas de secuencia
Los ‘diagramas de secuencia’ son usados para modelar la lógica de los escenarios de uso, mostrando la información transmitida entre los objetos del sistema a través de la realización del escenario.
Un ‘diagrama de secuencia’ muestra cómo las clases y los objetos interactúan durante un escenario. Las clases requeridas para ejecutar el escenario son mostradas en el diagrama, así como los mensajes que pasan de uno a otro (generados por los pasos en el caso de uso). El ‘diagrama de secuencia’ muestra cómo los objetos usados en el escenario interactúan, pero no cómo ellos se relacionan el uno con el otro. Los ‘diagramas de secuencia’ son también a menudo usados para mostrar cómo interactúan los componentes de la interfaz de usuario o los componentes de una aplicación de software.
Diagramas de estado
Un ‘diagrama de estado’ especifica una secuencia de estados por los cuales un objeto pasa durante su ciclo de vida, y define qué eventos causan una transición entre esos estados. El comportamiento aceptable del objeto es dependiente de su estado actual. Hay muchos títulos para el ‘diagrama de estado’, incluso ‘diagrama de máquina de estado’, ‘diagrama de transición de estado’, y ‘diagrama de ciclo de vida de la entidad’.
Revisión estructurada
La ‘revisión estructurada’ es una sesión de trabajo donde los participantes invitados examinan y discuten acerca de un conjunto de requerimientos. Se les requiere a los participantes que hagan preguntas, comentarios y sugerencias. Durante la sesión, se pueden también identificar otros asuntos. Todas las preguntas, comentarios, preocupaciones y sugerencias son registrados.
Una ‘revisión estructurada’ puede resultar en requerimientos revisados así como también asuntos que requieren investigación. Una ‘revisión estructurada’ también puede ser referida como una revisión de requerimientos. Una inspección es similar, pero sigue un proceso más formal y usa listas de verificación y otras herramientas.
Encuestas y cuestionarios
Una encuesta administra un conjunto de preguntas escritas para los stakeholders y los expertos en la materia. Alternativamente, se les proporciona a los encuestados una serie de declaraciones y se les solicita su nivel de conformidad o aval. Sus respuestas son analizadas y distribuidas a las partes apropiadas.
Las preguntas en una encuesta son de dos tipos:
- Cerradas: Se le pide al encuestado que seleccione entre las respuestas disponibles. Esto es útil cuando la gama de las respuestas del usuario es suficientemente bien entendida, pero tiene que ser determinada la fuerza de cada categoría de respuesta. Las respuestas a preguntas cerradas son más fáciles de analizar que aquellas conseguidas por preguntas abiertas, porque éstas pueden ser vinculadas a coeficientes numéricos.
- Abiertas: El encuestado es libre de contestar a las preguntas como lo desee. Es útil cuando los temas son conocidos, pero la gama de respuestas del usuario no lo es. Las respuestas a preguntas abiertas pueden proporcionar más detalle y una gama más amplia de respuestas que aquellas conseguidas en las encuestas de tipo cerrado. Sin embargo, las preguntas abiertas son más difíciles de cuantificar y resumir ya que a menudo incluyen lenguaje cualitativo, más que cuantitativo.
Análisis FODA
El ‘análisis FODA’ es una herramienta valiosa para analizar rápidamente varios aspectos del estado actual de los procesos de negocio sometidos a cambio.
El ‘análisis FODA’ es un acrónimo de “Fortalezas, Oportunidades, Debilidades, y Amenazas”. El ‘análisis FODA’ es un marco para la planificación estratégica, ‘análisis de oportunidad’, ‘análisis competitivo’, y desarrollo de negocio y productos.
Historias de usuario
Una ‘historia de usuario’ es una descripción textual de cosas que la solución necesita permitir que los usuarios hagan. Las ‘historias de usuario’ son habitualmente una oración o dos que describen quién usa la historia, la meta que ellos tratan de alcanzar y cualquier información adicional que puede ser crítica para el entendimiento del alcance de la historia.
Evaluación de los proveedores
Cuando las soluciones son en parte proporcionadas por proveedores externos (quienes pueden estar implicados en el diseño, construcción, implementación o mantenimiento de la solución o componentes de la solución), o cuando la solución es asignada por subcontratación externa, pueden haber requerimientos específicos en cuanto al involucramiento de este tercero.
Por ejemplo, puede haber una necesidad de asegurar que el proveedor sea económicamente seguro, capaz de mantener niveles específicos de personal, comprometiendo el personal calificado apropiado para apoyar la solución, y así sucesivamente. Se puede usar el Análisis de los requerimientos no-funcionales para definir los niveles de servicio esperados de un tercero. La ‘evaluación del proveedor’ es realizada para asegurar que el proveedor sea confiable y que los niveles de servicio satisfarán las expectativas de la organización.