IQBB
Ais
atr
adem
ark
of g
asq
Serv
ice
Gm
bH
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 techniquesMain 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
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
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
IQBBA syllabus section code and title1 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
M00 - Course introduction 7/9 | 7/527
quizlet.com/42802604/
M00 - Course introduction 8/9 | 8/527
twitter.com/mirodabrowski
linkedin.com/in/miroslawdabrowskigoogle.com/+miroslawdabrowski
miroslaw_dabrowski
www.miroslawdabrowski.com
Mirosław DąbrowskiAgile 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, independenttrainer 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
1. Fundamentals of business analysis2. Enterprise analysis3. Business analysis process planning4. Elicitation5. Requirements analysis6. Solution validation7. Tools and techniques8. Competences9. Process improvement10. Innovation, design and customer
M01 - Fundamentals of business analysis 2/46 | 11/527
M01 - Fundamentals of business analysis 3/46 | 12/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 stakeholders4. Lack of skills and proven approach to project and risk
management5. Project not broken down into manageable steps6. Evaluation of proposals linked to short term affordability
rather than longer term value for money7. Lack of understanding of and contact with suppliers8. 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
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
Report from 2015 studied 50,000 projects around the world, ranging from tiny enhancements to massive systemsre-engineering implementations
M01 - Fundamentals of business analysis 6/46 | 15/527
Top 10 Reasons for Success1. User Involvement2. Executive Management Support3. Clear Business Objectives4. Optimizing Scope5. Agile Process6. Project Manager Expertise7. Financial Management8. Skilled Resources9. Formal Methodology10. 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
Other1%
Lack of Qualified Resources
3%
Communication Problems
14%
Inadequate Risk Management
17%
Poor Scope Definition15%
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
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
M01 - Fundamentals of business analysis 10/46 | 19/527
Instability of the requirements (frequent changes)Redundant information Insufficient user
involvementUnderpowered usersOverlooked user personasMinimal or no specification
at allCommunication issuesCulture
Unclear goals/objectivesBad quality of the
requirements and/or business needs Language barriersDomain knowledge barriers Too formal formulationsAmbiguous, 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 costsPerceiving documentation or analyzing and understanding
business processes as a cost, not added value
1.1M01 - Fundamentals of business analysis 12/46 | 21/527
Business process within an organization not known or understood End products of the business processes not known Stakeholders not identified or empoweredBusiness 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
M01 - Fundamentals of business analysis 14/46 | 23/527
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
1.2.1M01 - Fundamentals of business analysis 16/46 | 25/527
Specific activities of the Business Analyst Identification Developing Managing the requirements
1.2.2M01 - Fundamentals of business analysis 17/46 | 26/527
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
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
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
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
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
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
M01 - Fundamentals of business analysis 24/46 | 33/527
1.3.1M01 - Fundamentals of business analysis 25/46 | 34/527
1.3.2
The two roles are complimentary
The Business Analystprovides an input information for the
System Analyst
The System Analyst writestechnical requirements from the
business requirements
The Business Analyst gathers and documents the business requirements
M01 - Fundamentals of business analysis 26/46 | 35/527
Elic
itatio
n
Anal
ytic
al a
bilit
ies
Writ
ing
Busin
ess K
now
ledg
e
Pres
enta
tion
Lead
ersh
ip
Com
mun
icat
ion
Rese
arch
Mod
elin
g
Data
ana
lysis
Prob
lem
Sol
ving
Tech
nica
l abi
litie
s
Business Analyst
System Analyst
M01 - Fundamentals of business analysis 27/46 | 36/527
IT BASystem Analyst
IT Enterprise Architect
Decision Systems
Enterprise Architect
Product Owner
Process Analyst
Business Architect
BI Business Relationship
Manager
Ente
rpris
e
BusinessTechnology
Proj
ect
M01 - Fundamentals of business analysis 28/46 | 37/527
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
A requirement is [lEEE Std 610.12-1990]1. A condition or capability needed by a stakeholder to solve a
problem or achieve an objective2. 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
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
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
1.3.6M01 - Fundamentals of business analysis 34/46 | 43/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
M01 - Fundamentals of business analysis 35/46 | 44/527
1.3.8M01 - Fundamentals of business analysis 36/46 | 45/527
Describes the function, architecture, and design of softwareDescribes the process of development itselfAll 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
M01 - Fundamentals of business analysis 38/46 | 47/527
Enterprise Analysis Requirements Planning and Management Requirements Elicitation (Identification) Requirements Communication Requirements Analysis and Documentation Solution Assessment and Validation
1.4M01 - Fundamentals of business analysis 39/46 | 48/527
1.4
Enterprise Analysis
Requirements Elicitation
Requirements Analysis and
Documentation
Requirements Communication
Requirements Planning and Management
Solution Assessment
and Validation
AS-IS
M01 - Fundamentals of business analysis 40/46 | 49/527
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
M01 - Fundamentals of business analysis 42/46 | 51/527
Requirements elicitation (identification)Requirements analysis and modellingRequirements realization planning Requirements realization planningRequirements communicationRequirements documentingRequirements validationRequirements configuration managementBusiness solution proposal
1.5.1M01 - Fundamentals of business analysis 43/46 | 52/527
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
M01 - Fundamentals of business analysis 45/46 | 54/527
I hope you enjoyed this presentation. If so, please like, share and
leave a commentbelow.
Endorsements on LinkedIn are also
highly appreciated! (your feedback = more free stuff)
MIROSLAWDABROWSKI.COM/downloads