Business Analysis and Requirements
Domain 1 - Business Analysis and Requirements
The GBDS requirements domain tests whether you can turn a vague business goal into testable, prioritized, traceable requirements - and whether you know who must approve them.
Requirement levels
- Business requirements state the objective and the value ("cut order-to-ship time by 30%"). Solution requirements describe behaviour (functional) and qualities (non-functional: performance, availability, usability, security, compliance).
- A requirement is a statement of need or obligation; a design is a chosen way to satisfy it. "Users need a dashboard" is usually a solution statement masquerading as a need.
- Non-functional requirements must be measurable: "search returns in under 2 seconds at p95 with 500 concurrent users", not "the system must be fast".
- User stories follow INVEST; acceptance criteria in Given/When/Then form convert directly into test cases.
Elicitation and traceability
Interviews, facilitated workshops, observation, document analysis, prototyping and data profiling all feed the requirement set. Give every requirement an ID and trace it upward to a business objective and downward to design, test case and sign-off in a requirements traceability matrix. Prioritize with MoSCoW or weighted scoring; resolve conflicts against the business objective, not the loudest stakeholder. Record assumptions and business rules explicitly - thresholds, approval limits, rounding - because they change behaviour and need an owner.
Worked example
Sales wants fulfilment to start the moment an order is placed; Finance wants credit approval first. Rather than pick a side, decompose against the objective "reduce cancelled orders without slowing repeat customers". That yields R1 (functional): orders above a credit threshold are held pending approval; R2 (non-functional): checkout confirmation renders in under 1.5 s regardless of approval state. R1 traces to Finance's control objective, R2 to Sales' experience objective, and the threshold itself is a business rule requiring an owner and a change process.
Traps
- Accepting a proposed solution as the requirement, which locks design prematurely.
- Deferring non-functional requirements to testing, when they are most expensive to fix.
- Unmeasurable adjectives ("intuitive", "robust", "user-friendly").
- Requirements with no owner or acceptance criteria, so "done" becomes arguable.
- Omitting exception paths: timeout, duplicate submission, partial approval, cancellation.