歴史的に、ITプロジェクトでは、システムが何をするべきかという機能要件に主な焦点が当てられてきました。そのため、パフォーマンス、信頼性、スケーラビリティ、可用性、安全性、保守性といった問題（これらの特性は「非機能要件」（NFR）という用語でまとめられています）は、長い間二次的なものとされ、しばしば正式に文書化されることすらありませんでした。
NFRの無視または形式的な記述は、運用の上で重大な問題を引き起こします。システムが期待される負荷に対応できず、サイバー攻撃に耐えられず、メンテナンスやスケーリングが困難であるか、必要な数のユーザーに対して利用できなくなる可能性があります。
現代のシステムアナリストは、NFRを提起し、形式化し、分析し、文書化する義務があります。これには以下が含まれます：
主な特徴：
「製品の品質」と「非機能要件」の違いは何ですか？
製品の品質は、形式化可能なパラメータだけでなく、主観的な評価（例：UX/UIの使いやすさ）を含むより広い概念です。NFRは、明確に測定可能な特性（パフォーマンス、信頼性など）であり、自動検証の対象となります。
アナリストは、すべての非機能要件の特定をアーキテクトに委任できますか？
いいえ、アナリストはアーキテクトおよびビジネスと共同でこれらの要件を分析段階で特定する必要があります。そうしなければ、要件は不完全であるか、ビジネスニーズを考慮せずに技術的側面のみが記述されることになります。
非機能要件を「システムは信頼できるべき」という一般的な表現のみで表現することはできますか？
いいえ、そのような表現は管理やテストには適していません。具体化が必要です：たとえば、「障害後のサービスの復旧時間は10分を超えてはならない」とする必要があります。
否定的なケース：国家サービスポータルのプロジェクトは、ピーク負荷に関する要件を正式に文書化しませんでした。人気のあるサービスが開始される日には、システムが「ダウン」し、セキュリティインシデントが発生しました。
利点：
欠点：
肯定的なケース：産業自動化工場のプロジェクト開始時にアナリストは、稼働の観点からシステムのダウンタイムが新機能よりも重要であることを明らかにしました。SLA、緊急シナリオを検討し、具体的なメトリクスを記述しました。
利点：
欠点：