ba by pmi - seccion 4 - elicitacion y analisis de requrimientos

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

http://www.bawarp.com/



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.




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.




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.




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.




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


http://www.projectworld.com/

http://ar.linkedin.com/pub/sergio-luis-conte/19/381/858

ba by pmi - seccion 4 - elicitacion y analisis de requrimientos

Leadership & Management