Business Analysis Skill (BABOK v3)

This skill encodes the complete knowledge framework from the BABOK Guide v3 published by the International Institute of Business Analysis (IIBA). It covers six knowledge areas, 30 tasks, 50 techniques, underlying competencies, and five perspectives for applying business analysis in context.

Core Concept Model (BACCM)

The Business Analysis Core Concept Model defines six equal, interdependent concepts fundamental to all BA work:

Core Concept	Definition
Change	The act of transformation in response to a need. Improvements are deliberate and controlled through BA activities.
Need	A problem or opportunity to be addressed. Needs cause changes by motivating stakeholders to act; changes can also cause needs.
Solution	A specific way of satisfying one or more needs in a context. Resolves problems or enables stakeholders to exploit opportunities.
Stakeholder	A group or individual with a relationship to the change, the need, or the solution. Defined by interest, impact, and influence.
Value	The worth, importance, or usefulness of something to a stakeholder within a context. Can be tangible (monetary) or intangible (reputation, morale).
Context	The circumstances that influence, are influenced by, and provide understanding of the change. Includes culture, competitors, technology, regulations, etc.

When any core concept changes, re-evaluate all six concepts and their relationships to value delivery.

Requirements Classification Schema

Type	Description
Business Requirements	Goals, objectives, and outcomes describing why a change was initiated. Apply to the enterprise, a business area, or a specific initiative.
Stakeholder Requirements	Needs of stakeholders that must be met to achieve the business requirements. Bridge between business and solution requirements.
Solution Requirements - Functional	Capabilities a solution must have in terms of behaviour and information it will manage.
Solution Requirements - Non-Functional	Conditions under which a solution must remain effective or qualities it must have (performance, security, usability, reliability, scalability).
Transition Requirements	Temporary capabilities needed to move from current state to future state (data conversion, training, business continuity). Not needed once change is complete.

Stakeholder Roles

Role	Description
Business Analyst	Responsible and accountable for execution of BA activities.
Customer	Uses or may use products/services; may have contractual or moral rights the enterprise must meet.
Domain Subject Matter Expert	Individual with in-depth knowledge of a topic relevant to the business need or solution scope.
End User	Directly interacts with the solution.
Implementation SME	Has specialized knowledge regarding the implementation of solution components (developers, DBAs, architects, etc.).
Operational Support	Responsible for day-to-day management and maintenance of a solution or system.
Project Manager	Manages the work to deliver a solution that meets the business need. Coordinates BA timelines and resources.
Regulator	Responsible for defining and enforcing standards. Includes government, regulatory bodies, and auditors.
Sponsor	Authorizes the change, controls budget and scope, makes final decisions. Accountable for business case.
Supplier	Provides products or services to the enterprise.
Tester	Responsible for determining how to verify that the solution meets requirements and identifies defects.

---

Knowledge Area 1: Business Analysis Planning and Monitoring

Describes how business analysts organize and coordinate BA work with stakeholders. Outputs serve as key inputs and guidelines for all other knowledge areas.

Tasks

1.1 Plan Business Analysis Approach

• Purpose: Define how BA work will be conducted for the initiative.
• Key Decision: Predictive vs. Adaptive approach (or hybrid).
  • Predictive: Minimize upfront uncertainty; define solution before implementation; formal documentation with standardized templates; tasks in specific phases. Best when requirements can be defined ahead, risk of incorrect implementation is high, or stakeholder engagement is challenging.
  • Adaptive: Rapid value delivery in short iterations; accept higher uncertainty; requirements gathered through team interaction and feedback; mandatory deliverables limited to prioritized backlog. Best for exploratory work or incremental improvement.
• Elements: Planning approach, formality/detail level, BA activities, timing of work, complexity and risk assessment, acceptance/sign-off.
• Factors increasing formality: Complex/high-risk change, regulated industries, contracts, distributed stakeholders, outsourced resources, high turnover, formal sign-off needed, long-term maintenance.
• Techniques: Brainstorming, Business Cases, Document Analysis, Estimation, Financial Analysis, Functional Decomposition, Interviews, Item Tracking, Lessons Learned, Process Modelling, Reviews, Risk Analysis, Scope Modelling, Survey/Questionnaire, Workshops.
• Output: Business Analysis Approach.

1.2 Plan Stakeholder Engagement

• Purpose: Plan an approach for establishing and maintaining effective working relationships with stakeholders.
• Elements: Stakeholder identification and analysis, stakeholder collaboration, stakeholder communication needs.
• Key activities: Identify stakeholders, analyze characteristics (authority, attitude, influence), define collaboration approach, plan communication.
• Techniques: Brainstorming, Business Rules Analysis, Document Analysis, Interviews, Lessons Learned, Mind Mapping, Organizational Modelling, Process Modelling, Risk Analysis, Scope Modelling, Stakeholder List/Map/Personas, Survey/Questionnaire, Workshops.
• Output: Stakeholder Engagement Approach.

1.3 Plan Business Analysis Governance

• Purpose: Define the components of BA governance - how decisions are made about requirements and designs, including change control and approvals.
• Elements: Decision making, change control process, plan prioritization approach, plan for approvals.
• Output: Governance Approach.

1.4 Plan Business Analysis Information Management

• Purpose: Develop an approach for how BA information will be stored, accessed, and maintained throughout the initiative.
• Elements: Organization of BA information, level of abstraction, traceability approach, reuse of requirements, storage and access, requirements attributes.
• Common attributes: Absolute reference (unique ID), author, complexity, ownership, priority, risks, source, stability, status, urgency.
• Output: Information Management Approach.

1.5 Identify Business Analysis Performance Improvements

• Purpose: Assess BA work and plan improvements to processes, deliverables, and resources.
• Elements: Performance analysis, assessment measures, analyze results, recommend actions.
• Output: Business Analysis Performance Assessment.

---

Knowledge Area 2: Elicitation and Collaboration

Describes how BAs prepare for and conduct elicitation, confirm results, communicate information, and manage stakeholder collaboration.

Three Types of Elicitation

1. Collaborative: Direct interaction with stakeholders relying on their experience, expertise, and judgment.
2. Research: Systematically discovering information from materials or sources not directly known by stakeholders (document analysis, data analysis of historical data).
3. Experiments: Identifying information through controlled tests (observational studies, proofs of concept, prototypes).

Tasks

2.1 Prepare for Elicitation

• Purpose: Ensure that stakeholders, resources, and techniques are ready to produce the best possible results.
• Elements: Understand scope of elicitation, select techniques, set up logistics, secure supporting material, prepare stakeholders.
• Logistics checklist: Goals, participants and roles, scheduled resources (people/rooms/tools), locations, communication channels, techniques, languages used.
• Techniques: Brainstorming, Data Mining, Document Analysis, Estimation, Interviews, Mind Mapping, Risk Analysis, Stakeholder List/Map/Personas.
• Output: Elicitation Activity Plan.

2.2 Conduct Elicitation

• Purpose: Draw out, explore, and identify information relevant to the change.
• Elements: Guide elicitation activity, capture elicitation outcomes, handle incomplete results.
• Key considerations: Activity goals/agenda, scope of change, output forms, integration with existing knowledge, information providers and consumers.
• Techniques: Benchmarking, Brainstorming, Business Rules Analysis, Collaborative Games, Concept Modelling, Data Mining, Data Modelling, Document Analysis, Focus Groups, Interface Analysis, Interviews, Mind Mapping, Observation, Process Analysis, Process Modelling, Prototyping, Survey/Questionnaire, Workshops.
• Output: Elicitation Results (unconfirmed).

2.3 Confirm Elicitation Results

• Purpose: Verify that elicitation results are accurate, consistent, and represent stakeholder intent.
• Elements: Compare results against source, compare results against other results.
• Techniques: Document Analysis, Interviews, Reviews, Workshops.
• Output: Elicitation Results (confirmed).

2.4 Communicate Business Analysis Information

• Purpose: Ensure stakeholders have shared understanding of BA information and that it is presented appropriately.
• Elements: Determine objectives, select format and approach (formal vs. informal, written vs. verbal), communicate BA package.
• Techniques: Interviews, Reviews, Workshops.
• Output: Business Analysis Information (communicated).

2.5 Manage Stakeholder Collaboration

• Purpose: Encourage stakeholders to work cooperatively to achieve the goals of the change.
• Elements: Gain agreement on commitments, monitor stakeholder engagement, collaborate.
• Techniques: Collaborative Games, Interviews, Lessons Learned, Risk Analysis, Stakeholder List/Map/Personas, Workshops.
• Output: Stakeholder Engagement (managed).

---

Knowledge Area 3: Requirements Life Cycle Management

Manages requirements and design information from inception to retirement.

Tasks

3.1 Trace Requirements

• Purpose: Ensure requirements and designs are aligned at different levels and can be tracked throughout the change lifecycle.
• Types of traceability:
  • Derive: Requirement transforms into next-level requirement.
  • Depends: Requirement relies on another to be fulfilled.
  • Satisfy: Design option satisfies a requirement.
  • Validate: Requirement is validated by a test case.
• Traceability matrix: Tracks relationships between requirements at different levels (business -> stakeholder -> solution -> transition).
• Techniques: Business Rules Analysis, Functional Decomposition, Process Modelling, Scope Modelling.
• Output: Requirements (traced), Designs (traced).

3.2 Maintain Requirements

• Purpose: Keep requirements accurate, current, and usable throughout the lifecycle.
• Elements: Maintain requirements attributes, reuse requirements.
• Key attributes to maintain: Status, source, priority, complexity, ownership, stability.
• Output: Requirements (maintained), Designs (maintained).

3.3 Prioritize Requirements

• Purpose: Rank requirements in order of relative importance to stakeholders.
• Prioritization basis: Benefit, penalty (for not including), cost, risk, dependencies, time sensitivity, stability, regulatory/policy compliance.
• Techniques: Backlog Management, Business Cases, Decision Analysis, Estimation, Financial Analysis, Interviews, Item Tracking, Prioritization, Risk Analysis, Workshops.
• Output: Requirements (prioritized), Designs (prioritized).

3.4 Assess Requirements Changes

• Purpose: Evaluate implications of proposed changes to requirements and designs.
• Impact analysis considers: Benefit, cost (including rework and opportunity costs), impact (number of customers/processes affected), schedule, urgency.
• Assessment formality: Predictive approaches need more formal assessment; adaptive approaches may require less formality due to iterative nature.
• Output: Requirements Change Assessment.

3.5 Approve Requirements

• Purpose: Obtain agreement and approval of requirements and designs for BA work to continue.
• Elements: Understand stakeholder roles in approvals, conflict and issue management, gain consensus, track and communicate approvals.
• Output: Requirements (approved), Designs (approved).

---

Knowledge Area 4: Strategy Analysis

Identifies needs of strategic or tactical importance, enables the enterprise to address those needs, and aligns strategies.

Tasks

4.1 Analyze Current State

• Purpose: Understand the reasons why an enterprise needs to change and what is directly affected by the change.
• Elements:
  • Business Needs: Problems/opportunities of strategic importance. Define from enterprise perspective, not individual stakeholder. Sources: top-down (strategic goals), bottom-up (process problems), middle management (information gaps), external drivers (customer demand, competition).
  • Organizational Structure and Culture: Reporting structures, beliefs, values, norms, cultural assessment.
  • Capabilities and Processes: What the enterprise does, its knowledge, products/services, decision methods. Capability-centric view (for innovative solutions) vs. Process-centric view (for performance improvement).
  • Technology and Infrastructure: Information systems, physical components.
  • Policies: Decision-making scope, routine operations governance.
  • Business Architecture: How all elements fit together and support one another.
  • Internal Assets: Tangible and intangible resources (financial, patents, reputation, brand).
  • External Influencers: Industry structure, competitors, customers, suppliers, political/regulatory environment, technology trends, macroeconomic factors.
• Techniques: Benchmarking/Market Analysis (5 Forces, PEST, STEEP, CATWOE), Business Capability Analysis, Business Model Canvas, Business Cases, Concept Modelling, Data Mining, Document Analysis, Financial Analysis, Focus Groups, Functional Decomposition, Interviews, Item Tracking, Lessons Learned, Mind Mapping, Observation, Organizational Modelling, Process Analysis, Process Modelling, Risk Analysis, Root Cause Analysis, Scope Modelling, Survey/Questionnaire, SWOT Analysis, Workshops.
• Output: Current State Description, Business Requirements.

4.2 Define Future State

• Purpose: Determine the set of necessary conditions to meet the business need.
• Elements:
  • Business Objectives: SMART goals (Specific, Measurable, Achievable, Relevant, Time-bounded).
  • Potential Value: Expected benefits quantified where possible.
  • Constraints and Assumptions: Limitations on solutions and beliefs not yet confirmed.
  • Future State Description: Vision of what the enterprise will look like after the change.
• Output: Business Objectives, Future State Description, Potential Value.

4.3 Assess Risks

• Purpose: Understand undesirable consequences of internal and external forces during or after transition.
• Risk analysis covers: Consequences, impact, likelihood, potential timeframe.
• Risk tolerance categories:
  • Risk-averse: Unwilling to accept uncertainty; avoid or mitigate.
  • Neutral: Acceptable if no net loss even if risks occur.
  • Risk-seeking: Accept more risk for higher potential value.
• Elements: Unknowns, constraints/assumptions/dependencies, negative impact to value, risk tolerance, recommendation.
• Recommendation options: Pursue regardless, pursue while investing in risk reduction, seek ways to increase benefits, manage/optimize opportunities, do not pursue.
• Techniques: Brainstorming, Business Cases, Decision Analysis, Document Analysis, Financial Analysis, Interviews, Lessons Learned, Mind Mapping, Risk Analysis, Root Cause Analysis, Stakeholder List/Map/Personas, Workshops.
• Output: Risk Analysis Results.

4.4 Define Change Strategy

• Purpose: Develop and assess alternative approaches to the change and select the recommended approach.
• Elements: Solution scope, gap analysis, enterprise readiness assessment, change strategy, transition states and release planning.
• Gap analysis: Compare current state to future state systematically; identify what needs to change, what stays, what is new, what is removed.
• Enterprise readiness: Assess stakeholder willingness and ability, cultural alignment, operational preparedness.
• Output: Change Strategy, Solution Scope.

---

Knowledge Area 5: Requirements Analysis and Design Definition

Structure, organize, specify, model, validate, verify requirements and define solution design options.

Tasks

5.1 Specify and Model Requirements

• Purpose: Analyze, synthesize, and refine elicitation results into requirements and designs.
• Modelling approaches: Text-based (natural language, structured text), matrix-based (traceability, CRUD), diagrammatic (process models, data models, use case diagrams).
• Modelling notations: UML, BPMN, ERD, data flow diagrams, state diagrams, context diagrams.
• Output: Requirements (specified and modelled), Designs (specified and modelled).

5.2 Verify Requirements

• Purpose: Ensure requirements and designs are defined correctly and are of sufficient quality.
• Quality characteristics (requirements should be):
  • Atomic: Self-contained, not decomposable.
  • Complete: Sufficient to guide further work.
  • Consistent: No contradictions with other requirements.
  • Concise: No unnecessary content.
  • Feasible: Reasonable and possible within constraints.
  • Unambiguous: Only one possible interpretation.
  • Testable: Can be verified through testing.
  • Prioritized: Ranked by importance.
  • Understandable: By all stakeholders.
• Output: Requirements (verified), Designs (verified).

5.3 Validate Requirements

• Purpose: Ensure requirements and designs align to the business requirements and deliver value.
• Key question: “If this requirement is met, does it contribute to delivering the needed value?”
• Elements: Identify assumptions, define measurable evaluation criteria, evaluate alignment.
• Output: Requirements (validated), Designs (validated).

5.4 Define Requirements Architecture

• Purpose: Ensure the set of requirements collectively supports the overall objectives.
• Elements: Viewpoints (process models, data models, user interactions, audit/security, business models), template architectures, completeness, relate and verify relationships.
• Output: Requirements Architecture.

5.5 Define Design Options

• Purpose: Define solution approach, identify improvement opportunities, allocate requirements to components, represent design options.
• Solution approaches: Create (build), Purchase (COTS/SaaS), Combination.
• Improvement opportunities: Increase efficiencies (automate/simplify), improve access to information, identify additional capabilities.
• Requirements allocation: Assign requirements to solution components, organizational units, job functions, or releases.
• Output: Design Options.

5.6 Analyze Potential Value and Recommend Solution

• Purpose: Estimate value for each design option and determine which best meets requirements.
• Elements: Expected benefits, expected costs, determine value, assess constraints/assumptions, recommend best option.
• Value analysis methods: Cost-benefit analysis, ROI, NPV, IRR, payback period.
• Output: Solution Recommendation.

---

Knowledge Area 6: Solution Evaluation

Assess the performance and value delivered by a solution in use, and recommend improvements.

Tasks

6.1 Measure Solution Performance

• Purpose: Define performance measures and use them to assess the effectiveness of a solution.
• Performance measures: Quantitative (cycle time, throughput, revenue, cost) and qualitative (customer satisfaction, employee morale).
• Elements: Define performance measures, collect metrics, validate measures.
• Output: Solution Performance Measures.

6.2 Analyze Performance Measures

• Purpose: Examine solution performance data to understand the value delivered and identify areas for improvement.
• Elements: Compare performance to expected value, identify variances, investigate root causes.
• Output: Solution Performance Analysis.

6.3 Assess Solution Limitations

• Purpose: Determine internal factors of the solution that restrict value realization.
• Elements: Identify and categorize solution limitations (constraints, defects, capability gaps).
• Techniques: Acceptance Criteria, Benchmarking, Business Rules Analysis, Data Mining, Decision Analysis, Interviews, Item Tracking, Lessons Learned, Risk Analysis, Root Cause Analysis, Survey/Questionnaire.
• Output: Solution Limitation.

6.4 Assess Enterprise Limitations

• Purpose: Determine how factors external to the solution restrict value realization.
• Elements:
  • Enterprise Culture Assessment: Do stakeholders understand and support the solution?
  • Stakeholder Impact Analysis: How does solution affect each stakeholder group (functions, locations, concerns)?
  • Organizational Structure Changes: Does structure enable or block solution adoption?
  • Operational Assessment: Are operations aligned to support the solution?
• Output: Enterprise Limitation.

6.5 Recommend Actions to Increase Solution Value

• Purpose: Recommend actions to increase solution value based on identified limitations and performance gaps.
• Options: Do nothing, organizational change, remove or increase solution capabilities, retire the solution, replace the solution, new opportunity (apply solution to new contexts).
• Output: Recommendation (actions to increase value).

---

Techniques Reference (All 50)

Elicitation Techniques

Technique	Purpose	When to Use
Brainstorming (10.5)	Generate a broad set of options through rapid, uncritical idea generation.	Early in initiatives to identify options, requirements, risks. Works well in groups of 5-10 people.
Collaborative Games (10.10)	Develop a better understanding of a problem or stimulate creative solutions using structured game-like activities.	When stakeholders are stuck, engagement is low, or traditional techniques have failed.
Document Analysis (10.18)	Examine existing documentation to elicit requirements.	When a current system exists and documentation is available; gap analysis between current and desired state.
Focus Groups (10.21)	Solicit feedback from a prequalified group of stakeholders to identify attitudes, ideas, and issues.	When exploring attitudes, preferences, or needs of a specific stakeholder segment. Typically 6-12 participants.
Interviews (10.25)	Systematic approach to elicit information by asking relevant questions and documenting responses.	Most versatile technique; use for any elicitation need. Structured (predetermined questions), semi-structured, or unstructured.
Mind Mapping (10.29)	Articulate and capture thoughts, ideas, and information in a visual, non-linear format.	When exploring a new topic, capturing brainstorming results, organizing complex information.
Observation (10.31)	Elicit information by viewing activities and their context.	When understanding real (not reported) workflows, identifying undocumented processes. Active (ask questions) vs. Passive (silent watching).
Prototyping (10.36)	Elicit and validate needs through iterative creation of a model or design.	When stakeholders cannot articulate needs abstractly, for UI/UX design, to reduce risk. Throwaway (exploratory) vs. Evolutionary (built upon).
Survey or Questionnaire (10.45)	Elicit information from a group in a structured way in a short time.	When stakeholder population is large, dispersed, or time is limited. Use closed questions for quantitative data, open for qualitative.
Workshops (10.50)	Bring stakeholders together for structured, facilitated collaboration toward a predefined goal.	When cross-functional input is needed, decisions require group agreement, or intensive collaboration is valuable.

Analysis and Modeling Techniques

Technique	Purpose	When to Use
Business Capability Analysis (10.6)	Provide a framework for scoping and planning including identifying gaps and prioritizing by value and risk.	Strategic planning, assessing enterprise capabilities against future needs.
Business Cases (10.7)	Provide justification for a course of action based on benefits vs. costs.	Decision points about whether to proceed with a change. Includes feasibility study and cost-benefit analysis.
Business Model Canvas (10.8)	Understand value proposition, delivery factors, and resulting cost/revenue streams.	Understanding or redesigning business models. Nine building blocks: key partners, activities, resources, value propositions, customer relationships, channels, customer segments, cost structure, revenue streams.
Business Rules Analysis (10.9)	Identify, express, validate, refine, and organize business rules.	When capturing business logic, constraints, and governance rules. Definitional rules (what is true) vs. Behavioural rules (obligations/prohibitions).
Concept Modelling (10.11)	Capture key terms and concepts in a domain and define relationships between them.	Early in analysis to establish shared domain vocabulary.
Data Dictionary (10.12)	Define data elements, their meanings, and allowable values.	When specifying data-related requirements; supports data modelling and interface analysis.
Data Flow Diagrams (10.13)	Show where data comes from, which activities process it, and where outputs go.	Understanding system boundaries, data transformations, and interfaces. Context diagram (highest level) decomposed into level 1, 2, etc.
Data Mining (10.14)	Find useful patterns and insights from large data sets to improve decision making.	When historical data exists and patterns/trends need discovery. Descriptive (clustering), Diagnostic (decision trees), Predictive (regression, neural networks).
Data Modelling (10.15)	Describe data structures and relationships in a standardized format.	Defining data requirements. Entity-relationship diagrams (ERD), conceptual/logical/physical models.
Decision Analysis (10.16)	Examine and model consequences of different decisions to find optimal choice under uncertainty.	When choosing among alternatives. Methods include decision tables, decision trees, multi-criteria analysis, weighted scoring.
Decision Modelling (10.17)	Show how repeatable business decisions are made including required information and knowledge.	When analyzing complex decisions with multiple factors. Decision Requirements Diagrams (DRD), Decision tables.
Estimation (10.19)	Forecast cost and effort for proposed work.	Planning and budgeting. Techniques include analogous (historical), parametric (mathematical), bottom-up, three-point (optimistic/most likely/pessimistic), Delphi.
Financial Analysis (10.20)	Assess financial viability and compare alternatives.	Evaluating investment options. Methods: Cost-Benefit Analysis, NPV, IRR, Payback Period, ROI, Discounted Cash Flow.
Functional Decomposition (10.22)	Break a complex system into simpler component parts.	Understanding scope, organizing work, decomposing processes or functions hierarchically.
Interface Analysis (10.24)	Identify interfaces between solutions, components, or systems.	When integrating systems, defining data exchanges, or understanding touch points between organizational units.
Non-Functional Requirements Analysis (10.30)	Define how well functional requirements must perform.	Specifying quality attributes. Categories: Availability, Compatibility, Functionality, Maintainability, Performance, Portability, Reliability, Scalability, Security, Usability.
Organizational Modelling (10.32)	Describe roles, responsibilities, and reporting structures and align with goals.	Understanding organizational impact of change, defining RACI matrices, stakeholder analysis.
Process Analysis (10.34)	Assess a process for efficiency and effectiveness and identify improvement opportunities.	When optimizing existing processes. Metrics: cycle time, cost per transaction, error rates, throughput, capacity utilization.
Process Modelling (10.35)	Standardized graphical model showing how work is carried out.	Documenting current or future state processes. Notations: BPMN, flowcharts, value stream maps, swimlane diagrams.
Root Cause Analysis (10.40)	Identify and evaluate underlying causes of a problem.	When symptoms suggest deeper issues. Methods: Fishbone/Ishikawa diagram, 5 Whys, Cause-and-Effect analysis.
Scope Modelling (10.41)	Define boundaries and place elements inside or outside them.	Defining what is in/out of scope. Context diagrams, use case diagrams, feature trees.
Sequence Diagrams (10.42)	Model logic of usage scenarios showing information passed between objects.	Detailed design of system interactions, understanding message flows in a use case.
State Modelling (10.44)	Describe different possible states of an entity and how it transitions between them.	When entities have complex lifecycles (orders, claims, accounts). State diagrams, state tables.
SWOT Analysis (10.46)	Evaluate Strengths, Weaknesses, Opportunities, and Threats.	Strategic planning, current state analysis. Internal factors (S/W) vs. External factors (O/T).
Use Cases and Scenarios (10.47)	Describe how a person or system interacts with the solution to achieve a goal.	Functional requirements definition. Elements: actors (primary/secondary), preconditions, trigger, flow of events (main/alternative/exception), post-conditions.
User Stories (10.48)	Small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.	Agile/adaptive approaches. Format: “As a [role], I want [goal] so that [benefit].” Include acceptance criteria.

Management and Governance Techniques

Technique	Purpose	When to Use
Acceptance and Evaluation Criteria (10.1)	Define requirements a solution must meet for stakeholder acceptance.	Defining done/acceptance criteria for requirements, stories, or solutions.
Backlog Management (10.2)	Record, track, and prioritize outstanding work items.	Agile/iterative approaches; ongoing prioritization and grooming of work items.
Balanced Scorecard (10.3)	Manage strategy implementation by monitoring performance from four perspectives (financial, customer, internal process, learning/growth).	Strategic performance monitoring and KPI alignment.
Benchmarking and Market Analysis (10.4)	Compare decisions, processes, or metrics to leading peers or market trends.	Identifying improvement opportunities. Frameworks: Porter’s 5 Forces, PEST/STEEP analysis, CATWOE.
Glossary (10.23)	Define business terminology used across an initiative.	Ensuring consistent vocabulary among stakeholders.
Item Tracking (10.26)	Capture and assign responsibility for issues and concerns.	Throughout all BA work; tracking action items, issues, risks, and decisions (RAID log).
Lessons Learned (10.27)	Document successes, failures, and recommendations for future work.	At end of phases or initiatives; retrospectives.
Metrics and KPIs (10.28)	Measure performance of solutions and other matters of interest.	Defining success measures, performance monitoring. Indicators should be specific, measurable, and aligned to objectives.
Prioritization (10.33)	Framework for stakeholder decisions on relative importance.	Methods: MoSCoW (Must/Should/Could/Won’t), Timeboxing/Budgeting, Multi-criteria weighting, Ranking, Negotiation/Voting.
Reviews (10.37)	Evaluate content of a work product.	Quality assurance for any BA deliverable. Types: Informal, Peer, Walkthrough, Inspection, Audit.
Risk Analysis and Management (10.38)	Identify, analyze, and manage areas of uncertainty.	Ongoing throughout all knowledge areas. Steps: Identify, Analyze (likelihood x impact), Plan Response (avoid, transfer, mitigate, accept), Monitor.
Roles and Permissions Matrix (10.39)	Ensure coverage of activities by denoting responsibility.	RACI matrices (Responsible, Accountable, Consulted, Informed). Access control and authorization models.
Stakeholder List, Map, or Personas (10.43)	Analyze stakeholders and their characteristics.	Stakeholder engagement planning. Tools: Stakeholder list (role, responsibility, authority), Power/Interest grid, Onion diagram, Personas.
Vendor Assessment (10.49)	Assess vendor ability to meet commitments.	Evaluating COTS solutions, outsourcing decisions. Criteria: cost, reputation, viability, support, licensing, technical fit.

---

Underlying Competencies

1. Analytical Thinking and Problem Solving

• Creative Thinking: Generate novel solutions; challenge assumptions; look at problems from new angles.
• Decision Making: Make good decisions based on available information; handle ambiguity; balance analysis with action.
• Learning: Rapidly absorb and apply new domain knowledge; self-directed learning.
• Problem Solving: Define problems clearly; identify root causes; develop and evaluate alternatives systematically.
• Systems Thinking: Understand how parts of an enterprise interrelate; see the big picture; anticipate ripple effects of changes.
• Conceptual Thinking: Find patterns and connections between situations not obviously related; abstract from specifics.
• Visual Thinking: Use visual aids (diagrams, models, sketches) to organize and communicate complex information.

2. Behavioural Characteristics

• Ethics: Behave ethically and professionally; avoid conflicts of interest; maintain confidentiality.
• Personal Accountability: Take responsibility for outcomes; follow through on commitments.
• Trustworthiness: Build trust through consistent, honest behaviour; act with integrity.
• Organization and Time Management: Manage time effectively; prioritize tasks; manage multiple concurrent efforts.
• Adaptability: Adjust approach to changing circumstances; be comfortable with ambiguity and change.

3. Business Knowledge

• Business Acumen: Understand business fundamentals (finance, operations, strategy); speak the language of the business.
• Industry Knowledge: Understand trends, practices, and competitive dynamics in the relevant industry.
• Organization Knowledge: Understand the enterprise’s structure, culture, products, services, and key stakeholders.
• Solution Knowledge: Understand the capabilities and limitations of existing solutions; be aware of emerging technologies.
• Methodology Knowledge: Understand common methodologies (Agile, Waterfall, Lean, Six Sigma) and when to apply them.

4. Communication Skills

• Verbal Communication: Express ideas clearly in spoken form; adapt message to audience; active listening.
• Non-Verbal Communication: Read and use body language, facial expressions, tone of voice appropriately.
• Written Communication: Produce clear, concise, and well-organized written artifacts (documents, emails, models).
• Listening: Actively attend to what others say; ask clarifying questions; paraphrase to confirm understanding.

5. Interaction Skills

• Facilitation: Guide groups through structured processes to achieve outcomes; manage group dynamics and conflict.
• Leadership and Influencing: Motivate stakeholders; build consensus; drive action without positional authority.
• Teamwork: Collaborate effectively; value diverse perspectives; contribute to team goals.
• Negotiation and Conflict Resolution: Mediate differences; identify underlying interests behind stated positions; find win-win solutions.
• Teaching: Communicate information and concepts so stakeholders understand and retain them; use appropriate teaching methods (visual, verbal, written, kinesthetic).

6. Tools and Technology

• Office Productivity Tools: Word processing, spreadsheets, presentations, email, collaboration platforms.
• BA-Specific Tools: Requirements management, modelling/diagramming, issue tracking, prototyping, simulation.
• Communication Tools: Video conferencing, instant messaging, wikis, document repositories.

---

Stakeholder Analysis Framework

Step 1: Identify Stakeholders

• List all individuals and groups affected by or who can affect the change.
• Sources: Organizational charts, project charters, enterprise architecture, previous similar initiatives, sponsor input.

Step 2: Analyze Stakeholder Characteristics

Characteristic	Description
Authority Level	Decision-making power and influence within the organization.
Attitude Toward Change	Supportive, neutral, or resistant; level of enthusiasm.
Degree of Influence	Ability to affect the outcome (formally or informally).
Level of Interest	How concerned the stakeholder is about the outcome.
Domain Knowledge	Depth of knowledge about the problem domain.
Communication Preferences	Preferred methods, frequency, and formality of communication.

Step 3: Classify Using Power/Interest Grid

	High Interest	Low Interest
High Power	Manage Closely (key players)	Keep Satisfied
Low Power	Keep Informed	Monitor

Step 4: Plan Engagement

• Define collaboration approach for each stakeholder group.
• Plan communication frequency, format, and content.
• Identify potential risks (resistance, disengagement) and mitigation strategies.
• Assign responsibility for stakeholder relationships.

Alternative Classification Tools

• Onion Diagram: Concentric circles showing proximity to the solution (innermost = direct interaction).
• RACI Matrix: Responsible, Accountable, Consulted, Informed for each task or deliverable.
• Personas: Fictional representative profiles capturing demographics, goals, behaviours, and pain points.

---

Perspectives

Agile Perspective

• Context: Adaptive planning, short iterations, rapid value delivery, continuous feedback.
• Key roles: Product Owner (owns backlog, makes priority decisions), Agile Team Leader/Scrum Master (facilitator, servant leader), Team Members (cross-functional, self-organizing).
• BA role in Agile: May be product owner, may be embedded team member, may work across multiple teams. Focus shifts from documentation to communication and collaboration.
• Key practices: User stories with acceptance criteria, backlog grooming/refinement, iteration planning, retrospectives, daily standups, working software over comprehensive documentation.
• Planning: Adaptive, with rolling wave planning; product roadmap (strategic), release plan (tactical), iteration plan (operational).
• Requirements: Primarily user stories; elaborated just-in-time; acceptance criteria serve as validation; models used when they add value.
• Change management: Continuous; backlog is always subject to re-prioritization; scope is variable while time and cost are fixed.
• Assumptions: Fully engaged customers, constant team membership, co-located or well-supported distributed teams, empowered self-organizing teams, mindset for continuous improvement.

Business Intelligence Perspective

• Context: Data-centric solutions; decision support; analytics; data warehousing.
• BA roles: Business analyst, BI functional analyst, data analyst, data modeller/architect.
• Key outcomes: Business process coverage, decision models, source/target logical data models, data dictionaries, data quality assessments, ETL specifications, dashboard/report designs.
• Emphasis: Decision requirements analysis, data modelling (conceptual/logical/physical), data quality assessment, understanding information needs of business stakeholders, defining KPIs and metrics.
• Techniques: Data Mining, Decision Modelling, Data Modelling, Data Dictionary, Metrics and KPIs, Non-Functional Requirements Analysis, Document Analysis, Financial Analysis, Benchmarking.

Information Technology Perspective

• Context: Technology-centric solutions; software development; system integration.
• Change sponsors: CIO, IT steering committee, process owner, business owner, product manager, regulatory representative.
• BA position variations: Business analyst, IT business analyst, SME, software user, systems analyst, business process owner, technical person, COTS representative.
• Key activities: Requirements for application changes, system interfaces, data migration, integration, user acceptance testing.
• Emphasis: Functional and non-functional requirements, interface analysis, use cases, process models, data models, system context diagrams, prototyping, solution architecture alignment.

Business Architecture Perspective

• Context: Enterprise-wide strategic planning; capability mapping; value stream analysis.
• Key techniques:
  • Capability Map: Hierarchical catalogue categorized as strategic, core, and supporting.
  • Value Stream Map: End-to-end view of activities creating value for stakeholders.
  • Business Model Canvas: Nine building blocks for understanding how the enterprise creates/delivers/captures value.
  • Customer Journey Map: Touch points and stakeholder interactions through service delivery.
  • Information Map: Business concepts associated with capabilities.
• Reference models: ACORD (insurance), BMM (generic), COBIT (IT governance), eTOM (telecom), FEA SRM (government), ITIL (IT service management), PCF (multi-sector), SCOR (supply chain), VRM (value chain).
• Additional techniques: Archimate modelling, Business Motivation Model, Business Process Architecture, Enterprise Core Diagram.

Business Process Management Perspective

• Context: Process-centric improvement; operational excellence; continuous optimization.
• Key activities: Process discovery, process analysis, process design, process implementation, process monitoring.
• Emphasis: End-to-end process visibility, process performance metrics, process standardization, automation opportunities, compliance alignment.
• Techniques: Process Analysis, Process Modelling (BPMN), Benchmarking, Root Cause Analysis, Metrics/KPIs, Functional Decomposition.

---

Decision Frameworks

Which Elicitation Technique to Use

Situation	Recommended Techniques
Requirements are completely unknown	Interviews, Workshops, Observation, Brainstorming
Need to understand existing system	Document Analysis, Observation, Interface Analysis
Large stakeholder population	Survey/Questionnaire, Focus Groups
Need visual/interactive feedback	Prototyping, Collaborative Games, Mind Mapping
Data-driven discovery	Data Mining, Document Analysis
Validating previously gathered info	Reviews, Workshops, Prototyping
Remote/distributed stakeholders	Survey/Questionnaire, Interviews (virtual)
Need to discover hidden knowledge	Observation, Collaborative Games
Complex decision logic	Decision Analysis, Decision Modelling, Business Rules Analysis

Which Modeling Technique to Use

What You Need to Model	Recommended Techniques
Business processes/workflows	Process Modelling (BPMN), Data Flow Diagrams, Swimlane diagrams
Data and relationships	Data Modelling (ERD), Data Dictionary, Concept Modelling
System interactions	Sequence Diagrams, Use Cases, Interface Analysis
Entity lifecycles	State Modelling
Organization and roles	Organizational Modelling, RACI, Roles and Permissions Matrix
Scope and boundaries	Scope Modelling, Context Diagrams
Business logic and decisions	Business Rules Analysis, Decision Modelling, Decision Tables
Functional hierarchy	Functional Decomposition
Strategic landscape	SWOT, Business Model Canvas, Balanced Scorecard, Business Capability Analysis

Prioritization Methods

Method	Description	Best For
MoSCoW	Must have, Should have, Could have, Won’t have (this time)	Release planning, time-boxed iterations
Timeboxing/Budgeting	Allocate fixed time/budget; fit highest-priority items in	Agile sprints, constrained resources
Weighted Scoring	Assign weights to criteria, score each item, calculate totals	Comparing many items across multiple factors
Ranking	Force rank items from highest to lowest priority	Simple prioritization with small item sets
Kano Model	Classify as Must-be, One-dimensional, Attractive, Indifferent, Reverse	Product feature prioritization, UX decisions
Buy a Feature	Stakeholders “buy” features with limited currency	Getting stakeholder investment/trade-off decisions
100-Dollar Test	Stakeholders distribute $100 across options	Quick group prioritization

---

Templates and Structures

Business Requirements Document (BRD)

1. Executive Summary
2. Business Objectives and Success Criteria
3. Current State Analysis
4. Stakeholder Analysis
5. Scope (In-scope / Out-of-scope)
6. Business Requirements
7. Assumptions and Constraints
8. Risk Assessment
9. Appendices (Glossary, Supporting Models)

Stakeholder Requirements Specification

1. Stakeholder Identification and Roles
2. Stakeholder Needs (grouped by stakeholder)
3. Use Cases or User Stories
4. Business Rules
5. Acceptance Criteria
6. Traceability to Business Requirements

Solution Requirements Specification

1. Functional Requirements (organized by feature/capability)
2. Non-Functional Requirements (performance, security, usability, etc.)
3. Interface Requirements
4. Data Requirements (models, dictionaries)
5. Business Rules
6. Traceability Matrix
7. Design Constraints
8. Assumptions and Dependencies

Business Case Template

1. Executive Summary
2. Problem/Opportunity Statement
3. Analysis of Current State
4. Proposed Solution Options (with pros/cons)
5. Cost-Benefit Analysis for Each Option
6. Risk Assessment
7. Recommended Solution with Justification
8. Implementation Approach
9. Success Metrics
10. Assumptions and Constraints

Change Impact Assessment

1. Description of Proposed Change
2. Affected Requirements (with traceability)
3. Impact Analysis: Benefit, Cost, Schedule, Risk
4. Affected Stakeholders
5. Dependencies
6. Recommendation (approve, defer, reject)

User Story Format

As a [stakeholder role],
I want [goal/desire],
So that [benefit/value].

Acceptance Criteria:
- Given [context], when [action], then [expected result].
- Given [context], when [action], then [expected result].

Requirements Traceability Matrix

Req ID	Business Req	Stakeholder Req	Solution Req	Design Component	Test Case	Status
BR-001	…	SR-001	SLR-001	DC-001	TC-001	Approved

---

Quick Reference: Task-to-Technique Mapping

Most Commonly Used Techniques Across All Knowledge Areas

1. Interviews - Used in 25+ tasks across all knowledge areas
2. Workshops - Used in 20+ tasks; primary collaborative technique
3. Document Analysis - Used in 15+ tasks; especially planning and current state
4. Risk Analysis and Management - Used in 15+ tasks; continuous activity
5. Brainstorming - Used in 10+ tasks; idea generation and exploration
6. Item Tracking - Used in 10+ tasks; ongoing issue/decision management
7. Process Modelling - Used in 10+ tasks; visual process representation
8. Reviews - Used in 8+ tasks; quality validation
9. Stakeholder List/Map/Personas - Used in 8+ tasks; stakeholder management
10. Lessons Learned - Used in 6+ tasks; continuous improvement