Business Analyst Vocabulary

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."

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."

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."

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."

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."

Sarah is referring to the REST architectural style. This means APIs should be designed around resources (like users), utilizing standard HTTP methods (POST, GET, etc.) and returning data in a structured format like JSON. The misconception is that 'RESTful' solely deals with JSON – it's about the overall design pattern.

Mark is describing a notification system. The message includes critical information (commit hash, error) and a link to facilitate debugging – all key components of an effective build failure notification. It's not documentation, Jira integration, or deployment.

Emily is explaining the concept of Agile velocity. Velocity is a metric used in Agile sprints to measure team productivity – specifically, the number of story points completed per sprint. This data is then used to forecast future delivery timelines. It's not about user stories, stand-ups, or requirements documentation.

David is explaining traceability. A traceability matrix provides a visual representation of the links between different artifacts – requirements, tests, and design documents – to ensure complete coverage and verify that everything has been addressed. It's not a database schema or technical specifications generation.

Jessica is writing a PR (Pull Request) description. This description provides context and justification for the code changes within the pull request – clearly outlining the problem solved and the solution implemented. It's not a technical specification, user guide, or automated tests.