要件定義（参照：「要求、要件、機能」は、調達する情報システムにどのような機能を持たせるかを決めるプロセスです。情報システム調達での最初のプロセスであり、後続のプロセスに大きな影響を与える最重要なプロセスです。しかも、経営者や利用部門が主体となることが求められます。
- 手戻りをするな
- 例えば、家を建築で間取りの変更をするのに、間取り図を検討している段階ならば容易に対処できますが、基礎ができ棟上式をする頃になってからでは、多大な費用や時間がかかります。実際に居住してからではなおさらです。システム開発でも同様です。要求分析や外部設計があいまいなままに下流工程に入り、プログラミングや実施のプロセスになってから不都合が発見されたら、多大な費用や時間がかかります。
ベーム（Boehm）は要件定義が確定した段階で、要求の誤りを発見して修正する場合のコストを１としたとき、後の段階で発見して修正するコストは、
設計段階 ５
プログラミング段階 １０
稼働開始後 １００
になると指摘しています。また、全体の欠陥のうち、プログラミングのエラーによるものは３５％程度で、６５％は、それ以前の要件定義や設計の上流工程で埋め込まれるとの指摘もあります。 - ２４２３の法則
- 契約時点での要求仕様が完璧で、引渡完了まで要求変更が生じないようなことはまずありません。作業を進めている間に要求が変更になったり追加されたりするのが通常です。そのとき、ベンダ側は仕様の変更・追加なのだから契約金額の変更を主張しますし、発注側は要求解釈の問題でありベンダが当然予測しているはずだとして拒否します。
昔、２４２３の法則がありました。「契約段階では２の金額で２の機能のシステムを作ることに合意したのに、その後、機能が４になってしまった。それでベンダは増額を要求したが、発注側の拒否により、２の金額は変更されなかった。結果として、ベンダは２の金額で３の機能を作ることになり、１の不満を持つ。発注側は４の機能を３の機能にさせられたので１の不満を持つ。」というのです。
ところが現在では、そのような鷹揚な対処はできません。裁判になることも多いのです。
また、金額面だけでなく、納期の遅れが問題になることもあります。その場合も、要求仕様の決定の遅れや作業開始後の変更・追加により開発が遅延したことが原因であることが多いのです。
利用部門の認識が重要
- 要件の取りまとめ
- 下図は「日経ＩＴプロフェッショナル（現 日経ＳＹＳＴＥＭＳ）」２００４年１月号によるアンケートですが、ベンダ（ＩＴ部門も）は発注者（利用部門）に対して、「人により要件が異なる」し、「いつになっても要件が決まらない」だけでなく、「作業が進んだ後から要件の変更・追加がでる」という不満を持っています。これが費用や納期に大きな影響を与えているのだということを理解してほしいと思います。
- 過剰要求
- 利用部門のなかには、ＩＴ化に異常に熱心な人がいます。これを機会にあれもしたいこれもしたいと、多くの要求事項を提出します。そのなかには、重要なものもありますが、たいして重要ではないものもあるし、すばらしいものでも自社の成熟度では到底実現できないようなものまであります。しかも熱心にそれらの重要性を説き、実現を強く要求します。
情報システムの開発費用（保守費用）は、規模の指数乗に比例して増大します。それに対して効果は、重要順にならべれば対数的にしか増大しません。効果－費用が最大になる点が情報システムの最適規模になりますが、このような過剰要求により、最適規模より大規模になり利益が下がり、極端なときには開発した時点で損失になるようなことになります。一見、熱心な人が、実は阻害要因だということになります。
