Business Analysis - Essentials

Barbara Bermes

Fundamentals of BUSINESS ANALYSISGlobal Knowledge, March 2011

Thursday, February 16, 2012

Overview

✤ Role of a BA - Solving “the problem”

✤ Business Analysis as part of a Project

✤ Eclication (Techniques)

✤ Stakeholders and Stakeholders Profiles

✤ 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

✤ To suggest a solution of the problem

✤ To meet the business needs related to the problem

✤ Bridge between the business and the stakeholders

✤ Need to understand all aspects of the solution

✤ How things are (as-is) and how they should be (to-be)

✤ Represent users to development team

✤ 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

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

System Analyst Technical solution Specifications


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, specification 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

✤ Business Analyst

✤ Project Manager

✤ Customer

✤ End User

✤ Domain SME

✤ Implementation SME

✤ Tester

✤ Regulator

✤ Supplier


Stakeholder Profiles

✤ Demographics

✤ Role and responsibilities

✤ Solutions attitude

✤ Number

✤ Location

✤ Special needs

✤ Name and Title

✤ Solution influence

✤ 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/AdvantageInterview need general information about requirements, want

stakeholders to explain their needs, conflicting req.

Focus Group want to gauge users’ attitude and preferences towards solution or current situation

Requirements Workshop Need requirment consensus on noncontroversial issues, want to generate ideas, review requirments

Brainstorming creative, innovative solutions (large number of solutions)

Observation Need to learn about user’s environment, need to understand workflow, need information that user can’t provide fully

Survey Only short time, have a lot of remote users to contact, need statistical and survey writing abilities

Prototyping Identify usability issues, concrete representation of the proposed solution to elicit feedback

Product Trials see how competitors solve the problem, see if COTS (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 simplification of reality developed to convey information to a specific 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, flow, 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 RequirementsDescribe 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 RequirementsDescribe the behavior or capabilities of the component of the solution

✤ Transition RequirementsDescribe 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

✤ Verification

✤ Validation

✤ Sign-Off


Why Documentation

✤ Stakeholders need to see a clear set of requirements which they can affirm 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

✓ CohesiveRequirements about a particular feature should be grouped together

✓ ConsistentRequirements 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

✓ ModularRequirements 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

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

Requirements not clearly differentiated from other information

Features are added into product that should not be there

Importance of each requirement is not documented

Tester concentrates on the wrong requirements

Requirements not numbered Review of requirements is wrong


Tips for writing BRD

✓ Use simple language

✓ Visual methods

✓ Use “shall”

✓ Importance ratings

✓ Unique identifiers

✓ 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

✤ Verification 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 conflicts, 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 defined, 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 identifier

✤ Source

✤ Priority

✤ Rationale


Requirements Communication

✤ Goal is

✤ to find 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

✤ Notifications of requirement changes: Even if a stakeholder does not have to approve the change, he or she should always be notified 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

Uncovering solution defects

Proving compliance to the

requirements+ = Validation

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


The Art of Testing

Performing the smallest number of tests

Finding the greatest number of defects


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

✤ Define 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

Technology

Transcript of Business Analysis - Essentials