5 exercises — vocabulary every business analyst needs in English: requirements elicitation, NFRs, prioritisation, acceptance criteria formats, and stakeholder management.
Stakeholders: interest-influence matrix, RACI, stakeholder register, communication plan
Modelling: use case diagram, user story (As a… I want… So that…), BPMN (Business Process Model and Notation)
0 / 5 completed
1 / 5
A business analyst explains their process to a new stakeholder: "Before we write a single requirement, I run discovery workshops — interviews, observations, and process walkthroughs — to surface what stakeholders actually need versus what they say they need. The gap between the two is where most project failures start." What is requirements elicitation?
Requirements elicitation: the proactive discovery of needs from stakeholders — not just asking "what do you want" but using techniques to uncover hidden needs, assumptions, and constraints. Key distinction: stated requirements (what stakeholders say) vs real requirements (what they actually need). Elicitation techniques: Interviews — structured/unstructured; open-ended questions. Workshops / JAD (Joint Application Development) — facilitated group sessions with all stakeholders. Observation / job shadowing — watching users perform their work; reveals requirements they can't articulate. Document analysis — reviewing existing systems, contracts, regulations. Prototyping — showing a visual mock-up to stimulate feedback. Surveys / questionnaires — good for large audiences. Brainstorming — group ideation of requirements. Use case walk-throughs — step through scenarios with the user. Requirements vocabulary: Business requirement — what the business needs to achieve (outcome). Stakeholder requirement — what a specific stakeholder needs. Solution requirement — what the system must do (functional and non-functional). Constraint — a restriction (time, budget, regulatory, technical). In conversation: "We stopped collecting requirements by email — now we run two-day discovery workshops and catch contradictions before sprint 1."
2 / 5
A BA presents a requirements document to the team: "I've split requirements into functional and non-functional. Functional ones describe what the system does — login, payment, search. Non-functional ones describe how well it does it — response time under 2 seconds, 99.9% uptime, GDPR compliance. Both matter, but they're validated differently." What are non-functional requirements (NFRs)?
Non-functional requirements (NFRs), also called quality attributes or cross-cutting concerns: they define how the system should behave, not what it should do. They often directly affect architecture choices. Common NFR categories: Performance — response time, throughput (requests/sec), latency (p95, p99). Availability / Reliability — uptime (99.9% = 8.7 hours downtime/year; 99.99% = 52 minutes). Scalability — ability to handle growth in load. Security — authentication, authorisation, encryption, OWASP compliance. Maintainability — code quality, testability, deployment complexity. Compliance / Regulatory — GDPR, PCI-DSS, HIPAA, SOX. Usability — accessibility (WCAG), learnability, error recovery. Portability — ability to run on different platforms. NFR vs functional: Functional — "The user can reset their password." NFR — "The password reset email is sent within 5 seconds." NFR measurement: NFRs should be measurable: "fast" is not testable; "response time under 200ms for 95th percentile" is. In conversation: "The system passed functional testing but failed production load testing — non-functional requirements were never properly defined."
3 / 5
A BA facilitates a requirements prioritisation session: "We have 60 requirements and a three-month timeline. Let's use MoSCoW: each requirement goes into Must Have, Should Have, Could Have, or Won't Have. Everything in Must Have must ship for the product to function. Should Haves ship if time allows." What does MoSCoW stand for and how is it applied?
MoSCoW prioritisation: Must Have — non-negotiable; without this, the product fails. Minimum Viable Product (MVP). Should Have — important but not critical; deliver if capacity allows. Could Have — nice-to-have; low business impact if omitted. Won't Have — explicitly out of scope for this release (not discarded forever — just not now). The capital letters in MoSCoW spell the acronym; lowercase vowels fill the word. Other prioritisation techniques: Kano Model — classifies features as Basic (expected, no surprise if present), Performance (more = better), Delight (unexpected = wow). Value vs Effort matrix (2×2 quadrant): High Value + Low Effort = Quick Wins; High Value + High Effort = Major Projects; Low Value + Low Effort = Fill-ins; Low Value + High Effort = Hard Nos. Weighted scoring — each requirement gets a score based on business value, risk, effort, and strategic alignment. RICE scoring — Reach, Impact, Confidence, Effort; each divided to give a priority score. Common BA challenge: every stakeholder thinks their requirements are Must Have; the BA must facilitate honest prioritisation. In conversation: "Using MoSCoW we discovered 70% of the backlog was Could Have — the Must Haves fit a 6-week sprint and we shipped on time."
4 / 5
A BA explains how to write good acceptance criteria to the product team: "I use the Gherkin format — Given/When/Then. It's precise enough for developers to code against and testers to write automated tests directly. 'Given the user is logged in' sets the context; 'When they click Reset Password' is the action; 'Then an email is sent within 5 seconds' is the expected outcome." What is Gherkin / Given-When-Then format in acceptance criteria?
Gherkin / Given-When-Then (GWT): a structured acceptance criteria format popularised by BDD (Behaviour-Driven Development) and the Cucumber testing framework. The format forces precision and makes tests automatable. Structure: Given [precondition/context] → When [user action or event] → Then [expected outcome, measurable]. Optional: And/But to chain multiple steps. Example: Given the cart has 3 items totalling €50 / When the user applies coupon "SAVE10" / Then the total is reduced by 10% to €45 / And a success message is shown. Acceptance criteria vocabulary: BDD (Behaviour-Driven Development) — a development process where requirements are written as executable specifications (Gherkin scenarios). Cucumber / SpecFlow / Behave — frameworks that run Gherkin scenarios as automated tests. Definition of Done vs Acceptance Criteria — DoD applies to all stories; AC is specific to one story. Feature file — a .feature file containing Gherkin scenarios linked to step definitions in code. Happy path — the main successful scenario; sad path / edge case — error or unusual scenarios (also need AC). In conversation: "After we switched to Gherkin AC, testers started writing automation before the feature was even coded — our release cycle dropped from weekly to daily."
5 / 5
A senior BA presents a process to management: "I've mapped all stakeholders on an interest-influence matrix — high influence, high interest stakeholders are our key sponsors and need weekly updates. Low influence, high interest stakeholders are our end users — keep them informed. High influence, low interest stakeholders are executives — brief them on exceptions only." What is a stakeholder analysis?
Stakeholder analysis: a systematic process to identify everyone who affects or is affected by a project, understand their interests and influence, and design an appropriate engagement strategy. Stakeholder vocabulary: Interest — how much a stakeholder cares about the project outcome. Influence / Power — how much authority or ability a stakeholder has to affect the project. Interest-Influence Matrix quadrants: High Influence + High Interest: Manage closely (sponsors, key users — weekly detailed updates, active involvement). Low Influence + High Interest: Keep informed (end users, affected teams — regular newsletters, preview demos). High Influence + Low Interest: Keep satisfied (executives, board — brief exception-based reports; don't overload). Low Influence + Low Interest: Monitor (peripheral teams — minimal effort; check-in only if changes affect them). Other stakeholder management tools: RACI matrix — Responsible, Accountable, Consulted, Informed — assigns roles to tasks and stakeholders. Stakeholder register — a documented list of stakeholders with their contact info, role, interest, influence, engagement strategy. Communication plan — who gets what information, how often, in what format. Common BA mistake: skipping low-influence groups — resistance from end users can derail even executive-backed projects. In conversation: "We forgot to include the compliance team in stakeholder analysis — they required 3 months of changes 2 weeks before launch."