Requirements Elicitation & Solution Scoping

Scoping turns “we need X” into a written, bounded problem statement — what’s in, what’s out, and for whom — before anyone draws a design.

At a glance

• What it is: Gathering the real requirements behind a business request and drawing an explicit boundary around what the solution will and won’t cover.
• Why it matters: Most failed designs trace back to solving the wrong problem, not choosing the wrong technology — scoping is the step that catches that early.
• For developers: this is the document that should exist before an epic gets broken into tickets; if the “why” and “boundaries” aren’t written anywhere, expect scope creep mid-sprint.
• When to use it: At the very start of any initiative, before Solution Options Analysis.
• When not to use it: As a one-time exercise — scope should be revisited if new information changes the problem.
• Prerequisites: A basic understanding of Introduction to Solution Architecture.

Mental model

flowchart LR
    A[Business need] --> B[Elicit requirements]
    B --> C[Draw scope boundary]
    C --> D[Problem statement]
    D --> E[Feeds Options Analysis]

Scoping is a funnel: a broad, often vague request narrows into a precise statement of the problem, its boundaries, and who it’s for — the input every later design decision is checked against.

Step-by-step walkthrough

1. Interview the requester and affected stakeholders to find the underlying problem, not just the requested solution.
2. Write a one-paragraph problem statement in plain language — no technology names.
3. List what’s explicitly in scope and, just as importantly, what’s explicitly out of scope.
4. Identify who the solution is for (which teams, customers, or systems depend on it).
5. Confirm the scope with stakeholders before starting Solution Options Analysis.

Worked example

A retail company’s support team reports “the checkout is too slow” and asks for “a faster checkout.”

• Input: a vague ask (“make checkout faster”) with no defined boundary.
• Process: elicitation reveals the real problem only happens during flash sales, only on the payment confirmation step, and only affects the web storefront (not the mobile app).
• Output: a scoping doc stating the problem (“payment confirmation times out under flash-sale load on web checkout”), in scope (payment confirmation step, web storefront), out of scope (mobile app, product browsing, warehouse systems), and audience (customers checking out during promotional events).

Common use cases

Use case	When to use	Notes
New initiative kickoff	Before any design or estimation work	Prevents designing against an assumed rather than a validated problem
Vendor/consultant handoff	Before an external team starts work	A written scope avoids “that wasn’t in scope” disputes later
Scope disputes mid-project	When stakeholders disagree on what’s included	Re-anchor on the written problem statement instead of re-litigating from memory

Advanced details

• Separate symptoms from causes: a reported symptom (“checkout is slow”) often hides a narrower, more specific real problem — dig until you can state it precisely.
• Out-of-scope is not optional: an unstated boundary gets filled in differently by every stakeholder; write it down even when it feels obvious.
• Revisit, don’t freeze: if elicitation during design surfaces a scope gap, update the scoping doc rather than silently expanding the design.

Quick reference

Term	Meaning
Elicitation	The process of drawing out real requirements from stakeholders, not just recording their first request
Problem statement	A plain-language, technology-free description of the problem being solved
In scope / out of scope	The explicit boundary of what the solution covers
Scope creep	Uncontrolled expansion of scope after it was agreed

Troubleshooting

Symptom	Likely cause	Fix
Design keeps expanding mid-project	Scope was never written down, or has no explicit “out of scope” list	Write a scope doc and check every new request against it
Stakeholders describe the problem differently	Elicitation stopped at the first person’s framing	Interview more than one stakeholder group before finalizing the statement
Solution solves a different problem than expected	Requirements were assumed, not elicited	Re-run elicitation with the actual requester before continuing

Check your understanding

• Why is “make checkout faster” not yet a usable problem statement?
• Take a request you’ve received recently and write its in-scope / out-of-scope boundary in one sentence each.

Related pages

Part of Introduction to Solution Architecture. See also Solution Options Analysis & Trade-offs for the next step, and the Glossary for term definitions.