Business Analysis - Essentials

Fundamentals of
BUSINESS ANALYSIS
Global Knowledge, March 2011

Barbara Bermes

Thursday, February 16, 2012

Overview

✤ Role of a BA - Solving “the problem”

✤ Business Analysis as part of a Project

✤ Eclication (Techniques)

✤ Stakeholders and Stakeholders Proﬁles

✤ Vision and Scope Document

✤ Business Needs & Business Requirements

✤ BRD - Business Requirements Document

✤ Business Plan

✤ How to apply all of this to CBC


Before we start...

✤ Have you ever worked on a project that was understood like this....


A project: from concept to delivery


CHAOS Report

✤ Common Reasons for Project Failure

✤ Incomplete requirements

✤ Changing requirements

✤ A requirement is something that a particular solution (product or service)
must have to ensure success


So why do we need BAs?

✤ To help identify the problem ✤ Need to understand all aspects
of the solution
✤ To suggest a solution of the
problem ✤ How things are (as-is) and how
they should be (to-be)
✤ To meet the business needs
related to the problem ✤ Represent users to development
team
✤ Bridge between the business and
the stakeholders ✤ Filter wishes from actual
requirements


The Definition of Business Analysis

✤ “Business analysis is the set of tasks and techniques used to
work as a liaison among stakeholders in order to understand
the structure, policies, and operations of an organization,
and to recommend solutions that enable the organization to
achieve its goals”
(The BABOK Guide, Business Analysis Body of
Knowlegde)

BA, PM, SA

Role Primary Focus Example

Project Manager Project Budget, schedule

Value business results,
Business Analyst Business needs product/service provided

System Analyst Technical solution Speciﬁcations


Knowledge Areas of a BA


BA Tasks
✤ Vision and Scope Document

✤ Planning requirement activities

✤ Requirements Elicitation

✤ Analyzing requirements

✤ Documenting requirements

✤ Verifying and Validation requirements

✤ Final testing of the solution

✤ Find solution to meet organizational goals


Definition of Requirement

1. A condition or capability needed by a stakeholder to solve a problem or
achieve an objective

2. A condition or capability that must be met or possessed by a solution or
solution component to satisfy a contract, standard, speciﬁcation or other
formally imposed documents

3. A documented presentation of a condition or capability as in (1) or (2)

- The BABOK Guide


Requirements Planning:
Vision and Scope Document

✤ Current state and desired state from the business perspective

✤ In-scope and out-of-scope solution features

✤ Puts the solution in the business context


Requirements Planning:
Vision and Scope Document

✤ Background: Need for solution

✤ Users and Stakeholders

✤ Vision Statement: How stakeholders envision the solution, purpose and intent

✤ In/Out Scope Features

✤ Assumptions, add some degree of risks

✤ Constraints

✤ Risks, Business, Financial, Technical, including Risk Mitigation, contingency


Stakeholders

✤ Sponsor ✤ Domain SME

✤ Business Analyst ✤ Implementation SME

✤ Project Manager ✤ Tester

✤ Customer ✤ Regulator

✤ End User ✤ Supplier


Stakeholder Profiles

✤ Demographics
✤ Location

✤ Role and responsibilities
✤ Special needs

✤ Solutions attitude
✤ Name and Title

✤ Number
✤ Solution inﬂuence

✤ Authority


Requirements Elicitation

✤ Elicitation is not requirements gathering (implies that requirements
already exist)

✤ Merriam-Webster Online Dictionary, elicitation means:

✤ To draw forth or bring out (something latent or potential)

✤ To call forth or draw out (as information or a response)


Elicitation Techniques

Preplanning Preparation

Closing Execution


Peoples Techniques

✤ People techniques are used when your resource for requirements is a
person

✤ Each person poses different challenges


Techniques

Technique When/Advantage
need general information about requirements, want
Interview stakeholders to explain their needs, conﬂicting req.
want to gauge users’ attitude and preferences
Focus Group towards solution or current situation
Need requirment consensus on noncontroversial
Requirements Workshop issues, want to generate ideas, review requirments
creative, innovative solutions (large number of
Brainstorming solutions)
Need to learn about user’s environment, need to understand
Observation workﬂow, need information that user can’t provide fully

Only short time, have a lot of remote users to
Survey contact, need statistical and survey writing abilities
Identify usability issues, concrete representation of
Prototyping the proposed solution to elicit feedback
see how competitors solve the problem, see if COTS
Product Trials (commercial off-the-shelf) product might be the solution


Select Techniques

✤ Always consider these three factors

✤ Stakeholders

✤ Requirement type

✤ Product geography


Using Models for Analysis

✤ Model: A representation and simpliﬁcation of reality
developed to convey information to a speciﬁc
audience to support analysis, communication and
understanding (The BABOK Guide)


Models/Diagrams

✤ Organizational Model: to show stakeholders connections, roles, help to
understand the scope of the organization

✤ Location Model: show geographical locations and facilities

✤ Process Model: show business process,

✤ Visual presentation of the order, ﬂow, and logic that controls a set of activities or actions,

✤ Excellent to show as-is and to-be state


Models

✤ Use Case Model: describes a system’s behavior as it responds to the
request that originates from outside of that system

✤ Can easily be understood

✤ Identify possible mistakes

✤ CRUD (Create-Read-Update-Delete) Matrix: describes users permissions
to manipulate the data


Models

✤ Data Model/ERD Diagram: describe the information needs of the business
area, data is clustered around the concept of a real-world object or event

✤ State Diagram: show how and why a data item, or a system, changes state,
sued to identify missing requirements related to business rules, events,
data attributes, use cases, and procedural steps


Types of Requirements

✤ Business Requirements
Describe the reasons a project is started, its objectives, and its success measures in
terms of the organization as a whole

✤ Stakeholder Requirements
Capture and describe requirements of a particular stakeholder or stakeholder
group

✤ Solution Requirements
Describe the behavior or capabilities of the component of the solution

✤ Transition Requirements
Describe the capabilities that the solution must process in order to assist the
change from current state to the desired future state of the enterprise


Prioritization of Requirements

✤ Consents/Agreements with stakeholders what requirements are high-
priority / low-priority in order to proceed/succeed with the solution

✤ Make sure requirements are accurate with stakeholders


Requirements Documentation

✤ Business Requirements Document

✤ Veriﬁcation

✤ Validation

✤ Sign-Off


Why Documentation

✤ Stakeholders need to see a clear set of requirements which they can afﬁrm
their needs to, evaluate the end solution

✤ Development Team needs clear set of requirements,

✤ Alleviate Risks

✤ Stakeholders can give feedback and to reduce risks


How to document

✓ Cohesive
Requirements about a particular feature should be grouped together

✓ Consistent
Requirements should not be duplicated, nor should they contradict each other.
The level of detail should also be consistent. The terminology should be consistent
with the language used in the organization

✓ Modular
Requirements should be presented in such a way that changes can be made easily
without affecting other unrelated requirements

✓ Unambiguous
Requirements should mean the thing to anyone who reads them


Common BRD Defects

BRD Defects Effects

Reviewers miss other defects;
Information hard to ﬁnd or unclear
developer does not follow requirements

Requirements not clearly differentiated Features are added into product that
from other information should not be there

Importance of each requirement is not Tester concentrates on the wrong
documented requirements

Requirements not numbered Review of requirements is wrong


Tips for writing BRD

✓ Use simple language

✓ Visual methods

✓ Use “shall”

✓ Importance ratings

✓ Unique identiﬁers

✓ Rational


Time Boxing

✤ Time Management Technique that divides the schedule into a number of
separate time periods/boxes where each box has its own deliverables,
deadline and budget


Verification

✤ Veriﬁcation of requirements, must be

✤ Consistent

✤ Complete

✤ Correct

✤ Feasible

✤ Validable


Validation

✤ Ensure that the requirement supports the business goals and objectives
meet the business needs

✤ Rule: If requirement cannot be validated as business need, it should be
eliminated


Verification and Validation
Techniques

✤ DESK CHECKING, individually go to desks and talk to stakeholders, time
intensive

✤ WALKTHROUGH, efficient method of finding defects, normally with a
group of people

✤ PEER REVIEW, walkthrough of group of people with same level to find
defects


Requirements Sign-Off

✤ Sometimes called Requirements Gate

✤ Releases the funds for the project

✤ Make sure stakeholder / sponsor actually read the document


Requirements Management and
Communication

✤ Happens throughout the whole life cycle

✤ Everyone should always have the same understanding of the solution
scope

✤ BAs manage conﬂicts, issues and changes


Change Control Process / Request
✤ Receive solution change request

✤ Determine impact of not implementing change

✤ Determine impact of implementing change

✤ Make decision

✤ Communicate actions to be taken

✤ Check if actions have been taken

✤ Changed need to be aligned with projects vision and scope

✤ Change needs approval


Change Requests - Steps

✤ Change request (CR) needs to be deﬁned, its impact , should be numbered
and tracked

✤ CR will be received by anyone who might be affected

✤ Change Authority (CA) meets with everyone who is affected by the
change

✤ CA makes the decision. The CA can be a PM, sponsor or Change Control
Board (CCB)


Requirement Attributes

✤ Gives additional information about requirement

✤ Unique identiﬁer

✤ Source

✤ Priority

✤ Rationale


Requirements Communication

✤ Goal is

✤ to ﬁnd the best way of communication with each stakeholder

✤ to make all stakeholders understand the requirements

✤ to make all stakeholders understand the BRD


Ways of Communication

✤ Emails

✤ Workshops

✤ Formal presentations, using slides and handouts

✤ Reports

✤ Memos

✤ Meetings, formal / informal

✤ Walkthroughs


Requirements Documentation

✤ Requirements activity status: Status reports include wether or not
deadlines are being met or if the schedule has changed

✤ Requests for requirement feedback and approval: Ask for feedback or
approval during requirements elicitation and when a requirement change
is requested

✤ Notiﬁcations of requirement changes: Even if a stakeholder does not have
to approve the change, he or she should always be notiﬁed of any changes
to the original requirements baseline


Solution Validation and Acceptance

✤ Assessments performed during solution validation include both

✤ Testing: solutions is run using defined inputs in a defined enviornment
with defined expected outputs

✤ Non-testing methods: Calculating, Simulating, Prototyping, Analyzing,
Reading documents, obtaining user feedback


Purpose of Validation

Proving
Uncovering
solution defects + compliance to the
requirements
= Validation

GOAL is to identify as many defects in the solution as possible


The Art of Testing

Finding the greatest number
of defects

Performing the smallest
number of tests


Levels of Testing

✤ Unit Testing: conducted by software developers

✤ Integration Testing: conducted by developers, QA

✤ System Testing: conducted

✤ Business-level testing/acceptance testing: solution tested against the BRD
requirements, followed by sign-off, managed by BA

✤ Stakeholder assessment: conducted after system has been deployed


Role of BA during Testing

✤ The BA is responsible for providing assurance to the PM and the customer
that all of the solution testing is adequate


Solution Acceptance and Closeout

✤ Sponsor is completely in charge of selecting the evidence he or she feels
provides the requisite comfort needed to accept and use the solution
within the scope of the requirements

✤ Once the solution is accepted, the ownership passes from project team to
sponsor and the project is considered completed


Enterprise Analysis

✤ Normally executed/done by Senior BAs or Business Architects

✤ Deﬁne the business need


Enterprise Analysis - Business
need

✤ Basis of the business analysis activities related to determining a solution

✤ Clearly defining the problem to find the solution

✤ Ask questions: Who? What? When? Where? Why? and How?

✤ Includes Root cause Analysis as the identification and evaluation of the
reason for the problem


Business Analysis - Essentials

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Business Analysis - Essentials

Similar a Business Analysis - Essentials (20)

Más de Barbara Bermes

Más de Barbara Bermes (11)

Último

Último (20)

Business Analysis - Essentials