Business Analysis
BA1. Introduction to Business Analysis
1. What is Business Analysis?
a. Practice of enabling change in an enterprise by defining needs and recommending solutions that
deliver value to stakeholders
b. BACCM: Business Analysis Core Concepts Management
i. Change, Solutions, Context, Value, Stakeholders, Needs
c. BABOK: Business Analysis Body of Knowledge
2. Role of a business Analyst
a. Works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate
requirements for changes to business processes, policies, and information systems
b. Business analysts, IT business analysts, System analysts, …
c. Role of a business analyst = Problem solver, Facilitator, Negotiator, Architect, Planner,
Communicator, Expert, Strategist
3. Competencies of a Business Analyst
a. Main areas of competence: Business knowledge, Analytical thinking, Organization and time
management, Communication and interaction, Tools and techniques
i. External business knowledge: Business acumen, Industry knowledge, Information technology
ii. Internal business knowledge: Business model and strategies, Organizational knowledge
4. BA Planning and Monitoring
Knowledge areas and tasks:
a. Business analysis planning & monitoring
i. Planning parameters: Objective, Needs, Scope, Approach, Activities, Complexity & risk,
Approval
b. Enterprise analysis
c. Elicitation
d. Requirements analysis
e. Requirements management and communications
f. Solutions assessment & validation
5. Stakeholder Engagement
a. A person or group with a relationship to the change or solution
b. Identify -> Attitude -> Expectations -> Contribution -> Communication
c. Stakeholder engagement: Identify, Analyze and Manage stakeholders
d. Who are stakeholders? (Identify)
i. Business analyst, Customers, Domain subject matter expert (SME), End user, Implementation
subject matter expert (SME), Project manager, Tester, Regulator, Sponsor, Supplier
e. Stakeholder analysis (Analyze)
i. Stakeholder matrix based on power of influence of and impact on stakeholder
ii. Onion diagram (most important stakeholders in the core)
iii. RACI matrix: Responsible, Accountable, Consulted, Informed (per deliverable/ activity)
f. Stakeholder management (Manage)
i. Managing stakeholders is about communication: Why, What, When and How ->
communication plan
1
, 6. Conclusion
BA2. Context Analysis
1. Business Strategy
a. The long-term direction of an organization
b. Foundation of success through aligning execution with the
context of the internal & external environment
c. Current state -> strategy execution -> target state
d. SWOT
i. Internal context analysis (SW): VMOST, Resource audit, BSC, Growth share matrix
ii. External context analysis (OT): PESTLE, Porters five forces
2. External Context Analysis
a. PESTLE analysis: Political, Economic, Sociological, Technological, Legal, Environmental. (Add in
an extra E for Ethical)
b. Porter’s Five Forces model: Threat of new entrants, Bargaining power of buyers, Threat of
substitute products, Bargaining power of supplies, Rivalry among existing competitors
c. Blue <-> Red ocean strategy
3. Internal Context Analysis
a. VMOST: Vision, Mission, Objectives, Strategy, Tactics
b. Resource audit: identify strengths and weaknesses per resource type
c. BSC: Balanced scoreboard
d. Boston Box = growth share matrix = BCG matrix
4. Strategy Execution
a. Business Model Canvas (BMC)
i. Customer segments & Value propositions: Customer jobs, Gains, Pains <-> Products &
services, Gain creators, Pain relievers
ii. Channels & Customer Relationships
iii. Key Resources & Key activities
iv. Cost structure and revenue streams
b. Business Capability Model (BCM)
i. Capability = an abstract collection of resources, processes, and technologies that
together in whatever combination, enables an organization to achieve a desired outcome
ii. Only focus on relevant capabilities for the project, unless there is value in having a
capability analysis do not do it
5. Link to Enterprise Architecture
a. Every organization has an EA: represents the core building blocks and demonstrates how it is
organized
b. Business architecture, Application architecture, Data architecture, Infrastructure architecture,
Compliance and security architecture
6. Conclusion
2
, BA3. Requirements Engineering
1. Requirements Definition and Types
a. A requirement is a feature or characteristic that has been
requested by a stakeholder and may form part of a solution
b. Business requirements, Stakeholder requirements,
Solution requirements (Functional requirements and
Non-functional requirements), Transition requirements
2. Requirements Elicitation
a. Qualitative or Quantitative elicitation techniques
3. Requirements Analysis
a. Objective: identify requirements that overlap, are in conflict, are duplicates, need to be separated
b. Categorizing requirements
c. Defining/ accepting requirements
i. Evaluate feasibility (Technical, Business, Financial)
ii. Quality of expression
d. Modelling requirements
e. Prioritizing requirements
i. MoSCoW (Must have, Should have, Could have, Would have)
ii. KANO model (Must-Be, One-Dimensional (Should have), Attractive (Could have), Indifferent,
Reverse)
4. Requirements Validation
a. = Show that the requirements define the system that the customer really wants
b. Formal vs Informal validation
c. Criteria: Validity, Consistency, Completeness, Realism, Verifiability
d. Techniques: Requirements review, Prototyping, Test-case
5. Requirements Documentation
a. Documentation style: Text based or Diagrammatic
b. Project approach: Linear (waterfall) vs Agile (scrum)
c. Requirements catalogue: simple tabular format for defining requirements (typical for linear
projects)
d. User stories: backlog of user stories (typical for agile projects)
6. Requirements Modelling
a. Modelling can be applied to many requirement levels: Business, Stakeholder, Solution, …
b. Diagrammatic models: ideal instruments to provide a picture of the entire solution and confirming
the requirements that are in scope (UML)
i. Business-perspective: UML Use Case Diagrams (Actors, Use case, System boundary,
Associations) (<<include>> and <<extend>>)
ii. Data perspective: UML class diagrams and Entity Relationship Diagrams (ERDs)
iii. Process perspective: BPMN and UML Activity Diagrams
7. Requirements Management
a. Sustainable requirements
b. Volatile requirements
i. Mutable, Emerging, Consequential, Compatibility
3
BA1. Introduction to Business Analysis
1. What is Business Analysis?
a. Practice of enabling change in an enterprise by defining needs and recommending solutions that
deliver value to stakeholders
b. BACCM: Business Analysis Core Concepts Management
i. Change, Solutions, Context, Value, Stakeholders, Needs
c. BABOK: Business Analysis Body of Knowledge
2. Role of a business Analyst
a. Works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate
requirements for changes to business processes, policies, and information systems
b. Business analysts, IT business analysts, System analysts, …
c. Role of a business analyst = Problem solver, Facilitator, Negotiator, Architect, Planner,
Communicator, Expert, Strategist
3. Competencies of a Business Analyst
a. Main areas of competence: Business knowledge, Analytical thinking, Organization and time
management, Communication and interaction, Tools and techniques
i. External business knowledge: Business acumen, Industry knowledge, Information technology
ii. Internal business knowledge: Business model and strategies, Organizational knowledge
4. BA Planning and Monitoring
Knowledge areas and tasks:
a. Business analysis planning & monitoring
i. Planning parameters: Objective, Needs, Scope, Approach, Activities, Complexity & risk,
Approval
b. Enterprise analysis
c. Elicitation
d. Requirements analysis
e. Requirements management and communications
f. Solutions assessment & validation
5. Stakeholder Engagement
a. A person or group with a relationship to the change or solution
b. Identify -> Attitude -> Expectations -> Contribution -> Communication
c. Stakeholder engagement: Identify, Analyze and Manage stakeholders
d. Who are stakeholders? (Identify)
i. Business analyst, Customers, Domain subject matter expert (SME), End user, Implementation
subject matter expert (SME), Project manager, Tester, Regulator, Sponsor, Supplier
e. Stakeholder analysis (Analyze)
i. Stakeholder matrix based on power of influence of and impact on stakeholder
ii. Onion diagram (most important stakeholders in the core)
iii. RACI matrix: Responsible, Accountable, Consulted, Informed (per deliverable/ activity)
f. Stakeholder management (Manage)
i. Managing stakeholders is about communication: Why, What, When and How ->
communication plan
1
, 6. Conclusion
BA2. Context Analysis
1. Business Strategy
a. The long-term direction of an organization
b. Foundation of success through aligning execution with the
context of the internal & external environment
c. Current state -> strategy execution -> target state
d. SWOT
i. Internal context analysis (SW): VMOST, Resource audit, BSC, Growth share matrix
ii. External context analysis (OT): PESTLE, Porters five forces
2. External Context Analysis
a. PESTLE analysis: Political, Economic, Sociological, Technological, Legal, Environmental. (Add in
an extra E for Ethical)
b. Porter’s Five Forces model: Threat of new entrants, Bargaining power of buyers, Threat of
substitute products, Bargaining power of supplies, Rivalry among existing competitors
c. Blue <-> Red ocean strategy
3. Internal Context Analysis
a. VMOST: Vision, Mission, Objectives, Strategy, Tactics
b. Resource audit: identify strengths and weaknesses per resource type
c. BSC: Balanced scoreboard
d. Boston Box = growth share matrix = BCG matrix
4. Strategy Execution
a. Business Model Canvas (BMC)
i. Customer segments & Value propositions: Customer jobs, Gains, Pains <-> Products &
services, Gain creators, Pain relievers
ii. Channels & Customer Relationships
iii. Key Resources & Key activities
iv. Cost structure and revenue streams
b. Business Capability Model (BCM)
i. Capability = an abstract collection of resources, processes, and technologies that
together in whatever combination, enables an organization to achieve a desired outcome
ii. Only focus on relevant capabilities for the project, unless there is value in having a
capability analysis do not do it
5. Link to Enterprise Architecture
a. Every organization has an EA: represents the core building blocks and demonstrates how it is
organized
b. Business architecture, Application architecture, Data architecture, Infrastructure architecture,
Compliance and security architecture
6. Conclusion
2
, BA3. Requirements Engineering
1. Requirements Definition and Types
a. A requirement is a feature or characteristic that has been
requested by a stakeholder and may form part of a solution
b. Business requirements, Stakeholder requirements,
Solution requirements (Functional requirements and
Non-functional requirements), Transition requirements
2. Requirements Elicitation
a. Qualitative or Quantitative elicitation techniques
3. Requirements Analysis
a. Objective: identify requirements that overlap, are in conflict, are duplicates, need to be separated
b. Categorizing requirements
c. Defining/ accepting requirements
i. Evaluate feasibility (Technical, Business, Financial)
ii. Quality of expression
d. Modelling requirements
e. Prioritizing requirements
i. MoSCoW (Must have, Should have, Could have, Would have)
ii. KANO model (Must-Be, One-Dimensional (Should have), Attractive (Could have), Indifferent,
Reverse)
4. Requirements Validation
a. = Show that the requirements define the system that the customer really wants
b. Formal vs Informal validation
c. Criteria: Validity, Consistency, Completeness, Realism, Verifiability
d. Techniques: Requirements review, Prototyping, Test-case
5. Requirements Documentation
a. Documentation style: Text based or Diagrammatic
b. Project approach: Linear (waterfall) vs Agile (scrum)
c. Requirements catalogue: simple tabular format for defining requirements (typical for linear
projects)
d. User stories: backlog of user stories (typical for agile projects)
6. Requirements Modelling
a. Modelling can be applied to many requirement levels: Business, Stakeholder, Solution, …
b. Diagrammatic models: ideal instruments to provide a picture of the entire solution and confirming
the requirements that are in scope (UML)
i. Business-perspective: UML Use Case Diagrams (Actors, Use case, System boundary,
Associations) (<<include>> and <<extend>>)
ii. Data perspective: UML class diagrams and Entity Relationship Diagrams (ERDs)
iii. Process perspective: BPMN and UML Activity Diagrams
7. Requirements Management
a. Sustainable requirements
b. Volatile requirements
i. Mutable, Emerging, Consequential, Compatibility
3
