5 exercises on stating scope boundaries, dependencies, assumptions and out-of-scope items clearly.
Key patterns
Name out-of-scope items explicitly — exclusions matter as much as deliverables.
An assumption is specific, falsifiable, and states the impact if it’s wrong.
A constraint is a hard boundary: must run on…, cannot exceed….
Document dependencies with owner, date and the consequence of delay.
0 / 5 completed
1 / 5
A spec needs an out-of-scope section so reviewers know what the project will not deliver. Which statement is clearest?
An out-of-scope statement should name the excluded items explicitly, not gesture at them.
Option C lists exactly what is in (email/password login) and exactly what is out (social sign-in, 2FA), and says where the excluded work will live (separate stories). A reader knows immediately not to expect those features.
“The rest”, “some less important features”, and “everything around it” are unbounded — each reader fills the gap differently, which is how scope creep and missed expectations begin. Strong scope prose uses explicitly out of scope, not included in this milestone, and tracked separately as…. Naming exclusions is as important as naming deliverables: it sets the boundary both sides can point to.
2 / 5
Which sentence states an assumption properly — flagging something taken to be true that, if wrong, would affect the design?
A good assumption is specific, falsifiable, and states the consequence if it’s wrong.
Option B names a concrete figure (500 req/s), ties the design to it, and spells out the impact if the assumption breaks (horizontal scaling needed, not budgeted). That lets reviewers challenge the number and plan for the risk.
“Mostly work”, “used normally”, and “performance will be fine” are untestable — nobody can confirm or refute them, so they protect no one. Useful framing: We assume X; the design depends on it; if X is false, then Y. Documenting assumptions this way turns hidden risk into a visible, reviewable decision and gives you cover when conditions change later.
3 / 5
Which is the clearest statement of a technical constraint the team must design within?
A constraint is a fixed boundary on the solution space — name it precisely.
Option C states the exact platform (on-prem Kubernetes 1.27, no GPU nodes) and immediately draws the consequence (no managed cloud services, no GPU workloads). An architect reading it knows which designs are off the table before drawing a single diagram.
“Older technology”, “a few limitations”, and “a bit limited” convey worry but no boundary — they can’t guide a decision. Distinguish a constraint (a hard limit you must obey: platform, budget, regulation, deadline) from an assumption (something you believe but haven’t verified). Constraint prose is declarative and absolute: must run on…, limited to…, cannot exceed….
4 / 5
Which statement documents an external dependency most clearly, so its risk is visible?
A dependency statement should name the thing depended on, who owns it, and the impact of delay.
Option C names the specific API and version (Payments team’s charge v2), gives a date (GA 2026-08-01), and states the consequence (launch slips one-for-one, no fallback). That makes the dependency a tracked risk a project manager can act on.
“Some other teams”, “a few external things”, and “affect the timeline somewhat” are too vague to manage — you can’t escalate a dependency you can’t name. Effective dependency prose answers: what we depend on, who owns it, when it’s due, and what happens if it’s late. Listing dependencies explicitly surfaces cross-team risk early, while there’s still time to plan around it.
5 / 5
Which sentence draws a clear scope boundary between this project and a neighbouring system?
A scope boundary should state exactly where this system’s responsibility ends and another’s begins.
Option B draws a precise line: this service owns order creation up to and including the database write; everything downstream (fulfilment, shipping, inventory) belongs to a named system and is out of scope. There is no overlap and no gap.
“Our part”, “roughly where you’d expect”, and “the later stuff” leave the seam undefined — exactly where two teams end up either both building it or neither building it. Clear boundary prose uses ownership verbs (owns, is responsible for, hands off to) and a precise cut point (up to and including…). Naming the adjacent owner turns a fuzzy edge into a contract between teams.