Constraint

In technology selection, a constraint is a condition that limits which solutions are permissible and that is imposed from outside the design trade-off: a law or policy, an approved data location, an existing contract, a budget, a deadline, the staff available, or a mandated platform. NASA’s systems-engineering guidance describes constraints as conditions the design must adhere to, or that limit how the system will be used, and notes that they typically cannot be changed through trade-off analysis.

Constraints rule options out before scoring

“Invoice data must remain in the approved region” — a data residency obligation — “no new operating platform before the current contract ends,” and “two people are available to support the system” are constraints for a lookup project. A product that stores data elsewhere is excluded before its features are compared. A constraint therefore works like a mandatory condition, and it should be justified in the same way: name the source and the person who owns it.

Without a named source, a preference can pose as a constraint. “We must use the vendor we already know” is a preference unless a contract or supported-environment rule actually says so. Ask where the sentence comes from, and write the answer beside it.

Check who has authority to change it

A constraint is often written in the same form as any functional or quality requirement; the difference is who may change it. A scoring formula cannot lift a data-location rule, and a low price cannot compensate for breaking it. This is what separates a constraint from a quality attribute trade-off, where a worse result on one attribute can be bought with a better one on another. If a constraint blocks every workable option, ask its owner to identify its source, whether a change is permitted, and who may approve it. Being named as owner does not itself grant authority to change a law, contract, or policy. Record any authorized change and its consequences. If the condition cannot be changed, revise the scope or approach, or exclude the option.

Constraints also expire or change: a contract ends, a budget is revised, a platform is retired. Date them and note when they should be rechecked. NASA separately describes design constraints that arise from decisions made as the design evolves; keep those apart from stakeholder constraints so that a choice made by the project is not mistaken for a rule imposed on it.

Examples here are illustrative.

References

• NASA: Technical requirements definition