ほとんどの要求事項はテスト可能であるべきである。もしテストできない要求事項があれば、代替となる検証方法が使われるべきである(例えば、分析、インスペクション、設計レビューなど)。テスト可能な要求事項は評価(ソフトウェアテストなど)の重要な要素となる。要求事項によっては、その構造上テスト不可能な場合がある。例えば、ある事象が「決して起きてはならない」とか「常にそうでなければならない」といった要求事項は、テストができない。こういった事項をテストしようとすると、テストを無限に実施しなければならなくなる。このような要求事項はより現実的な時間を指定するよう書き換えられることが多い。テスト不可能で非機能的な要求事項が、顧客の要請で残される場合がある。しかし、そのような要求事項は適切な実際的方法で限定された開発手法の要求事項として置き換えられるのが一般的である。要求分析.要求仕様はあいまいで不正確で一貫しないものになりやすい。この問題への対処として厳密なインスペクションなどの技法が示されてきた。あいまいさや不完全性や不整合性を要求仕様からなくすことで、開発工程の後の方で同様の問題が発覚したときよりも遥かに費用がかからなくなる。要求分析はそのような問題に対応する努力である。要求仕様の詳細さの程度には、以下のような工学的トレードオフがある:要求仕様の記述.要求仕様の変更.時と共に、要求仕様は変更されることがある。その場合、要求仕様が定義され承認された後、要求仕様は変更制御の管理下におかれる。多くのプロジェクトでは、要求仕様はシステム完成前に変更される。このような特性があるため、要求仕様には要求管理が必要とされる。ソフトウェアの要求仕様の厳密性に関する論争.エクストリーム・プログラミングのような最近のソフトウェア工学の方法論では、要求仕様を厳密に記述する必要性に疑問を呈している。その代わりとして要求仕様を「ユーザーストーリー」として非形式的に記述し、そのユーザーストーリーから受け入れテストのテストケースを作成する。ユーザーストーリーとは、システムのすべきことをある観点から簡単に描いたものである。要求定義歴史.