ソフトウェア開発のビジネスでは，最終プロダクトを想定できないためにおこる発注者側と開発者側のやりとりの難しさがある．ソフトウェア開発は，常に最終成果物であるソフトウェアそのものへの仕様決めと実装である．ソフトウェアが発展的にどのように変化していく必要があるのかを想定し，ソフトウェアそのものの性質に応じて開発プロセスを選択していく．このソフトウェアの性質を，発注者側と開発者側の双方が早期に認識し，変化に対応できる開発プロセスを経ていく必要がある．開発プロセスの中で，仕様決めと実装が徐々に詳細になっていく．
ソフトウェア開発を行うメンバーは，営業，プロジェクトマネージャ，ソフトウェアエンジニアによる開発者サイドの基本的構成メンバーと発注者である．仕様決めには，発注者とプロジェクトマネージャ，ソフトウェアエンジニアが共同して行い，実装はそれにしたがってソフトウェアエンジニアが行う．プロジェクトにかかわる要員のアサインは，コストバランスと将来の受注へのつなぎを勘案して営業とプロジェクトマネージャが行うのであろう．
さて，ここで，ソフトウェアがどういう経緯をたどって作られるのかということの合意がない時，発注者の想定開発プロセスと受注者の想定開発プロセスが異なるとき，発注時の仕様書にソフトウェアの機能や性能が十分に記述されていない時，発注者の想定するソフトウェアは作られないことが起きる．発注者からすれば理想のソフトウェアを実現するために仕様を決定し実装に反映させようとする．一方，開発者からすれば優先順位の低い仕様を見送らせ実装すべき部分を最小化しようとする．このときどこでどう折り合いをつけるのか，ビジネス上の攻防が始まるに違いない．
我々の体験した開発者の対応は，発注者の仕様を最小化し実装すべき部分を最小化するひとつのやり方ではあった．それは大方の仕様を発注者と開発者と双方で決定するときに発注者から出される仕様の欠点を常々指摘したのち実装に着手する．検収期間を数日の範囲しかとれない状況で動作するシステムを発注者に提示し，改善すべき瑕疵について問いただす．その間に出される改善要求リストの項目に対してだけ改修しようとするが，改善すべき機能については新規案件だと主張し改修はしない．すなわち，要求機能は実装前に固定されて，その後実装を開始し，瑕疵についてだけ改修するというものであった．
要求機能を確定する段階はそう単純ではない．システムに対する入力と出力が明確に規格として決まっている仕様であれば，比較的早い段階で要求機能を固定することができる．しかし，開発者としてどのような仕様であるのかシステムの本質的な意図を把握することが難しい場合，開発者として見える要求仕様は徐々に明確になっていく．明確化する方法は，発注者からのフィードバックを得るしか方法がない．そのためには開発者は早々にプロトタイプシステムを発注者に提示して，発注者からのフィードバックを得ながらシステム仕様の詳細化と実装に取り組む方が，より早く必要なシステム仕様を確定できるのではないだろうか．周囲のビジネス状況の変化によって発注者の要求が変化すると同時に，システムに必要な機能が徐々に明確化するのである．
