Lockout Requirement

A stated requirement, the sole or primary purpose of which is to guide/force the design team into choosing a particular technology/architecture/implementation strategy. All other choices are locked out by the requirement.

Often times justified by BestPractice arguments. (If a technique is indeed a BestPractice, then there should be considerable team experience or discussion in the literature which justifies this claim....the mere unsupported opinion of the architect, manager, or project lead that something is a BestPractice is suspicious. It should also be noted that a BestPractice is only best within an appropriate context. And only ever temporarily.)

The term only applies if the requirement is not a bona fide customer, legal, or business requirement (requirements to interface with existing or legacy systems count as customer requirements).

For example, if a project had a requirement to use a "statically typed, cross-platform OO language with garbage collection and a large available talent pool" (assuming not a customer requirement), you can bet that this is a LockoutRequirement to force the team to select Java. Not to flame JavaLanguage; this is merely an example.

More commonly seen is a "3-tiered architecture with a Web-based front end, Unix application server and database server", or more simply "J2EE compliant architecture".

Another common example is one that requires big iron relational database, and no so round about either, just direct and to the point: System data must be stored in a relational database. Most likely found in government projects.