Hábitos de un efectivo Analista de Negocio

De acuerdo con Karl Wiegers, Principal Consultant en Process Impact,( www.ProcessImpact.com), los Administradores de Software muchas veces asumen que un talentoso programador es también competente entrevistando clientes y escribiendo requisitos sin ninguna formación previa, recursos o entrenamiento, lo cual resulta un supuesto mal fundamentado y que requiere de tener su propio conjunto de habilidades.
Sostiene que el rol del Analista de Negocio es crítico para un proyecto de software y muchas organizaciones esperan que los desarrolladores o los directores de proyectos (PM’s) gestionen esta función vital. El analista de negocio proporciona capacidades especializadas que pueden hacer la diferencia entre un proyecto exitoso y aquel que avanza con dificultad y mucho esfuerzo.

En este artículo de dos partes, Karl describe varias características y prácticas para analistas de negocio exitosos.

CERRAR LA BRECHA DE LA COMUNICACIÓN

El analista de negocio es un interlocutor que cierra la brecha entre las vagas nociones del cliente y unas especificaciones claras. El analista de negocio debe de entender las necesidades reales del usuario y entonces definir el conjunto de requisitos funcionales y objetivos de calidad que permita a los desarrolladores construir y a los ingenieros de pruebas verificar el sistema. Para ser un efectivo analista de negocio, se debe de ser competente en todas las formas de comunicación, incluyendo el saber escuchar, hablar y escribir. En la medida que el analista de negocio interactúa con los patrocinadores ejecutivos del proyecto, mercadotecnia, y usuarios, entiende los objetivos para el sistema propuesto y las preocupaciones de los usuarios con relación al negocio y la aplicación. Utilizar un vocabulario adecuado al dominio de la aplicación en lugar de forzar a los clientes a entender la jerga de la computación es elemental.

Tómese el tiempo para aprender acerca de sus clientes y usuarios y entienda como prefieren ellos establecer esa comunicación. Vigile los supuestos que se esconden debajo de la expresión de necesidades de los usuarios y sus propios pensamientos. Evite imponer filtros personales de lo que escucha de los usuarios. Mantenga uno de los axiomas de Karl para desarrollo de software: El cliente no siempre tiene la razón, pero siempre tiene un punto importante. Ud. Tiene que entender y respetar estos puntos de tal forma que puedan ser apropiadamente considerados en el producto.

Por otro lado también recomienda entender las expectativas implícitas del usuario con relación a las características del sistema, tales como rendimiento, usabilidad, eficiencia, y confiabilidad. Como analista de negocio, debe de entender la intención detrás de cada una de esas expectativas de tal forma que se pueda traducir de algo muy vago y subjetivo a algo concreto y específico. Una técnica es preguntar al usuario que constituye un rendimiento, usabilidad o confiabilidad inaceptables.

Otro aspecto importante es la escritura de los requisitos que expresen claramente un entendimiento compartido la cual es responsabilidad del analista de negocio. El escribir documentos de especificación de requisitos que los usuarios puedan entender y verificar, mientras que comunique de una manera precisa y sin ambigüedades requisitos funcionales y no funcionales a los desarrolladores es una tarea difícil y complicada.

Los usuarios con frecuencia proponen sólo fragmentos de funcionalidad y comunican solo parte de lo que tienen en mente. Karl propone que es preferible enfocarse en las tareas que el usuario necesita lograr con el sistema: casos de uso o historias de usuario (desarrollo ágil). Este enfoque ayuda a entender porque la funcionalidad o características descritas por el cliente son importantes. El entendimiento de sus objetivos, lleva a los requisitos funcionales necesarios, los cuales llevan al diseño detallado de la interface.

Debido a que los casos de uso describen la vista del usuario respecto del sistema, los usuarios deben de entenderlos. Sin embargo los casos de uso solos raramente comunican suficiente información a los desarrolladores. Una tarea importante del analista de negocio es inferir de cada caso de uso los requisitos funcionales específicos que, cuando se implementen, permitan al usuario realizar las tareas descritas en el caso de uso. Esto significa que debe de estar en posibilidad de comunicar efectivamente en ambas direcciones: con los usuarios (la vista de tareas) y con los desarrolladores (la vista técnica). Para estar seguro de lo que ha Ud. entendido, haga que los usuarios, desarrolladores e ingenieros de pruebas revisen sus documentos.

EJECUTE DE FORMA SEGURA, NO CORRA RIESGOS

Inicie su investigación de los requisitos del nuevo sistema a través de la última visión de lo que el producto o aplicación será o tendrá que hacer. Hable con el patrocinador, gerente de mercadotecnia o de producto anticipadamente para definir los objetivos de negocio del proyecto. Esta información le ayudará a contestar esta pregunta crítica cada vez que alguien sugiere una nueva característica del producto: “Esta esta característica incluida en el alcance?”.

Los equipos rara vez implementan la última solución en un solo paso. En su lugar, definen el alcance de una primera versión o iteración como un subconjunto de un producto final. Describa una ruta de evolución a partir de la primera versión hasta alcanzar la última visión a través de una serie de versiones o iteraciones, También documente cualquier limitante conocida o funcionalidad que no intente construir pero que algún usuario espere encontrar en la aplicación. La gestión de las expectativas es una estrategia importante.

REALICE PREGUNTAS RELEVANTES

Cuando trabaje como analista de negocio, necesita facilitar activamente la discusión con los usuarios para obtener información que de otra forma podría no ser especificada. Realice preguntas para identificar posibles formas alternativas que el usuario podría querer para realizar alguna tarea y descubrir tareas relacionadas que los usuarios no mencionaron inicialmente.

Los usuarios normalmente se enfocan en el comportamiento normal esperado del sistema, Sin embargo, los desarrolladores, escriben mucho código para el manejo de excepciones, de tal forma que tiene que buscar posibles condiciones de error que puedan surgir y decidir como debe de responder el sistema. Si no describe Ud. las excepciones durante la elicitación de los requisitos, pasa una de dos cosas: o los desarrolladores harán su mejor elección para manejarlos o el sistema simplemente fallará cuando el usuario se encuentre con esa condición de error. Seguro que un error del sistema no es parte del plan.

Un analista de negocio creativo debe sugerir ideas y alternativas durante la elicitación. Cuando los usuarios no pueden expresar lo que necesitan, obsérvelos trabajando y sugiera alternativas para automatizar parte del trabajo. Los analistas de negocio frecuentemente piensan “fuera de la caja” que limita la creatividad de las personas que están demasiado cerca del problema que se desea resolver. Sea cuidadoso para evitar exceder las expectativas del usuario adicionando funcionalidad extra que solo se vea agradable o de alguna forma sólo es deseable.

Les agradezco su atención y espero que este artículo haya sido de su interés. Nuevamente, les invito a colaborar con este blog a través de sus comentarios y buscar temas de tu interés que ayuden a contribuir al crecimiento de la práctica.

Tomado del artículo original en http://www.batimes.com/blog/karl-wiegers.html. Espere el segundo artículo que comentará sobre otros hábitos que ayudan al analista de negocio hábil a contribuir a construir estupendos sistemas.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.5 Tareas

En esta ocasión les voy a compartir la sección 1.5 Tareas, la cual describe la forma en que el BABOK estructura cada una de las tareas contenidas en cada una de las áreas de conocimiento.

Lo anterior es importante tomarlo en cuenta al momento de leer el BABOK para lograr una mejor comprensión del mismo. Esta estructura se repite a lo largo del libro para cada una de las áreas de conocimiento.

Como siempre los invito a enviarme sus comentarios y observaciones.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.4 Áreas de Conocimiento

Ahora vamos a ver la sección 1.4 que explica de modo general cada una de las áreas de conocimiento que componen la práctica de Análisis de Negocio en el BABOK®:

Lo anterior es sólo una breve descripción de cada una de las áreas de conocimiento y su interrelación con el resto de áreas de conocimiento. Algo importante que hay que considerar, es que el BABOK® no prescribe un orden para la ejecución de cada una de las áreas de conocimiento y manifiesta en todo momento que las actividades en cada una de ellas se pueden realizar en distintos momentos a lo largo del ciclo de vida de la solución.

Espero que esta nueva sección del BABOK® le sea de utilidad y como siempre los invito a enviarme sus comentarios y observaciones.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.3.3 Requerimientos

En esta ocasión vamos a ver la sección 1.3.3 Requerimientos dentro de 1.3 Conceptos Clave, la cual explica el concepto y clasificación manejado por el BABOK para este término.

Como podrán ver, este concepto de requerimientos está piramidado partiendo de un enfoque de negocio hasta llegar a un enfoque de solución en donde cada uno de ellos tiene un objetivo bien definido. Lo anterior se puede representar mejor con el siguiente modelo:

Bien amigos, con esto damos por terminada esta sección, recuerden que todos sus comentarios son bienvenidos.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – Conceptos Clave

Continuando con el estudio de las secciones del BABOK, esta vez veremos la sección de Conceptos Clave, estos conceptos se manejan a lo largo del BABOK y es importante homologar su significado en estos términos con el fin de tener el mismo entendimiento respecto a ellos.
En esta ocasión veremos el concepto de Dominios y el de Soluciones y la siguiente semana explicaremos lo correspondiente a los Requerimientos y los diferentes tipos de Requerimientos (o Requisitos como se conocen en algunos otros lugares de habla hispana).

La definición de Dominio en el BABOK dice lo siguiente:

En este sentido, un Dominio es el área donde vamos a trabajar y realizar el análisis de negocio. Puede ser un área, departamento o toda la organización, define las fronteras de esta área y establece las interrelaciones con stakeholders que están dentro y fuera de esas fronteras.

Con relación al concepto de Soluciones, el BABOK establece:

Los cambios se derivan generalmente de una necesidad de negocio o problema de negocio, estos para que causen efecto en la organización necesitan ser aplicados al estado actual de la organización lo cual generará un nuevo estado de la organización que responde a las necesidades del negocio.

Con relación al alcance del dominio éste normalmente comprende al alcance de la solución y éste a su vez está compuesto de los diferentes componentes de solución que afectarán al estado actual de la organización con el fin de habilitarlo con la nueva necesidad de negocio.

Si se dan cuenta, una de las diferencias importantes del enfoque del análisis de negocio, es su alcance respecto de las soluciones, ya que su visión abarca cualquier capacidad que requiera una organización para satisfacer una necesidad de negocio, las cuales pueden ser desde aplicaciones de software, servicios web, procesos de negocios, reglas de negocios hasta cambios en la estructura organizacional o procesos de outsourcing.

Pues bien amigos con esto damos por terminado el comentario de esta semana y como siempre, quedo en espera de sus comentarios.

Nuevos retos para el Analista de Negocio

De acuerdo a Gartner, cuatro fuerzas están dando forma al futuro de IT teniendo a la “Consumerization” –tecnología orientada al consumidor- de fondo.

1.- La Nube. La cual ofrece nuevas opciones y estilos de entrega industrializados en una cadena de valor en donde TI es sólo una parte de la entrega
2.- Computación Social. Permite la colaboración entre los usuarios y esta generando cambios los patrones de conducta de los usuarios en las comunidades personales, laborales y profesionales en las cuales se desempeñan
3.- Mobilidad. Ofrece nuevos accesos hacia a aplicaciones y datos y al mismo tiempo proporciona a los usuarios una amplia variedad de dispositivos a elegir
4.- “Big Data”. Inició para alterar por siempre la relación de la tecnología con el consumo de información. En la medida que los datos llegan desde múltiples fuentes y en formas tanto estructuradas como no estructuradas estos deben de ser analizados utilizando nuevas metodologías

Los resultados son ya por todos conocidos:

El reto para los analistas de negocio es primero comprender en que consiste cada una de estas fuerzas, cómo afectará a nuestra organización, cuales nuevas soluciones en torno a estas tendencias puedo ofrecer a mis stakeholders, que implicaciones hacia adentro de la organización puede ocasionar (procesos, sistemas, estructura organizacional, etc.)
Ud. estimado lector ¿que opina?, ¿ha considerado estas nuevas tendencias?, ¿cree que tengan algún impacto en su organización?, ¿afectará a la interacción del negocio con su entorno?
Como siempre lo invito a que envíe sus comentarios.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – ¿Qué es el Análisis de Negocio?

Estimados amigos, continuando con las secciones del BABOK ya traducidas, esta semana les comparto la sección ¿Qué es el Análisis de Negocios? En este capítulo se define el Análisis de Negocios: Que es, Qué implica, Para que se utiliza, Cuáles son las funciones del Analista de Negocio y Cuál es la definición del Analista de Negocio.

Textualmente podemos leer lo siguiente:

Interpretando esta definición de Análisis de Negocio hay que comprender que el análisis de negocio requiere entender ampliamente a la organización. Esto es, requiere entender cual es la razón de ser del negocio (metas y objetivos), cuales son las diferentes áreas de que está compuesta la organización, los principales procesos que se ejecutan, las reglas de negocio que rigen esos procesos, los sistemas (aplicativos, de seguridad, etc.) que apoyan esos procesos, con el fin de tener la visión más amplia posible que permita recomendar la mejor solución viable a una iniciativa de negocio.

Por años, esta función ha sido realizada por diferentes personas dentro de la organización los cuales tenían diferentes roles, algunas veces eran analistas de sistemas que demostraban habilidades para entender del negocio y a veces eran analistas de producto o personal operativo que tenia habilidades para entender de procesos y sistemas. Al final, siempre ha habido algún rol que ha servido de puente entre el negocio y las áreas de ejecución (sistemas, procesos y procedimientos, operaciones, producción). La diferencia ahora con la aparición del Análisis de Negocio como una profesión, es que el rol está definido, y lo más importante es que ahora con esta práctica también está definida una forma estándar de trabajo apoyada con una serie de técnicas y tareas que permiten realizar esta función de una manera más eficiente y que en el futuro, en la medida que esta práctica se extienda, los diferentes analistas de negocio de diferentes organizaciones y de diferentes países podrán tener un marco de referencia estándar que norme su función.

Como siempre, quedo en espera de su participación y sus importantes comentarios. Saludos.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – ¿Qué es la Guía de Los Fundamentos del Conocimiento del Análisis de Negocio?

Estimados amigos, esta semana iniciaremos con el capítulo 1 del BABOK. Este capítulo está dedicado a la Introducción la cual iremos viendo por partes a fin de poder discutir su contenido y en su caso aclarar los puntos que crean convenientes.
Este capítulo se compone de lo siguiente:

Así que iniciaremos primero por entender el primero de ellos dedicado a que es esta Guía y cuál es su propósito. Textualmente podemos leer lo siguiente:

De este texto lo que es importante resaltar, es que el BABOK es esencialmente una Guía para aplicar de manera estándar esta práctica y describe que tareas y habilidades son requeridas en cada área de conocimiento con el fin de ser efectivo en la ejecución de la misma.

Si hablamos de que es un estándar para la práctica del análisis de Negocio, se comprenderá que uno de sus propósitos es que cada uno de los Analistas de Negocio en el mundo trabajen de manera similar y que ejecuten esta función aplicando los mismos conceptos, actividades y tareas sugeridos y que tengan las mismas habilidades, conocimiento y competencias aquí definidos.

Considero que uno de los valores importantes de este documento, entre otros, es que establece el marco de referencia necesario para que tanto los profesionales que las practican, así como las organizaciones que utilizan a esos profesionales, tengan claro qué deben de esperar de un Analista de Negocio calificado y asegurar que se tienen las habilidades necesarias para para ejecutar con eficiencia la función.

Como siempre, quedo en espera de su participación y sus importantes comentarios.

Entendiendo el BABOK® en Español

A partir de hoy, estaré publicando algunas secciones del BABOK® en idioma Español (o Castellano) con el fin de compartir este conocimiento con aquellos colegas que se les dificulta leer la versión del BABOK® en Inglés.
La idea es que generemos un grupo de estudio virtual del BABOK®, comentando todo en nuestro idioma.

Para iniciar, voy a compartirles el Índice y la parte del Prefacio e iré publicando algunas otras secciones a lo largo de las siguientes semanas para discutirlas.

Agradeceré sus comentarios y por favor envíenme las dudas que tengan para comentarlo en el blog. También si tienen interés en abordar algún tema particular del BABOK®, déjenme saber.

Para iniciar, les comparto lo que es el Índice o Tabla de Contenido. Aquí Uds. encontraran las diferentes secciones de que se compone el BABOK® que básicamente se compone de 9 Capítulos y 5 Apéndices.

Tabla de contenido

Prefacio
Capítulo 1: Introducción
Capítulo 2: Planeación y Monitoreo del Análisis de Negocio
Capítulo 3: Elicitación
Capítulo 4: Administración y Comunicación de Requerimientos
Capítulo 5: Análisis Empresarial
Capítulo 6: Análisis de Requerimientos
Capítulo 7: Evaluación y Validación de la Solución
Capítulo 8: Competencias Fundamentales
Capítulo 9: Técnicas
Apéndice A Glosario
Apéndice B: Bibliografía
Apéndice C: Colaboradores
Apéndice D: Resumen de cambio de la versión 1.6
Apéndice E: Índice

La siguiente sección es el Prefacio, aquí lo que podrán encontrar es un poco de historia del IIBA, sus objetivos, como fue fundado el comité BABOK® y cuándo y el número de versiones que ha habido del mismo y los objetivos de las diferentes revisiones.

Prefacio

El IIBA® (International Institute of Business Analysis) fue fundado en Toronto, Canadá en octubre de 2003 para apoyar a la comunidad de analistas de negocio a través de:

• Crear y desarrollar conciencia y reconocimiento del valor y contribución del Analista de Negocio.
• Definir los Fundamentos del Conocimiento del Análisis de Negocio – Business Analysis Body of Knowledge® (BABOK®).
• Proporcionar un foro para compartir el conocimiento y contribuir a la profesión de Análisis de Negocio.
• Reconocimiento público y certificación de profesionales calificados a través de un programa de certificación reconocido.

El comité del BABOK® fue formado en octubre de 2004 para definir y preparar una versión del estándar global para la práctica del Análisis de Negocio. En enero de 2005, el IIBA® liberó la versión 1.0 de la Guía para los Fundamentos del Conocimiento del Análisis de Negocio – Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) para retroalimentación y comentarios. Esa versión incluía un esbozo del contenido propuesto para algunas definiciones claves. La versión 1.4 fue liberada en octubre 2005 con un borrador de algunas de las áreas de conocimiento. La versión 1.6 la cual incluía información detallada acerca de la mayoría de las áreas de conocimiento fue publicada en borrador en junio de 2006 y actualizada para incorporar omisiones en octubre de 2008.

Esta publicación sustituye a la Guía para los Fundamentos del Conocimiento del Análisis de Negocio – Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Versión 1.6. Tras la publicación de la versión 1.6, el IIBA® buscó la participación de expertos reconocidos en el Análisis de Negocio y temas afines y solicitó su retroalimentación acerca del contenido de dicha edición. Sus comentarios fueron utilizados para planear el alcance de esta revisión. Los voluntarios del IIBA® entonces trabajaron para definir la estructura para la versión 2.0 y desarrollaron el texto, el cual se puso a disposición de la comunidad de analistas de negocio para revisión en 2008. Durante ese período de exposición, el IIBA® también solicitó la retroalimentación de expertos de la industria y profesionales del Análisis de Negocio a través de un proceso formal de revisión. El IIBA® recibió miles de comentarios durante este proceso, y este documento fue revisado para incorporar tantos de esos comentarios como fuera posible.

La Guía BABOK® contiene una descripción de prácticas generalmente aceptadas en el campo del Análisis de Negocio. El contenido incluido en esta versión ha sido verificado a través de revisiones realizadas por profesionales, encuestas de la comunidad de analistas de negocio y consulta con expertos reconocidos en este campo. Los datos proporcionados al IIBA® demostraron que las tareas y técnicas descritas en esta publicación están en uso por la mayoría de los profesionales del Análisis de Negocio. Como resultado, tenemos confianza en que las tareas y técnicas descritas en la Guía BABOK® podrán ser aplicadas en la mayoría de los contextos donde el Análisis de Negocio es, la mayor parte del tiempo, utilizado.

La Guía BABOK® no debe ser interpretada como un mandato para que las prácticas descritas en ella sean seguidas bajo cualquier circunstancia. Cada conjunto de prácticas debe ser adecuado a las condiciones específicas, bajo las cuales el Análisis de Negocio es realizado. Adicionalmente, las prácticas que no fueron aceptadas por la comunidad de Análisis de Negocio al momento de publicar esta Guía pueden ser igualmente efectivas o más efectivas que las prácticas descritas en la Guía BABOK®. En la medida que estas prácticas vayan siendo aceptadas y en la medida que los datos sean recabados para verificar su efectividad, éstas serán incorporadas en futuras ediciones de esta publicación. El IIBA® alienta a todos los profesionales del Análisis de Negocio a ser abiertos a nuevos enfoques y nuevas ideas y desea alentar la innovación en la práctica del Análisis de Negocio.

El objetivo de esta revisión fue:

• Complementar la descripción de todas las áreas de conocimiento.
• Simplificar la estructura para hacerla más fácil de entender y aplicar.
• Mejorar la consistencia y calidad de textos e ilustraciones.
• Integrar las áreas de conocimiento y eliminar el traslape de las diferentes áreas
• Mejorar la consistencia con otros estándares generalmente aceptados relacionado a la práctica del Análisis de Negocio.
• Extender la cobertura de la Guía BABOK® para describir al Análisis de Negocio en contextos más allá de los enfoques tradicionales para el desarrollo de aplicaciones de software a la medida, incluido pero no limitado a metodologías ágiles, Administración de Procesos de Negocios, y consultoría e implementación de aplicaciones comerciales off-the-shelf (COTS – por sus siglas en inglés – Commercial Off The Shelf) o aplicaciones listas para su uso.
• Aclarar la relación entre el Análisis de Negocio y otras disciplinas, particularmente la administración de proyectos, ingeniería de pruebas, usabilidad y arquitectura de la información.
• Enfocarse en la práctica del análisis de negocio en el contexto de la iniciativa individual, manteniendo por separado material de índole estratégico o a nivel empresarial para su inclusión en una futura extensión de la aplicación.

Los mayores cambios en esta versión incluyen:

• Cambios a todo lo largo para responder a los objetivos descritos anteriormente
• Todo el contenido ha sido revisado y editado, y mucho del mismo ha sido reescrito
• Muchas de las tareas contenidas en la versión 1.6 han sido consolidadas, resultando en una reducción de tareas de 77 a 32.
• Las tareas del área de conocimiento Administración y Planeación de Requerimientos han sido reubicadas en Planeación y Monitoreo del Análisis de Negocio y Comunicación y Administración de Requerimientos.
• Otras tres áreas de conocimiento han sido renombradas para reflejar mejor su propósito.
• Las Técnicas aplican a lo largo de las múltiples áreas de conocimiento.
• Se han definido Entradas y Salidas para todas las tareas.

No lo olviden, haganme llegar sus comentarios!

¿Cómo entender mejor que es Análisis de Negocio?

Una de las cosas a las que me he enfrentado más al hablar acerca de Análisis de Negocio, es que las personas no relacionan este título con lo que la práctica es.

Este nombre tiene una razón lógica: el Análisis de Negocio tiene un alcance más amplio al tradicional análisis de sistemas y a la ingeniería de requerimientos. Lo que busca el Análisis de Negocio, es contemplar dentro del proyecto, todos aquellos componentes del negocio que se ven afectados por el desarrollo de una nueva iniciativa.
Estos componentes van desde, procesos, reglas de negocio, stakeholders, áreas y sistemas afectados por la iniciativa así como todos los recursos técnicos y humanos requeridos, para darle solución integral a la iniciativa de o resolver un problema de negocio, entonces… estamos hablando del negocio.

En fin son una amplia cantidad de factores y habría que dedicar una buena cantidad de tiempo para discutirlos, así que lo mejor es recomendarles, a aquellas personas que estén interesados en clarificar aun más el concepto de Análisis de Negocio, un libro que pone en contexto todos estos factores en un breve pero efectivo texto:“Professionalizing Business Analysis” de Kathleen B. Hass de la serie de libros Business Analysis Essential Library.

Este libro hace una reseña de todo el concepto del análisis de negocio, desde qué es el análisis de negocio, para que sirve, cómo se integra en una organización y como interactúa con su complemento principal: el del Project Manager. Describe también cómo juega el análisis de negocio en los diferentes ciclos de vida: el ciclo de vida de proyectos, el ciclo de vida de la solución de negocio y el ciclo de vida de los requerimientos de sistemas. Explica por otro lado, las funciones del analista de negocio, así como un breve recorrido de cada una de las áreas de conocimiento del análisis de negocio.

En fin, en mi opinión, este libro es una excelente forma de entender mejor el análisis de negocio que complementa muy bien el conocimiento de la práctica plasmado en el BABOK o de adquirir una formación formal acerca del tema.

Si ud. amable lector tiene dudas respecto a este tema, le recomiendo la lectura de este libro, es un libro sencillo de rápida lectura que le puede aclarar muchas de ellas.