01 October 2011

RA en BABOK v2.0 (6)

REQUIREMENTS ANALYSIS (RA)

Introducción

Es un área de conocimiento que determina cómo elaborar la definición de la solución que permita al equipo del proyecto diseñar una solución que cumpla con las necesidades del negocio y de las partes interesadas. Para hacer esto se debe analizar el estado inicial de los requerimientos de las partes interesadas para asegurar que son los correctos, evaluar el estado actual del negocio para identificar y recomendar mejoras, y, por último, verificar y validar los resultados.

TAREA 1 – Priorizar los requerimientos

Propósito

No todos los requerimientos tienen la misma importancia. La priorización de los requerimientos permite asegurar que el análisis y la implementación están enfocados en los requerimientos críticos.

Entradas

(1) Business case, (2) Stated requirements y (3) Stakeholder analysis

Técnicas

Análisis Moscow (los requerimientos se clasifican en las categorías de ‘debe’, ‘sería’, ‘podría’ y ‘no será’) – Análisis Kano – Tiempos y presupuesto – Votación

Partes interesadas

Sponsor – Project manager – Domain SME – Implementation SME

Salidas

(1) Prioritized requirements

TAREA 2 – Organizar los requerimientos

Propósito

El propósito de organizar los requerimientos consiste en crear un conjunto de vistas de requerimientos que sean comprensivos, completos, consistentes y entendidos por las partes interesadas incluyendo los expertos de dominio del negocio, usuarios del negocio, diseñadores de la solución, desarrolladores, integradores y equipo de prueba.

Descripción

En este caso se pretende crear una estructura organizada de los requerimientos e identificar la interrelación entre los requerimientos y sus dependencias.

Entradas

(1) Business case, (2) Solution scope, (3) Stated requirements y (4) Organizational standards

Elementos

Seleccionar el método para organizar los requerimientos – Determinar el nivel de requerimiento – Documentar las dependencias e interrelaciones de los requerimientos

Técnicas

Descomposición jerárquica – Escenarios y casos de uso - Otras técnicas (Reglas de negocio, modelos de datos, modelo de eventos, análisis de objetivos, métricas e informes, modelo organizacional, personas y perfiles de usuario, modelo de procesos, prototipos, escenarios y casos de uso)

Partes interesadas

Business analyst – Customer- Domain Subject matter expert (SME) – End user – Implementation Subject matter expert (SME) – Operational support – Project manager – Quality assurance – Regulator – Sponsor

Salidas

(1) Organized requirements

TAREA 3 – Especificar y modelar los requerimientos

Propósito

Esta tarea tiene como propósito documentar los requerimientos de varias formas usando una combinación de enunciados, matrices diagramas y modelos formales en un lenguaje natural.

Entradas

(1) Requirements

Técnicas

Matriz de documentación – Tabla o árbol de decisión

Partes interesadas

Business analyst – Customer - Domain SME – End user - Implementation SME – Operational support – Project manager – Quality assurance – Regulator – Sponsor

Salidas

(1) Modeled and Specified requirements

TAREA 4 – Determinar las suposiciones y restricciones

Propósito

Esta tarea tiene como propósito identificar las suposiciones realizadas y restricciones identificadas durante el análisis de requerimientos que impactarán en el diseño de la solución.

Entradas

(1) Elicitation results (suposiciones y restricciones)

Técnicas

Administración del riesgo

Partes interesadas

Implementation SME

Salidas

(1) Documented assumptions and constraints

TAREA 5 – Verificar los requerimientos

Propósito

Esta tarea permite evaluar los requerimientos para verificar que cumplen las especificaciones de calidad. Esta tarea asegura que los requerimientos están definidos y estructurados, así como que la solución del equipo de desarrollo puede ser usada en el diseño, desarrollo e implementación de la solución.

Entradas

(1) Requirements artifacts

Técnicas

Lista de verificación – Walkthrough

Partes interesadas

Business analyst – Customer - Domain SME – End user - Implementation SME – Operational support – Project manager – Quality assurance – Regulator – Sponsor

Salidas

(1) Verified requirements

TAREA 6 – Validar los requerimientos

Propósito

No todos los requerimientos tienen la misma importancia. La priorización de los requerimientos permite asegurar que el análisis y la implementación están enfocados en los requerimientos críticos.

Entradas

(1) Business case y (2) Verified requirements

Técnicas

Structured Walkthrough – Estudios de factibilidad – Criterio de aceptación – Métricas e Informes – Prototipos

Partes interesadas

Business analyst – Customer - Domain SME – End user - Implementation SME – Operational support – Project manager – Quality assurance – Regulator – Sponsor Salidas

(1) Validated requirements y (2) Evaluation criteria