ソフトウェアエンジニアリングにおける非機能要件とは何ですか?
チャールズ・ムーア
⚡ スマートサマリー
非機能要件は、パフォーマンス、セキュリティ、ユーザビリティ、信頼性、拡張性、移植性といった品質属性を規定し、ソフトウェアシステムがどの程度適切に動作する必要があるかを定義し、漠然とした期待を、開発ライフサイクル全体にわたって測定可能でテスト可能かつ強制力のあるエンジニアリング目標へと変換します。
非機能要件とは何ですか？
A 非機能要件 （NFR）は、ソフトウェアシステムの品質属性を指定します。NFRは、応答性、ユーザビリティ、セキュリティ、移植性、および成功に不可欠なその他の品質属性に基づいてシステムを評価します。一般的な非機能要件の例は次のとおりです。 「ウェブサイトの読み込み速度はどのくらいですか?」 非機能要件を満たさないと、ユーザーを不満にさせるシステムが生まれてしまう。
ソフトウェアエンジニアリングにおける非機能要件は、アジャイルバックログ全体にわたってシステム設計に制約を課します。例えば、同時接続ユーザー数が1万人を超えた場合、サイトは3秒以内に読み込まれる必要があります。非機能要件を記述することは、機能要件を把握することと同様に重要です。
非機能要件の種類
非機能要件の主なカテゴリは以下のとおりです。
非機能要件の種類
- 使いやすさ
- 保守性
- 管理容易性
- 回復性
- セキュリティ
- Rescale データ Integrity
- 容量
- 利用状況
- 拡張性
- 相互運用性（インターオペラビリティ）
- 信頼性の向上
- 保守性
- 企業コンプライアンス
- 環境上の制約
非機能要件の例
以下に、非機能要件の具体的な例を示します。
- ユーザーは初回ログイン成功後に初期パスワードを変更する必要があり、初期パスワードは決して再利用してはなりません。
- 従業員は自身の給与情報を更新することは認められず、そのような試みがあった場合はセキュリティ管理者に報告しなければならない。
- ユーザーがデータ項目にアクセスしようとして失敗した場合、そのすべての試行は監査証跡に記録される。
- ウェブサイトは、応答時間を低下させることなく、20万人の同時接続ユーザーをサポートしなければならない。
- ソフトウェアは移植性を備え、あるオペレーティングシステムから別のオペレーティングシステムに移行する際に問題が発生しないようにする必要がある。
- 情報のプライバシー、制限技術の輸出、および知的財産権は監査の対象となる。
機能要件と非機能要件
機能要件と非機能要件の主な違いは以下のとおりです。
| 技術パラメータ | 機能要件 | 非機能要件 |
|---|---|---|
| それは何ですか？ | 動詞 | Attributes |
| 要件 | それが必須です | 強制ではありません |
| 捕獲タイプ | ユースケースでキャプチャされます。 | それは品質属性として捉えられます。 |
| 最終結果 | 製品の機能 | 製品の特性 |
| キャプチャ | 捕獲が簡単 | 捕獲が難しい |
| DevOps Tools Engineer試験のObjective | ソフトウェアの機能を検証するのに役立ちます。 | ソフトウェアのパフォーマンスを検証するのに役立ちます。 |
| 重点分野 | ユーザーの要件に焦点を当てる | ユーザーの期待に集中します。 |
| ドキュメント | 製品の機能を説明する | 製品の仕組みについて説明します |
| テストの種類 | 機能テスト システムテスト、統合テスト、エンドツーエンドテスト、APIテストなど。 | パフォーマンス、ストレス、ユーザビリティ、セキュリティテストなどの非機能テスト。 |
| テストの実行 | テストの実行は、非機能テストの前に行われます。 | 機能テスト後 |
| 製品情報 | 製品の特徴 | 製品のプロパティ |
非機能要件の利点
の主な利点は 非機能テスト には次の値があります:
- 非機能要件は、システムが法律およびコンプライアンス規則を遵守することを保証するものです。
- それらはシステムの信頼性、可用性、およびパフォーマンスを保護する。
- それらは優れたユーザーエクスペリエンスと操作の容易さを提供します。
- それらはソフトウェアのセキュリティポリシーを策定する。
非機能要件の欠点
非機能要件の一般的な欠点は以下のとおりです。
- 非機能要件は、複数の上位レベルのソフトウェアサブシステムに影響を与える可能性があります。
- それらは建築設計や高度な設計段階で特別な配慮を必要とし、コスト増につながる。
- 実装は、単一のソフトウェアサブシステムに一致することは稀である。
- 設計段階が完了すると、それらを変更するのは困難です。
非機能要件を分類するためのFURPS+モデル
FURPS+は、非機能要件の分類法として最も広く用いられている。元々はヒューレット・パッカード社で開発されたもので、品質属性を5つの主要カテゴリに分類し、さらに「+」で示される追加の制約事項も加えている。このモデルは、ビジネスアナリストが要件のクラス全体を見落とすことを防ぐのに役立つ。
- 機能性： 基本的な機能リストを超えた、機能性、セキュリティ、そして再利用性。
- ユーザビリティ： ユーザーエクスペリエンスにおける人間工学、美観、一貫性、ドキュメント作成、応答性。
- 信頼性： 可用性、平均故障間隔、復旧性、予測可能性、および精度。
- パフォーマンス： 負荷時の速度、スループット、容量、拡張性、およびリソース消費量。
- サポート性: 納品されたシステムのテスト容易性、柔軟性、インストール容易性、ローカライズ容易性、および保守容易性。
- プラス（+）： 設計、実装、インターフェース、および必要なプラットフォーム、規格、ハードウェアなどの物理的な制約。
非機能要件をすべてFURPS+カテゴリにマッピングするチームは、機能面では満たしていても、パフォーマンス、セキュリティ、保守性において問題のあるシステムを出荷する可能性が低くなります。
テスト可能な非機能要件の書き方
適切に記述された非機能要件は、測定可能、検証可能、かつ期限が定められている必要があります。「システムは高速でなければならない」や「アプリは安全でなければならない」といった曖昧な記述は、要件ではなく願望です。以下の手順に従って、意図をテスト可能な非機能要件に変換してください。
- 品質特性を特定する。 懸念事項をFURPS+のカテゴリにマッピングすることで、チームはそれがパフォーマンス、ユーザビリティ、セキュリティ、信頼性のいずれの要件であるかを把握できます。
- 指標を選択してください。 すべての非機能要件（NFR）には、ミリ秒、1秒あたりのリクエスト数、同時接続ユーザー数、稼働率、またはISO 27001などの準拠規格といった単位が必要です。
- 数値のしきい値を設定します。 「高速」を「95パーセンタイルで400ミリ秒未満」に置き換えてください。「高可用性」を「月間稼働率99.9%」に置き換えてください。
- 症状を説明してください。 しきい値が適用される負荷、環境、またはユーザーセグメントを明記してください。例えば、「同時接続ユーザー数が10,000人に達するピーク時の売上時」などです。
- 検証方法を定義する。 テストの種類（負荷テスト、侵入テスト、カオス実験、アクセシビリティ監査など）と、しきい値を確認するためのツールをメモしておいてください。
- SMARTチェックを実施してください。 要件がバックログに追加される前に、その要件が具体的、測定可能、達成可能、関連性があり、期限が定められていることを確認してください。
書き換え例：「システムは高速でなければならない」は「チェックアウトページは、同時接続ユーザー数5,000人に対して95パーセンタイルで500ミリ秒未満で応答し、 JMeter 「各リリースごとに負荷テストを実施する。」この改訂された声明により、開発者はそれを前提とした設計を行い、テスターはそれを検証し、製品オーナーは異論なくそれを受け入れることができる。
