要件は、顧客とプロジェクトによって合意される必要があります。要件を理解するために、まず要件を提供する人は誰なのか明確にしましょう。いろいろな人が好き勝手なことを言うと、要件が肥大化し、プロジェクトの範囲を超えたものになるかもしれません。そして要件を受け入れる基準を作りましょう。要件が明確かどうか、矛盾がないか、一意に特定されているか、テスト可能か等が受け入れ基準として考えられます。要件が曖昧であると誤解される恐れがあります。要件を分析し、この基準を満たすことを確実にし、要件提供者と、要件に対する認識を合わせ合意しましょう。

前述のチェック項目No.1は、要件提供者と要件を合意することを扱っていましたが、このチェック項目は、要件を実装するのに必要な活動を行うプロジェクトメンバ等の人々の間での合意やコミットメントを扱います。コミットメントは、リソースやスケジュールなどを含みます。新しい要件に着手するときや要件が変更されるときには、その影響を評価する必要があります。また、既存のコミットメントに対する変更については、要件を受け入れたり変更したりする前に協議する必要があります。コミットメントの証拠は、署名でなくても、会議議事録や電子メール等でもかまいません。

プロジェクト実行中に要件はいろいろな理由で変更されます。ニーズの変化や作業の進行に伴って、追加の要件が導出され、既存の要件に対して変更が必要になる場合があります。このような追加や変更を効率的かつ効果的に管理しなければなりません。変更の影響を効果的に分析するためには、各要件の出所が把握されており、変更の論理的根拠が文書化されている必要があります。要件変更の出所は、プロジェクトの内部の場合も外部の場合もあります。また要件変更履歴は、プロジェクトメンバが後で疑問に思ったときに、なぜ決定がなされたのか振り返ることができます。

要件が設計書のどの部分に対応しているのか分からないといけません。すべての要件が設計に反映していないとえらいことになります。また要件変更の際には、設計のどの部分に影響があるのか知る必要があります。設計を修正する場合は、他の要件に悪影響がでないか確認しないといけません。だから、要件から作業成果物、作業成果物から要件への双方向のトレーサビリティを維持するのです。
テスト仕様書を作るときには、すべての要件がテストされるようにテスト仕様書を作らないといけません。また、どの要件がテストされているのか分からないといけません。要件に優先順位をつけていますと、それと関連づけてテスト項目の優先順位も分かります。

プロジェクト計画や活動、設計書などのドキュメントをレビューし、要件と矛盾していないかレビューしましょう。もし矛盾があれば、修正して整合性を保ってください。必要があればトレーサビリティ・マトリクスも更新します。
特に大きなプロジェクトでは、要件に変更があった場合に、すべてのドキュメントの整合性を維持するのは大変です。トレーサビリティ・マトリクスがあれば大いに役立つことでしょう。