要件定義書や設計書のチームレビューを実施したとき、誤字脱字のような「軽微な指摘」ばかりが挙がり、テスト工程になってから修正工数の大きい不具合がいくつも見つかったという経験はないだろうか。 一般的なシステム構築プロジェクトでは、要件定義書や設計書のレビューに費やせる時間は限られている。多くの場合、その時間は十分とはいえないだろう。レビューで軽微な指摘に時間をかけてしまっている状況は、決して好ましくない。 本来レビューで注力すべきは、「重大な指摘」を数多く挙げることである。ここでいう重大な指摘とは、一般的な意味と異なり、レビューで見逃しテスト工程になって検出した場合に修正工数・コストが膨らむものを指す。致命的な欠陥であっても、テスト工程で検出して修正すれば十分なものへの指摘は含まないことに注意してほしい。なお、重大な指摘と軽微な指摘のどちらでもない中間的なものは「グレーな指摘注1」と呼ぶことに

JUAS(日本情報システム・ユーザー協会）が，「非機能要求仕様定義ガイドライン」を発行した。このガイドラインは，JUASが2007年9月から2008年3月にかけて実施した「UVC(User Vender Collaboration）研究プロジェクトII」の成果で，ユーザー企業がベンダーに提示する要求仕様書(別の言い方ではRFP＝提案依頼書）における非機能要求の定義方法をまとめたものである。 JUASは，2007年に「UVC研究プロジェクト」の成果として「要求仕様定義ガイドライン」を発行しているが，非機能要求については不十分だった。これを補うために，非機能要求に正面から取り組んだのがUVC研究プロジェクトIIであり，「非機能要求仕様定義ガイドライン」だ。 言うまでもなく，ユーザー企業がシステムの非機能要求を明確にベンダーに伝えることは非常に大切である。しかしこれまでは，どんな非機能要求を伝え