Constraint Discovery
The systematic elicitation of the fixed conditions a solution must satisfy, distinguished from requirements because they are not negotiable and are rarely volunteered.
Requirements are asked for. Constraints are discovered, usually late, usually by something failing.
The categories to work through deliberately, because none of them appear in a feature backlog:
Regulatory — data residency, retention, auditability, sector-specific rules. These bound the solution space more sharply than any technical consideration and are expensive to retrofit.
Organisational — approved technologies, existing vendor agreements, the skills of the team who will operate it, procurement lead times, and the release calendar.
Technical — systems that must be integrated with and cannot be changed, protocols fixed by a partner, performance floors set by an existing user expectation.
Commercial — budget, timeline, and contractual commitments already made to customers.
The distinction that matters in a design conversation: a requirement can be traded against another requirement; a constraint cannot, and a design that violates one is not a trade-off but a failure. Conflating them wastes time exploring options that were never available.
Record the ones that are assumed rather than confirmed separately, and confirm them — an assumed constraint that turns out to be negotiable frequently unlocks a much better design.