ビジネスアナリストは、機能要件だけでなく、システムの動作速度、セキュリティ、スケーラビリティ、可用性、インターフェースの使いやすさなどの非機能要件の完全な収集、合意、文書化を担当します。そのためには、ステークホルダー（特にビジネスとIT）と密接に連携し、シナリオを使用し、基準を分析します。彼は明示的な期待を収集するだけでなく、隠れた要件（例：データ保護に関する規制）を特定する必要があります。最終的に、アナリストは非機能要件を文書化し、プロジェクトチームおよび技術チームと合意し、プロジェクト全体でこれらの要件が遵守されるよう監視します。
主な特徴：
非機能要件をメトリックや具体性なしにテキストで記述するだけで十分ですか？
いいえ、抽象的な表現（「速い」、「安全」）は検証には適しません。明確なパラメータが必要です：たとえば、応答速度は2秒以内。
非機能要件は技術者のみの関心事ですか？
いいえ、アナリストはビジネスと共同でそのような要件を特定し、形式化しなければなりません。これを遵守しないと、ビジネスの重要な利害関係者が不満を抱くことになります。
非機能要件の作業をプロジェクトの最終段階まで延期することは可能ですか？
いいえ、そのような要件はしばしば解決策のアーキテクチャにとって重大です。遅い段階での特定は、再作業や高いコストにつながります。
ネガティブケース： 期待される「使いやすさ」や「迅速な動作」を仕様書に記述しましたが、具体的なメトリックは固定しませんでした。 利点：ドキュメント作成時のコストが低い 欠点：結果が顧客を満足させなかったとき、チームに不満を言うことができませんでした。
ポジティブケース： 合意された内容：「ページの読み込み速度 — 最大2秒、1000ユーザーまでの負荷、SLAレベル — 99.95%」。個人データ保護に関する要件が形式化されました。 利点：結果の明確な検証、再作業のリスクの低減、すべての参加者への透明性 欠点：IT部門や法律家との合意に時間がかかりました。