''Category:'' AntiPattern (CategoryAntiPattern)

''Problem:'' 

How do you make sure that the correct system is developed? 

''Forces:''
	* The system is intended to work with the customer's existing processes and or systems. 
	* The individuals who understand those processes and systems best are busy working with them.
	* Development of the new system will take a long time to do, and the expert cannot be spared to spend a lot of time away from his/her ''real'' responsibilities. 

''Bad solution:'' 

The development team is given a high-level view of the new system and asked to make a detailed proposal. The expert then reviews the proposal and comments on its obvious flaws. If the developers have any questions during development, they can request a meeting or send over a list of questions. The expert will answer as soon as is convenient. When the system is finally delivered, the expert tries to use it and tells the developers what is wrong with it. 

''Resulting Context:'' 

A lot of time is spent on trying to make the proposal as accurate as possible, necessitating many revisions. The team makes a good-faith effort, and guesses when the specs seem to be vague. At times, they practice DefensiveProgramming, making the system as general as possible, in hopes that one of the possible uses of the system will turn out to be a valid one. If time permits, they build a ConceptualPrototype, hoping to elicit further comments; however, without a good understanding of the system, they get some major details wrong and fail to appreciate where the problems will be.

When the first version of the system is finally delivered, the expert comments on its errors and virtues, but cannot accurately comment on as-yet unbuilt functionality.

Through Herculean effort, the team finally manages to build an acceptable system, but finds that it has wasted a lot of time building unneeded functionality and optimizing for the wrong set of priorities.

''A Better Solution:''

Customer expert is part of the team and is available on an ongoing basis to make functionality and priority decisions.

-- RussellGold

''Business versus Technical Requirements''

Lack of technical requirements is common - project teams are very often expected to come up with a first draft of the technical requirements (which is then aproved by management). However, the existence of well-defined, stable(ish) business requirements is fulcral for any project to succeed. If the project team does not understand what the project is all about from a business perspective, failure is likely.

-- NunoLeitao

''See Also:''

ThrownOverTheWall is a strongly related and possibly more general description of RequirementsTossedOverTheWall (and it talks of another similar AntiPattern named "Integration Wall").
Certainly the ill-effects of ''Systemic Disconnection''
and ''Social Isolation'' apply here as well, but the parties they apply to may be slightly different.

DogFood discusses some issues of feedback & feed-forward that may apply here also, but the connection is probably an indirect one and harder to make.

Trained logic users like programmers are far from perfect at writing unambiguous code in logical languages to do what they mean. The chance that a normal human can write an unambiguous requirements document that actually communicates what they mean is vanishingly small.
-------
See Also: SpecificationsAreNotEconomical
----
CategoryDevelopmentAntiPattern