要求は、製品が何をしなければならないかを定める。それはプロジェクトの実施結果について文書化された期待である。この文書は、プログラム、その機能、そしてプロジェクト全体について、顧客の期待と開発者の期待の双方を書き留める。要求には特性、費用、日程、リスクが含まれる。したがって要求とは、何を開発する必要があるかの言明であり、プロジェクトの実施の結果として何を得ると期待するかの精確で量的な記述である。要求の定義が不十分であることが、プロジェクト遂行中の問題の主たる原因である。
要求は、何をしなければならないか、どの程度うまく行わなければならないか、どのような制約のもとで行わなければならないかを指定する。要求が誤っていれば、プロジェクトも製品も欠陥をもつことになる。要求、制約、仮定は問題を部分に分ける。それがプロジェクト全体の成否を定める。
要求の種類。
- 機能要求は、当のシステム要素が何をしなければならないかを定める。
- 性能要求は、システムが遂行する対応する機能の量的なパラメータを定める。
- 制約要求は、運用様式の制限、環境条件、安全上の考慮、あるいは規制への適合から生じる。
- 検証要求は、実際の運用環境においてシステムが指定された特性をそなえているという確信を与える。
- インターフェース要求は、すべてのインターフェースの機能、特性、公差、制約を定める。
- 運用要求は、システムの運用上の即応性を指定し、システムの性能に主眼を置きつつ、システムが利用者とどう相互作用するかをも定める。
英語圏の文献では、よい要求の特性を覚えるために SMART という頭字語が用いられる。
- Specific（具体的である）——要求はプロジェクトの一つの特徴、あるいはシステムの一つの特性だけを扱わなければならない。それは何をしなければならないか、どの程度うまく行わなければならないかという言い方で定式化すべきであり、ありうる解——どう行うか——という言い方で定式化してはならない。
- Measurable（測定できる）——測定しうるパラメータは、客観的かつ量的に表される。
- Achievable（達成できる）——要求は妥当な費用のもとで技術的に達成しうるものでなければならない。
- Relevant（適切である）——要求は、選ばれたシステムの階層に対応していなければならない。
- Traceable（追跡できる）——下位の階層の要求は、上位の階層の要求から明示的に導かれ、および／またはそれによって支えられていなければならない。「親」をもたない要求は「孤児」とみなされ、その実現の必要性を評価しなければならない。
必要性。ある要求が必要かどうか疑わしければ、単にこう問えばよい。「この要求を一覧に含めなければ、システムにどのような害が及ぶか」。答えがないなら、その要求はおそらく不要である。
検証可能性。要求が定式化されたらただちに、それをどう検証しうるかを定めなければならない。そのためには、ふさわしい適合の基準を選ばなければならない。
達成可能性。要求が達成しうるものであるためには、与えられた日程と予算のうちに、付加的な制約のもとで技術的に実現可能でなければならない。要求の技術的な実現可能性に不確かさがあるなら、しかるべき検討あるいはさらなる調査を行わなければならない。それでもなお不確かさが残るなら、要求ではなく目標を定式化すべきである。要求が技術的に実現可能であっても、費用、日程、あるいは重量などのほかの制約のために達成しえないことがあるのは明らかである。成し遂げることが不可能なものについて要求を定式化しても意味がない。実際的でなければならない。
明確さ。どの要求も一つの考えを表し、簡潔で単純でなければならない。要求が明確で一義的であることが重要である。よい要求には、単純な文以上のものが必要ないことも多い。
要求は肯定の形で述べるべきであり、否定で始めては決してならない。文法的に正しく、誤字と脱落がないものでなければならない。システムのあらゆる階層で、一貫した用語を用いなければならない。