パターン22:シナリオは問題を明らかにする

   

 

問題:

多くの場合、システムがどのように動くのかという顧客の観点での情報交換に使うには、設計ドキュメントは非効率的である。

コンテキスト:

顧客に参加して欲しい、そして顧客・開発者間の組織的な協力関係を支援するような仕組みが欲しい。

影響する事柄:

顧客と開発者の間には、もともとビジネス上の距離があり、不信感がある。

開発者と顧客の間の情報交換はシステムの成功にとって決定的なものである。

解決策:

Jacobson式に、システム要求仕様をユースケースとして取り込みなさい。

結果として生じるコンテキスト:

問題が明らかになり、アーキテクチャが本格的に決まり出す。雇われ分析者のパターンを参照してください。雇われ分析者は、シナリオを取り込み、プロジェクトドキュメントのために利用する(外部仕様も内部仕様もどちらも)。

論理的根拠:

Jacobsonにより、およびRalph Johnson によるCACM Nov. `88 (v. 31, no. 11) pp 1268-1287で実証されている。RubinとGoldbergは、設計の前も含めてすべての場合にシナリオをプロセスの前面に押し出している。"Formal Approach to Scenario Analysis," Pei Hsia, Jayaranan Samuel, Jerry Gao, and David Kung, IEEE Software, March, 1994, Vol. 11, No. 2, ff 33も参照してください。