Business Analysis

Guruprasad R
rgp1981@gmail.com
+91-8971050233
What is Business Analysis?

Business Analysis is the practice of enabling change in an organizational

context, by defining needs and recommending solutions that deliver value
to stakeholders.
What is a Business Analyst? Consultant?

• Someone who practices Business Analysis

• Title is not always present

• BAs could be differentiated on a linear continuum

Offering existing solution vs offering innovative solutions
General solutions Vs Business transformation solutions
(Technology or Business process)
Value of the Business Analyst

Model the
Organization

Realize Understand
Needed
Benefits Capabilities

Avoid Find New

Costs Opportunities
High Level Tasks of a Business Analyst

• Identify problems and opportunities

• Determine and document the requirements

• Define/design the solution that best achieves the requirements

• Implement the solution

• Test the solution to verify the requirements have been met

• Validate the end result achieves the original problem

Types of Business Analyst Roles

• Business Process Analyst

• Requirements Analyst

• Systems Analyst

• Data Analyst

• User Experience Analyst

Types of Business Analyst Roles

• Business Process Analyst • Determines workflow in a

• Requirements Analyst
• Systems Analyst
• Data Analyst
• User Experience Analyst
business process
• Models business processes
• Compares “as-is” and “to-be”
models
Types of Business Analyst Roles
• Business Process Analyst
• Requirements Analyst
• Systems Analyst
• Data Analyst
• User Experience Analyst
• Answer “What” the software should
do?
• Elicits/analyzes requirements
• Bridges the gap between the business
and IT
• Solves problems with information
technology solutions
• Can be involved in functional design
Types of Business Analyst Roles
• Business Process Analyst
• Requirements Analyst
• Systems Analyst
• Data Analyst
• User Experience Analyst
• Elicits/analyzes requirements
• Bridges the gap between the
business and IT
• Solves problems with
information technology
solutions
• Can be involved in functional
design
Types of Business Analyst Roles

• Business Process Analyst • Creates functional

• Requirements Analyst
• Systems Analyst
• Data Analyst
• User Experience Analyst
specifications from
documented requirements
• Defines “how” a system will do
the “what”
• Works with the technical team
Types of Business Analyst Roles

• Business Process Analyst • Performs logical data modeling

• Requirements Analyst • Identifies patterns in data
• Systems Analyst • Designs and creates reports
• Data Analyst
• User Experience Analyst
Types of Business Analyst Roles

• Business Process Analyst • Designs the user interface look

• Requirements Analyst and interaction
• Systems Analyst • Focuses on efficiency and ease
of use
• Data Analyst
• Understands the end-user’s
• User Experience Analyst behavior
Types of Business Analyst Roles

• Business Process Analyst • Designs the user interface look

• Requirements Analyst and interaction
• Systems Analyst • Focuses on efficiency and ease
of use
• Data Analyst
• Understands the end-user’s
• User Experience Analyst behavior
Overview of Requirements
Why Do I Need Requirements?

• Guides the design of the eventual solution

• Without correct requirements, you cannot design or build the
correct product

60% of project failures originate with the requirements

Why Do I Need accurate Requirements?
Categories of Requirements
Solution requirements

Something a product must do or a quality it must have

Business Analysis

Guruprasad R
rgp1981@gmail.com
+91-8971050233
 Categories of Requirements

• Things the product must do

Functional Requirements
• Action the product must take

• Properties or qualities the product must

Non-Functional Requirements have
• How the product will behave

Constraints • Global requirements

• Purpose of the project
• Users of a product
Constraints

• Purpose of the Product – reason for building the product

• Client, Customer, and Stakeholders – people that interact with the product
Eg: Users of the Product – intended end-users and how they affect product usability

• Infrastructure Constraints – limitations of the project and restrictions on

design
• Naming Conventions and Definitions – vocabulary of the product
• Relevant Facts – outside influences that make a difference to this product
 Product Constraint Examples

• The product budget must not exceed $50,000

• The product shall run on the company’s existing machines

• Implementation of the product cannot interrupt daily business

• The last 5 years of historical data needs to be made available in the

product
Functional Requirements

• Scope of the Product – defines the boundaries and connections to

other products

• Functional and Data Requirements – Things the product must do

and data manipulated by the functions
Functional Requirement Examples

• The product must track recipes down the ingredient and quantity level

• The recipes must be editable by an administrator

• The product must display the orders that need to be completed

• The product must display the recipes to make the orders

• The product must track ingredients including their cost, vendors, and quantity in
inventory

• The product must interact with the current Point of Sale system
Non-Functional Requirements

• Look and Feel Requirements – intended appearance

• Usability Requirements – based on the intended users

• Performance Requirements – how fast, big, accurate, safe, reliable, etc.

• Operational Requirements – product’s intended operating environment

• Maintainability and Portability/Scalability Requirements – how changeable

• Security Requirements – security, confidentiality, and integrity of the product

• Legal Requirements – conformance to applicable laws

Non-Functional Requirement Examples

• The product shall use the company colors and logos

• The product shall be intuitive, even to first time users

• The product shall only allow bakers and administrators to view recipes

• The product shall be easily upgraded for future business needs

• The product shall be scalable to multiple bakery locations

Business Rules

• What are Business Rules?

• Business Rules vs Requirements

• Best Practices
Business Rules Explained

Definition:
A business rule is a rule that defines or constrains some aspect
of business and always resolves to either true or false.

Purpose:
Business rules are intended to assert business structure or to control or
influence the behavior of the business.
Business Rules Examples

• Each course must have at least one instructor

• Customers must have a valid driver’s license to rent a vehicle

• A quote must be completed prior to an invoice being generated

Business Rules vs Business Requirements

Rule:
• Each course must have at least one instructor

Possible Requirements:
• Able to create an instructor

• Capability for Dean to assign instructor to course

• Course registration cannot be opened until an instructor is assigned

Business Rules vs Business Requirements

Rule:
• Customers must have a valid driver’s license to rent a vehicle

Possible Requirements:
• Employee to inspect driver’s license (if it is in a database)

• Ability for employee to validate driver’s license

Business Rules vs Business Requirements

Rule:
• A quote must be completed prior to an invoice being generated

Possible Requirements:
• Capability to enter a quote

• Details from quote must automatically flow to the invoice

• Ability to tie the quote and invoices together for reporting

Business Rules Best Practices

• When documenting business rules, keep it simple

• Business requirements are used to comply with business rules

• Each business rule may need multiple requirements

• Business rules should not be changed

• Changes can cause major constraints down the road
Categories of Requirements
Project Stakeholders
 Identifying Stakeholders

• What is a stakeholder?
• Project team members
• Customer
• Suppliers
• Employees/Unions
• Regulators Eg: FDA in Pharma
• Any individual impacted by the project
• Any individual to support the project
Identifying Stakeholders

• Why identify stakeholders?

• It increases the chances for success

• Additional ideas

• Varied perspectives

• Gains buy-in
 Identifying 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 Eg; CEO, CTO, Vice president etc

• Get ideas from stakeholders as you identify them-Brainstorm to identify other

stakeholders
 Stakeholder Map

President
Dough-C-Dough
Vice President
Executive Suppliers Bake Goods R Us
Head of Operations Management

Dough-Licious
System
Cashier
Order Placer
Customers Employees
Baker
Goods Consumer

Shopper

Store Management
Organizational Chart
CEO
Executive
x5555
Homer Owner

Service Manager Sales Manager

Service Dept Sales Dept
x6669 x6666
Lisa Manager Marge Manager

Service Rep Sales Rep

Service Dept Sales Dept
x6670 x6668
Bart Service Apu Sales

Service Rep Sales Rep

Service Dept Sales Dept
x6671 x6667
Maggie Service Ned Sales
Assigning Stakeholders
Responsibilities
 RACI Matrix: Why is it used?

Critical tool to understand and align the

responsibilities of stakeholders.

Alleviates power struggles

Reduces lack of ownership

Sets clear expectations!

 RACI Matrix: R.A.C.I.

Responsible
Accountable
Consulted
Informed
RACI Matrix: An Overview
RACI Matrix: R.A.C.I.

• Who is/will be doing this task?

Responsible
• Who is assigned to work on this task?
Accountable
Consulted
Informed
RACI Matrix: R.A.C.I.

Responsible
• Who’s head will roll if this goes wrong?
Accountable
• Who has the authority to sign off the
Consulted work?
Informed
RACI Matrix: R.A.C.I.

Responsible
Accountable
• Who can tell me more about this task?
Consulted
• Who are the Subject Matter Experts?
Informed
RACI Matrix: R.A.C.I.

Responsible
Accountable
Consulted
• Who’s work depends on this task?
Informed
• Who has to be kept update about the
progress?
RACI Matrix: Breakdown
RACI Matrix: Breakdown
RACI Matrix: Breakdown
 Phases of the Requirements Process

1. Requirement Elicitation

2. Requirement Analysis

3. Requirement Specification

4. Requirements Approval
Sub disciplines of software requirements
engineering
Requirement development process
 Business Analysis-
Requirements Elicitation

Guruprasad R
rgp1981@gmail.com
+91-8971050233
Phases of the Requirements Process

1. Requirement Elicitation
2. Requirement Analysis
3. Requirement Specification
4. Requirements Approval
Questioning

1 Questioning Skill’s

2 Open Ended and Close Ended Questions

Questioning
The answer you get lies in the question you ask!
From the preceding anecdote, what inferences can you draw? Read the
statements below and state whether you agree or disagree with these inferences.

o To question effectively, we must be cautious and never trust a stranger's (or

strange) answers.
o To question effectively, we must question comprehensively, i.e. get the
entire background information before taking any action.
o To question effectively, we must question intelligently and leave no room
for ambiguity or innuendo.
o To question effectively, we must already know the answer. Otherwise, we
may look foolish or be proved wrong.
Check your understanding
What are the characteristics of a good question? Select all the options that
apply.
o A good question is never ambiguous about the issue of aspect being questioned.

o A good question is always based on some assumptions about the person being
questioned.

o A good question always elicits a ‘yes' ‘no’ response.

o A good question is framed such that the person being questioned is clear about
the information required.
Questioning
 Open-Ended Questions - Such questions do not restrict responses to
specifics.

 Close-Ended Questions - Such questions restrict responses to specifics.

Open Ended and Close ended questions
Gain Agreement Gather Background
Information

Present available and Elicit Specific Needs and

relevant alternatives Problems
Open Ended and Close ended questions
Open Ended and Close ended questions
• The types of open-ended and close-ended questions:

 Broad Scoped Open-Ended (BSOE) questions

 Narrow Scoped Open-Ended (NSOE) questions

 Alternative Choice Close-Ended (ACCE) questions

 Single Outcome close-Ended (SOCE) questions

Requirements Elicitation
• Requirements elicitation is perhaps the most challenging, critical, error-
prone, and communication-intensive aspect of software development.

• Numerous elicitation techniques can be employed on software projects.

• Its not interrogation

• Could be facilitated Vs Independent activities.

Interviewing
Interviewing: What is it?

• Systematic discussion to drive out accurate requirements quickly

• Gain understanding of high-level needs, constraints, and assumptions

• Reduces misunderstanding due to cultural differences, lack of openness

• One on one or with a small group

• Can be formal or informal

• See the process or requirements from interviewee’s perspective

Interviewing: Types

• Personal interviews
• Scripted questions – interviewee’s answers are documented
• Exploratory questions to clarify and validate requirements, while removing assumptions
• Job shadowing/Customer site visits
• Walk through a work day with a user or user group observing them
• 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
Interviewing: Best Practices

• Determine the best interview type to accomplish your goals

• Appropriately prepare for the interview

• Match the pace of the interviewee

• If they are cautious, talk slow. If they are in a hurry, talk quickly

• Check understanding often

• One person conducts interview while the other documents the answers.
Always record the interview.
 Interviewing: Best Practices (continued)

• Ask for examples of their issues and document screen shots

• Interview two to three users for each user category you are targeting

• Be sure to interview end-users, not just managers who think they know how the
process/system is used

• Allow time in the schedule to debrief and finish documentation after each
interview
Interviewing: Interview Questions

• Make questions open-ended

• If they could answer the question with a yes or no, reword it

• Avoid questions that may present judgement or a conclusion

• Allow the questions to flow naturally so they can be put into conversation
rather than a survey
Requirement Workshops
 Requirement Workshop: What is it?

• Structured meetings that involve

• End-users
• Subject Matter Experts
• Project Manager
• Business
• IT reps
• Generally is used for projects with multiple business units
• Works to define, clarify, and complete requirements
• Starts at broad level and dives into functions and processes as the workshop moves
forward
Requirement Workshop: Types

• Formal Requirements Workshops

• Highly structured and formal

• Carefully selected group of stakeholders

• Define, create, refine, and reach closure on business requirements

• Business Process Improvement Workshops

• Analyzes existing business processes

• Identify and agree upon solutions implement process improvements

Requirement Workshop: Best Practices

• Determine the type of requirement workshop ahead of time

• Be clear on what the session will deliver

• Utilize modeling tools to visualize the processes and requirements

• Limit the meeting to the key project participants

• Include end-users, subject matter experts, developers, and senior management

• Remember that you are an analyst, not just a scribe/facilitator

Questioning- Scenario
 Broad scoped open ended question’s
Sales Scenario: Brandon, a representative
Brandon needs to get a feel of the business
and his first objective is to elicit background
information. what question should he pose to
Ms Tan?
o Are you looking for faster connectivity or safety of
data transfer over your Intranet?
o Please tell me about the company’s strength and the
kind of Internet connections in use across all the
locations.
o Do you think our product will suit your need?
Broad scoped open ended question’s

3G

•Non-Intrusive, helps elicit background information, do not focus on specifics.

•Starting a conversation.
Narrow scoped open ended question’s (PROBING)

Having obtained background information from Ms Tan, Brandon’s next objective

is to narrow down to specific problem being faced. What question should he use
for this purpose?
o Tell me more about the state of Internet connections used by the
company.
o Are you looking for faster connectivity or safety of data transfer over the
Intranet?
o what is the reason that there are no Internet connections for half the
staff?
o Do you think our product will meet your need?
Narrow scoped open ended question’s

•Extract specific detailed information

•Narrow down the discussion on specific problem area
•Steering a conversation.
Narrow scoped open ended question’s
Alternative choice close ended Qn’s

•Enable the client to choose from option.

•Pre-decided
Single outcome close ended Qn’s

•The last stage where it gets concluded.

•Get the other person to agree or disagree with you.
Summary-Asking Questions
1. Asking questions establishes a two-way communication channel
between people.

2. To keep the communication channel open and arrive at the desired

answer, it is necessary to ask the right question.

3. To ask a correct question, you must keep the situation, the context
and the intent in mind.

4. Incorrect questioning may result in blocked, missed or distorted

communication.