This document discusses business analysis methodologies and frameworks. It defines a methodology as describing who performs what tasks using what inputs to produce what outputs, when, how, and why. A framework is described as a partially completed solution with options for completion. The document outlines the Unified Methodology Architecture (UMA) components of roles, tasks, inputs, outputs, processes, and guidance. It presents a business analysis framework that maps requirements from business objectives to technical requirements. Finally, it discusses how methodologies and frameworks can be customized based on factors like competency levels and technique complexity.

2. Business Analysis Methodology
and Framework
David Peters
Principal Consultant
2

3. Discussion Points
• What is a Framework
• What is a Methodology
• Methodology Components (UMA)
• Business Analysis Framework
• Customisation
• Availability
• Look and Play
3

4. What is a Framework?
• A Partially completed solution
Various degrees
of completion
• Various options to complete
4

5. What is a Methodology?
It Describes: Unified Methodology Architecture:
Who Role (UMA)
does What Task
with What input Work Product
to produce What output Work Product
When Process
How Guidance
Why Outcome
5

6. Relationships
Steps
Role Task
Primary
Performs
and
Additional
Input Guidance
Skill Set
Competency Level Output Checklists
Concepts
Guidelines
Templates
Examples
Work Product Term Definitions
Artifacts, Outcomes and Deliverables etc.
6

7. 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

8. 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) See Practices and
Disciplines Matrix
• Disciplines
– A Discipline is a categorization of Tasks based upon
similarity of concerns and cooperation of work effort.
(Horizontal Slices)
8

9. Business Analysis Framework
Domain Scope
Why Value Business Objectives
Solution Scope
What Entities Processes
Business Requirements
Traceability
Business Rules
(high level) Logical Data Functionality Functional
what Model and Workflow
How Requirements
Technology Platform
System Scope
Interfaces Non-Functional
how
Requirements
(detail) Physical Data Model System Specification
Technical
(technical) Requirements
DDL Code
Product Data Base Application Transitional
Requirements
Data Process
9

10. Practices and Disciplines Matrix
Why (Objective)
Practice BA Business Business Functional Non-Functional Transitional Solution
Planning Case Requirements Requirements Requirements Requirements Validation
How (Tasks, Techniques)
Outcome
Deliverable Outcomes and Deliverables
(Scope BA Work)
(Work Plan)
10

11. Practices and Disciplines Matrix
Why (Objective)
Practice BA Business Business Functional Non-Functional Transitional Solution
Discipline Planning Case Requirements Requirements Requirements Requirements Validation
Planning &
Monitoring
Elicitation
What (Focus)
Analysis
How (Tasks, Techniques)
Management &
Communication
Validation &
Verification
Outcome
(Scope BA Work) Deliverable Outcomes and Deliverables
(Work Plan)
11

12. Practices and Disciplines Matrix
Why (Objective)
Practice BA Business Business Functional Non-Functional Transitional Solution
Discipline Planning Case Requirements Requirements Requirements Requirements Validation
Planning &
Monitoring
Prepare
Elicitation Elicit Pyramid
Evaluate
What (Focus)
Plan
Analysis Analyse Do
How
Management & What
produced
Communication Document produced
Validation &
Verification Review
Outcome
(Scope BA Work) Deliverable Outcomes and Deliverables
(Work Plan)
12

13. Practices and Disciplines Matrix
Why (Objective)
What (Focus)
When ?
Outcome
Deliverable
13

14. Workflow
Click on Activity to drill
down to Role-Task-
Work Product
14

15. Workflow Detail
15

16. Does one Methodology fit all?
• Varying Factors?
16

17. Varying Competency Levels
Supervision
Knowledge
Experience
Complexity
Scope
• Entry Level Some but
Narrow
Little to none Needs
constant
Little
understanding
Narrow
Deep in Some but Minimal Broadening Deepening
• Junior Some areas narrow Broadening
Deep in many Wide Provides Good Wide
• Intermediate areas understanding
Wide and Vast Leads Creative Vast
• Senior
deep
17

18. Many Techniques
Very
Data Requirements
Detailed (entities, Attributes
Database Design
Relationships) System Use case
Description
Essential Process
Description
Business Use case
Screen Prototype
Description Glossary
Screen Storyboard
Process
Maps Workflow Diagram Workflow Diagram
Business Use case
Decomposition Description Workflow Diagram
Diagram
System Use case
Description
Context Level
DFD Diagram Workflow Diagram
Use Case Diagram
User Story
High
Level
Business Functional
Requirements Requirements
18

19. Diverse Jargon
Problem Scope
Domain Scope
BAUS (Business Area
Business Initiative Under Study)
Value
Project Scope
Solution Scope
System Scope BUA (Business Area
Entities Processes
Traceability
Product Scope under Analysis)
Business Rules
Logical Data Functionality SUD (System
Project Scope Model and Workflow under Design)
Technology Platform
System Scope
Design Scope Interfaces
System Scope Physical Data Model System Specification
Software Scope
DDL Code
Product Solution Data Base Application
Data Process
19

20. Standards - Flexibility Dichotomy
Two Approaches To Documenting Requirements
Few Fixed Templates Many Suitable Templates
VS
Flexibly Packaged Appropriately
“Boxed” Sent down the delivered
“Conveyor”
Cannot Change Methodology Can Change
(Wisdom)
20

21. Does one Methodology fit all?
• No, because of:
– Project Complexity
– Project Type
– Project Size
– Stakeholders
– Skill Sets
– And more
So, we need to be able to Customise
21

22. Eclipse Process Framework Composer
22

23. IBM Rational Method Composer
23

24. Publish It
24

25. Let’s Look and Play
25

26. Conclusions
• 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
26

27. Any Questions?
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
27

28. 28