要件定義は、顧客から明確な形で提示された要望を記述すればよいというものではありません。顧客はニーズや期待の内容の全てを説明できないかもしれません。場合によっては顧客にとっては当たり前のことが、わざわざ説明するまでもないと思っているかもしれません。積極的にニーズ、期待、制約等を引き出しましょう。その方法は、打ち合わせやプロトタイプ、市場調査などがあります。また顧客だけではなく場合によっては法規制等も考慮する必要があります。顧客が設計について要求するかもしれませんが、そもそもなぜそれが必要なのかニーズを確認するといいです。

利害関係者のニーズ、期待、制約、およびインタフェースを、顧客要件へ変換しましょう。顧客要件に優先順位をつけると、もし対立があった場合、合理的に解決できます。顧客の要件は、顧客の用語で表現され、技術的でない記述を含むかもしれません。

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

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

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

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