The document provides an overview of the Foundations of Business Analysis certificate course. The course consists of 3 modules that cover the disciplines and practices of business analysis: Foundations of Business Analysis, Leadership in Business Analysis, and Tools and Techniques in Business Analysis. The introductory module outlines the course content over 12 weeks, covering topics such as business analysis competencies, techniques, requirements elicitation, and case study assignments. The document defines business analysis and compares the roles and certifications of business analysts and project managers.

1. Foundations of Business Analysis
Module 1 - Introduction
1

2. Certificate in Business Analysis
 Foundations of Business Analysis
– High level introduction to the disciples and practices of
Business Analysis
 Leadership in Business Analysis
– Focuses on practicing the soft skills associated with
Business Analysis such as: conflict management,
communications, leading and facilitation
 Tools and Techniques in Business Analysis
– Focuses on practicing the hard skills associated with
Business Analysis such as: charting, data analysis, process
modeling
2 2

3. A Walk through the course outline
3 3

4. 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
4 4

5. 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
5 5

6. Case Study Work Due Week 6
 Teams of 5-6
 Select a study area:
– Strategic / Fact Finding / Information Knowledge /
Process Knowledge / Solution Knowledge
 Research this area and produce a synopsis
report with examples or case studies
showing how these techniques are
employed.
6 6

7. 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
Fact Finding
Analysis Knowledge Knowledge Knowledge
 Benchmarking  Acceptance Criteria
 Brainstorming  Data Dictionary/Glossary
 Data Flow Diagram  Estimating
 Decision Analysis  Lessons Learned Process
 SWOT Analysis  Data Modeling
 Organization Modeling  Metrics & KPIs
 Non-functional Requirements
 Problem Tracking
 Prototyping
 Risk Analysis
 Scope Modeling
 Vendor Assessment
7 7

8. Case Study Work due Week 11
 Teams of 5-6 (Different team composition)
 Identify a project (An idea for improving an
existing process) and develop a proposal
identifying how you would use Business
Analysis practices to solve the problem.
– Enterprise Analysis, Business Requirements
Elicitation, Requirements Analysis and Proposed
Solution
8 8

9. 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?
9 9

10. 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
10 10

11. What is a Business Analyst?
 BA’s come with many titles….
Systems Analyst Requirements
Engineer
Business Systems Analyst Business
Architect
Process Analyst
Enterprise
Product Mgr. Analyst
11 11

12. 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
12 12

13. 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?
13 13

14. The Big Picture
Risk
Schedule Budget
Quality Resources
Scope /
Requirements
14 14

15. 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
15 15

16. 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.
16 Source: Business Analysis Body of Knowledge® 16

17. 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
17 17

18. Comparison of Certifications
Project Manager Business Analyst
 PMI – Proj. Mgmt. Inst.  IIBA – Intl. Inst. of Business
 PMP + CAPM Analysis
designation  CBAP designation
 Thousands of PMP’s  Hundreds of CBAP’s
 PMBoK version 4  BABoK version 2
 Experience Req’d  Experience Req’d
 Professional Dev. Req’d Professional Dev. Req’d
 Certification Exam  Certification Exam
 Maintain standing Maintain standing
18 18

19. 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
19 19

20. 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
20 20

21. 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
21 21

22. PM/BA Interactions – Time Mgmt.
Project Manager Business Analyst
 Define Activities  Develops the BA Approach
 Sequence Activities  Defines BA Activities
 Est. Activity Resources  Sequences BA Activities
 Est. Activity Durations  Estimates BA Activities
 Develop Schedule  Reports status of BA
 Control Schedule Activities
 Identifies time impacts of
change requests
22 22

23. 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

23 23

24. PM/BA Interactions – Quality Mgmt.
Project Manager Business Analyst
 Plan Quality  Establishes performance
 Perform Quality criteria (user advocate)
Assurance  Establishes acceptance
 Perform Quality Control criteria
 Monitors product/service
adherence to criteria
throughout the project
Identifies impact of change
requests
 Leads testing activities
24 24

25. 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
25 25

26. 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
26 26

27. PM/BA Interactions – Risk Mgmt.
Project Manager Business Analyst
 Plan Risk Mgmt.  Identifies internal and
 Identify Risks external risks
 Perform Qualitative Participates in Qualitative
Risk Analysis and Quantitative Risk
 Perform Quantitative Analysis
Risk Analysis Identifies alternative Risk
 Plan Risk Responses mitigation scenarios
 Participates in Risk
 Monitor + Control Risks
monitoring
27 27

28. 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
28 28

29. 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
29 29

30. BA Techniques – Tools of the Trade
Acceptance and Evaluation Criteria Definition Brainstorming
Benchmarking
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
30 30

31. 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.
31 31

32. 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
32 32

33. 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
33 33

34. 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.
34 34

35. 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.
35 35

36. 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.
36 36

37. 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.
37 37

38. What is a requirement?
Definition:
“ A condition or capability needed by a
stakeholder to solve a problem or achieve an
objective”
(Source IIBA BABOK)
38 38

39. 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
39 39

40. 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)
40 40

41. 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
41 41

42. 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
42 42

43. 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
43 43

44. 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)
44 44

45. 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
45 45

46. Requirements Management Disciplines
 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
46 46

47. 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
47 47

48. 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
48 48

49. 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
49 49

50. 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
50 50

51. 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…
51 51

52. 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
52 52

53. 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
53 53

54. 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
54 54

55. 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
55 55