IQBBA® - Foundation Level Business Analyst

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


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


quizlet.com/42802604/


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 …


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


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


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 systemsre-engineering implementations


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


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


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

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


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


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


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


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)


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



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 modellingRequirements realization planning Requirements realization planningRequirements communicationRequirements documentingRequirements validationRequirements configuration managementBusiness 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 commentbelow.

Endorsements on LinkedIn are also

highly appreciated! (your feedback = more free stuff)

MIROSLAWDABROWSKI.COM/downloads

Date post:	15-Jul-2015
Category:	Education
Upload:	miroslaw-dabrowski
View:	1,178 times
Download:	14 times

IQBBA® - Foundation Level Business Analyst

Education