IQBBA® - Foundation Level Business Analyst

IQBBAisatrademarkofgasqServiceGmbH

Start and finish Course style
LunchCoffee and breaks
M00 - Course introduction 2/9 | 2/527

 The role of Business Analyst
 The underpinning philosophy and principles of
business analysis profession
 Business analysis process
 The products produced by business analyst
 Business analysis roles
 Business analysis tools and techniques
Main goal
 Attempt Foundation exam with confidence
 Communicate freely within business analysis team
with confidence, understanding its principles and
philosophy
Secondary goal
 Benefits and value of business analysis and IQBBA

Please share with the class:
 Your name and surname
 Your organization
 Your profession (title, function,
job responsibilities)
 Your familiarity with the:
 Project management
 Business analysis
 Your experience with BABOK
 Your personal session
expectations

 Foundation Exam
 Computer based and closed book exam
 Only pencil and eraser are allowed
 Simple multiple (ABCD) choice exam
 Only one answer is correct
 30 questions, pass mark is 26 (65%)
 1 hour exam
 No negative points, no “Tricky Questions”
 No pre-requisite for Foundation exam
 Sample, one (official) mock exam is
provided to you
Candidates completing an examination in a language that
is not their mother tongue, will receive additional time

IQBBA syllabus section code and title
1 Fundamentals of Business Analysis (K2)
2 Enterprise Analysis (K3)
3 Business Analysis Process Planning (K3)
4 Elicitation (K3)
5 Requirements Analysis (K3)
6 Solution Validation (K3)
7 Tools and Techniques (K3)
8 Competencies (K2)
9 Process Improvement (K2)
10 Innovation, Design and the Customer (K2)
Module slide number / total module slides
Slide number /
total slides
Module number
and name
IQBBA syllabus
section code
SyllabusM00 - Course introduction 6/9 | 6/527

quizlet.com/42802604/

twitter.com/mirodabrowski
linkedin.com/in/miroslawdabrowski
google.com/+miroslawdabrowski
miroslaw_dabrowski
www.miroslawdabrowski.com
Mirosław Dąbrowski
Agile Coach, Trainer, Consultant
(former JEE/PHP developer, UX/UI designer, BA/SA)
Creator Writer / Translator Trainer / Coach
• Creator of 50+ mind maps from PPM and related
topics (2mln views): miroslawdabrowski.com
• Lead author of more than 50+ accredited materials
from PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, ITIL,
M_o_R, MoV, PMP, Scrum, AgilePM, DSDM, CISSP,
CISA, CISM, CRISC, CGEIT, TOGAF, COBIT5 etc.
• Creator of 50+ interactive mind maps from PPM
topics: mindmeister.com/users/channel/2757050
• Product Owner of biggest Polish project
management portal: 4PM: 4pm.pl (15.000+ views
each month)
• Editorial Board Member of Official PMI Poland
Chapter magazine: “Strefa PMI”: strefapmi.pl
• Official PRINCE2 Agile, AgilePM, ASL2, BiSL methods
translator for Polish language
• English speaking, international, independent
trainer and coach from multiple domains.
• Master Lead Trainer
• 11+ years in training and coaching / 15.000+ hours
• 100+ certifications
• 5000+ people trained and coached
• 25+ trainers trained and coached
linkedin.com/in/miroslawdabrowski
Agile Coach / Scrum Master PM / IT architect Notable clients
• 8+ years of experience with Agile projects as a
Scrum Master, Product Owner and Agile Coach
• Coached 25+ teams from Agile and Scrum
• Agile Coach coaching C-level executives
• Scrum Master facilitating multiple teams
experienced with UX/UI + Dev teams
• Experience multiple Agile methods
• Author of AgilePM/DSDM Project Health Check
Questionnaire (PHCQ) audit tool
• Dozens of mobile and ecommerce projects
• IT architect experienced in IT projects with budget
above 10mln PLN and timeline of 3+ years
• Experienced with (“traditional”) projects under high
security, audit and compliance requirements based
on ISO/EIC 27001
• 25+ web portal design and development and
mobile application projects with iterative,
incremental and adaptive approach
ABB, AGH, Aiton Caldwell, Asseco, Capgemini, Deutsche Bank,
Descom, Ericsson, Ericpol, Euler Hermes, General Electric,
Glencore, HP Global Business Center, Ideo, Infovide-Matrix,
Interia, Kemira, Lufthansa Systems, Media-Satrun Group,
Ministry of Defense (Poland), Ministry of Justice (Poland),
Nokia Siemens Networks, Oracle, Orange, Polish Air Force,
Proama, Roche, Sabre Holdings, Samsung Electronics, Sescom,
Scania, Sopra Steria, Sun Microsystems, Tauron Polish Energy,
Tieto, University of Wroclaw, UBS Service Centre, Volvo IT…
miroslawdabrowski.com/about-me/clients-and-references/
Accreditations/certifications (selected): CISA, CISM, CRISC, CASP, Security+, Project+, Network+, Server+, Approved
Trainer: (MoP, MSP, PRINCE2, PRINCE2 Agile, M_o_R, MoV, P3O, ITIL Expert, RESILIA), ASL2, BiSL, Change Management,
Facilitation, Managing Benefits, COBIT5, TOGAF 8/9L2, OBASHI, CAPM, PSM I, SDC, SMC, ESMC, SPOC, AEC, DSDM Atern,
DSDM Agile Professional, DSDM Agile Trainer-Coach, AgilePM, OCUP Advanced, SCWCD, SCBCD, SCDJWS, SCMAD, ZCE 5.0,
ZCE 5.3, MCT, MCP, MCITP, MCSE-S, MCSA-S, MCS, MCSA, ISTQB, IQBBA, REQB, CIW Web Design / Web Development /
Web Security Professional, Playing Lean Facilitator, DISC D3 Consultant, SDI Facilitator, Certified Trainer Apollo 13 ITSM
Simulation …

1. Fundamentals of business analysis
2. Enterprise analysis
3. Business analysis process planning
4. Elicitation
5. Requirements analysis
6. Solution validation
7. Tools and techniques
8. Competences
9. Process improvement
10. Innovation, design and customer
M01 - Fundamentals of business analysis 2/46 | 11/527

1. Lack of clear link to the organisation’s
key strategic priorities
2. Lack of clear senior management
ownership and leadership
3. Lack of effective engagement with stakeholders
4. Lack of skills and proven approach to project and risk
management
5. Project not broken down into manageable steps
6. Evaluation of proposals linked to short term affordability
rather than longer term value for money
7. Lack of understanding of and contact with suppliers
8. Lack of effective integration between
the client, supplier and supply chain
Reported by Office of
Government Commerce (OGC)
in respect of Gateway Reviews

Lovallo Kahneman (2003)
NAO (2011)
Flyvbjerg et al (2003, 2005)
Research in Australia by
Capability Management
(2006)
A study Moorhouse
Consulting (2009)
Beer & Nohria (2000)
Gauld & Goldfinch (2006)
eGovernment Economics
Project (2006)
Altschuler & Luberoff
(2003)
Seldon & Colvin (2003)
Cameron & Green (2009)
Schaffer & Thomson (1992)
Ballhaus (2005)

Report from 2015 studied 50,000 projects
around the world, ranging from tiny
enhancements to massive systems
re-engineering implementations

Top 10 Reasons for Success
1. User Involvement
2. Executive Management Support
3. Clear Business Objectives
4. Optimizing Scope
5. Agile Process
6. Project Manager Expertise
7. Financial Management
8. Skilled Resources
9. Formal Methodology
10. Standard Tools and Infrastructure
Research by The Standish Group International Inc.
End User
involvement!
Not just customer

Other
1%
Lack of Qualified
Resources
3%
Communication
Problems
14%
Inadequate Risk
Management
17%
Poor Scope Definition
15%
Poor Requirements
Definition
50%
Other
Lack of Qualified Resources
Communication Problems
Inadequate Risk Management
Poor Scope Definition
Poor Requirements Definition
ESI International survey of 2000
business professionals, 2005

The major reasons of projects' failure are problems with
requirements and communication
 Business requirements are not aligned with business real needs
 No recognition between needs and wants
The base for identifying, defining the business
requirements is Business Analysis which acts as a
“communication bridge” between client and supplier
ESI International survey of 2000 business professionals, 2005

Instability of the
requirements (frequent
changes)
Redundant information
Insufficient user
involvement
Underpowered users
Overlooked user personas
Minimal or no specification
at all
Communication issues
Culture
Unclear goals/objectives
Bad quality of the
requirements and/or
business needs
Language barriers
Domain knowledge barriers
Too formal formulations
Ambiguous, overly
specified, unclear, unclear,
impossible, contradictory
requirements
1.1M01 - Fundamentals of business analysis 11/46 | 20/527

Time pressure
Exclusive orientation toward fast results
Exclusive fixation on costs
Perceiving documentation or analyzing and understanding
business processes as a cost, not added value

Business process within an organization not known or
understood
End products of the business processes not known
Stakeholders not identified or empowered
Business goals or needs not identified
 The organization needs not defined and wants not satisfied
 The business goals not achieved
Result
 Imprecise, ambiguous, contradictory or missing requirements
 Not stable requirements that change very often
 Requirements that do not fulfill the agreed criteria (i.e. quality
criteria) or real business needs and priorities

1.2.1M01 - Fundamentals of business analysis 15/46 | 24/527

Development
of software
systems
Development
of software
components
Extensions of
existing
software
Improvements
to the business
process
Changes to the
organization

Specific activities of the Business Analyst
 Identification
 Developing
 Managing the requirements

Objectives
of BA
Collect and
document
the business
requirements
Design
solutions for
the business
problem
Assist in the
timely
completion
of projects
Improve
efficiency by
increasing
the quality of
requirements

The Business Analysis in the analysis phase
 Identification and evaluating of the current business processes (AS
IS analysis)
 Gathering initial requirements for needed business solution (TO BE
analysis)
 Creating and analyzing the Business Case
 Conducting feasibility study/assessment
 Preparing ideas/alternatives of business solution
Analysis Specification Testing Deployment

The Business Analysis in the specification phase
 Identifying and documenting business requirements on more
detailed level
 Supporting System Analyst in preparing detailed system
specifications
 Validating proposed software design with the customer and other
stakeholders (e.g. users/legal/compliance etc.)
 Managing any requirements changes
1.2.4

The Business Analysis in testing phase
 Checking test results
 Resolving issues related to defects or gaps in the requirements
 Supporting preparing test cases for User Acceptance Testing
 Supporting acceptance testers in executing test cases
1.2.4

The Business Analysis in development phase
 Supporting development team during implementation
 Validating increments of solution according to intended
requirements and needs
 Supporting testers in preparing test cases and test scripts at
business level
 Managing potential changes in requirements
1.2.4

Different projects or methodologies may have different
approaches for defining requirements
Some projects run under external regulations requirements
Tasks and techniques defined in general Business Analysis
process must be adjusted for a specific project (e.g.
Traditional vs Agile)
 Requirement format and level of detail will be different
Example
 Enterprise Analysis will not be conducted in every case
 In some projects initial requirements and business processes
within an organization are already known and understood

1.3.2
The two roles are complimentary
The Business Analyst
provides an input information for the
System Analyst
The System Analyst writes
technical requirements from the
business requirements
The Business Analyst gathers and
documents the business requirements

Elicitation
Analyticalabilities
Writing
BusinessKnowledge
Presentation
Leadership
Communication
Research
Modeling
Dataanalysis
ProblemSolving
Technicalabilities
Business Analyst
System Analyst

IT BA
System
Analyst
IT
Enterprise
Architect
Decision
Systems
Enterprise
Architect
Product
Owner
Process
Analyst
Business
Architect
BI
Business
Relationship
Manager
Enterprise
BusinessTechnology
Project

The Project Manager ensures PROJECT progress against
schedule, risk management and mitigation, and delivering
of the product of the project on time, within budget, and to
specified quality standards.
 PM is focused on resources, time, schedule, cost, risk and quality
and has the ultimate responsibility for project success.
The Business Analyst, ensures that the PRODUCT of the
project is well-defined throughout the project and meets
the targeted business needs through expert requirements
management, systems analysis, business analysis, and
requirements analysis.
 BA works with stakeholders, structures, policy, operations and
recommends solutions.

A requirement is [lEEE Std 610.12-1990]
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
system or system component to satisfy a contract, standard,
specification, or other formally imposed documents
3. A documented representation of a condition or capability as in 1
or 2
 Requirements should be preceded by descriptors like
 Business requirements
 User requirements
 Functional requirements (FR)
 Non-functional requirements (NFR)

Requirement
Provide foundation
for project's
assessment,
planning, execution
and monitoring
Defines customer
expectations
(stakeholders value)
Acting as
component of
agreements,
project plans
Establish system
boundaries, scope
of delivery

Requirement
Product
Functional
(FR)
External
Internal
Non-functional
(NFR)
External
Internal
Process
Needs and limitations of the business processes:
• Costs, marketing, processing time, sales and distribution,
organization, documentation
• May specify methodologies or frameworks to be followed
1.3.4; 1.3.5M01 - Fundamentals of business analysis 32/46 | 41/527

Customer
requirements
(business requirements)
Solution/system
requirements
Product/component
requirements
1.3.4; 1.3.5M01 - Fundamentals of business analysis 33/46 | 42/527

Traceability is an association that exists between different
types of requirements and:
 Requirements (mapping the higher level requirements that defined
the needs and features to the more detailed requirements)
 Detailed requirements and design models
 Detailed requirements and test cases (e.g., for system testing)
 High level requirements and test cases (e.g., for user acceptance
test)
 Requirements and design artefacts
1.3.7
• Bidirectional traceability from
requirements to software
architecture to code.
• Bidirectional traceability from
requirements to test cases.
Requirement Model Source Code Object

Describes the function, architecture, and design of software
Describes the process of development itself
All artefacts should be under configuration management
(e.g. version control, naming conventions, archiving, etc.)
Vison
Statement
Business Case Use Cases
Activity
diagrams
Class diagrams
Component
diagrams
Design
documents
Requirements
documentation
Project
documentation
Risk
assessment

 Enterprise Analysis
 Requirements Planning and Management
 Requirements Elicitation (Identification)
 Requirements Communication
 Requirements Analysis and Documentation
 Solution Assessment and Validation

1.4
Enterprise
Analysis
Requirements
Elicitation
Requirements
Analysis and
Documentation
Requirements Communication
Requirements Planning and Management
Solution
Assessment
and Validation
AS-IS

Project management
 Classic iron triangle: Scope, Time, Budget
 PRINCE2 approach: Scope, Time, Budget, Quality, Risk, Benefits
Design
 Required shape and scope of the solution
Development
 What has to be implemented (or fixed)
Testing/Quality Assurance (QA)
 Provides a base to testing
 Is a subject of testing

Requirements elicitation (identification)
Requirements analysis and modelling
Requirements realization planning
Requirements realization planning
Requirements communication
Requirements documenting
Requirements validation
Requirements configuration management
Business solution proposal

Why a Business Analyst is needed?
When a Business Analyst is needed?
 When a need for clarification of business issues
appears (implementation, testing)?
 When a need for new functionalities appears?
 When the business changes?
 When the end users need support with working
with the solution?
1.5.2
A Business Analyst is involved during the
whole software life cycle, including
maintenance phase

I hope you enjoyed
this presentation. If so,
please like, share and
leave a comment
below.
Endorsements on
LinkedIn are also
highly appreciated! 
(your feedback = more free stuff)

MIROSLAWDABROWSKI.COM/downloads

IQBBA® - Foundation Level Business Analyst

More Related Content

What's hot

Viewers also liked

Similar to IQBBA® - Foundation Level Business Analyst

More from Mirosław Dąbrowski C-level IT manager, CEO, Agile, ICF Coach, Speaker

Recently uploaded

IQBBA® - Foundation Level Business Analyst