Está en la página 1de 28

¿Por qué necesitamos analistas de

negocio y administradores de
proyectos?
Los roles
 El administrador de proyecto asegura
entregar el producto al cliente en tiempo,
dentro del presupuesto.
 El analista de negocio asegura que el
producto se construye de acuerdo a los
requerimientos del cliente.
Entre los dos…

 Asegura que el producto se


construye de acuerdo a los
requerimientos del cliente en el
tiempo y el presupuesto
acordados.
El analista de negocio
Las soluciones generalmente incluyen un
componente de sistema, pero puede
contener también una mejora de procesos o
un cambio en la organización.
El analista de negocio
Es responsable de:
 Identificar las necesidades de cliente.
 Cerrar la brecha entre las áreas de TI y las usuarias.
 Desarrollar y administrar los requerimientos,
específicamente, de obtener, analizar, validar y
documentar los requerimientos organizacionales y
operacionales.
 Servir como el arquitecto de la solución junto con el líder
técnico.
 Observar a la organización desde dentro y fuera.
El reto de ser BA y PM al mismo
tiempo
 Jugar un rol a la vez!
Diferencias

PM BA
Dirige al equipo Escucha al cliente
Ayuda al equipo a Ayuda al cliente a
realizar las tareas describir cómo realiza
su tareas
Remueve barreras Identifica factores
clave en la
organización
La metodología
 Business Analysis Body of Knowledge
 Análisis de la organización
 Planeación y administración de los
requerimientos
 Obtención de los requerimientos
 Análisis y documentación de los requerimientos
 Comunicación de los requerimientos
 Evaluación y validación de la solución
Requerimiento
 Una condición o capacidad necesitada por
un grupo de interés para resolver un
problema o alcanzar un objetivo
 Una condición o capacidad que debe cubrir
o poseer un sistema para satisfacer un
contrato, estándar,o especificación
Tipos de requerimientos
 De negocio u organización
 Enunciado de alto nivel de las metas, objetivos y
necesidades de la organización
 De usuario
 Enunciado de las necesidades de los grupos de interés.
Describe cómo el grupo interactúa com la solución.
 Funcionales
 Describen el comportamiento y la información que la
solución maneja. Describe las capacidades que el
sistema es capaz de desempeñar en términos de
comportamiento y operación.
Tipos de requerimientos
 De calidad de servicio
 Captura las condiciones que no están relacionadas a la
funcionalidad, pero describe las condiciones del
contexto en el que la solución será efectiva y las
carácterísticas de calidad del sistema.
 De implementación
 Describe las cpaacidades que tendrá la solución para
facilitar la transición del estado actual al estado futuro.
 Limitaciones y asunciones
Planeación y administración de
los requerimientos
 En coordinación con el PM
 Tareas:
 Identificación de roles
 Identificación de grupos de interés
 Consulta de material de referencia
 Definición de la estrategia de trabajo
 Identificación de necesidades y ubicación de los grupos de
interés
 Determinar el equipo y actividades para la obtención,
análisis, documentación y comunicación de requerimientos
 Determinar el equipo y las actividades para la evaluación y
validación de la solución
 Estructurar los requerimientos para trazabilidad
Adminstración del cambio de
requerimientos
 Quién, cómo y cuándo
 Impacto del cambio
Proceso del cambio
1. Identificar el cambio
2. Crear la requisición formal de cambio
3. Definir ligas a otros requerimientos
4. Enviar cambio para aprobación
Obtención de requerimientos
Técnicas:
 Lluvia de ideas
 Análisis de documentos
 Focus Group
 Entrevistas
 Observación
 Prototipo
 Taller
 Cuestionario
Obtención de requerimientos
 Lluvia de ideas
 Mapa mental
 Alrededor de una idea central

 Focus Group
 Grupo de expertos alrededor de ideas específicas
 Dirigido por un moderador
 Investigación cualitativa
Obtención de requerimientos
 Taller de requerimientos
 Forma estructurada para captar requerimientos
 Utilizado para definir alcance y prioridad de los requerimientos
encapsulados en el sistema
 Joint Application Design
 Se requiere de moderador y escribano
 Para alcanzar consenso y acuerdo de los requerimientos
 Detalle de los requerimientos
Análisis de requerimientos
 Describe cómo se analizan, estructuran y especifican los
requerimientos para diseño y construcción de la solución.
Técnica de análisis
 Análisis de procesos de la organización-
enfocado al mejoramiento de los procesos
de la organización de acuerdo con su
misión, visión y objetivos.
 Business process mapping (diagramas de flujo
y flujos de trabajo, mapas de procesos)
Análisis de Requerimientos
 Estructurar requerimientos
 Generar Modelo
 Analizar requerimientos de usuario
 Analizar requerimientos funcionales
 Analizar requerimientos de calidad de servicio
 Determinar las limitaciones y asunciones
 Determinar los atributos de los requerimientos
 Documentar la especificación de requerimientos
 Validar la especificación de requerimientos
Estructurar requerimientos
 Descomposición de las metas
 Descomposición de las carácterísticas de la
solución (prioridad, complejidad y versión
de implementación)
 Descomposición funcional

Entregable: Modelo de la solución


Generación de modelo
 Describir mestado actual y estado futuro
 Utilizado para asumir el estado actual de la
organización
 Utilizado para tener la visión compartida de
la solución

Entregable: Documento de modelo actual y


futuro
Análisis de requerimientos de
usuario
 Describir los requerimientos por usuario o grupos
de usuario

Considerar:
 Cómo se distribuye y aplica la solución?
 Número de grupos de usuarios
 Complejidad de la solución
 Consenso entre los grupos de interés
Análisis de requerimientos
funcionales
 Describe el comportamiento deseado de la
solución.
 Estos requerimientos describen las capacidades
del sistema (acción-respuesta)
El comportamiento incuye:
 El efecto que tendrá la solución acerca de un
problema dado
 La interacción de personas o sistemas con la
solución propuesta
 El eumplimiento de un estándar
Documentación de
requerimientos
 Evento/condición
 Sujeto
 Acción
 Objeto
 Reglas
 Resultado
Análisis de requerimientos de
calidad de servicio
 Requerimientos del contexto (regulatorios, políticos,
estándates, políticas, condiciones físicas)
 Requerimientos de auditoría
 Requerimientos de localización (tropicalización)
 Requerimientos de la interfaz
 Glosario
 Requerimientos de operacionales
 Requerimientos de desempeño y disponibilidad
 Requerimientos de calidad
 Privacidad de la información
 Requerimientos de seguridad
 Entrenamiento
Limitaciones y asunciones
 Limitaciones de la organización
 Limitaciones técnicas
 Asunciones (algo que se cree cierto pero no
se puede verificar y si cambia, puede afectar
negativamente el proyecto)
Atributos de los requerimientos
 Metadata incluye: quién lo hace, cuándo lo hace,
quién autorizó
 Uso de imperativos
 Elementos:
 Referencia
 Criterio de aceptación
 Autor
 Complejidad
 Propiedad
 Fuente
 Estabilidad (madurez del req.)
 Status (propuesto, aceptado, verificado)
 Urgencia
Validación de requerimientos
 Firma!!!