Este documento resume la sección 4 de la Guía Práctica del Análisis de Negocio publicada por el PMI. La sección se enfoca en la elicitación y análisis de requerimientos. Explica que la elicitación implica extraer información de los interesados para luego analizarla y derivar los requerimientos de la solución. También describe diferentes técnicas para la planificación, ejecución y documentación de las actividades de elicitación y análisis, así como la importancia de validar y verificar los requerimientos.

1. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 1
BA by PMI® – Entendiendo la Guía Práctica del Análisis de Negocio
Sección 4: Elicitación y Análisis de Requerimientos (Requirements
Elicitation and Analysis)
Introducción.
La intención de esta serie de artículos es divulgar la Guía Práctica del Análisis de Negocio (“La
Guía”, en los párrafos siguientes) recientemente publicada por el PMI®. Esta organización
reconoce el crecimiento de la profesión del Análisis de Negocio y su importancia como factor
crítico de éxito de cada proyecto o programa que las organizaciones emprenden para solucionar
sus problemas de negocio satisfaciendo sus necesidades de transformación. La Guía incluye
también puntos aclaratorios respecto de cómo el Analista de Negocio (“BA” en lo que sigue) y
Administrador de Proyectos (“PM” en lo que sigue) colaboran para lograr los objetivos del
emprendimiento.
4.1. Resumen.
Según La Guía la Planificación del Análisis de Negocio consiste en el trabajo iterativas relacionadas
con definir planificar, preparar y realizar las actividades de elicitar información desde los
interesados, analizar y documentar los resultados y definir los requerimientos con suficiente
detalle para habilitar la definición y selección de la solución esperada. El BA usa un número de
técnicas de elicitación y aplica un número de modelos de análisis que soportarán las actividades de
elicitación y análisis.
4.2. Qué significa elicitar información.
Elicitar es el acto de tomar información desde los interesados y otras fuentes. Esto implica elicitar
información referente a las causas del problema de negocio o las razones para alcanzar una
oportunidad como así también toda la información necesaria que será utilizada para derivar con
suficiente detalle los requerimientos que permitan desarrollar e implementar la solución.
La Guía hace mención respecto que el proceso de elicitación es más que recolectar (collect) o
tomar (gather) requerimientos. El término “tomar” implica que los interesados tienen los
requerimientos listos para ser tomados y especificados y esto no es así. La Guía claramente
menciona que los requerimientos no están listos y esperando en la mente de los interesados o
dentro de documentos del negocio. Dice que los interesados tienen necesidades que, además,
generalmente no pueden expresar con claridad. Conocen que tienen un problema, pero no saben
exactamente cuál es. Conocen que deben tomar ventaja de una oportunidad, pero no saben como
empezar.
Nota del autor: la importancia del término “elicitar” es crítica. Implica que el Analista de Negocio
tiene la responsabilidad de extraer toda información desde los interesados y cualquier otra fuente
para luego convertirla en requerimientos. Este es un cambio radical en la forma de pensar el

2. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 2
trabajo relacionado a la problemática de extraer información para convertirla en los
requerimientos de la solución que se ajusta a las necesidades estratégicas de la organización.
4.3. Planear la Elicitación.
La Guía hace referencia a que gran parte de esta actividad se realiza durante la construcción del
Plan del Análisis de Negocio (Sección 3 de La Guía).
El plan de elicitación no es un entregable ya que es parte del Plan del Análisis de Negocio pero
debe incluir todo lo necesario para:
 Entender qué información hay que elicitar.
 Dónde encontrar la información.
o Se hace mención a otro concepto crítico: los componentes de la arquitectura
empresarial. Dentro de esta se pueden encontrar todos los documentos que dan
origen y mantienen la estructura de la organización.
 Cómo obtener la información.
o En la sección 4.5.5 se listan varias técnicas que pueden utilizarse. Alguna de las
señaladas son:
 Brainstorming, Análisis de Documentos, Workshops de Facilitación, Focus
Groups, Entrevistas, Observación, Prototipos, Cuestionarios.
 La secuencia de actividades de elicitación junto con tiempos y recursos necesarios.
4.4. Prepararse para la Elicitación.
En este punto, se muestra la importancia de estar preparado para la actividad de elicitación.
Alguno de los puntos a tener en cuenta son 4.4.1. Determinar los objetivos, 4.4.2. Determinar los
participantes, 4.4.3. Determinar las preguntas (en caso que aplique para la técnica a utilizar).
4.5. Realizar la Actividad de Elicitación.
Según La Guía la actividad debe ser planificada y consta de cuatro partes principales:
 Introducción: pone en claro el objetivo, el tiempo y el propósito.
 Cuerpo: se realizan las preguntas. Según la guía los tipos de preguntas a utilizar pueden ser
Open-ended (la forma de respuesta la elige el entrevistado), Close-ended (la forma de
respuesta está limitada a seleccionar opciones), Contextual (la respuesta se limita al
contexto) y Context-free (la respuesta no tiene un contexto definido).
 Cierre. revisión final de la sesión.
 Seguimiento. la información se consolida y se confirma con los participantes.
4.6. Documentar la Salida de las Actividades de Elicitación.
Los documentos a generar dependen de varios factores pero se puntualiza que los resultados
deben documentarse formal o informalmente.

3. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 3
4.7. Completar la Elicitación.
La Elicitación debe considerarse una actividad progresiva de elaboración de información. La
información se elabora luego de analizar el resultado de la elicitación. Puntos tales como la
aprobación de los resultados de la elicitación, haber alcanzado el objetivo de la elicitación, haber
identificado claramente la solución pueden considerarse para declarar finalizada la actividad.
4.9. Analizar los Requerimientos.
La Guía define “Análisis” como el proceso de examinar, disgregar y sintetizar la información para
entenderla, completarla y mejorarla. El Análisis involucra el trabajo progresivo e iterativo con la
información para abstraer distintos niveles de detalle principalmente para proveer estructura a los
requerimientos y la información relacionada.
Hay que realizar la actividad de planeación del análisis definiendo que actividades y técnicas son
útiles y cuándo deben ser utilizadas. Muy importante es decidir qué tipos de modelos van a
utilizarse para realizar el análisis.
El BA trabaja con diferentes tipos de información pero principalmente el análisis se realiza sobre
los resultados de la elicitación1
. Si bien dependerá del enfoque o ciclo de vida utilizado en general
las tareas de elicitación y análisis son iterativas.
4.10. Modelar y Refinar los Requerimientos.
Para La Guía modelo significa la representación visual de la información, abstracta y específica,
que cumple con un conjunto de guías con el objetivo de presentar la información en forma
concisa.
La Guía hace mención a diferentes tipos de modelos, a saber:
 Modelo de Alcance. Estructuran y organizan todo lo relativo a los límites del dominio.
 Modelo de Proceso. Describen los procesos y la interacción de los interesados.
 Modelo de Reglas. Describen conceptos y comportamientos relacionados con políticas.
 Modelo de Datos. Documentan los datos utilizados en los procesos.
 Modelo de Interfaces. Describen el sistema y sus relaciones.
La Guía menciona que la selección del modelo dependerá de factores tales como la metodología a
utilizar, las características del proyecto, el ciclo de vida del proyecto y el nivel de abstracción.
Las secciones 4.10.7 a 4.10.11 describen en detalle los modelos y las distintas herramientas que
pueden utilizarse para trabajar con ellos.
4.11. Documentar los Requerimientos de la Solución.
Según La Guía, luego de analizar toda la información resultado de la elicitación el analista de
negocio documenta los requerimientos resultantes en algún formato, dependiendo de la
1
La Guía deja implícito que los requerimientos se obtendrán luego de analizar el resultado de la elicitación. Lo mismo puede verse en
4.11.

4. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 4
organización, las necesidades del proyecto y el ciclo de vida del proyecto. El BA prepara el paquete
de requerimientos de manera tal que el equipo que genera la solución entienda claramente el
alcance de la solución y el problema u oportunidad de negocio al que está dirigida.
Dentro de la documentación propuesta La Guía hace mención a:
 Documento de Requerimientos del Negocio. Mostrando claramente el problema u
oportunidad y la razón que impulsa a generar la solución.
 Documentación de la Solución. Todo lo necesario y previamente definido para que la
solución pueda ser generada por el equipo seleccionado durante el proyecto definido.
La Guía hace clara mención a que los requerimientos del producto son responsabilidad del BA
mientras que los requerimientos del proyecto son responsabilidad del PM.
Los supuestos y restricciones deben ser documentados dentro de la especificación de
Requerimientos. El BA documenta las restricciones del producto y en caso de encontrar
restricciones del proyecto debe documentarlas y entregarlas al PM.
La Guía expresa también varios lineamientos que pueden ayudar como complemento sobre la
escritura de los requerimientos y su verificación mostrando que adhieren a los estándares de la
IEEE. También resalta la importancia de la priorización y de la documentación con técnicas
relacionadas al mundo de la tecnología y el software tales como Casos de Uso o Historias de
Usuario.
4.12. Validar Requerimientos.
La Guía define la validación como la garantía de que un producto, servicio o sistema cumple con
las necesidades del cliente y otros interesados. En Análisis de Negocio la validación de
requerimientos es el proceso de asegurar que los requerimientos muestran las intenciones y
expectativas de todos los interesados. También se lo conoce con el nombre de “Confirmar los
Requerimientos”.
También define el concepto de “confirmación continua” diciendo que, teniendo en cuenta que
confirmar no es lo mismo que aprobar, la confirmación puede realizarse toda vez que los
requerimientos son escritos en algún lugar y puestos a consideración de los interesados o todo
aquel que pertenezca al equipo de generación de la solución. Confirmar los requerimientos
significa obtener desde los interesados el acuerdo sobre que la solución alcanza los objetivos.
La técnica propuesta es el “requirements walkthrough” que permite revisar en conjunto los
requerimientos con los interesados.
4.13. Verificar Requerimientos.
La Guía define la verificación como el proceso de revisar los requerimientos en busca de errores o
problemas de calidad. Verificación debería ocurrir previa a la Validación. La Verificación se realiza
con los integrantes del equipo que genera la solución para asegurar que los requerimientos
cumplen con los estándares de calidad definidos.

5. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 5
La Guía define dos procesos de verificación:
 Peer Review. Se realiza con otros pares del BA que conocen los estándares de calidad
definidos.
 Inspection. Con la utilización de un checklist se verifica que los requerimientos
especificados en el documento a inspeccionar cumplen con los atributos señalados en el
checklist.
4.14. Sesiones de Aprobación.
En el final, los requerimientos deben ser aprobados formalmente. Según La Guía esta aprobación
formal podría ser un proceso automático. Los conflictos podrían ocurrir en este punto y a lo largo
de la Elicitación y el Análisis y es por eso que, en la sección 4.15, se expresa claramente que es
responsabilidad del BA resolverlos. Tres técnicas (Delphi, Multi-Voting y Ranking por Pesos) son
propuestas por La Guía como buenas herramientas para resolver y anticipar los conflictos.
Conclusión.
En esta sección puede verse que el PMI® agrega una importante consideración cuando de
requerimientos se trata: los requerimientos surgirán luego de analizar la información extraída
desde los interesados o desde cualquier otro tipo de fuente. Y muestra también la clara diferencia
entre requerimientos del proyecto y del producto, qué rol tiene responsabilidad sobre cada uno, y
la importancia de dos tareas críticas tales como la verificación y la validación.
Esta sección de La Guía está en línea con el Área de Conocimiento 3-Elicitation y 6-Requirements
Analysis de la Guía BABOK® del IIBA®. El lector encontrará, en caso de comparar ambas guías, que
esta última es mucho más consistente en puntos tales como las técnicas y métodos para encontrar
las necesidades del negocio. Vale aclarar que el PMI® ha señalado que esta es la primera versión
de La Guía y que sufrirá evoluciones.

6. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 6
ABOUT THE AUTHOR
Sergio Luis Conte, República Argentina
Sergio Luis Conte es Ph.D in Software Engineering egresado de la
Universidad Cargnegie Mellon, USA.
También obtuvo su título de Licenciado en Sistemas de la Universidad CAECE
y realizó estudios de Magister en Administración y Dirección Empresarial en
la Facultad de Ingeniería de la UBA, en Ingeniería de Software en la
Universidad CAECE y en Ingeniería del Conocimiento en el ITBA.
Actualmente trabaja en PepsiCO en el GPMG (Global Project Management
Group) como responsable de Programas de Transformación e Innovación
para Latino America.
Ha desarrollado el E2A Framework - NOELIA Method® utilizado en
organizaciones de todo el mundo y actualmente en PepsiCO.
A dictado conferencias en varios países de Latino América, Europa y en
Estados Unidos y es profesor en la Escuela de Negocio de varias
Universidades de Argentina y el exterior. Fué el primer Latino Americano en
ser invitado a dictar una conferencia en la “2012 ProjectWorld® & World
Congress for Business Analysts® Conference (www.projectworld.com)”
Sergio posee las certificaciones PMP®, PMI-PBA® y PMI-ACP® del PMI®,
CBAP® del IIBA® y DSDM AP&Coach (DSDM Agile Method).
Con el PMI® y el IIBA® y el DSDM Consortium® ha desarrollado y desarrolla
las siguientes actividades:
 Reviewer PMI´s PMBOK 2008 and 2012
 Co-Author PMI´s PMBOK Software Extension
 Co-Author IIBA´s BABOK 2003 and 2013
 Co-Author DSDM Method version 1 and 2
 Subject Matter Expert, Quality Assurance, Examination for PMI´s
Certification Credentials.
En su faz personal, fué jugador de tenis de la ATP y posee la matrícula
profesional Level 1 de la ITF como Profesor y Entrenador de Tenis.
Para más información sobre sus antecedentes puede consultar:
http://ar.linkedin.com/pub/sergio-luis-conte/19/381/858