A Constraint Is a Decision Already Made For You; a Requirement Is One You Still Get to Make
Some lines in a brief are not asking for anything. They are reporting a decision that has already been taken somewhere outside your control: the data must stay inside one country, the team knows only one programming language, the budget for this quarter is fixed, the existing payment provider cannot be replaced this year, the release must ship before a legal deadline. These are constraints. A requirement, functional or quality, is something you must satisfy but are free to satisfy in any way you can defend. The difference is what you are allowed to argue about. You can propose three ways to reach a reliability target; you cannot propose that the data leave the country. Treating a constraint as a requirement wastes design effort exploring options that were never available. Treating a requirement as a constraint is worse: it quietly freezes one solution, usually the first one somebody mentioned, and hides the alternatives from review. Constraints also expire, so each one is worth recording with its source, because when the source changes the design space opens again. After this Concept you can sort a brief into constraints and requirements, name the source of each constraint, and say which of your design options a given constraint has already removed.
This Concept is waiting for its first lesson!
Some lines in a brief are not asking for anything. They are reporting a decision that has already been taken somewhere outside your control: the data must stay inside one country, the team knows only one programming language, the budget for this quarter is fixed, the existing payment provider cannot be replaced this year, the release must ship before a legal deadline. These are constraints. A requirement, functional or quality, is something you must satisfy but are free to satisfy in any way you can defend. The difference is what you are allowed to argue about. You can propose three ways to reach a reliability target; you cannot propose that the data leave the country. Treating a constraint as a requirement wastes design effort exploring options that were never available. Treating a requirement as a constraint is worse: it quietly freezes one solution, usually the first one somebody mentioned, and hides the alternatives from review. Constraints also expire, so each one is worth recording with its source, because when the source changes the design space opens again. After this Concept you can sort a brief into constraints and requirements, name the source of each constraint, and say which of your design options a given constraint has already removed.
Are you a teacher? Sign in to start contributing.
Sign In