Foundations of Business Analysis

Module 1 - Introduction

1
 A Walk through the course outline

2 2
 Welcome
 Introductions
 Outline of the Course Content
– Week 1 – Introduction to Business Analysis
– Week 2 - BA – Underlying Competencies
– Week 3 – BA – Strategic / Fact Finding /
Information Knowledge Techniques
– Week 4 – BA – Process Knowledge / Solution
Knowledge Techniques
– Week 5 – Enterprise Analysis
– Week 6 – Mid Term Examination
3 3
 Welcome

 Outline of the Course Content (cont’d)

– Week 7 – BA Planning & Monitoring
– Week 8 - Requirements Elicitation
– Week 9 – Requirements Analysis
– Week 10 – Requirements Mgmt.& Communication
– Week 11– Solution Assessment & Validation
– Week 12 - Final Examination

4 4
Case Study Work Due Week 8

 Teams of 5-6
 Create a BA requirements and
communication plan for small start up
business

5 5
 BA Tools & Techniques
 Focus Groups  Document Analysis
 Interviews  Business Rules
 Observation  Functional Decomposition
 Requirement Workshops  Interface Analysis
 Root Cause Analysis  Process Modeling
 Structured Walkthrough  Scenarios & Use Cases
 Surveys/Questionnaires  Sequence & State Diagrams
 User Stories

Strategic Information Process Solution

Strategic Fact Information Process Solution
Analysis FactFinding
Finding Knowledge Knowledge Knowledge
Analysis Knowledge Knowledge Knowledge

 Benchmarking  Acceptance Criteria

 Brainstorming  Data
Dictionary/Glossary  Estimating
 Decision Analysis  Lessons Learned Process
 SWOT Analysis  Data Flow Diagram
 Data Modeling  Metrics & KPIs
 Organization Modeling  Non-functional Requirements
 Problem Tracking
 Prototyping
 Risk Analysis
 Scope Modeling
 Vendor Assessment

6 6
 Discussion Board Assignment
 Identify subject, and lead a discussion forum
with 4-5 others

7 7
 Introduction to Business Analysis

Learning Outcomes:
1. What is a Business Analysis?
2. The Business Analyst’s responsibilities
3. How does the BA relate to the PM?

8 8
 Business Analysts –
Why are they growing in importance?
 Delivery of business solutions in an orderly, cost
effective manner NEEDS trained Business Analysts
to succeed
– Cost overruns, poor performance of business solutions are
usually caused by poorly understood and loosely managed
requirements
– With outsourcing there is a greater need to effectively
document requirements that are universally understood
– The formation of the BABOK is proof that the profession
has come into its own

9 9
What is a Business Analyst?
 BA’s come with many titles….

Systems Requirements
Analyst Engineer

Business Systems Business

Analyst Architect

Process Analyst
Enterprise
Product Mgr. Analyst

10 10
Where do they fit?
 BA’s act as a bridge between the business
and the delivery team to ensure usability of
the product
Quality
Assurance
Domain
SME’s Project
Business
Manager
Analyst

Testing
Group Information
Architect

11 11
What does a BA do?
 Works within the business domain (the business
area undergoing analysis) to produce solutions
(create capability for the business) from business
requirements within the constraints of time, cost and
regulations
 The goals of the Organization are sometimes
documented in a Business Case – The BA must
transform those goals into detailed requirements

Wait a minute doesn’t that sound like what a project

management does?

12 12
 The Big Picture

Time Cost
Quality

Scope / Performance

13 13
 What does a BA do?
The Big Difference:

 The Business Analyst elicits, analyzes,

validates and documents requirements
 The Business Analyst focuses on the solution
(Product or Service) to ensure that it meets
the needs of the organization

14 14
 What is Business Analysis?
The set of tasks, knowledge, & techniques required to identify business needs
& determine solutions to business problems. Solutions often include a systems
development component, but may also consist of process improvement or
organizational change.

15 Source: Business Analysis Body of Knowledge ® 15

 How does the BA relate to the PM?
 Throughout the life cycle of a project the
Business Analyst and the Project Manager
will work closely to deliver the project under
the constraints of time and cost. The Project
Manager will rely heavily on the Business
Analyst in relation to the scope
(Requirements) of the project since the
Business Analyst must ensure that the
stakeholders of the solution are satisfied

16 16
 Comparison of Certifications
Project Manager
 PMI – Proj. Mgmt. Inst.
 PMP + CAPM
designation
 Thousands of PMP’s
 PMBoK version 4
 Experience Req’d
 Professional Dev. Req’d
 Certification Exam
 Maintain standing
17
Business Analyst
 IIBA – Intl. Inst. of Business
Analysis
 CBAP designation
 Hundreds of CBAP’s
 BABoK version 2
 Experience Req’d
 Professional Dev. Req’d
 Certification Exam
 Maintain standing
17
 Comparison of Knowledge Topics
Project Manager Business Analyst
 Integration Mgmt  BA Planning + Monitoring
 Scope Mgmt  Elicitation
 Time Mgmt  Req. Mgmt. + Comm.
 Cost Mgmt  Enterprise Analysis
 Quality Mgmt  Requirements Analysis
 Human Res. Mgmt  Solution Assessment +
 Communications Mgmt Validation
 Risk Mgmt  Underlying Competencies
 Procurement Mgmt  Techniques
18 18
 PM/BA Interactions – Integration Mgmt.
Project Manager Business Analyst
 Develop the Project  Involved in Strategy
Charter  Involved in Business Case
 Develop PM Plan  Involved in Feasibility
 Direct/Manage Exec.  Activities are usually on the
 Monitor/Control Work critical path
 Perform Change  Evaluates the impact of
Control change requests –
 Close Project recommends alternatives
 Involved with lessons
learned
19 19
 PM/BA Interactions – Scope Mgmt.
Project Manager Business Analyst
 Collect Requirements  Elicits Requirements
 Define Scope  Manages Requirements
 Create WBS  Analyzes Requirements
 Verify Scope  Involved in Def’n of Scope
 Control Scope  Involved in trade-off
analysis for change requests
 Develop WBS for BA
activities

20 20
 PM/BA Interactions – Time Mgmt.
Project Manager
 Define Activities
 Sequence Activities
 Est. Activity Resources
 Est. Activity Durations
 Develop Schedule
 Control Schedule
21
Business Analyst
 Develops the BA Approach
 Defines BA Activities
 Sequences BA Activities
 Estimates BA Activities
 Reports status of BA
Activities
 Identifies time impacts of
change requests
21
 PM/BA Interactions – Cost Mgmt.
Project Manager Business Analyst
 Estimate Costs  Involved in initial
 Determine Budget cost/benefit analysis
 Control Costs  Provides BA costs
 Involved in costs impacts of
change requests

22 22
 PM/BA Interactions – Quality Mgmt.
Project Manager
 Plan Quality
 Perform Quality
Assurance
 Perform Quality Control
23
Business Analyst
 Establishes performance
criteria (user advocate)
 Establishes acceptance
criteria
 Monitors product/service
adherence to criteria
throughout the project
 Identifies impact of change
requests
 Leads testing activities
23
 PM/BA Interactions – HR Mgmt.
Project Manager Business Analyst
 Develop HR Plan  Identify key resources
 Acquire Project Team (Stakeholders, SME’s)
 Develop Project Team  Ensure that project
 Manage Project Team performance and
acceptance criteria is
understood
 Lead information sessions
regarding interactions with
other business processes

24 24
 PM/BA Interactions - Communications
Project Manager Business Analyst
 Identify Stakeholders  First to deal with
 Plan Communications Stakeholders
 Distribute Information  Prepares and
 Manage Stakeholder communicates requirements
Expectations  Addresses Stakeholder
 Report Performance concerns and requests
 Develops product/service
performance reports for PM

25 25
 PM/BA Interactions – Risk Mgmt.
Project Manager
 Plan Risk Mgmt.
 Identify Risks
 Perform Qualitative
Risk Analysis
 Perform Quantitative
Risk Analysis
 Plan Risk Responses
 Monitor + Control Risks
26
Business Analyst
 Identifies internal and
external risks
 Participates in Qualitative
and Quantitative Risk
Analysis
 Identifies alternative Risk
mitigation scenarios
 Participates in Risk
monitoring
26
 PM/BA Interactions – Procurement Mgmt.
Project Manager Business Analyst
 Plan Procurements  Identifies Procurement
 Conduct Procurements requirements
 Administer  Evaluates alternative
Procurements sources
 Close Procurements  Evaluates performance of
product/service vs
acceptance criteria

27 27
 PM/BA Attributes and Abilities

Project Manager Business Analyst

 Organized  Analytical Thinking
 Problem Solving  Problem Solving
 Leadership  Behavioral Understanding
 Decision Making  Business Acumen
 Open Communicator  Trusted Advisor
 Thorough  Methodical Analyzer
 Methodical
 Walk the Talk

28 28
 BA Techniques – Tools of the
Trade
Acceptance and Evaluation Criteria Brainstorming
Benchmarking
Definition
Structured Walkthrough
Business Rule Analysis
Data Dictionary and Glossary
SWOT Analysis Data Flow Diagrams
Scope Modeling Sequence Diagrams
Decision Analysis Document Analysis
Estimation Data Modeling
Focus Groups
Functional Decomposition State Diagrams
Vendor Assessment
Interface Analysis
Lessons Learned Process
Interviews
Metrics + Key Performance Indicators Process Modeling Prototyping

Non-functional Requirements Analysis Risk Analysis

Observation Problem Tracking Requirements Workshops

Organizational Modeling User Stories Root Cause Analysis
Scenarios and Use Cases Survey/Questionnaire
29 29
BA – Techniques
 Acceptance and Evaluation Criteria Definition:
– To define the requirements that must be met in order for a solution to be
considered acceptable to key stakeholders.
 Benchmarking
– Benchmark studies are performed to compare the strengths and
weaknesses of an organization against peers and competitors
 Brainstorming
– Brainstorming is an excellent way to foster creative thinking about a
problem. The aim of brainstorming is to produce numerous new ideas, and
to derive from them themes for further analysis.
 Business Rules Analysis
– To define the rules that govern decisions in an organization and that
define, constrain or enable organizational operations.
 Data Dictionary and Glossary
– A data dictionary or glossary defines key terms and data relevant to a
business domain.

30 30
BA - Techniques
 Data Flow Diagrams
– To show how information is input, processed, stored, and output from a
system.
 Data Modeling
– The purpose of a data model is to describe the concepts relevant to a
domain, the relationships between those concepts, and information
associated to them.
 Decision Analysis
– To support decision-making when dealing with complex, difficult, or
uncertain situations
 Document Analysis
– Document analysis is a means to elicit requirements by studying available
documentation on existing and comparable solutions and identifying
relevant information.
 Estimation
– Estimating techniques forecast the cost and effort involved in pursuing a
course of action

31 31
BA - Techniques
 Focus Groups
– A focus group is a means to elicit ideas and attitudes about a specific product,
service or opportunity in an interactive group environment. The participants share
their impressions, preferences and needs, guided by a moderator.
 Functional Decomposition
– To decompose processes, functional areas, or deliverables into their component
parts and allow each part to be analyzed independently.
 Interface Analysis
– To identify interfaces between solutions and/or solution components and define
requirements that describe how they will interact.
 Interviews
– An interview is a systematic approach designed to elicit information from a person or
group of people in an informal or formal setting by talking to an interviewee, asking
relevant questions and documenting the responses.
 Lessons Learned Process
– The purpose of the lessons learned process is to compile and document successes,
opportunities for improvement, failures, and recommendations for improving the
performance of future projects or project phases

32 32
BA - Techniques
 Metrics and Key Performance Indicators
– The purpose of metrics and key performance indicators are to measure the
performance of solutions, solution components, and other matters of interest to
stakeholders.
 Non-functional Requirements Analysis
– The purpose of non-functional requirements is to describe the required qualities of a
system, such as its usability and performance characteristics. These supplement the
documentation of functional requirements, which describe the behavior of the system.
 Observation
– Observation is a means of eliciting requirements by conducting an assessment of the
stakeholder’s work environment. This technique is appropriate when documenting
details about current processes or if the project in intended to enhance or change a
current process.
 Organizational Modeling
– Organizational Modeling is used to describe the roles, responsibilities, and reporting
structures that exist within an organization and to align those structures with the
organization’s goals.
 Problem Tracking
– Problem tracking provides an organized approach to tracking, management, and
resolution of defects, issues, problems, and risks throughout business analysis
activities. Management of issues is important so they can be resolved in a timely
manner to ensure success.

33 33
BA - Techniques
 Process Modeling
– To understand how work that involves multiple roles and departments is performed
 Prototyping
– Prototyping details user interfaces requirements and integrates them with other
requirements such as use cases, scenarios, data and business rules. Stakeholders
often find prototyping to be a concrete means of identifying, describing and validating
their interface needs.
 Requirements Workshops
– A requirements workshop is a structured way to capture requirements. A workshop
may be used to scope, discover, define, prioritize and reach closure on requirements
for the target system. Well-run workshops are considered one of the most effective
ways to deliver high quality requirements quickly. They promote trust, mutual
understanding, and strong communications among the project stakeholders and
project team and produce deliverables that structure and guide future analysis
 Risk Analysis
– To identify and manage areas of uncertainty that can impact an initiative, solution, or
organization
 Root Cause Analysis
– The purpose of root cause analysis is to determine the underlying source of a
problem.

34 34
BA - Techniques
 Scenarios and Use Cases
– Scenarios and use cases are written to describe how an actor interacts
with a solution to accomplish one or more of the actor’s goals, or to
respond to an event.
 Scope Modeling
– Scope models are used to describe the scope of analysis or the scope of
the solution.
 Sequence Diagrams
– Sequence diagrams are used to model the logic of usage scenarios, by
showing the information passed between objects in the system through the
execution of the scenario.
 State Diagrams
– A state diagram shows how the behavior of a concept, entity, or object
changes in response to events.
 Structured Walkthrough
– Structured walkthroughs are performed to communicate, verify and validate
requirements.

35 35
BA - Techniques
 Survey/Questionnaires
– A survey is a means of eliciting information from many people, sometimes
anonymously, in a relatively short period of time. A survey can collect
information about customers, products, work practices and attitudes. A
survey may also be referred to as a questionnaire.
 SWOT Analysis
– A SWOT analysis is valuable tool to quickly analyze various aspects of the
current state of the business process undergoing change.
 User Stories
– User Stories are a brief description of functionality that users need from a
solution to meet a business objective.
 Vendor Assessment
– To assess the ability of a potential vendor to meet commitments regarding
a product or service.

36 36
What is a requirement?

Definition:

“ A condition or capability needed by a

stakeholder to solve a problem or achieve an
objective”
(Source IIBA BABOK)

37 37
Who do BA’s Support?
 The BA works with a number of different
stakeholders:

BA
Customer Domain End
SME’s User
Implementation
SME’s Supplier Regulator
Developers,
Systems Arch.
Change Agents, Project Tester Sponsor
Trainers, Manager
Usability Pros

38 38
 Definitions and Roles
 The Requirements describe WHAT needs to be
delivered (Provided by the BA)
– The Requirements are then handed over to a technical delivery
group in order for them to develop technical specifications
 The Specifications describe HOW it will be delivered
(Provided by the Technical Solution Team)
 The BA must then confirm that all of the requirements
have been included in the Specifications
(This is called Allocation)
(This is the first step in Requirements Traceability)
39 39
What is a requirement?
 Requirements come in many forms:
– Business Requirement – a higher-level statements of
goals, objectives or needs of the organization
– Stakeholder Requirement – statements of needs for
particular stakeholders or classes of stakeholders
– Solution Requirements – describes the characteristics of
a solution that meets business and stakeholder
requirements.
 Functional – describes the behavior and information that the
solution must manage
 Non-Functional – describes the environmental conditions
under which the solution must remain effective and qualities
that the systems must have
– Transitional Requirements – describes the capabilities
needed to get from the current state of the enterprise to the
future state that will not be needed once the transition is
complete

40 40
 The BA’s Role (Master of Requirements)

 To act as the intermediary between the

business unit(s) (clients), stakeholders and
the solution delivery team
 Solutions usually are focused on:
– Improving efficiency
– Addressing customer expectations
– Delivering necessary capability

41 41
The BA’s Responsibilities - Needs
 Understands the business capability that the
organization needs to develop in order to achieve its
goals (what is needed) (Enterprise Analysis)
 Understands the stakeholders who need to
participate in the development of this capability
 Participates in Business Case Development
 Gathers, analyzes, documents requirements and
presents them in a meaningful form to all
stakeholders to ensure completeness (Elicitation,
Analysis)
 Prepares the formal Business Requirements
Document
 Tailor the documents so they are understood by the
resources who are charged with developing and
delivering the solution
42 42
The BA’s Responsibilities - Delivery
 Determines the Solution approach to be followed
(Requirements Mgmt.)
 Facilitates the development of the solution with the
solution delivery team
 Ensures that the solution remains consistent with the
formal Business Requirements Document
(Traceability)
 Participates actively in solution risk assessment,
prototyping, testing and change management
 Monitors the solution to ensure that it achieves the
desired performance characteristics (Validation)

43 43
The BA’s Responsibilities - Deliverables
 Business Case development
 Sourcing Activities – RFP’s
 BA’s Activity planning - Estimating
 Requirements documents - BRD
 Modeling – Data Flow
 Charting – Process Flow (As is, To Be)
 Ensure Requirements are satisfied thru
testing
 Acceptance of the solution

44 44
 Requirements Management
 Composed of 8 Activities:
– Enterprise Analysis Week 5
– Requirements Planning Week 7
– Requirements Elicitation Week 8
– Requirements Analysis Week 9
– Requirements Documentation Week 10
– Requirements Communication Week 10
– Requirements Implementation Week 11
– Requirements Management Week 11

45 45
 Enterprise Analysis
 Look at the Big Picture
 Analyze what the business needs to satisfy
its goals
 Look into potential options and evaluate
them for profitability and do-ability
 Provide the initial scope statement to direct
future activities

46 46
 Requirements Planning
 Stipulate the deliverables that the BA will be
responsible to produce
 Identifies the time and cost elements for the
project plan
 Outlines how the requirements will be
tracked and managed after the initial scope
has been approved

47 47
 Requirements Elicitation
 Identifies the types of elicitation activities to
be performed
 Gathers requirements by executing against
the elicitation plan
 May require many repeat activities to ensure
that all stakeholders are interviewed

48 48
 Requirements Analysis
 Review the requirements to ensure that they
are complete and comprehensive
 Ensure that any conflicting requirements are
resolved between the stakeholders
 Organize the requirements into logical
groupings and prioritize the requirements into
acceptable phases for delivery

49 49
 Requirements Documentation
 Produce understandable requirements in
formats relevant to each type of stakeholder
 Breakdown a large topic into building blocks
showing relationships and dependencies
 Produce diagrams and charts where
necessary to convey complex information
– Process models, Activity diagrams, Use cases,
– Data Flow Diagrams, Entity Relationship
Diagrams…

50 50
 Requirements Communication
 Inform the stakeholders using
demonstrations, presentations and any other
means necessary to ensure that they each
commonly understand the requirements
 Ensure that sign-off is achieved prior to
commencing the next stage of work

51 51
 Requirements Implementation
 Ensure that outsourced functionality is
verified
 Ensure that adequate testing is performed
 Ensure that risk assessment is performed
 Provide support for data conversion and
other transition activities

52 52
 Requirements Management
 Conduct traceability activities to ensure that
the all requirements are delivered throughout
the project phases
– Ensure that no extra functionality is allowed to be
included in the scope without going through the
change management process
 Engage in Trade-off assessment when
multiple options for delivery of a solution are
available

53 53
 Recap:
 What is a BA
 How the BA’s role is compared to the PM role
 What knowledge a PM is required to possess
 Where the BA fits in the project environment

54 54