---
name: Requirements Engineering & System Scoping
description: Turn fuzzy business asks into precise, testable technical requirements and a defensible scope — with explicit boundaries, non-goals, assumptions, and acceptance criteria — so a team builds the right thing once instead of discovering the real requirement in QA or after launch.
audience: engineer · product manager · tech lead · founding engineer
---

# Requirements Engineering & System Scoping

## What this is
A method for the hardest part of building: converting a vague business request into unambiguous requirements and a bounded scope. It elicits the real need, writes it as testable criteria, draws the system boundary, and names what's explicitly out — so ambiguity is resolved on paper, not in production.

## What this is NOT
- **Not a spec dictated top-down.** Requirements are elicited and validated with the people who have the need; the skill surfaces disagreement rather than papering a false consensus.
- **Not a frozen document.** Scope is defined *and* its change process is defined; requirements evolve, but changes are explicit and costed, not silent.
- **Not architecture or estimation.** It defines *what* and *the boundary*; the *how* (design) and *how long* (estimation) are downstream and route to those skills.

## When to use
A request that's too vague to build ("make it faster," "add reporting"); scoping a feature or system; setting boundaries and non-goals before design; writing acceptance criteria; reconciling conflicting stakeholder asks into one buildable spec.

## Operating principle
A requirement isn't real until it's testable and bounded. If you can't write the acceptance check, the requirement is still an idea — and every scope needs an explicit "not this," because unstated boundaries are where projects bleed.

## Capabilities
- **Elicitation & disambiguation** — Goal: the real need, not the stated fix. Method: interview for the underlying job, separate problem from proposed solution, surface implicit assumptions and constraints, resolve conflicting asks by tracing to the business goal. Output: a validated problem statement + assumptions list. Quality bar: the underlying need is named (not just the requested feature); conflicts are surfaced, not averaged away.
- **Testable requirements** — Goal: unambiguous, verifiable specs. Method: write functional and non-functional requirements (performance, security, accessibility, scale) each with acceptance criteria; use concrete examples/scenarios; flag the untestable and rewrite it. Output: a requirements set with acceptance criteria. Quality bar: every requirement has a check a machine or a tester could run; "fast," "intuitive," "robust" are quantified or cut.
- **Scope & boundary definition** — Goal: a defensible edge. Method: draw the system boundary and interfaces, state non-goals explicitly, list dependencies and assumptions, define the change process for when scope shifts. Output: a scope statement with in/out and a change protocol. Quality bar: the "out of scope" list is real and specific; a scope change is an explicit, costed decision, not a quiet addition.

## A worked example
"We need reporting." → Elicitation reveals the real job is "the finance lead needs a monthly revenue-by-segment figure they can trust and export," not a BI platform. Requirements become testable ("exports a CSV matching the ledger to the cent, for a chosen month, in under 5s"), the boundary is drawn (no ad-hoc query builder — a named non-goal), and the assumptions (data source, timezone, access) are listed. The team builds the one thing that was actually needed.

## Guardrails & escalation
Architecture/design of the solution → the distributed-systems or relevant engineering skill. Effort estimation and sequencing → planning/PRD skills. Regulated or safety requirements → domain specialists for the acceptance bar. The skill defines the target; others hit it.

## References
Requirements-engineering practice (elicitation, functional vs non-functional, INVEST criteria); acceptance-criteria and example-mapping techniques; the cost-of-late-defect curve (Boehm); scope-management discipline. Validate requirements with the people who hold the need.