Xupperの開発手法では、論理モデルと物理モデルを切り分けて考えるというコンセプトがあります。
ここで言っている論理モデルとは要件といってもいいかもしれません。要件を整理した後にどのように実装していくのかを検討しましょうという考え方です。(ある意味当たり前なのですが・・・)
しかし、実際のプロジェクトではなかなか両者を峻別して作業を行うということは困難です。
言葉で説明すると理解してもらえるのですが、では、実際に成果物を作ってくださいということになると、なかなかできません。(頭で理解できるということと、それを実際に行えるということは別ものです。)
業務要件を定義すべきところに、物理仕様(要件)が記述されていたり、物理仕様(要件)を記述すべきところに、業務要件(人間が行うこと)が記述されていたりします。
一旦、論理と物理が混在した成果物を作成してしまうと、その成果物の理解は非情に困難となります。
そういう成果物が出来て、顧客の承認も降りてしまうと、ある意味その成果物がバイブルとなってしまいます。
理解困難な成果物をベースに作業を行うということになりますので、その後の作業生産性は当然落ちることになります。
実際に作成するのは機能なわけですから、機能としての要件を明確にする必要が出てきます。
その場合、論理仕様(業務要件)と物理仕様(機能仕様)が混在している成果物から物理仕様(機能仕様)のみを拾い出して、機能定義を行うという作業を行う必要が出てきます。
最初から、論理仕様と物理仕様を明確に分けて作業を行えば、そのような作業は行う必要はないのですが・・・。
※コメント投稿者のブログIDはブログ作成者のみに通知されます