The document provides an overview of the role and responsibilities of a business analyst. It discusses how business analysts work throughout various phases of a project, including analysis, specification, testing and deployment. They are responsible for identifying and documenting business requirements, validating proposed solutions, and managing any changes to requirements. The document also compares the roles of a business analyst and system analyst, noting they are complementary with the business analyst focusing on requirements and the system analyst writing technical specifications.
2. Start and finish Course style
LunchCoffee and breaks
M00 - Course introduction 2/9 | 2/527
3. 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
M00 - Course introduction 3/9 | 3/527
4. 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
M00 - Course introduction 4/9 | 4/527
5. 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
M00 - Course introduction 5/9 | 5/527
6. 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
9. 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 …
M00 - Course introduction 9/9 | 9/527
10.
11. 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
13. 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
M01 - Fundamentals of business analysis 4/46 | 13/527
14. 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)
M01 - Fundamentals of business analysis 5/46 | 14/527
15. Report from 2015 studied 50,000 projects
around the world, ranging from tiny
enhancements to massive systems
re-engineering implementations
M01 - Fundamentals of business analysis 6/46 | 15/527
16. 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
M01 - Fundamentals of business analysis 7/46 | 16/527
17. 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
M01 - Fundamentals of business analysis 8/46 | 17/527
18. 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
M01 - Fundamentals of business analysis 9/46 | 18/527
20. 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
21. 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
1.1M01 - Fundamentals of business analysis 12/46 | 21/527
22. 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.1M01 - Fundamentals of business analysis 13/46 | 22/527
26. Specific activities of the Business Analyst
Identification
Developing
Managing the requirements
1.2.2M01 - Fundamentals of business analysis 17/46 | 26/527
27. 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
1.2.3M01 - Fundamentals of business analysis 18/46 | 27/527
28. 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
1.2.4M01 - Fundamentals of business analysis 19/46 | 28/527
29. 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
Analysis Specification Testing Deployment
M01 - Fundamentals of business analysis 20/46 | 29/527
30. 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
Analysis Specification Testing Deployment
M01 - Fundamentals of business analysis 21/46 | 30/527
31. 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
Analysis Specification Testing Deployment
M01 - Fundamentals of business analysis 22/46 | 31/527
32. 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.2.5M01 - Fundamentals of business analysis 23/46 | 32/527
35. 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
M01 - Fundamentals of business analysis 26/46 | 35/527
38. 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.
M01 - Fundamentals of business analysis 29/46 | 38/527
39. 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)
1.3.3M01 - Fundamentals of business analysis 30/46 | 39/527
40. 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
1.3.3M01 - Fundamentals of business analysis 31/46 | 40/527
44. 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
M01 - Fundamentals of business analysis 35/46 | 44/527
46. 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
1.3.8M01 - Fundamentals of business analysis 37/46 | 46/527
50. 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
1.4M01 - Fundamentals of business analysis 41/46 | 50/527
52. 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
1.5.1M01 - Fundamentals of business analysis 43/46 | 52/527
53. 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
M01 - Fundamentals of business analysis 44/46 | 53/527
55. 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