要求確認とは
要求仕様書の一貫性、完全性、正確性、実現可能性を確認するフェーズです。
一般的に要求確認のフェーズで上席者の参加が増える場合が多く、出戻りが多く発生するフェーズです。
出戻りを防ぐためには、要件抽出・分析時に上席者承認を行う事が大切です。
フェーズの後半で帳尻をあわせようとすると、だいたい破綻するので注意してください。
要求確認のポイントは下記一点につきます。
「何が確認できれば、要求仕様の妥当性を確認できたことになるか」という評価基準について関係者と合意しておく事。
では具体的に、どういった観点で確認がとれたと判断すべきなのでしょうか？下記に項目を並べます。
・要求の正確性：要求の記述が曖昧でないことを確認する。
・記述の最小性：要求の記述が重複していないか、設計段階で解決するようなことまで含めて詳細に記述しすぎていないかを確認する。
・外部環境との一貫性：業務やシステム環境、組織の中で要求が一貫しているかを確認する。
・要求の完全性：必要な要求がすべて記述されていることを確認する。
・要求の実現可能性：記述された要求を実現するために、技術的に開発可能であることと、必要な経費や開発期間、開発要員が用意できることを確認する。
次に、どのような手法を用いて要求確認を行えば良いかを列挙します。
・要求仕様のレビュー
現在採用されている確認手法です。
妥当性の確認基準を定めて対応するチェックリストを用意しておくと効率的で公平なレビュを実施できるという利点があります。
裏を返せば、確認基準が曖昧な場合この手法は用いるべきではありません。
・プロトタイピング
要求に基づいてシステムのプロトタイプを作成する手法です。
相手に触ってイメージしてもらえるため、文書よりも深い議論が可能性になります。
欠点としては、プロトタイプの作成に工数がかかる、プロトタイプのイメージに縛られるため、革新的なアイデアが生まれにくいといった点が上げられます。
・モデルの確認
文書だけのレビューでなく、図を用いて確認する手法です。
フローを追うことでロジックが明確になる半面、担当者に対してある程度の業務知識を要求します。
・要求テスト
受け入れテスト仕様書と要求仕様を照らし合わせるパターン。
いかがでしたでしょうか？
要求確認はアイデアを生み出す場でなく確定させる場ですので、
このフェーズにおける最大の失敗は新しいアイデア、要求が発生する事です。
かと言っても上席者と要求確認をしていると・・・
・やっぱりこうした方が良くない？
・こういうのは出来ない？
と言われる事など日常茶飯事なはずです。
偉い人は忙しく、要求確認より前のフェーズに参加をする事が難しいのは理解出来ます。
ただ、結果的に早く要件定義を終わらせるためには偉い人を速いタイミングで巻き込んでいかなければいけない事を理解してください。