BUSINESS

ANALYSIS
FOUNDATION
Lecture 3 – Business Analysis Process
01 Business Analysis Process
02 Factors to notice
03 Requirement collection
techniques
04 Practice
01 Business Analysis Process
02 Factors to notice
03 Requirement collection
techniques
04 Practice
 Analysis Activities

Flow of interaction between user and

system
05 Evaluate

04 Develop
User-
Interface User involvement, feedback, adapt to
Modeling functional requirements and
non-functional requirements 03 Prioritize
Dialogs changes

Requirement
02 Define
Requirement Essential, important, vs. nice to have
01 Gather
Detailed
Information
Interviews, questionnaires, documents,
observing business processes,
researching vendors, comments and
suggestion
Requirement
Process
REQUIREMENT PROCESS
Elicitation

Approval
Requirement Analysis
Process

Specification
Requirement
Process
Requirement Elicitation
 Requirement Elicitation
Brainstorming: What is it?
Solve problems
Create consensus

Generate ideas
 HOW ?

Elicitate requirements
 Interviewing
 Survey
 Document review
 Analyzing Interface/ Observation
Requirement
Process
Requirement Analysis
 What Are Requirement?

A thing that is needed or wanted

Problems from the user side: Issues from the developer:

• Users don't understand what they want • User and developer language mismatch
• Users are constantly changing requirements even when• The developer tries to drive the user's request into an
product development has been started existing system or model instead of developing a
• User does not understand the technique system according to customer needs.
• Users do not understand the development process • The analysis can be done by programmers instead of
analytical skills staff to be able to understand customer
needs properly.
 Requirements
• System Requirements
 Functional requirements
 Non-functional requirements

• Functional Requirements – the activities the system must perform

 Business uses, functions the users carry out
• Non-Functional Requirements – other system characteristics
 Constraints and performance goals
 FURPS MODEL
This principle helps the BA determine the method of collecting user information as well as sorting and grouping requirements

Availability
Testability
Predictable
Flexibility
Accuracy
Install
Failure

01 03 05
Functional Reliability Supportability

Capability
Reusability
Security 02 04
Usability Performance

Human factor Speed

Consistency Efficiency
Documentation Scalability
Responsiveness
 Additional Requirement Categories
• Design constraints –
 Specific restrictions for hardware and software
• Implementation requirements
 Specific languages, tools, protocols, etc.
• Interface requirements
 Interface links to other systems
• Physical requirements
 Physical facilities and equipment constraints
• Supportability requirements
 Automatic updates and enhancement methods
 Requirement Analysis
What is Visual Modeling

Graphical representation using a modeling

language that takes something complex and
makes it easier to understand.
 Benefits of Visual Modelling
• Easily understand complex information
• Gets all stakeholders involved
• Receive requirements efficiently
• Identify the underlying problem
• Analyze ‘what if’ scenarios
• Allows remove of irrelevant information
 Example
Organizational Chart
 Example
Competitive Comparison Matrix
 Example
Stakeholder Map
 Example
Use Case Diagram
 Example
Process flow/ Activity diagram
 Example
User Interface Wireframe
Requirement
Process
Requirement Specification
 Requirement Specification
• Categories Requirements
• Deriving Requirements
• Parsing Requirements
• Interpreting Requirements
• Focusing Requirements
• Qualifying Requirements
 Prioritization Factors
• Value to the business
• Value to the customer
• Minimize cost to develop
• Time to implement
• Ease of technical implementation
• Ease of business implementation
• Obligation to some external authority
 OUTPUT
• Business Requirement Documents
• User Requirement Documents

• Review BRD Template

Requirement
Process
Requirement Approval
 Business Approval: Schedule
• Schedule multiple review sessions
• Separate business units
• Never exceed four hours per session
• Involve Subject Matter Experts (SME)
• Keep it relevant to the audience
• Create meeting agenda
 Business Approval: Schedule
Business Team Approval
Technical Team Approval
Project Sponsor / Committee Approval
 Business Approval: Conduct
1. Explain the purpose of the meeting and the agenda
2. Review project and objective
3. Go over each requirement
4. Address questions and concerns immediately
5. Change and update requirements
6. Table all new requirements unless deemed critical
01 Business Analysis Process
02 Factors to notice
03 Requirement collection
techniques
04 Practice
What makes a Good requirement?
Understandable
Allocatable Measurable
Correct
Necessary
Testable
Design-independent Attainable

Unambiguous Concise Modifiable

Consistent
Feasible

Complete Prioritized
Organized
Traceable
SMART MODEL
Specific

Measurable

Attainable

Reasonable

Traceable
 TIPS
• Should use the word shall
• Only one shall per requirement
• Written in short, simple sentences
• Consistent terminology
• Stated positively
• Accompanied by notes and comments to support and clarify
• Stated imperatively
• Don’t use will and should
01 Business Analysis Process
02 Factors to notice
03 Requirement collection
techniques
04 Practice
 TECHNIQUES
Interview

Analyzing
Interface Techniques Survey

Documentation
Review
 INTERVIEWING
• Personal interviews
• Scripted questions – interviewee’s answers are documented
• Exploratory questions to clarify and validate requirements, while removing assumptions
• Job shadowing
• Walk through a work day with a user or user group observing them
• Customer site visits
• Understand operational environment to discover prerequisites for job success
• Task analysis
• Ask end-users to walk through their current jobs
• Show as-is process in order to identify essential and frequent tasks
• Interviewer asks questions to understand what works well and what doesn’t
 SURVEY
• Open-ended questions
• Gives respondents an opportunity to answer in their own words
• Useful, but very time consuming to interpret and catalogue
• Closed-ended questions
• Finite set of answers for each question
• Lends itself to statistical analysis
• Tough to create questions that are not leading or need an “Other” answer
• Questions can vary
• Ranking from “not very important” to “extremely important”
• Ranking from “strongly disagree” to “strongly agree”
• Rank order a list of items
• Multiple choice question
 Document Review

• Review existing documentation

• User guides
• Prior system implementation documentation, including lessons learned
• Technical documentation
• Lessons learned after completion of latest project
• Formulates context for understanding the scope of the project
 Analyzing interface

• Customer review meetings

• Identify formal requirements to link information, people, and processes
• Drives a robust, complete, and accurate solution
• Developer review meetings
• Happen early on
• Review high-level requirements and system models
• Identify interfaces, regulations, or technical standards
01 Business Analysis Process
02 Factors to notice
03 Requirement collection
techniques
04 Practice
 CASE STUDY
Vietnamese Government want to launch the Corona Health Record project.

Practice to collect requirements from stakeholders:

Hints:
1. What is the requirements of the project
2. Function and Non – function
3. Needs and Demand
4. Others
THANK YOU
Insert the Subtitle of Your Presentation