Methodology framework

Business Analysis Methodology and Framework

2

David Peters Principal Consultant

Discussion Points

3

• What is a Framework

• What is a Methodology

• Methodology Components (UMA)

• Business Analysis Framework

• Customisation

• Availability

• Look and Play

What is a Framework?

• A Partially completed solution

• Various options to complete

4

Various degrees of completion

What is a Methodology?

It Describes:

Who

does What

with What

to produce What

When

How

Why

5

Unified Methodology Architecture:

Role (UMA)

Task

input Work Product

output Work Product

Process

Guidance

Outcome

Relationships

6

Performs

Input Output

Role Task

Work Product

Guidance

Artifacts, Outcomes and Deliverables

Checklists Concepts Guidelines Templates Examples Term Definitions etc.

Primary and Additional

Skill Set Competency Level

Steps

Practices and Disciplines

Tasks (and their associated Roles and Work Products)

can be grouped into:

• Practices and

• Disciplines

Either or both can be used to organise tasks

7

Practices and Disciplines (contd.)

• Practices

– A practice is an approach to solving one or several commonly occurring problems. Practices are intended as "chunks" of methodology for adoption, enablement, and configuration. (Vertical Slices)

• Disciplines

– A Discipline is a categorization of Tasks based upon similarity of concerns and cooperation of work effort. (Horizontal Slices)

8

See Practices and Disciplines Matrix

9

Business Analysis Framework Domain Scope

Why Business Objectives Value

Trac

eab

ility

Product Transitional Requirements

Data Base Application

(technical) Technical Requirements

DDL Code

(high level)

How Functional Requirements

Logical Data Model

Functionality and Workflow

What Solution Scope

Business Requirements Entities Processes

Business Rules

Data Process

Non-Functional Requirements

how (detail) Physical Data Model System Specification

Interfaces

Technology Platform System Scope

what

Practices and Disciplines Matrix

10

Why (Objective)

Deliverable (Work Plan)

How (Tasks, Techniques)

Outcome (Scope BA Work)

Practice BA Planning

Business Case

Business Requirements

Functional Requirements

Non-Functional Requirements

Transitional Requirements

Solution Validation

Outcomes and Deliverables

Practices and Disciplines Matrix

11

Why (Objective)

How (Tasks, Techniques)

Practice BA Planning

Business Case

Business Requirements

Functional Requirements

Non-Functional Requirements

Transitional Requirements

Solution Validation

Planning & Monitoring

Discipline

Elicitation

Analysis

Validation & Verification

Management & Communication W

hat

(Fo

cus)

Outcome (Scope BA Work) Outcomes and Deliverables Deliverable

(Work Plan)

Practices and Disciplines Matrix

12

Why (Objective) Practice BA

Planning

Business Case

Business Requirements

Functional Requirements

Non-Functional Requirements

Transitional Requirements

Solution Validation

Planning & Monitoring

Discipline

Elicitation

Analysis

Validation & Verification

Management & Communication W

hat

(Fo

cus)

Outcome (Scope BA Work) Outcomes and Deliverables Deliverable

(Work Plan)

Do

Pyramid

Pla

n

Eval

uat

e

Prepare

Elicit

Document

Review

Analyse

What produced

How produced

Practices and Disciplines Matrix

13

Why (Objective)

Wh

at (

Focu

s)

When ?

Outcome Deliverable

Workflow

14

Click on Activity to drill down to Role-Task-

Work Product

Workflow Detail

15

Does one Methodology fit all?

• Varying Factors?

16

17

Varying Competency Levels

• Entry Level • Junior • Intermediate • Senior

Kn

ow

led

ge

Exp

erie

nce

Su

per

visi

on

C

om

ple

xity

Sc

op

e

Some but Narrow

Deep in Some areas

Deep in many areas

Wide and deep

Little to none

Some but narrow

Wide

Vast

Needs constant

Minimal

Provides

Leads

Little understanding

Broadening

Good understanding

Creative

Narrow

Deepening Broadening

Wide

Vast

Many Techniques

18

Very Detailed

High Level

Business Requirements

Functional Requirements

Decomposition Diagram

Business Use case Description

Workflow Diagram Context Level DFD Diagram

System Use case Description

Workflow Diagram

Use Case Diagram

Business Use case Description

Data Requirements (entities, Attributes Relationships)

Essential Process Description

Glossary

Process Maps Workflow Diagram

Database Design

System Use case Description

Screen Prototype

Screen Storyboard

Workflow Diagram

User Story

19

Problem Scope Tr

acea

bili

ty

Product

Diverse Jargon

Solution Scope

Value

Data Base Application

DDL Code

Logical Data Model

Functionality and Workflow

Entities Processes

Business Rules

Data Process

Physical Data Model System Specification

Interfaces

Technology Platform System Scope

Design Scope

Domain Scope

Project Scope

BAUS (Business Area Under Study)

Product Scope

Business Initiative

System Scope

Project Scope

System Scope

Solution

Software Scope

BUA (Business Area under Analysis)

SUD (System under Design)

20

Standards - Flexibility Dichotomy

VS

Few Fixed Templates Many Suitable Templates

Two Approaches To Documenting Requirements

“Boxed” Sent down the “Conveyor”

Flexibly Packaged Appropriately delivered

Cannot Change Can Change Methodology (Wisdom)

Does one Methodology fit all?

• No, because of:

– Project Complexity

– Project Type

– Project Size

– Stakeholders

– Skill Sets

– And more

21

So, we need to be able to Customise

Eclipse Process Framework Composer

22

IBM Rational Method Composer

23

Publish It

24

Let’s Look and Play

25

Conclusions

26

• We need to Plan

• We need a Methodology

• It must be easily accessible

• It must be easy to use – Novices and Experts

• It must be customisable

27

The IndigoCube Business Analysis Practice is committed to assisting clients to perform Business Analysis better through solutions in

‒ Business Analyst Assessments ‒ Methodology Provisioning

Creation Customisation Implementation

‒ Skills Development

Any Questions?

28