BCS – International Diploma in Business Analysis

1.1 The Rationale for Business Analysis

Why Business Analysis is important:

  • Ensures business change delivers real value.
  • Helps organisations adapt to fast-paced environments.
  • Reduces project failure by clarifying needs before designing solutions.

Benefits to organisations:

  • Aligns business needs with solutions.
  • Identifies real problems and opportunities.
  • Supports informed decision-making at all levels.

Key takeaway:
Business Analysts provide structure and clarity, enabling better questions, answers, and options across strategic to technical levels via the Business Analysis Service Framework.

1.2 The Holistic View of a Business System

Importance:

  • Helps understand all interacting parts of a business.
  • Prevents suboptimal or siloed change decisions.

Aspects – POPIT model:

  • People: Skills, attitudes, motivation.
  • Organisation: Structure, roles, culture.
  • Processes: Business processes and workflows.
  • Information: What’s needed to make decisions.
  • Technology: Tools and systems to deliver/access information.

Key takeaway:
Considering all five elements prevents overlooking critical impacts when implementing change.

1.3 Competencies of a Business Analyst

Three categories:

  1. Business knowledge: Domain-specific knowledge.
  2. Personal qualities: Communication, critical thinking, adaptability.
  3. Professional techniques: Modelling, stakeholder analysis, requirements engineering.

Key takeaway:
All three are essential for delivering effective and professional business analysis services.

1.4 Professionalism in Business Analysis

BCS role:

  • Sets standards via certification and a code of conduct.
  • Encourages lifelong learning.

Why professionalism matters:

  • Builds trust and credibility.
  • Aligns behaviour to ethical standards.

Key takeaway:
Even though not legally a profession, business analysis has professional characteristics upheld by bodies like BCS.

1.5 Business Environment Analysis

External Analysis (e.g., PESTLE, Porter’s 5 Forces):

  • Understand external drivers of change.
  • Identify threats and opportunities.

Internal Analysis (e.g., VMOST, Resource Audit):

  • Evaluate internal capability to respond to change.

Key takeaway:
Business Analysts must understand both external and internal environments to guide successful change.

1.6 SWOT Analysis

  • Strengths/Weaknesses: Internal factors.
  • Opportunities/Threats: External factors.

Purpose:

  • Summarises internal and external analysis.
  • Identifies areas to focus business change efforts.

Key takeaway:
SWOT helps frame the scope and priorities of business change initiatives.

1.7 Business Performance Measurement

Key tools:

  • CSFs (Critical Success Factors): Key goals for success.
  • KPIs (Key Performance Indicators): Metrics to track CSFs.
  • Performance Targets: Specific, measurable goals.

Balanced Scorecard: Four perspectives:

  1. Financial
  2. Customer
  3. Internal processes
  4. Learning & growth

Key takeaway:
These tools help track progress against strategic objectives and identify improvement areas.

1.8 Business Analysis Within the Business Change Lifecycle

Stages:

  1. Alignment – Align with strategy.
  2. Definition – Define the change.
  3. Design – Plan the solution.
  4. Implementation – Manage the rollout.
  5. Realisation – Measure the benefits.

Linear vs. Iterative:

  • Linear: Sequential, best for stable environments.
  • Iterative: Flexible, good for uncertain/complex projects.

2. Business Analysis Techniques (K Level 4/5)

2.1 Investigating and Documenting Business Situations

  • Selection of techniques depends on situation (e.g. complexity, stakeholder availability).
  • Techniques:
    • Interviews – detailed, personal insights. Weakness: time-consuming.
    • Workshops – fast consensus, group interaction. Weakness: hard to schedule.
    • Observation – uncovers actual practice. Weakness: time-intensive, observer bias.
    • Document analysis – historical context. Weakness: may be outdated or irrelevant.
    • Scenario analysis – explores “what if”s. Weakness: based on assumptions.
    • Surveys/Questionnaires – quantitative breadth. Weakness: lack depth.
  • Documentation techniques:
    • Customer Journey Maps – visualise customer experience across touchpoints.
    • Rich Pictures – holistic view, especially of messy problems.
    • Mindmaps – structure ideas and relationships informally.

➡ BCS Insight: Recognise when to use qualitative (e.g., interviews, rich pictures) vs. quantitative (e.g., surveys) methods. Combine techniques to form a complete picture of the business situation.

2.2 Stakeholder Analysis

  • Identification techniques: Brainstorming, organisational models, business process analysis.
  • Categories:
    • Internal: sponsor, manager, users, SMEs.
    • External: customers, suppliers, regulators.
  • Prioritisation technique: Power/Interest Grid
  • Communication strategies: stakeholder matrix, communication plan.
  • Understand perspectives via CATWOE, empathy maps.
  • Conflict resolution: negotiation, workshops, facilitated sessions.
  • RACI Matrix: clarifies roles (Responsible, Accountable, Consulted, Informed).

➡ BCS Insight: Understand emotional intelligence, collaboration, and cultural awareness are critical to stakeholder engagement.

2.3 Modelling Business Activities

  • Purpose: Achieve consensus on what business should be doing (conceptual model).
  • Model used: Business Activity Model (BAM)
    • Shows Doing activities.
    • Categories: Planning, Enabling, Doing, Monitoring, Controlling.
    • Activities linked via logical dependencies.

➡ BCS Insight: BAMs are conceptual – not “as-is” or “to-be”. Based on stakeholder perspectives, e.g., derived from CATWOE.

2.4 Business Events

  • Types:
    • External (customer order),
    • Internal (system update),
    • Time-based (monthly billing).
  • Importance: Events trigger processes and help define system boundaries.

➡ BCS Insight: Clearly distinguish between events (triggers) and activities (responses). This is foundational for process modelling.

2.5 Business Rules

  • Types:
    • Constraints (e.g. legislation),
    • Internal policies (e.g. discount thresholds),
    • Procedures (e.g. login verification).
  • Use: Guide process behaviour and system logic.
  • Must be documented, communicated, and auditable.

➡ BCS Insight: Business analysts challenge and validate rules – they are not always optimal or necessary.

2.6 Gap Analysis

  • Process: Compare ‘as-is’ vs. ‘to-be’ to identify what’s missing.
  • Techniques:
    • Documenting current state,
    • Designing future state,
    • Highlighting gaps,
    • Suggesting solutions.
  • Thinking models:
    • Divergent thinking: generate options.
    • Convergent thinking: evaluate and select options.

➡ BCS Insight: Gap analysis supports structured change and improvement planning.

3. Business Case Development (K Level 4/5)

3.1 Rationale for Making a Business Case

  • Purpose: Support informed decision-making before committing resources.
  • Provides: Justification, transparency, accountability.

➡ BCS Insight: No change initiative should begin without evaluating its justification through a formal business case.

3.2 Contents of a Business Case

  • Sections:
    • Background
    • Options (including ‘do nothing’)
    • Costs (tangible/intangible)
    • Benefits (tangible/intangible)
    • Cost-benefit analysis
    • Risks
    • Impacts
    • Recommendation (preferred option)

➡ BCS Insight: Business case is not just about finance—it also weighs strategic, operational, and human impacts.

3.3 Options

  • Always include:
    • Do nothing (baseline).
    • Viable alternatives.
  • Evaluate via:
    • Business feasibility (desirable),
    • Technical feasibility (possible),
    • Financial feasibility (affordable).

➡ BCS Insight: ‘Do nothing’ might reveal hidden costs or risks. Every option must be real, measurable, and justifiable.

3.4 The Financial Case

  • Ensures value for money.
  • Links benefits to investment.
  • Used to compare with alternative uses of funds.

➡ BCS Insight: Must align with organisation’s financial planning and ROI expectations.

3.5 Investment Appraisal Techniques

  • Payback Period: How long to recover investment.
  • Net Present Value (NPV): Future cash flows discounted to present.

➡ BCS Insight: Know pros/cons:

  • Payback: Simple but ignores value after break-even.
  • NPV: More accurate but needs forecasts and assumptions.

3.6 Risk Analysis

  • Assess:
    • Impact,
    • Likelihood.
  • Responses:
    • Accept,
    • Avoid,
    • Mitigate,
    • Transfer.

➡ BCS Insight: Risks must be tied to each option. Good business cases show how risk is managed, not just that it exists.

3.7 Impact Analysis

  • Focus: Organisation culture, structure, and people.
  • Impact ≠ Risk: Impact is certain (e.g. staff training needed); risk is uncertain.

➡ BCS Insight: Impacts shape implementation planning—ignore them and you risk change failure.

3.8 Lifecycle for the Business Case

  • Living document.
  • Reviewed at gateways:
    • Feasibility,
    • Design,
    • Implementation.

➡ BCS Insight: Agile or Waterfall – both need business case updates to reflect changes and confirm continued justification.

4. Requirements Definition

4.1 Requirements Engineering

The Requirements Engineering Framework is a cyclical and iterative process that guides business analysts in ensuring requirements are identified, analysed, validated, documented, and managed effectively.

Framework Components:

  1. Requirements Elicitation – engaging stakeholders to discover requirements.
  2. Requirements Analysis – structuring and prioritising requirements.
  3. Requirements Validation – ensuring requirements are accurate and aligned to business needs.
  4. Requirements Documentation – capturing requirements formally.
  5. Requirements Management – controlling, tracking and updating requirements.

Key Concepts:

  • Requirement: A feature or condition needed by a stakeholder or system.
  • Hierarchy of Requirements:
    • Business Requirements: High-level needs.
    • Stakeholder Requirements: Derived from business needs.
    • Solution Requirements: Functional/non-functional.
    • Transition Requirements: Temporary to support implementation.
  • Planning & Estimating: Includes stakeholder analysis, technique selection, and time/resource estimation.

4.2 Requirements Elicitation

Elicitation is the purposeful discovery of stakeholder needs, using suitable techniques for gathering both explicit (non-tacit) and tacit knowledge.

Elicitation Techniques (from 2.1):

  • Interviews
  • Workshops
  • Observation
  • Document analysis
  • Prototyping
  • Focus groups
  • Surveys
  • Scenarios

Tacit vs Non-Tacit Knowledge:

  • Tacit: Embedded in experience (needs interviews, workshops).
  • Explicit: Documented or easy to verbalise (can use document analysis, questionnaires).

Application:

  • Iterative projects require continuous elicitation and flexible techniques.
  • Linear projects benefit from up-front planning and structured sessions.

4.3 Requirements Analysis

The process of refining and validating elicited requirements to make them useful for solution design and delivery.

Key Analysis Activities:

  • Validate alignment with business objectives.
  • Check technical, business, and financial feasibility.
  • Structure and group requirements logically.
  • Prioritise using techniques such as MoSCoW or 100-point method.
  • Package into delivery bundles or releases.
  • Use scenarios and prototyping to clarify requirements.
  • Resolve duplicates, overlaps, and conflicts.

Quality Criteria:

  • Clear, complete, unambiguous, consistent, testable, traceable, relevant.

User Profiling: Informs functional needs and UX requirements.

4.4 Requirements Validation

Validation ensures the documented requirements truly reflect stakeholder needs and support business objectives.

Process:

  • Formal reviews or walkthroughs (esp. in Waterfall).
  • Iterative feedback loops and demonstrations (Agile).
  • Stakeholder engagement to confirm completeness and accuracy.

Rationale:

  • Avoids misalignment.
  • Minimises costly rework.
  • Confirms solution deliverables match expectations.

Stakeholders: Must confirm the requirement supports their needs and is realistic.

5. Requirements Management and Documentation

5.1 Requirements Management

A structured approach to track, control, and ensure the integrity of requirements throughout their lifecycle.

Key Elements:

  • Identifying, recording, and categorising requirements.
  • Tracking the source, owner, and cross-references.
  • Maintaining a requirements repository.
  • Applying change control and version control.
  • Ensuring traceability:
    • Vertical (requirement ↔ objective).
    • Horizontal (requirement ↔ solution component).

5.2 Change Control

The change control process ensures changes to requirements are considered and managed effectively.

Process:

  1. Identify change (source: stakeholders, environment).
  2. Assess impact.
  3. Approve or reject.
  4. Record the decision and update documentation.

Rationale:

  • Prevents scope creep.
  • Ensures traceability.
  • Maintains project integrity.

5.3 Version Control

Tracks the evolution of individual requirements or documents.

Principles:

  • Assign unique identifiers.
  • Use version numbers to differentiate updates.
  • Maintain a clear audit trail.
  • Supports configuration management at the requirement or document level.

5.4 Tools in Requirements Management

Requirements tools support:

  • Documentation and model storage.
  • Linking requirements across artifacts.
  • Change and version control.
  • User access management.

Examples include: JIRA, Confluence, DOORS, Azure DevOps.

5.5 Types of Requirements

Business Requirements:

  • High-level needs related to organisational goals.
  • Can include technical infrastructure requirements.

Solution Requirements:

  • Functional: What the solution should do.
  • Non-functional: Performance, security, usability, etc.

Usefulness: Helps prioritise, allocate, and trace requirements to delivery.

5.6 Legal Issues and Business Analysis

BA Legal Awareness:

  • Data Protection: e.g., GDPR – requires secure and justified data handling.
  • Disability Access: e.g., WCAG – must ensure inclusive and accessible design.

BAs should flag any non-compliance in requirements early and consult with legal/compliance teams.

5.7 Documenting Requirements

Documentation Styles:

  • Text-based: User stories, requirements catalogues.
  • Diagrammatic: Use case diagrams, data models.

Requirements Catalogue Elements:

  • Identifier, name, description, business area, type, author, owner, source, priority, rationale, acceptance criteria, cross-references, status, version.

Purpose: Ensures consistency, traceability, communication, and reuse.

5.8 Requirements Modelling

Used to visualise and validate requirements.

Types:

  • Conceptual models: Show business activities and their interrelations.
  • Use Case Diagrams: Show system interactions:
    • Actors, use cases, associations, system boundaries.
  • Data Models: Show data structure:
    • Entities, relationships, optionalities, cardinalities.
  • CRUD Matrix: Shows how data is Created, Read, Updated, Deleted across processes.

Prototyping: Helps refine requirements through tangible feedback loops.