Comprehensive notes on CBAP knowledge areas, agile vs waterfall, and core concepts from the session

Session purpose and structure

  • Quick audio check and presenter rights confirmed; session outline established

  • Recap plan: quick recap of yesterday, then overview of six knowledge areas in the BABOK, with brief coverage today and deeper dives in future sessions

  • Topics planned for today:

    • Six knowledge areas (brief overview)

    • Requirements classification schema to be covered in a future session

    • Elicitation vs requirements vs design definitions (high-level distinctions)

    • Differences between requirements and designs

    • Stakeholders and related concepts

    • Competencies, techniques (50 in total, to be covered in detail later—not all today)

    • Business analysis perspectives (high level)

  • Ground rules:

    • Be on time; session length is ~1 hour plus Q&A

    • Participants are muted; questions via chat during topics; then some unmuting for Q&A at end

    • Pace feedback via poll at the one-hour mark; adapt as needed based on feedback

  • Pace feedback from learners: some requested more pace, some asked for more examples; plan is to maintain pace with periodic checks

  • Two anchor examples used throughout:

    • Patient management system (PMS) in a hospital

    • Mobile banking solution for a bank

Key concepts in business analysis (CBAP context)

  • Business analysis definition discussed: enabling change by identifying needs and recommending solutions

  • Core concept model (six elements):

    • Need: a problem or an opportunity

    • Solution: a way of satisfying a need in a specific context

    • Change: moving from not addressing a need to addressing it

    • Stakeholders: anyone connected to the need, solution, or change

    • Value: the benefit or worth of addressing the need

    • Context: the environment or circumstances in which the change occurs

  • Typical ongoing discussion: relate concepts to real-world IT and banking examples

  • Stakeholders definition nuance

    • A stakeholder is someone with an interest in the need, change, or solution, or who is related to the need/change/solution in practice

    • Distinctions for IT projects: doctors, nurses, hospital admin, IT staff, patients, customers, etc.

Six knowledge areas in business analysis (high-level overview)

  • Knowledge areas outline tasks and responsibilities for BAs; primary focus is to understand, plan, analyze, design, implement, and evaluate business change

  • Note on task counts (as discussed in session):

    • Across knowledge areas, there are multiple tasks; commonly framed as about 30 tasks in total across the six knowledge areas

    • 50 techniques referenced in Babok discuss various techniques used within those tasks

    • There are six knowledge areas; specifics discussed below with the associated focus

1) Business Analysis Planning and Monitoring

  • Purpose: plan and monitor all BA activities

  • Key activities and outputs:

    • Decide BA approach (e.g., agile vs. waterfall) for the project

    • Identify key stakeholders (e.g., doctors, nurses, admin, IT in a hospital example)

    • Document how requirements will be captured and approved; determine performance metrics for BA activities

    • Define stakeholder engagement, communication plans, and governance for BA work

  • Example scenarios discussed:

    • Hybrid approach: blend agile and waterfall as appropriate

    • Pure agile: faster delivery to enable rapid feedback

  • Outputs vs governance:

    • Outputs include chosen approach, stakeholder engagement strategy, communication approach, and governance for BA work

    • Governance covers how requirements are managed and how changes are controlled

  • Example alignment with PMS and mobile banking projects

  • Q&A themes touched: resolving questions on agile vs. waterfall; how to choose an approach; defining performance metrics (KPIs)

  • Quick explainer: performance metrics for BA work can include KPIs to measure BA effectiveness and value realization

  • Practical notes from the instructor: material will be shared after class; focus on concepts; pace adjustments based on learner feedback

2) Elicitation and Collaboration

  • Purpose: gather information from stakeholders to understand needs, current processes, pain points, and desired outcomes; then, communicate findings back for validation

  • Key activities:

    • Preparation: logistics, stakeholder readiness, session materials, and pre-session handouts

    • Elicitation: interviews, workshops, observations, document analysis, etc. (drawing out information)

    • Documentation: capture information gathered (e.g., as user stories, use cases, process flows)

    • Validation: confirm back with stakeholders that captured requirements are correct

  • Techniques and examples:

    • Workshops with medical staff to understand patient management requirements

    • Interviews with doctors, nurses, reception staff; observation of current appointment processes

    • Customer input for mobile banking app expectations; security considerations from fraud/security teams

  • How elicitation relates to requirements: elicitation yields information, which may be represented as user stories or other models; user stories are one way to represent elicited information, not the only way

  • Everyday-life analogy provided (car sales example) to illustrate elicitation: asking customers questions to reveal problems and constraints so solutions can be crafted

  • Notes about roles: requirements gathering can be performed by a BA or by a Product Owner/PO with BAs assisting; backlog vs requirements mapping explained

  • Key takeaway: elicitation is about drawing out information, not delivering a solution; it supports subsequent analysis and design work

3) Requirements Life Cycle Management

  • Purpose: end-to-end management of requirements from initial capture through retirement

  • Core tasks (approximate counts discussed):

    • Prioritize requirements (ranking by business value, risk, urgency, etc.)

    • Maintain requirements for easy retrieval and traceability

    • Manage changes via a Change Request (CR) process; evaluate impact, cost, and timelines

    • Approve changes and update the requirements repository accordingly

  • Example scenarios:

    • PMS: initial scope may omit self-check-in kiosks; after stakeholder feedback, a CR adds kiosks; evaluate impact and approvals required

    • New regulatory requirements: evaluate impact, cost, and schedule implications; obtain approvals; implement changes

  • Real-world analogy shared: version control for documents (tracking changes, highlighting updates, and approvals)

  • CR concept: a change request is used to propose adding or altering requirements; CRs must be evaluated and approved before acceptance

  • Ongoing nature: requirements life cycle management is not a one-time activity; it handles ongoing changes and re-prioritizations as the project evolves

  • Discussion on what constitutes maintenance and versioning for requirements

4) Strategy Analysis

  • Purpose: big-picture analysis to understand the need, assess the current state, define goals, identify risks, and plan an implementation approach

  • Key activities:

    • Assess the current state of the process or system (e.g., how patient registrations are handled today)

    • Define the future state and goals (e.g., reduce wait times, improve patient experience, enable online bookings)

    • Identify risks and resistance to change; assess regulatory, security, or operational risks

    • Propose an implementation strategy or rollout plan

  • Examples discussed:

    • PMS: centralized data storage and process redesign to improve wait times and flow

    • Mobile banking: expand capabilities (payments, transfers, loans) with cybersecurity controls

    • GMAT readiness analogy: analyze a failed score, identify gaps in sections (quant, verbal, etc.), and plan targeted preparation to raise score toward a target (720)

    • Uber example: analyze pre-Uber taxi system (stand-based) and design a ride-hailing app to cut wait times and increase revenue

  • Important concept: the question of order – elicitation vs strategy analysis – is context-dependent; these activities are not strictly sequential; one feeds the other depending on the situation

  • Contextual dependencies: the same logic applies across industries (e.g., IT vs real estate) where context determines whether agile or waterfall is appropriate

  • Emphasized distinction: strategy analysis is about understanding and shaping the change strategy; planning and monitoring focus on the BA activities to execute that strategy

  • The instructor offered to provide more examples and repeated the point that context drives the approach and tool choice

5) Requirements Analysis and Design Definition

  • Purpose: convert elicitation results into well-structured requirements and models; define business designs (not necessarily technical designs); develop and compare design options; validate with stakeholders

  • Key tasks and outputs:

    • Model workflows and processes (e.g., process flows for PMS registration)

    • Create data models or other design representations (e.g., wireframes/mockups) for key screens

    • Validate requirements with stakeholders and other documentation

    • Define design options (different ways to address the requirements, such as web portal vs mobile app)

  • Business design emphasis: design here means how the business will operate (not purely technical architecture)

  • Examples of modeling techniques mentioned:

    • Flowcharts showing how patient moves from check-in to discharge

    • Wireframes/mock screens for key views

    • Use cases or user stories as representations of requirements

  • Validation and elicitation tie-in: ensure designs align with elicited information and stakeholder expectations

  • Solution options evaluation: compare different design options (e.g., web portal vs mobile app) and assess feasibility, value, and alignment with goals

  • Clarification on DoD vs solution evaluation: DoD (definition of done) is a criterion for a specific requirement; solution evaluation is a broader assessment of whether the overall solution meets business goals and can yield systemic improvements

6) Solution Evaluation

  • Purpose: assess whether the implemented solution delivers the intended business value and goals; identify gaps and opportunities for improvement

  • Key activities:

    • Define measurable success criteria (e.g., target improvements in metrics like wait times, revenue, engagement)

    • Collect data from users and system metrics to evaluate performance against goals

    • Perform root cause analysis for gaps between expected and actual outcomes

    • Recommend improvements to the solution or surrounding processes and people

  • PMS example: evaluate if wait times reduced as planned; if not, analyze whether issues are in the system or in usage/training; propose UI simplifications, additional training, or process changes

  • Alternative delivery forms: evaluation can be performed on prototypes, beta releases, or full releases; entry criteria require a working solution available for evaluation

  • Techniques and modeling: acknowledges that many modeling techniques exist (e.g., data modeling, process modeling); flowcharts were used as a relatable example

  • Important distinctions:

    • DoD vs solution evaluation: DoD centers on acceptance criteria for individual requirements

    • Solution evaluation centers on measuring outcomes against business goals and making broader improvements

The big picture: how the knowledge areas relate and in what order they occur

  • The six knowledge areas are interrelated and often non-linear; the order is not strictly fixed and is influenced by context and project needs

  • Elicitation and collaboration, as well as requirements life cycle management, are seen as overarching activities that support multiple knowledge areas

  • Planning and monitoring feeds into everything: how you plan BA work, governance, and metrics

  • Strategy analysis provides the high-level direction, while requirements analysis and design definition translate elicitation into concrete representations and options

  • Solution evaluation closes the loop by assessing value realization and guiding further improvements

Agile vs. Waterfall: differences, rationale, and when to use which

  • Waterfall (predictive model)

    • Sequential flow: requirements analysis → design → development → testing → deployment → maintenance

    • Pros: thorough upfront documentation and planning; clear milestones

    • Cons: long cycles; late feedback; difficult to accommodate changes; risky in highly dynamic environments

    • Real-world example discussed: large-scale construction (e.g., metro line) where end-to-end planning and approvals are necessary before execution

  • Agile (adaptive model)

    • Short iterations (sprints) delivering working software regularly; continuous feedback

    • Pros: fast feedback, ability to respond to changes, early and continuous delivery of value

    • Cons: requires strong collaboration, discipline, and stakeholder availability

    • Typical sprint cadence mentioned: 2 weeks per sprint; sometimes 4 weeks; goal is to deliver working software at the end of each sprint

  • How to choose in practice

    • Use waterfall when requirements are clear, stable, and stakeholders have limited access; changes are unlikely

    • Use agile in fast-moving environments (e.g., ecommerce platforms like Swiggy, Blinkit) where competition necessitates rapid iterations and frequent releases

    • Real-world analogies discussed: real estate construction (often not suited to agile due to dependencies and regulatory constraints)

  • Key process concepts within agile contexts mentioned

    • Sprint: a fixed timebox during which a subset of features is developed and demonstrated

    • Backlog: prioritized list of features/requirements for future sprints

    • Velocity: a measure of how much work a team can complete per sprint (often in story points or number of features)

    • Backlog prioritization approach mentioned: Moscow method (Must, Should, Could, Won’t)

    • Tools commonly used by BAs in agile projects: Jira (for storing requirements and user stories) and Confluence (for documentation). Note: these tools were mentioned as common in industry discussions

  • Practical examples from the session

    • PMS and mobile banking projects often leverage agile delivery to enable fast iterations and quick feedback loops

    • An example discussed: delivering two features per sprint, each sprint lasting two weeks; total of 35 features would take approximately 18 sprints (assuming 2 features per sprint)

    • Calculation: number of sprints needed = n=⌈352⌉=18,n = \left\lceil \dfrac{35}{2} \right\rceil = 18, duration = 18×2 weeks=36 weeks.18 \times 2\text{ weeks} = 36\text{ weeks}.

  • Context matters

    • Context influences whether agile or waterfall is more appropriate, including regulatory constraints, organizational culture, stakeholder availability, and competitive environment

  • Practical takeaway on DoD vs solution evaluation

    • DoD defines acceptance criteria for individual requirements, while solution evaluation looks at whether the overall solution achieved the intended business results and what improvements are needed

Context, stakeholders, and practical implications discussed in the session

  • Context matters across all BA activities

    • External factors (market competition, regulatory constraints, organizational policies) influence what solutions are feasible and how changes are implemented

    • Example: using AI-based tooling like ChatGPT for SRS/BRDs must comply with organizational security and data policies; some banks prohibit using internal data in public AI tools

  • Stakeholders defined and discussed in depth

    • Stakeholders include anyone with an interest in the need, change, or solution; the BA’s job is to understand their needs, expectations, and constraints

  • Real-world discussions and questions from learners included topics like:

    • How to manage context-dependent situations (e.g., when a solution cannot be used due to policy constraints)

    • How to map current state to future state in different industries (e.g., ecommerce vs real estate) to illustrate strategy analysis

Quick numerical references and formulas used in examples

  • Percent improvement example (PMS wait time):

    • *Old wait time: 60min60\text{min}, New wait time: 15min15\text{min}

    • Percent improvement: \text{% improvement} = \frac{Old - New}{Old} \times 100\% = \frac{60-15}{60} \times 100\% = 75\%.

  • Feature delivery in Agile (two features per sprint):

    • If there are 35 features and 2 features are shipped per sprint, number of sprints needed: n=⌈352⌉=18n = \left\lceil \dfrac{35}{2} \right\rceil = 18

    • Duration: 18 sprints×2 weeks per sprint=36 weeks.18 \text{ sprints} \times 2\text{ weeks per sprint} = 36\text{ weeks}.

  • Velocity concept (informational): Velocity=Number of features delivered in a sprint1 sprint.\text{Velocity} = \dfrac{\text{Number of features delivered in a sprint}}{1\text{ sprint}}. (Represents throughput of the team per sprint)

Summary takeaways for exam-style understanding

  • Be able to articulate the six knowledge areas and their primary purpose, including key outputs and typical activities

  • Distinguish elicitation from analysis and design: elicitation is about information gathering; analysis/design define and validate what must be built and how

  • Understand the concept of strategy analysis as the high-level view to identify needs, goals, risks, and rollout strategies

  • Know how to convert elicitation results into formal requirements and design options (requirements analysis and design definition), including modeling techniques like flowcharts and wireframes

  • Recognize solution evaluation as the assessment of achieved value and the initiation of improvement actions based on root cause analysis

  • Explain waterfall vs. agile contrasts, including when each is appropriate and how sprint-based delivery works in agile contexts

  • Appreciate the role of context and stakeholder dynamics in shaping BA work, including real-world constraints and policy considerations

  • Be comfortable with common BA terminologies and their practical implications (need, solution, change, value, context, stakeholder, CR, DoD, backlog, user stories, etc.)

Next steps emphasized by the instructor

  • Tomorrow: dive into the Requirements Classification Schema

  • Continue with deeper coverage of each knowledge area and the associated techniques

  • Revisit the relationship among knowledge areas with concrete examples and projects

  • Additional sessions to cover all 50 techniques and 6 knowledge areas in detail

  • Expect further materials sharing (notes, slides, and LMS uploads) to support study and exam prep