非機能要件

システムエンジニアリングおよび要求工学において、非機能要求( NFR ) は、特定の動作ではなく、システムの動作を判断するために使用できる基準を指定する要求です。これらは、特定の動作や機能を定義する機能要求とは対照的です。機能要求の実装計画はシステム設計に詳細に記載されています。非機能要求の実装計画は、通常、アーキテクチャ的に重要な要求であるため、システムアーキテクチャに詳細に記載されています。^[¹^]非機能要求は、クロスファンクショナル要求とも呼ばれます。^[²^]

ソフトウェアアーキテクチャでは、非機能要件は「アーキテクチャ特性」として知られています。ソフトウェアアーキテクチャコンポーネント間の同期通信はそれらを絡み合わせ、それらは同じアーキテクチャ特性を共有する必要があることに注意してください。^{[ 3 ]}

意味

概して言えば、機能要件はシステムが何を行うべきかを定義し、非機能要件はシステムがどのような状態であるべきかを定義します。機能要件は通常、「システムは<要件>を行うべきである」という形式で、個々の動作またはシステムの一部、場合によっては数学関数、ブラックボックス記述、入力、出力、処理、制御機能モデル、またはIPOモデルといった形で明示的に示されます。一方、非機能要件は「システムは<要件>であるべきである」という形式で、システム全体または特定の側面に関する全体的な特性であり、特定の機能ではありません。システムの全体的な特性は、開発プロジェクトの成否を左右する重要な要素となることがよくあります。

非機能要件は、システムの「品質属性」と呼ばれることが多い。システムの創発特性^{[注1 ]}は、非機能要件に分類される。非機能要件の他の用語としては、「品質」、「品質目標」、「サービス品質要件」、「制約」、「非行動要件」^{[ 4 ] 、または「技術要件」}^{[ 5 ]}などがある。非公式には、安定性や移植性などの属性から、「ilities」と呼ばれることもある。品質、つまり非機能要件は、大きく2つのカテゴリに分類できる。

安全性、セキュリティ、ユーザビリティなど、実行時（運用時）に観察可能な実行品質。
システムの静的構造に具現化される、テスト容易性、保守容易性、拡張性、スケーラビリティなどの進化特性。 ^{[ 6 ]}^{[ 7 ]}

非機能要件とは、機能要件の範疇に入らないすべての要件を指すため、機能の特性だけでなく、法令、規制、規格、プロトコルなどの設計以外の項目や、その他の外部要件といったシステムに対する制約も含まれます。

非機能要件は、具体的かつ測定可能な方法で規定することが重要です。^{[ 8 ]}^{[ 9 ]}

非機能要件の分類

すべてのタイプのシステムに関連する一般的な非機能分類には、^{[ 10 ]が含まれます。}

パフォーマンス
信頼性、可用性、保守性、安全性
拡張性
テスト可能性

特定のシステムタイプでは、規格の中で非機能要件のカテゴリを明示的に列挙している。

ハードウェアシステム
組み込みシステム
安全性が極めて重要なシステム
ソフトウェアシステム

例

システムは、データベース内のレコード数をユーザーに表示する必要がある場合があります。これは機能要件です。この数値がどの程度最新の状態である必要があるかは、非機能要件です。数値をリアルタイムで更新する必要がある場合、システム設計者は、レコード数の変更から許容できる短い間隔でレコード数を表示できるシステムを保証しなければなりません。

十分なネットワーク帯域幅は、システムの非機能要件となる場合がある。その他の例としては、以下のようなものがある。

アクセシビリティ
適応力
監査可能性と統制
利用可能性（サービスレベル契約を参照）
バックアップ
起動時間
容量、現在および予測
認証
コンプライアンス
構成管理
適合性
コスト、初期費用、ライフサイクルコスト
データ整合性
データ保持
他者への依存
デプロイメント
開発環境
災害復旧
文書
耐久性
効率（与えられた負荷に対する資源消費量）
有効性（努力に対する成果）
弾性
感情的な要素（楽しい、夢中になれる、あるいは「すごい！」と思わせる要素があるなど）
環境保護
預託
倫理
悪用可能性
拡張性（機能の追加、および次回のメジャーバージョンアップグレード時のカスタマイズの引き継ぎ）
障害管理
耐障害性（例：運用システムの監視、測定、管理）
柔軟性（例えば、将来の要件変更に対応できる能力）
フットプリントの削減 - 実行ファイルのサイズを小さくする
統合可能性（例：コンポーネントを統合する能力）
国際化とローカライゼーション
相互運用性
法的およびライセンス上の問題、または特許侵害の回避可能性
保守性（例：平均修復時間– MTTR）
管理
メモリ最適化
変更可能性
ネットワークトポロジー
オープンソース
操作性
パフォーマンス（速度、バッテリー寿命、スループット、応答時間（パフォーマンスエンジニアリング））
物理的特性（サイズ、重量、電力、冷却性能など）
プラットフォーム互換性
プライバシー（プライバシー関連法の遵守）
携帯性
品質（例：発見された欠陥、納品された欠陥、欠陥除去の有効性）
読みやすさ
信頼性（例：平均故障間隔／平均故障時間– MTBF／MTTF）
報告
回復力
リソースの制約（プロセッサ速度、メモリ、ディスク容量、ネットワーク帯域幅など）
応答時間
再利用性
堅牢性
安全性または安全率
拡張性（水平方向、垂直方向）
開発および納品のスケジュール（プロジェクト管理）
セキュリティ（サイバーセキュリティと物理セキュリティ）
ソフトウェア、ツール、規格などの互換性
安定性
サポート可能性
テスト可能性
スループット
トレーニング
透明性
対象ユーザーコミュニティによるユーザビリティ（人間工学）
ボリュームテスト

批判

「非機能要件」という用語は、それが対象とする一連の要件の重要性を軽視する不適切な名称であるとして批判されている。 ^{[ 11 ]}^{[ 12 ]}その代わりに、「クロスファンクショナル要件」（CFR）という用語がThoughtWorksで提案され採用された。^{[ 2 ]}

参考文献

↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software . 30 (2): 38–45 . doi : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .
1 2 「クロスファンクショナル要件 (CFR) の 10 年 - Sarah Taraporewalla」 . sarahtaraporewalla.com . 2025 年 11 月 08 日取得.
↑リチャーズ、マーク、フォード、ニール (2020)。ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア社。ISBN 978-1492043454。
↑ステルマン、アンドリュー；グリーン、ジェニファー（2005）。応用ソフトウェアプロジェクト管理。オライリーメディア。p. 113。ISBN 978-0-596-00948-92015年2月9日にオリジナルからアーカイブされました。
↑ Ambler, Scott. "技術的（非機能的）要件：アジャイル入門" . Agile Modelling . Ambysoft Inc . 2018年10月5日取得.
↑ Wiegers, Karl; Beatty, Joy (2013).ソフトウェア要件、第3版。Microsoft Press。ISBN 978-0-7356-7966-5。
↑ヤング、ラルフ・R. (2001).効果的な要件定義の実践. アディソン・ウェスリー. ISBN 978-0-201-70912-4。
↑ Zimmermann, Olaf; Stocker, Mirko (2021). Design Practice Repository . LeanPub.
↑ Glinz, Martin (2008). "品質要求事項に対するリスクベースの価値指向アプローチ" (PDF) . IEEE Software . 25 (2): 34– 41. doi : 10.1109/MS.2008.31 . S2CID 19015424 .
↑ 「システムエンジニアリングと品質属性 KA」。sebokwiki.org 。 2025年5月24日取得。
↑ 「私はNFRを信じていません - Sarah Taraporewalla」 . sarahtaraporewalla.com . 2025年11月8日取得。
↑ニューマン、サム（2015）。マイクロサービスの構築：きめ細かいシステムの設計（第1版）。カリフォルニア州セバストポル：オライリーメディア。151ページ。ISBN 978-1-4919-5035-7。

注記

↑ SeBoK用語集の定義を参照

外部リンク

Petter L. H. Eide (2005). "Quantification and Traceability of Requirements". CiteSeerX 10.1.1.95.6464.
Dalbey, John. "Nonfunctional Requirements". Csc.calpoly.edu. Retrieved 3 October 2017.
"Modeling Non-Functional Aspects in Service Oriented Architecture"(PDF). Cs.umb.edu. Archived from the original(PDF) on 24 July 2011. Retrieved 3 October 2017.
"Non-Functional Requirements: Do User Stories Really Help?". Methodsandtools.com. Retrieved 3 October 2017.
"Non-Functional Requirements Be Here - CISQ - Consortium for IT Software Quality". it-cisq.org. Archived from the original on 26 September 2018. Retrieved 3 October 2017.
""Do Software Architectures Meet Extra-Functional or Non-Functional Requirements?"". 19 November 2020.

[ASR_Chen-1] Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software . 30 (2): 38–45 . doi : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .

[:1-2] 1 2 「クロスファンクショナル要件 (CFR) の 10 年 - Sarah Taraporewalla」 . sarahtaraporewalla.com . 2025 年 11 月 08 日取得.

[3] リチャーズ、マーク、フォード、ニール (2020)。ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア社。ISBN 978-1492043454。

[5] ステルマン、アンドリュー；グリーン、ジェニファー（2005）。応用ソフトウェアプロジェクト管理。オライリーメディア。p. 113。ISBN 978-0-596-00948-92015年2月9日にオリジナルからアーカイブされました。

[6] Ambler, Scott. "技術的（非機能的）要件：アジャイル入門" . Agile Modelling . Ambysoft Inc . 2018年10月5日取得.

[Wiegers13-7] Wiegers, Karl; Beatty, Joy (2013).ソフトウェア要件、第3版。Microsoft Press。ISBN 978-0-7356-7966-5。

[Young01-8] ヤング、ラルフ・R. (2001).効果的な要件定義の実践. アディソン・ウェスリー. ISBN 978-0-201-70912-4。

[9] Zimmermann, Olaf; Stocker, Mirko (2021). Design Practice Repository . LeanPub.

[MGUZH-10] Glinz, Martin (2008). "品質要求事項に対するリスクベースの価値指向アプローチ" (PDF) . IEEE Software . 25 (2): 34– 41. doi : 10.1109/MS.2008.31 . S2CID 19015424 .

[11] 「システムエンジニアリングと品質属性 KA」。sebokwiki.org 。 2025年5月24日取得。

[:0-12] 「私はNFRを信じていません - Sarah Taraporewalla」 . sarahtaraporewalla.com . 2025年11月8日取得。

[:2-13] ニューマン、サム（2015）。マイクロサービスの構築：きめ細かいシステムの設計（第1版）。カリフォルニア州セバストポル：オライリーメディア。151ページ。ISBN 978-1-4919-5035-7。

[4] SeBoK用語集の定義を参照

[

[ 3 ]

[注1 ]

[ 4 ] 、または「技術要件」

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]が含まれます。

非機能要件

意味

非機能要件の分類

例

批判

関連項目

参考文献

注記

外部リンク

関連するトピック

システムエンジニアリング

要求工学

要求です。これらは、特定の動作や機能を定義する

機能要求とは対照的です。