Análisis empresarial

Introducción

El ‘análisis empresarial’ es a menudo el punto de partida para el inicio de un nuevo proyecto y este continúa conforme surjan cambios del proyecto y se tenga disponible más información. Es a través de las actividades del ‘análisis empresarial’ que los requerimientos del negocio son identificados y documentados.

El ‘análisis empresarial’ describe las actividades del Análisis de Negocio que se realizan
en las organizaciones para:

  • Analizar la situación de negocio con el fin de entender plenamente los problemas y oportunidades del negocio.
  • Evaluar las capacidades de la empresa a fin de comprender los cambios necesarios para satisfacer las necesidades de negocio y alcanzar las metas estratégicas.
  • Determinar el enfoque más factible para la solución del negocio.
  • Definir el alcance de la solución y desarrollar el caso de negocio para una solución propuesta.
  • Definir y documentar los requerimientos del negocio (incluidas la necesidad de negocio, las capacidades requeridas, el alcance de la solución y el caso de negocio).

Definir la necesidad de negocio

La definición de la necesidad de negocio es con frecuencia el paso más crítico dentro
de cualquier esfuerzo del Análisis de Negocio. La necesidad de negocio define el problema para el cual el Analista de Negocio está tratando de buscar una solución.
La forma en la que la necesidad de negocio es definida determina cuál alternativa de solución será considerada, qué stakeholders serán consultados, y cuáles enfoques de solución serán evaluados.

Un asunto identificado dentro de la organización, tal como la queja de un cliente, una pérdida de ingresos, o una oportunidad nueva de mercado, habitualmente activa la evaluación de una necesidad de negocio. Es común que las organizaciones actúen para resolver el tema sin investigar la necesidad de negocio fundamental de ese problema. El Analista de Negocio debería cuestionar los supuestos y limitaciones que en general están sepultados en la declaración del problema, para asegurar que el problema correcto se esté resolviendo, y que la variedad más amplia posible de soluciones alternativas esté siendo considerada.

Las necesidades nuevas de negocio pueden ser generadas de varias maneras:

  • De arriba hacia abajo – la necesidad de alcanzar una meta estratégica.
  • De abajo hacia arriba – un problema con el estado actual de un proceso, función o sistema.
  • De gerencia media – un gerente necesita información adicional para tomar decisiones fundamentadas, o debe desempeñar funciones adicionales para alcanzarlos objetivos de negocio.
  • De factores externos – derivados de la demanda de los clientes o competencia de mercado. 

Técnicas

Estudio comparativo: Entender qué están haciendo los profesionales y las organizaciones
de la competencia, permitiendo que la organización permanezca en un nivel comparable de servicio o identificar oportunidades para incrementar la eficiencia.
Tormenta de ideas: Genera comprensión y opciones.
Análisis de las reglas de negocio: Identifica cambios en las políticas que guían a la organización para el logro de sus metas y objetivos.
Grupos de opinión: Para identificar y discutir problemas.
Descomposición funcional: Convertir metas de negocio en objetivos alcanzables y medibles.
Análisis de causa raíz: Determina la fuente fundamental de un problema.

Análisis de los requerimientos

Resumen

El área de conocimiento Análisis de los requerimientos describe las tareas y técnicas
usadas por un Analista de Negocio para analizar los requerimientos declarados por los stakeholders con el fin de definir las capacidades requeridas por una solución potencial,
que cubra las necesidades de los stakeholders. El ‘análisis de requerimientos’ comprende la definición de los requerimientos de los stakeholders, los cuales describen lo que una solución debe ser capaz de hacer para satisfacer las necesidades de uno o más grupos de stakeholders, y los requerimientos de la solución, los que describen el comportamiento de los componentes de la solución con suficiente detalle para permitir que sean construidos. Las tareas en esta área de conocimiento se aplican a ambos: requerimientos de los stakeholders y requerimientos de la solución.


Además, el ‘análisis de los requerimientos’ puede ser realizado para desarrollar modelos
del estado actual de una organización. Estos modelos de dominio son útiles para validar el alcance de la solución con los stakeholders técnicos y de negocio, para analizar el estado actual de una organización, para identificar oportunidades de mejora, o para ayudar a los stakeholders en el entendimiento de ese estado actual.

Priorizar los requerimientos

La priorización de los requerimientos asegura que los esfuerzos del análisis e implementación se centren en los requerimientos más críticos.

Es un proceso de decisión usado para determinar la importancia relativa de los requerimientos. La importancia de los requerimientos puede estar basada en su valor relativo, riesgo, dificultad de implementación, o en otros criterios.
Estas prioridades son usadas para determinar cuáles requerimientos deberían ser destinados
a un análisis posterior y determinar cuáles deberían ser implementados primero.

Bases para la priorización

Los requerimientos pueden ser priorizados mediante una serie de criterios diferentes, incluyendo:
Valor de negocio: Este enfoque prioriza requerimientos basados en el análisis de costo-beneficio de su valor relativo para la organización. Los requerimientos más valiosos serán objeto de desarrollo en primer lugar. Este enfoque es común en la mejora de una solución existente que ya satisface los requerimientos mínimos especificados, o cuando la entrega de la solución es en incrementos.
Riesgos de negocio o riesgos técnicos: Este enfoque selecciona los requerimientos que presentan el riesgo más alto de falla del proyecto. Estos requerimientos son investigados
e implementados primero para asegurar que si en el caso que el proyecto falle, lo haga con el menor gasto posible.
Dificultad de implementación: Este enfoque selecciona los requerimientos que son más fáciles de implementar. Este enfoque es a menudo seleccionado durante el piloto de un proceso de desarrollo nuevo, o de herramientas nuevas, o cuando se implementa en forma gradual una solución empaquetada, ya que permite al equipo del proyecto ganar familiaridad con esas cosas mientras trabajan sobre los requerimientos de bajo riesgo.
Probabilidad de éxito: Este enfoque se centra en los requerimientos que probablemente produzcan ciertos resultados relativamente exitosos rápidamente. Es común
cuando un proyecto es controvertido, y los primeros signos de progreso son necesarios
para obtener apoyo para la iniciativa.
Cumplimiento con reglamentaciones o políticas: Este enfoque prioriza los requerimientos que deben ser implementados con el fin de cumplir con las demandas regulatorias o políticas impuestas sobre la organización, las cuales pueden tener prioridad sobre los intereses de otros stakeholders.
Relación con otros requerimientos: Un requerimiento puede que no sea de gran valor en sí mismo, pero puede apoyar otras necesidades de alta prioridad y como tal, puede ser un candidato para su pronta implementación.
Acuerdos con los stakeholders: Este enfoque requiere que los stakeholders alcancen un consenso sobre cuáles requerimientos son más útiles o de más valor. Esto a menudo es usado en combinación con uno o más de los enfoques descritos anteriormente.
Urgencia: Este enfoque prioriza los requerimientos de acuerdo a las limitaciones
de tiempo.

Técnicas

Técnicas generales

Análisis de decisiones: El ‘análisis de decisiones’ puede ser usado para identificar requerimientos de alto valor.
Análisis de los riesgos: Los requerimientos que son considerados riesgosos pueden necesitar ser investigados o implementados primero, de modo que si los riesgos causan que el proyecto fracase, la organización habrá invertido lo menos posible hasta ese punto.

Técnica MoSCoW (Must, Should, Could, and Won’t, en inglés)

La técnica MoSCoW divide los requerimientos en 4 categorías: Obligatorio, Requerido, Potencialmente requerido, No necesario. Las descripciones de las categorías son las siguientes:
Obligatorio: Describe un requerimiento que debe ser satisfecho en la solución final para que la solución sea considerada como exitosa.
Requerido: Representa una alta prioridad que debería incluirse si es posible dentro de la solución. Esto es a menudo un requerimiento crítico, pero que puede ser satisfecho
de otra manera si es estrictamente necesario.
Potencialmente requerido: Describe un requerimiento que es considerado como deseable pero no necesario. Será incluido si el tiempo y los recursos lo permiten.
No necesario: Representa un requerimiento que los stakeholders han acordado que no será implementado en una versión dada, pero puede ser considerado para el futuro.

Límite de tiempo / Presupuesto

El ‘límite de tiempo’ o el ‘presupuesto’ priorizan los requerimientos para la investigación e implementación basadas en la asignación de recursos fijos. Esto es usado cuando se ha determinado el enfoque de la solución. El ‘límite de tiempo’ prioriza requerimientos basados en la cantidad de trabajo que el equipo de trabajo es capaz de entregar en un periodo de tiempo dado. En contraste, el ‘presupuesto’ es usado cuando al equipo de trabajo se le ha asignado un monto fijo de dinero. Este enfoque es a menudo más usado cuando se tiene que cumplir con una fecha límite inamovible o para soluciones que son mejoradas regular o frecuentemente. Hay una serie de enfoques que pueden adoptarse para determinar cuáles requerimientos pueden ser incluidos en una iteración con límite de tiempo:

Todos incluidos: Iniciar todos los requerimientos elegibles con duración o costo asignados. Eliminar los requerimientos con el fin de cumplir con las fechas límites o el presupuesto.

Todos excluidos: Iniciar agregando el(los) requerimiento(s) con duración o costo asignados al calendario o al presupuesto. Detenerse cuando se alcanza la fecha límite o el presupuesto.

Selectivo: Iniciar identificando los requerimientos de alta prioridad incluyéndolos al calendario o presupuesto. Incluir o eliminar requerimientos para cumplir con las fechas límites o el presupuesto.

Votación

Los métodos de votación asignan una cantidad fija de recursos (votos, dinero de juego, o fichas) a cada participante para que ellos los distribuyan entre las características o requerimientos propuestos. Los requerimientos que reciben más recursos son
los que serán investigados y desarrollados primero.

Evaluación y validación de la solución

Resumen

El área de conocimiento Evaluación y validación de la solución describe las tareas que se realizan para asegurar que la solución satisface la necesidad de negocio y para facilitar su implementación exitosa. Estas actividades se pueden realizar para evaluar y validar los procesos de negocio, las estructuras de la organización, los acuerdos de subcontratación externa, aplicaciones de software, y cualquier otro componente de la solución.


El Análisis de Negocio juega un rol vital para asegurar que el proceso de revisión, selección y diseño de la solución esté hecho de forma tal que maximice el valor entregado a los stakeholders. El Analista de Negocio conoce el ambiente del negocio y puede evaluar cómo cada solución propuesta puede afectar ese ambiente. El Analista de Negocio es el responsable de asegurar que los stakeholders entiendan completamente los requerimientos de la solución y que las decisiones de su implementación estén alineadas con los requerimientos relevantes.

Evaluar la solución propuesta

La evaluación de la solución puede ser realizada sobre una sola solución o para comparar múltiples soluciones propuestas.

Cuando se evalúa una sola solución, el Analista de Negocio determina si la solución entrega suficiente valor al negocio para justificar su implementación. Este es el caso más común cuando ha sido creada una solución a la medida, para satisfacer una necesidad de negocio específica.
Cuando se evalúan múltiples soluciones alternativas, el Analista de Negocio tiene la meta adicional de intentar determinar cuál de las soluciones entrega el mayor valor de negocio. Esto requiere el entender las ventajas y desventajas de cada alternativa
propuesta.

Técnicas

Definición de los criterios de aceptación y evaluación: Los requerimientos deberían ser expresados en la forma de criterios de aceptación para hacerlos más útiles cuando se evalúan las soluciones propuestas.
Análisis de decisiones: Los métodos del ‘análisis de decisiones’ apoyan directamente la evaluación y posicionamiento de las opciones de solución.
Evaluación de los proveedores: Cuando una opción está siendo proporcionada total o parcialmente por un tercero, la evaluación de la solución debería estar acompañada con una evaluación del proveedor para asegurar que todas las partes
estarán disponibles para desarrollar y mantener una relación de trabajo saludable.

Competencias fundamentales

Introducción

El área de conocimiento Competencias fundamentales provee una descripción de los comportamientos, características, conocimientos y cualidades personales que apoyan la práctica del Análisis de Negocio.
Las competencias fundamentales no son por supuesto únicas para la profesión del Análisis de Negocio. Se describen aquí para asegurar que el lector esté al tanto de la gama de habilidades requeridas, y proporcionarle las bases para investigar más acerca
de las habilidades y conocimientos que le serán necesarios para ser un Analista de Negocio consumado y flexible.

Pensamiento creativo

Los Analistas de Negocio deben ser eficientes en generar ideas nuevas para enfoques de solución de problemas y en generar soluciones alternativas.

El pensamiento creativo involucra generar ideas y conceptos nuevos, así como también encontrar asociaciones o aplicaciones nuevas de ideas y conceptos existentes.
Estos conceptos deberían ser innovadores y apropiados para la solución.
Además de identificar y proponer alternativas, los Analistas de Negocio pueden ser eficaces en promover el pensamiento creativo en otros haciendo preguntas y cuestionando supuestos.

Las medidas de éxito de un pensamiento creativo incluyen:

  • Generación exitosa y consideración productiva de ideas nuevas.
  • Aplicación de ideas nuevas para resolver problemas existentes.
  • Disposición de los stakeholders para aceptar enfoques nuevos.

Toma de decisiones

El Analista de Negocio debe ser eficaz en entender los criterios involucrados en tomar una decisión, generar decisiones y en ayudar a otros en la toma de mejores decisiones.

Se requiere una decisión siempre que sea necesario seleccionar una alternativa o enfoque entre dos o más opciones. El ‘análisis de decisiones’ incluye reunir información relevante para la decisión, desglosando la información relevante a la decisión, haciendo comparaciones y adoptando soluciones de compromiso entre opciones similares y diferentes, e identificando la opción más deseable. El Analista de Negocio debe estar en conocimiento de los problemas que impiden una toma de decisión exitosa, incluyendo la tendencia a aceptar el primer enunciado del problema, la falacia de costos irrecuperables y la tendencia a darle mayor peso a las evidencias que confirman las impresiones existentes.

Las medidas que aseguran el éxito de la toma de decisiones incluyen:

  • Confianza de los participantes en el proceso del ‘análisis de decisiones’ de que la decisión es la correcta.
  • Información o alternativas nuevas que causen que la decisión sea revisada nuevamente sean genuinamente nuevas y no simplemente pasarlas por alto.
  • Las decisiones son eficaces para abordar el problema fundamental.
  • El impacto de la incertidumbre y de la nueva información a la hora de tomar decisiones puede ser evaluado eficazmente.

Aprendizaje

El Analista de Negocio debe ser eficiente en el aprendizaje acerca de dominios de negocio y de cómo funcionan, y luego traducir ese aprendizaje en un entendimiento de cómo beneficiar a la organización.

Aprender es el proceso de obtener conocimientos o habilidades. El aprender acerca de un dominio pasa por un conjunto de etapas, desde la adquisición inicial y el aprendizaje de hechos sin procesar, a través de la comprensión de su significado hasta aplicar el conocimiento en el trabajo día a día, y finalmente el análisis, síntesis y evaluación. Un Analista de Negocio debe ser capaz de describir su nivel de comprensión del dominio del negocio y ser capaz de aplicar ese nivel de comprensión para determinar qué actividades del análisis se necesitan poner en práctica en una situación dada. Una vez que el aprendizaje acerca del dominio ha alcanzado el punto donde el análisis esté completo, el Analista de Negocio debe ser capaz de sintetizar la información para identificar oportunidades de crear soluciones nuevas, y evaluar esas soluciones para asegurar que son eficaces.

Las medidas de un aprendizaje exitoso incluyen:

  • Acuerdo por los stakeholders que los modelos del análisis describen el dominio eficaz y completamente.
  • Identificación de problemas o asuntos relacionados de múltiples áreas en el dominio.
  • Asimilación rápida de información nueva o dominios nuevos.

Solución de problemas

El Analista de Negocio debe ser eficaz para definir y solucionar problemas con el fin de asegurar que el problema real, fundamental sea entendido, y que las soluciones aborden verdaderamente ese problema.

La definición de un problema implica asegurar que la naturaleza del problema sea claramente entendida por todas las partes y que los asuntos fundamentales estén a la vista. Los conflictos entre los objetivos y metas de los stakeholders necesitan ser articulados y abordados. Los supuestos fundamentales deben ser identificados y puestos a prueba. Los objetivos que serán satisfechos una vez que el problema esté resuelto, necesitan ser claramente especificados y se deberían desarrollar alternativas de solución. Las alternativas son medidas en relación con los objetivos para determinar
cuál solución posible es la mejor e identificar las decisiones de compromiso que puedan existir entre las soluciones. El Analista de Negocio debería tener conocimiento de una serie de técnicas de solución de problemas que pueden aplicarse.

Las medidas de un proceso exitoso de solución de problemas incluyen:

  • Confianza de los participantes en el proceso de solución de problemas y que la solución seleccionada sea la correcta.
  • Opciones nuevas de solución pueden ser evaluadas eficazmente usando el marco de solución del problema.
  • Las soluciones seleccionadas satisfacen los objetivos definidos y solucionan el problema fundamental.
  • El proceso de solución de problemas evita tomar decisiones de acuerdo a nociones preconcebidas, políticas de la organización u otro tipo de problemas que pueden llevar a seleccionar una solución por debajo del óptimo.

Pensamiento sistémico

El Analista de Negocio debe ser eficiente en comprender cómo las personas, procesos y tecnología dentro de la organización interactúan en relaciones y patrones para crear un sistema como un todo.

La ‘teoría de sistemas’ y el ‘pensamiento sistémico’ sugieren que el sistema como un todo tendrá propiedades, comportamientos y características que emergen de la interacción de los componentes del sistema, los cuales no son predecibles si se parte de una comprensión de componentes aislados. En el contexto de la ‘teoría de sistemas’ el término “sistema” es más amplio que el de un sistema de tecnologías de la información, también incluye a las personas involucradas, la interacción entre ellas, las fuerzas externas que afectan su comportamiento y todos los otros factores y elementos relevantes.

Las medidas de un ‘pensamiento sistémico’ eficaz incluyen:

  • Entender cómo un cambio a un componente afecta al sistema como un todo.
  • Identificar ciclos de retroalimentación de refuerzo y compensación.
  • Entender cómo los sistemas se adaptan a presiones y cambios externos.

Técnicas utilizadas

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.