Business Analysis & Modeling

By:
Pallavi J. Bhojak
 Business Analysis & Modeling
• What is Business Analysis?
• Business Analyst Role in a Project

Communication
Expert

Interface – Interface –
End Users Development Team

Interface-
Customer
 Business Analysis & Modeling
BA Role in SDLC

Requirements Gathering

Design

Coding

Unit Testing

Integration Testing

System Testing

Deployment

Strengthened Quality with BA Induction in Development

Cycle
 Business Analysis & Modeling

• Framing the Business Problem

• Identification of need
 Typical questions for Project Sponsor & End Users
 Segregation of Critical & Nice to have features
• System Concepts Documentation
• Feasibility Study
 Business Analysis & Modeling
• Solution Vision & Scope
 What are the Scope and Vision of a Project?
 A Project’s Scope defines the broad parameters of the project.
 A Project’s Vision is the desired state or ultimate condition that
the project is working to achieve.

 Why Is Defining a Scope and Vision important?

 Scope & Vision provide the foundation for all subsequent steps in
project or programme cycle.
 A clear Scope sets the rough boundaries for what the project will
attempt to do.
 The Scope makes it clear what the team is focusing on and where
the final outcomes will be measured
 Vision enables the core project team members to discuss and
agree on what the broad purpose of their project will be.
Solution Vision & Scope
Business
Requirements

Vision & Scope Document

User
Requirements

Quality Attributes
Use Cases

Other Non
Functional Functional
Requirements Requirements

Software Requirements
Specifications (SRS)
 Business Analysis & Modeling
• Vision vs. Scope
 Product Vision – A long term strategic concept of the ultimate
purpose and form a new system
 Project Scope – The portion of the ultimate product vision that the
current project will address. The Scope draws the line boundary what
is in and what is out of the current project

ProductVision
Product Vision

ProductScope
Product Scopefor
for ProductScope
Product Scopefor
for ProductScope
Product Scopefor
for
release1.0
release 1.0 release1.1
release 1.1 releaseNN
release
 Business Analysis & Modeling
• Project Priorities
 To enable effective decision making, stakeholders should agree on the
project priorities
 5 Dimensions of a software project

Feature
Quality
s
(Scope)

Schedule Staff

Cost
 Business Analysis & Modeling
• Those must be classified into one of the following categories
 Constraint – a limiting factor within which the project manager must
operate
 Driver – a significant success objective with limited flexibility for
adjustment
 Degree of freedom – a factor that the project manager has some
latitude to adjust and balance against the other dimensions
 Vision & Scope Document
• Business Requirements • Scope and Limitations
 Background  Scope of Initial Release
 Business Opportunity  Scope of Subsequent
 Business Objectives & Releases
Success Criteria  Limitations & Exclusions
 Customer or Market needs
 Business Risks

 Vision of the Solution  Business Context

 Vision Statement  Stakeholder Profiles
 Major Features  Project Priorities
 Assumptions and  Operating Environment
Dependencies
 Return on Investment (ROI)
• Assess the ROI potential
 Breadth – How many people will be helped by the application ?
The greater the number of people, the greater the potential ROI.
 Repeatability – How often will people use the application ? The
more often an application is used, the greater the ROI

The Objective should be to maximize benefit rather

then minimize the cost
 Return on Investment (ROI)
• Secondary factors to consider include:
 Cost – The more costly the task, the greater the benefit from
automation or appropriate technology support
 Knowledge – The greater potential to re-use the information in the
system, the greater the potential ROI
 Collaboration – Communication between employees is costly, so the
greater the collaboration component, the greater the potential ROI

Financial measurements should only be compared to other

internal decisions – not other companies Financial measurements
 Business Analysis & Modeling
• Net Benefits (expressed in currency)
 Incremental Value Generated
 Productivity gained
 Expenses Saved
 Redeployment of Resources
 Hire new resources to perform the task
• Net Costs (expressed in currency)
 Recruiting
 Salaries & Benefits
 Software Licensing & Maintenance
 General & Administrative Overheads
 Training and Education
 Hardware Costs
 Business Analysis & Modeling
• Determining the costs
• Acquisition Costs
Hardware, Software, Management, Support,
Development & Communications
• Management Costs
Budget & Resource expenses, administrative and office
costs
• Intangible Costs
Unplanned Costs, Downtime, User Costs & Miscellaneous
Costs
 Business Analysis & Modeling
• Steps to Calculate the Costs
 Determine period of analysis
 Collect all the relevant financial, resources and costs data
 Identify potential issues and make educated guesses and
action items
 Understand change control by doing WHAT IF analysis
 Set a process of accounting for ongoing costs, maintenance
and support cost management
 Use the numbers to determine the costs
 Business Analysis & Modeling
• Analysis detecting feasibility
 Economic Analysis
 Cost Benefit Analysis
 Technical Analysis
 Legal Analysis
 Alternative Solutions
 Business Analysis & Modeling
• Root Cause Analysis
 Define Problem / Collect Data
 Criteria for Well defined problem
 It focuses on the gap between what is and what should be reflects a
change or deviation from the requirement, norm, standard or
expectation.
 It states the effect. It states what is wrong, not why it is wrong.
 It is measurable. It says how often, how much, when. It avoids broad
and ambiguous categories like ‘morale’, ‘productivity’
&’communication’
 It is stated in positive manner and describes the pain
 It avoids “lack of” and “no” statements
 It highlights the significance of effects
 Business Analysis & Modeling
Collecting the Information

• Sources of Information
Direct Observation
Documentation
Interviews
 Business Analysis & Modeling
• Prototyping

Identify whether S/W is good candidate

for Prototyping
Need to develop an abbreviated
representation of requirements
Create abbreviated design specification
for the prototype
Develop Prototype S/W, test and refine
it
Present it to customer
Finalize the Prototype
Why requirements necessary?
• Unmet expectations

• Effectiveness (meeting stakeholder’s

expectations) & efficiency (time, cost & human
resource) are developed
• The need: Requirements errors are the most expensive
to fix when found during production but cheapest to fix
early in development.
Key benefits of good requirements processes

Improved system quality and customer satisfaction

Easing compliance with standards and regulations
Reduced project cost and delay
Better control of complex projects
Improved team communication
Documentation: Business on paper
 Well-documented user requirements are useful
information for many groups: designers, testers, user
manual writers, management and marketing personnel.
 Systematic user requirement documentation at the
beginning of the product development saves time and
decreases rework in later phases of the project.
Types of documents
• BRD: represent high-level objectives of the organization
or the customer requesting the system
• FRD: specify the functionality the developers must build
into the product to enable users to accomplish their
tasks, thereby satisfying the business requirements
• Project plans: for deciding the phases of development
of Project as per client
• Use –Case approach
Functional Requirements are then developed based on the
use cases
A use case describes a sequence of interactions between a
system and an external actor(s)
An actor is a person, another software system, or a hardware
device that interacts with the system to achieve a useful goal.
Type of actors do not correspond to user classes. They
rather represent the roles, which a user can play
 Business Analysis & Modeling
Business Features
Requirements
Business
Rules

Vision & Scope

Document

User
Requirements

Quality Constraints
Use Cases Attributes

External
System Functional Interfaces
Requirements Requirements

Software Requirements
Specifications (SRS)
Software Engineering process models
• Requirements in Agile SE
Agile approaches
People – Oriented rather than process –
Oriented
Adaptive rather than predictive
Stakeholders are involved throughout the
project, not only in the beginning and in the
end of the project

This changes the Scope RE, however does not

remove the need for RE as such
Probably, no defined RE process then.
• Correctness and Necessity
• Correctness
Each requirement must accurately describe the
functionality to be build and correspond well to
the intentions of the stakeholder who is the
source of that requirement

• Necessity
Each requirement should document a capability
that the customers really need or one that is
required for conformance to an external system
requirement or a standard
• Sign Off
Freezing requirements is unwise and unrealistic,
changes are inevitable.
Signing off the requirements document by the
customer means that a baseline of requirements
agreement has been established. It does not mean
that requirements have been finalized
The subtext of a signature on a requirements
specification sign-off page should read something like
(Wiegers, 2003):
“I agree that this document represents our best understanding of the requirements
for this project today. I agree to make future changes in this baseline through
the project’s defined change process. I realize that approved changes might
require us to renegotiate cost, resource, and schedule commitments for this
project.”
Business Analysis & Modeling
 Validation vs. verification

Validation – “Am I building the right product?” checking a work

product against higher-level work products or authorities that
frame this particular product.
- Requirements are validated by stakeholders

Verification – “ Am I building the product right?” checking a

work product against some standards and conditions imposed
on this type of product and the process of its development
- Requirements are verified by the analysts mainly
• Main issue in validation
While elicitation and analysis are attempts to cross the
boundary from the domain world to the machine
world, validation is an attempt to cross the same
boundary in the opposite direction
The difficulty of the former is well acknowledged, and
the latter can almost as difficult
Main problem is achieving a sufficient level of
understanding of the stated requirements by a
particular stakeholder, which may be hindered by:
 Lack of technical expertise
 Lack of some special domain knowledge (domain of
another stakeholder)
Requirements change factors
• Requirements errors, conflicts and inconsistencies
As the system development proceeds, some errors and
inconsistencies may be discovered that were not
revealed earlier (in validation) and must be corrected

• Evolving customer/end-user knowledge of the system

Customers and end-users may develop a better
understanding of what they really require from a system

• Technical, schedule or cost problems

Problems may be encountered in implementing a
requirement. It may be too expensive or take too long to
implement certain requirements
• Requirements change factors
Changing Customer priorities
Customer priorities change during system
development as a result of a changing business
environment, the emergence of new competitors, staff
changes, etc.

Environmental changes
The environment in which the system is to be
installed may change so that the system requirements
have to change to maintain compatibility

Organizational changes
The organization which intends to use the system
may change its structure and processes resulting in
new system requirements
 Brief up: After (BRD)

Training / Functional Inputs to Development team

Training / Functional Inputs to QA team
Value addition during ongoing development work
Perform Integration testing
Interfacing with the client for clarifications during ongoing
development work
Try to achieve early buy in from the customer
Conduct User training & UAT
Thank You 