Babok v3 Knowledge Area Summary v0.15 (DRAFT)

Download as pdf or txt
Download as pdf or txt
You are on page 1of 2

BABOK® v3 Knowledge Area Summary v0.

15 (DRAFT)
Prepared by Alan Maxwell (Christchurch, New Zealand) using information from Watermark Learning BABOKv3 Study Guide + other resources Page: 1 of 2

Definition of Terms Knowledge Area Interaction Diagrams Business Analysis Core Concept Model
 Business Analysis: The practice of enabling change in an enterprise by defining Business Analysis is the practice of enabling change in an enterprise by defining
needs and recommending solutions that deliver value to stakeholders. needs and recommending solutions that deliver value to stakeholders.
 Business Analysis Information: This refers to the broad and diverse sets of  Changes: The steps involved in transforming ‘Needs’ into ‘Solutions’.
information that business analysts analyze, transform, and report.  Needs: Business problems that require solving or an opportunity that can be seized.
 Design: A design is a usable representation of a solution and focuses on ‘Needs’ are satisfied by ‘Solutions’.
understanding how value might be realized by a solution if it is built.  Solutions: The products and services that provide ways to take advantage of
 Enterprise: An enterprise is a system of one or more organizations and the opportunities and satisfy ‘Needs’. ‘Solutions’ are developed through ‘Changes’
solutions they use to pursue a shared set of common goals. consisting of one or several projects, programs or initiatives.
 Organization: An autonomous group of people under the management of a single  Stakeholders: Are individuals or groups that have ‘Needs’, an interest in the
individual or board, that works towards common goals and objectives. ‘Solution’, and/or are affected by the ‘Changes’.
 Plan: A plan is a proposal for doing or achieving something and describe a set of  Value: ‘Solutions’ need to provide ‘Value’ to the organisation and ‘Stakeholders’. If
events, the dependencies among the events, the expected sequence, the ‘Solutions’ do not provide ‘Value’, they have not met the ‘Need’.
schedule, the results or outcomes, the materials and resources needed, and the  Contexts: Are those things that affect and are relevant to the ‘Changes’, and is the
stakeholders involved. environment in which the ‘Solution’ will be developed. E.g. Organisation culture etc.
 Requirement: A requirement is a usable representation of a need. All of these Business Analysis Core Concepts interact with each other.
 Risk: Risk is the effect of uncertainty on the value of a change, a solution, or the
enterprise.
Requirements Classification Schema
Requirement + Design Lifecycles
 Business requirements: statements of goals, objectives, and outcomes that
describe why a change has been initiated.
 Stakeholder requirements: describe the needs of stakeholders that must be met
in order to achieve the business requirements. They may serve as a bridge
between business and solution requirements.
 Solution requirements: describe the capabilities and qualities of a solution that
meets the stakeholder requirements.
o Functional requirements: describe the capabilities that a solution must have in
terms of the functional behaviour and information that the solution will manage.
o Non-functional requirements or quality of service requirements: do not relate
directly to the behaviour or functionality of the solution, but rather describe
conditions under which a solution must remain effective or qualities that a
solution must have.
 Transition requirements: describe the capabilities required to facilitate transition
from the current state to the future state, but which are not needed once the
change is complete.

Perspectives
 11.1 Agile
 11.2 Business Intelligence
 11.3 Information Technology
 11.4 Business Architecture
 11.5 Business Process Modelling

Knowledge Area > Tasks (+ Elements) Addn Info Task: Stakeholders + Input / Output CRUD Task Techniques
KA 3: BA Planning & Monitoring [BAPM>ASGIP) 3.1.2 Formality Considerations:
BA planning & monitoring needs to be completed on all initiatives. It is • Complex and High Risk
intentionally positioned before the other Knowledge Areas in the BABOK, • In highly regulated industry
as all work must be planned. • Contracts with Vendors
p3.1 Plan BA Approach • Geographic location of
.1 Planning Approach (Predictive or Adaptive) stakeholders
.2 Formality + level of detail of deliverables • Outsourced resources
.3 The BA Activities (to produce required deliverables) • High turnover/inexperienced staff
.4 Timing of BA activities (in required phases or iterations) • Need formal sign-off requirements
.5 Complexity and Risk • Permanence of documentation
.6 Acceptance 3.2.1 Stakeholder Analysis
p3.2 Plan Stakeholder Engagement • RACI matrix (Responsible,
.1 Stakeholder Analysis Accountable, Consulted, Informed)
.2 Define Stakeholder Collaboration • Attitudes (to BA, Collaboration,
.3 Stakeholder Communication Needs The Sponsor, Team Members)
p3.3 Plan BA Governance • Authority levels
.1 Decision Making (and roles of individual stakeholders) • Level of power & influence
.2 Change Control Process (evaluation and impact of changes) 3.3.3 Prioritisation Factors
.3 Plan Prioritisation Approach • The formality and rigor required
.4 Plan for Approvals • Prioritisation process to follow
p3.4 Plan BA Information Management • Technique to use (e.g. MoSCoW)
.1 Orgainsation of BA Information Management • Criteria (Cost, risk, value etc)
.2 Level of Abstraction (high level ‘conceptual’ or very detailed) 3.4.6 IM Requirement Attributes:
.3 Plan Traceability Approach (must add value) • Complexity + Absolute Ref +
.4 Plan requirements Reuse (via a centralised repository) Risks + Author + Source + Status +
.5 Storage and Access Ownership + Urgency + Priority +
.6 Requirement Attributes Stability
p3.5 Identify BA Performance Improvements 3.5.2 Assessment Measures
.1 Performance Analysis • Timeliness + Accuracy +
.2 Assessment Measures Completeness + Knowledge +
.3 Analyse Results Effectiveness + Organisational
.4 Recommend Actions for Improvement Support + Significance + Strategic.
KA 4: Elicitation & Collaboration [EC>PCCCC] 4.1.2 Factors when selecting
Elicitation – To ‘call forth or draw out’ requirements from and with Techniques
stakeholders. • Cost & time constraints
Collaboration – Working together with stakeholders to achieve a mutual • Type of sources available
goal. • Culture
p4.1 Prepare for Elicitation • Desired outcomes
.1 Understand scope of Elicitation • Techniques used in similar
.2 Select Elicitation techniques projects
.3 Set up Logistics (People + Resources + Locations) • Techniques suited to situation
.4 Secure Supporting Material (People + Systems + Historical Data + • Work needed to finish a technique
Materials + Documents + WIP Analysis outputs) 4.2 Types of Elicitation
.5 Prepare Stakeholders (Educate in elicitation techniques) • Collaborative (Directly with
p4.2 Conduct Elicitation Stakeholders)
.1 Guide elicitation activity • Research (Non stakeholder
.2 Capture Elicitation Outcomes sources + data analysis)
p4.3 Confirm Elicitation Results • Experiments (e.g observation +
.1 Compare elicitation results against source info Proof of concept + Prototypes)
.2 Compare elicitation results against other elicitation results 4.4 Communication Objectives &
p4.4 Communicate BA Information Format
.1 Determine objectives and format of communication • Communication Objectives
.2 Communicate BA package) • Package Considerations (Who is
p4.5 Manage Stakeholder Collaboration audience + what will they
.1 Gain agreement on commitments (E.g. Time + Resources) understand & need + What is
.2 Monitor Stakeholder engagement (contributing effectively not just important to communicate
perfunctorily, interest kevels have not declined, timely turnaroun is • Package Format (Formal +
occurring, monitor risks) Informal + Presentations)
.3 Collaboration (regular, frequent + bi-directional comms + Maintain • Communication Platform (Group
comm channels + Promote shared responsibility) + Individsual + Written)

KA 5: Requirement Lifecycle Management [RLCM>TMPCA] 5.1.2 Trace Requirement


Describes how requirements and designs are managed and maintained Relationships
from the time they are created until they are retired (deleted, archived, • Derive (E.g. Business Rqmnt >
stored for re-use etc) Stakeholder Rqmnt > Solution
p5.1 Trace Requirements (manage scope + risk of scope creep + help Rqmnt
identify gaps + analyse impact + determine status + allocate) • Depends (Necessity + Effort)
.1 Level of Formality (Complex is harder to maintain) • Satisfy (Component)
.2 Relationships • Validate (Solution fulfils
.3 Traceability Repository (Automated for complex) requirement)
p5.2 Maintain Requirements (to ensure continue to be accurate and 5.3.1 Basis for Prioritisation
consistent and support re-use) • Cost
.1 Maintain Requirements (accuracy + traced relartionships) • Risk
.2 Maintain Attributes (In Plan BA Information Management) • Dependencies
.3 Re-using Requirements (Re-used on current efforts + similar • Benefit
initiatives + similar business domains + enterprise-wide) • Penalty
p5.3 Prioritise Requirements • Regulatory Compliance
.1 Basis for Prioritisation • Time Sensitivity
.2 Challenges of Prioritisation (everything is high priority + risk) • Stability
.3 Continual Prioritisation 5.4.1 Assessment Formality
p5.4 Assess Requirement Changes • Predictive (more formal)
.1 Assessment Formality • Adaptive (less formal)
.2 Impact Analysis 5.4.2 Impact Analysis Factors
.3 Impact Resolution (Approved, Denied, Deferred) • Cost
p5.5 Approve Requirements • Benefit
.1 Understand Stakeholder Roles • Urgency
.2 Conflict and Issue Management (In Governance Plan) • Schedule
.3 Gain Consensus • Impact
.4 Track and Communicate Approval 5.5.4 Track and Communicate
Approval
• Record the decisions
• Communicate the status
• Maintain an Audit History

Distributed by: <Logos Here>


BABOK® v3 Knowledge Area Summary v0.15 (DRAFT)
Prepared by Alan Maxwell (Christchurch, New Zealand) using information from Watermark Learning BABOKv3 Study Guide + other resources Page: 2 of 2

Knowledge Area > Tasks (+ Elements) Addn Info Task: Stakeholders + Input / Output CRUD Task Techniques
KA 6: Strategy Analysis [SA>CFRS] 6.1.1 Examine Needs to find Root
Strategy Analysis aims to identify business needs of tactical and strategic Cause
importance, enable the enterprise to respond to those needs, assess risk 6.1.1 Needs > Potential benefits
and align the ‘change strategy’ with existing higher and lower level • Increase revenue or market share
strategies. • Decrease costs and lost revenue
p6.1 Analyse Current State (Done only enough to determine if a change • Intangibles like customer
is really needed and to guide change strategy) satisfaction or employee morale
.1 Business Needs (Top down + Bottom Up + Middle Out + External • Ease of implementation
drivers) • Cost and harm of doing nothing
.2 Organisational Structure (formal relationships between people) & 6.1.3 Capabilities & Processes
Culture (beliefs, values and norms shared) • Process centric view (E.g. end to
.3 Capabilities and Processes end supplier to customer process)
.4 Technology & Infrastructure (current IT systems) • Capability centric view (‘Value
.5 Policies (Internal rules and constraints on decision making) added’ that transcends process –
.6 Business Architecture helps generate innovative Solns)
.7 Internal Assets (E.g. financial resources + investments + property + 6.2 Future State Measurements
patents + brand names etc) • Predictable outcomes
.8 External Influencers (Industry structure + Competitors + Suppliers + • Unpredictable outcomes
Political/regulatory environment + technology + Macroeconomic factors) 6.2 Future State SMART Goals
p6.2 Define Future State • Specific
.1 Business Goals and Objectives • Measurable
.2 Scope of Solution Space • Achievable
.3 Constraints • Relevant
.4 Organisational Structure and Culture • Time Bound
.5 Capabilities and Processes 6.3 Risks Analysed for:
.6 Technology & Infrastructure • Consequences + Impact
.7 Policies • Likelihood
.8 Business Architecture • Potential Timeframe
.9 Internal Assets 6.3.5 Risk Recommendations
.10 Identify Assumptions • Pursue change regardless of risk
.11 Potential Value • Manage & optimise opportunities
p6.3 Assess Risks • Pursue risk mitigation
.1 Unknowns • Seek to increase value
.2 Constraints + Assumptions + Dependencies • Do not pursue change (too risky)
.3 Negative Impact to Value 6.4 Change Strategy
.4 Risk Tolerance (Risk averse + Neutral + Risk seeking) Components
.5 Recommendation • Context for change
p6.4 Define Change Strategy (via Business Case or SOW etc) • Alternative strategies
.1 Solution Scope (Capabilities + Data + Process + Resources + • The recommended strategy
Business Rules + Organisation structure + Technology) • Investments & resources needed
.2 Gap Analysis (Variance between current + future states) • How solution will deliver value
.3 Enterprise Readiness Assessment • Key stakeholders involved
.4 Change Strategy (Org. readiness for change + Costs + Timelines + • Key states or phases in transition
Alignment to Objectives + Opportuinity Costs)
.5 Transition States and Release Planning
KA 7: Requirement Analysis+Design Defn [RADD>SEAROR] 7.1.1 Model Types
This describes how requirements that are discovered during elicitation are • Matrices (Text Only)
organised, specified, modelled, designed, verified and validated. This KA is • Diagrams (graphical + text)
where different solution options ability to meet business needs are 7.1.1 Diagram Types
explored, potential value is estimated and a recommendation on most • Rationale
effective solution is proposed. • Activity Flow
p7.1 Specify & Model Requirements • People & Roles
.1 Model Requirements (via diagrams and matrices etc) • Capability
.2 Analyse Requirements (Split something large into smaller • Data & Information
components until appropriate for examination) 7.2.1 Characteristics of
.3 Represent requirements & attributes Requirements (FAC CUP CUT)
.4 Implement appropriate levels of abstraction (Level of detail or the • Feasible
‘views’ stakeholders require) • Atomic
p7.2 Verify Requirements (Review by BA’s) • Complete
.1 Characteristics of requirements & design quality • Consistent
.2 Verification Activities • Unambiguous
.3 Checklists • Prioritised
p7.3 Validate Requirements (Review by Stakeholders) • Concise
.1 Identify Assumptions • Understandable
.2 Define Measurable Evaluation Criteria • Testable
.3 Evaluate Alignment with Solution Scope 7.2.2 Verification Activities
p7.4 Define Requirement Architecture (Understand how all requirements • Completeness checks
and design pieces fit together) • Comparison checks
.1 Requirements Viewpoints (how they are modelled e.g. data v • Correctness checks
process) and Views (what is presented to specific shareholders) • Compliance checks
.2 Template Architecture • Terminology checks
.3 Completeness • Examples to clarify
.4 Relate and verify quality of requirement relationships 7.5.4 Design Option Elements
.5 BA Information Architecture • Business policies and rule
p7.5 Define Design Options (Solution Options) • Business Processes
.1 Define Solution Approaches (Create + Buy + Combination) • Affected stakeholders
.2 Identify Improvement Opportunities • Operational business decisions
.3 Requirements Allocation (to solution components + releases) • Software applications
.4 Describe Design Options (including performance measures) • Organisational structures
p7.6 Analyse Potential Value and Recommend Solution 7.6.1 Expected Costs
.1 Expected Benefits (Benefit +ve, Cost –ve, Other value) • Schedule & effort
.2 Expected Costs • Support
.3 Determine Value (to enterprise as a whole outweighs impact on any • Purchase and/or Implementation
particular stakeholder) • Resources
.4 Assess Design Options and Recommend Solution (Assess design • Opportunity
options + rearrange soln components to maximise value)

KA 8: Solution Evaluation [SE>MASER] 8.1.1 Define Solution


To assess the performance and value of an existing solution. To discover Performance Metrics
and recommend removing any barriers or constraints preventing realisation • Quantitative – contains numbers
of solution benefits and value. Existing solution can apply to various • Qualitative – Subjective measures
stages: Prototypes, Pilots and Operational Releases. 8.1.3 Collect Performance
p8.1 Measure Solution Performance Measures considerations
.1 Define Solution Performance Metrics • Volume or sample size
.2 Validate Performance Measures • Frequency and timing
.3 Collect Performance Measures • Currency (recent better than old)
p8.2 Analyse Solution Performance 8.2.1 Insufficient measures
.1 Solution Performance vs Desired Value • Collect more data
.2 Risks • Note lack of measures as a risk
.3 Trends (identified after ensuring quality of data) 8.3.3 Impact Assessment Action
.4 Accuracy (accurate and reproducible and repeatable) • Must be resolved
.5 Performance Variances (If large do root cause analysis) • Might be mitigated
p8.3 Assess Solution Limitation • Can be accepted
.1 Identify Internal Solution Component Dependencies 8.4.1 Enterprise Considerations
.2 Investigate Solution Problems • Culture + Operations + Technical
.3 Impact Assessment (Severity + Probability of occurrence + Impact on components + Stakeholder
operations + Capacity to absorb impact) interests + Reporting structures +
p8.4 Assess Enterprise Limitation External factors
.1 Enterprise Culture Assessment 8.5.2 Recommendations
.2 Stakeholder Impact Analysis (Function +Location +Concerns) • Do nothing
.3 Organisational Structure Changes • Organisational change
.4 Operational Assessment • Reduce Complexity of Interfaces
p8.5 Recommend Action to Increase Solution Value • Eliminate Redundancy
.1 Adjust Solution Performance Measures • Avoid Waste
.2 Recommendations • Identify Additional Capabilities
• Retire the Solution

Technique Master List showing Importance [1]/grey background + Knowledge Areas used in
T:10.01 Acceptance and Evaluation Criteria [1] [RLCM | SA | RADD | SE] T:10.18 Document Analysis [1] [BAPM | EC | RLCM | SA | RADD | SE] T:10.35 Process Modelling [1] [BAPM | EC | RLCM | SA | RADD | SE]
T:10.02 Backlog Management [RLCM | RADD] T:10.19 Estimation [BAPM | EC | RLCM | SA | RADD] T:10.36 Prototyping [EC | SA | RADD | SE]
T:10.03 Balanced Scorecard [SA] T:10.20 Financial Analysis [1] [BAPM | RLCM | SA | RADD | SE] T:10.37 Reviews [BAPM | EC | RLCM | RADD]
T:10.04 Benchmarking and Market Analysis [1] [EC | SA | RADD | SE] T:10.21 Focus Groups [EC | SA | RADD | SE] T:10.38 Risk Analysis and Management [1] [BAPM | EC | RLCM | SA | RADD | SE]
T:10.05 Brainstorming [1] [BAPM | EC | SA | RADD | SE] T:10.22 Functional Decomposition [BAPM | RLCM | SA | RADD] T:10.39 Roles and Permissions Matrix [RADD | SE]
T:10.06 Business Capability Analysis [SA | RADD] T:10.23 Glossary [RADD] T:10.40 Root Cause Analysis [BAPM | SA | RADD | SE]
T:10.07 Business Cases [1] [BAPM | RLCM | SA | RADD | SE] T:10.24 Interface Analysis [EC | RLCM | RADD] T:10.41 Scope Modelling [BAPM | RLCM | SA | RADD]
T:10.08 Business Model Canvas [SA | RADD] T:10.25 Interviews [1] [BAPM | EC | RLCM | SA | RADD | SE] T:10.42 Sequence Diagrams [RADD]
T:10.09 Business Rules Analysis [BAPM | EC | RLCM | RADD | SE] T:10.26 Item Tracking [1] [BAPM | RLCM | SA | RADD | SE] T:10.43 Stakeholder List, Map, or Personas [BAPM | EC | RADD]
T:10.10 Collaborative Games [EC] T:10.27 Lessons Learned [1] [BAPM | EC | SA | RADD | SE] T:10.44 State Modelling [RADD]
T:10.11 Concept Modelling [EC | SA | RADD] T:10.28 Metrics and KPIs [BAPM | SA | RADD | SE] T:10.45 Survey or Questionnaire [1] [BAPM | EC | SA | RADD | SE]
T:10.12 Data Dictionary [RADD] T:10.29 Mind Mapping [1] [BAPM | EC | SA | RADD] T:10.46 SWOT Analysis [SA | RADD | SE]
T:10.13 Data Flow Diagrams [RLCM | RADD] T:10.30 Non-Functional Requirements Analysis [RADD | SE] T:10.47 Use Cases and Scenarios [RLCM | RADD | SE]
T:10.14 Data Mining [EC | SA | SE] T:10.31 Observation [BAPM | EC | SA | SE] T:10.48 User Stories [RLCM | RADD]
T:10.15 Data Modelling [EC | RLCM | RADD] T:10.32 Organizational Modelling [1] [BAPM | SA | RADD | SE] T:10.49 Vendor Assessment [SA | RADD | SE]
T:10.16 Decision Analysis [1] [RLCM | SA | RADD | SE] T:10.33 Priortization [RLCM | SE] T:10.50 Workshops [1] [BAPM | EC | RLCM | SA | RADD | SE]
T:10.17 Decision Modelling [SA | RADD] T:10.34 Process Analysis [BAPM | EC | SA | SE]

Distributed by: <Logos Here>

You might also like