BUSINESS

ANALYSIS
FOUNDATION
Lecture 4 – Initial Steps in Projects
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 What is a Business Case
A decision-making tool used to determine the effects a particular decision will have on profitability.

The business case is created prior to the project being

started. This frames up the return on investment prior to
taking the action.

A business case is generally created by a business

executive, a business manager, or a business analyst.
 Business Case Phases
4. Review Business Case
Validate problem statement. Ensure all
valid solution given. Get project
stakeholders
05 Present

2. Determine Potential Solution

04
Review

03
Identify all possible solutions to the
5. Present the Business Case
problems. E.g. Benefits, Costs,
Timetable of project, Risks Business Present the content. Give your
recommendation
Case
02 Potential
Solution
01 3. Writing the Business Case
Summary, Problem Statement, Analysis,
Solution Options, Cost-Benefit Analysis,
Initial
Recommendation
1. Initial Analysis
Understand the problem or opportunity
Determine high-level requirements
Analyze likelihood project will be approved
and if should continue
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 What is Stakeholders
What is a stakeholder?
• Project team members
• Customer
• Suppliers
• Employees
• Employers (Manager, Director, C-Levels, BOM)
• City/Community
• Professional organizations
• Any individual impacted by the project
• Any individual to support the project
 How to Identify Stakeholders

Why identify stakeholders?

• It increases the chances for success
• Additional ideas
• Varied perspectives
• Gains buy-in
• Increases credibility
 How to Identify Stakeholders

How to identify stakeholders to my project?

• Walk through anticipated scope/process
• Beneficiaries of the effort
• Directly involved with the beneficiaries of the effort
• Jobs that may be affected by project or results
• Government officials
• Influencers
• Interest in outcome
• Get ideas from stakeholders as you identify them
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 Root cause analysis
Root cause analysis is used to identify and evaluate the underlying causes
of a problem

Applying the iterative analysis approach to take into account all the root
cause contributing to the effects

Root cause analysis looking at the main types such as:

• People (error, training…)
• Physical (failure, poor, old tech…)
• Organizational (faulty, poor)
 Purpose

Reactive • Occurring problem

Analysis • Corrective action

Proactive • Potential problem area

Analysis • For preventing
RCA Activities
Problem • Issue to be
Statement
Definition addressed

• Information
Data about nature,
Collection magnitude,
location, timing

• Patterns of
effects
Cause
identification • How
contributing to
the problem
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 Requirements
Busines
s

Stakeho
Solution Requirement
lder

Transiti
on
 Business Requirement
Business Outcome

Need/Want/Will/Should

Example: To maintain our leadership

Role within the industry => increase
Gross, online sales by 15% in this
fiscal year
 Stakeholder Requirement
I want, you want, we want, they want

How to collect: Interview, Workshop,

Observation, Self-authored

Example: Epic/ User stories

 Solution Requirement
Functional vs Non-functional

Example:
• Lists of functions
• Solution use cases
• Detailed user stories
• List of data elements
 Transition Requirement
Existing Environment to Proposed Solution

Capability requirement

Example:
• Sales personnel must attend the 2-day new
customer acquisition program prior to using
the new Sale Support System
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 Purpose
Verify (thẩm tra, kiểm tra):
• Ensure requirement and the design specification
• Meet quality standards
• Usable

Validate (hiệu lực, phê chuẩn):

• Ensure that the stakeholder, solution, and transition requirement
• Align to the business requirements
• Also validate the designs to ensure the stated requirements
 Verify requirement
Characteristics Verification Checklists
• Atomic • Perform iteratively • Used for quality
• Complete • Verified for: control
• Consistent • Compliance with • Include set of quality
• Concise org. standards elements
• Feasible • Correct usage of
• Unambiguous modelling notations
• Testable and templates
• Consistency
• Prioritized
between models
• Understandable • Terminology is
understandable to
stakeholders
 Validate requirement

01 03
Business Future State
Objective Description

02 04
Potential Value Solution Scope
Business Analysis Documents

Requirement Collection
Requirement Survey, Interview, Observation…

Use case analysis

General Analysis URD/BRD, System Design

SRS
Detail Analysis Data architect

Changes management
Development Testcase, User Acceptance Testing

Manual
Maintenance
 Common Documents
Requirement Collection
General requirement Analysis
Survey
Interview
Detail Requirement Analysis
BRD
Observation URD Testing
SRS
Analyzing Deployment
Interface Technical
Testing
Manual
UAT
Business Analysis Diagrams

General Function Data

• BPMN • Sequence • ERD
• Use Case • State • Dataflow
• Activity machine Diagram
• Class
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 USER STORY
• Product documentation based on users,
customers demand

• Present customers

• Pain points of Customer

 HOW ??
● Gather information and Understand
customer

● Identify: Needs, Drives, Fears, and

Frustrations

● Design products, UI/UX => BACKLOGS

 HOW ??
• User stories ≠ tasks
• Stay high-level
• Understand the users
• Think as a user
• Think big
• Use epics
• Don’t discard — prioritize instead
 STEPS
● Create simple user personas

● Conduct research

● Analyze the data: customer journey

● Define “Done”
 MODEL
• Independent 
• Negotiable
• Valuable 
• Estimable
• Sized appropriately 
• Testable
 BENEFITS
• Stories keep the focus on the user. A To Do list keeps the team
focused on tasks that need checked off, but a collection of stories
keeps the team focused on solving problems for real users.
 
• Stories enable collaboration. With the end goal defined, the team
can work together to decide how best to serve the user and meet
that goal.
 
• Stories drive creative solutions. Stories encourage the team to
think critically and creatively about how to best solve for an end goal.
 
• Stories create momentum. With each passing story the
development team enjoys a small challenges and a small win,
driving momentum.  
USER STORY MAP
USER STORY TEMPLATE
01 Business Case
02 Project Stakeholders
03 Root Cause Analysis
04 Requirement Classification
05 Requirement Verification and
Qualification
06 User Story and Practice
 CASE STUDY
We need to build an app about shipping, what
are the user stories here ???
 FURPS MODEL
This principle helps the BA determine the method of collecting user information as well as sorting and grouping requirements

01 03 05
Functional Reliability Security

02 04
Usability Performance
THANK YOU
Insert the Subtitle of Your Presentation