問題の歴史：
最初は要件の形式化が機能的な能力に焦点を当てていましたが、時間が経つにつれて、一見「見えない」基準（パフォーマンス、セキュリティ、耐障害性など）が製品の成功した導入と持続可能性にとって極めて重要であることが明らかになりました。それらを無視することは、失敗や予測不可能なソフトウェアの挙動を引き起こす結果となりました。
問題：
非機能要件はしばしばテンプレート的に記録され、文脈が考慮されていません。それらは「チェックリスト」のためだけに記載されるか、あまりにも抽象的に形成されます。例えば、「システムは使いやすいべきである」や「システムは迅速であるべきである」というように。これでは、開発者、アーキテクト、テスターに明確なKPIを提供することができません。
解決策：
システムアナリストは、ビジネス、IT、および運用担当者とのセッションを行い、実際の制約を特定し、数値的なメトリクス（例えば、SLA、TPS、レイテンシ指標）を記録し、非機能要件を明示的に仕様に記述し、その後、テストケースやプロジェクトのアーキテクチャーのアーティファクトと関連付けてテスト可能性を確保します。
主な特徴：
「システムは24時間365日利用可能であるべき」といった要件のグループを詳細化なしに残すことは可能ですか？
いいえ、可用性のパラメータ（例えば、99.95%）と復旧条件を必ず明確にする必要があります。
「応答速度は速いべき」と記載するだけで十分ですか？
いいえ、そのような表現は機能しません。例えば、「応答時間は95%のリクエストでXの負荷条件下で3秒未満であるべき」と指定する必要があります。
非機能要件は、一般的な仕様書にのみ記載され、さらなる詳細がない場合、正式化されていますか？
いいえ、これらは分解し、アーキテクチャの解決策やテスト計画と関連付ける必要があります。そうしないと、実行不可能または検証不可能なまま残ります。
否定的なケース：eバンキングプロジェクトは「24時間営業、高速動作」という要件で始まりましたが、SLAの明確化はありませんでした。
利点：
欠点：
肯定的なケース：アナリストは運用部門と連携し、99.9%の稼働時間、最大応答2秒を記録し、劣化シナリオを説明しました。
利点：
欠点：