Loading article…
システム工学と要件工学 において、非機能要件( NFR ) は、特定の動作ではなく、システムの動作を判断するために使用できる基準を指定する要件です。これらは、特定の動作または機能を定義する機能要件とは対照的です。機能要件を実装するための計画は、システム設計で詳細に記述されます。非機能要件を実装するための計画は、通常、アーキテクチャ的に重要な要件であるため、システムアーキテクチャで詳細に記述されます。[1]
ソフトウェアアーキテクチャでは、非機能要件は「アーキテクチャ特性」として知られています。ソフトウェアアーキテクチャコンポーネント間の同期通信はそれらを絡み合わせ、同じアーキテクチャ特性を共有する必要があることに注意してください。[2]
意味
大まかに言えば、機能要件はシステムが何をすべきかを定義し、非機能要件はシステムがどうあるべきかを定義します。機能 要件は通常、「システムは <要件> を行うものとする」という形式をとり、これはシステムの個々のアクションまたは一部であり、数学的関数、ブラックボックス記述の入力、出力、プロセス、および制御機能モデル、またはIPO モデルといった意味で明示的に表される場合もあります。対照的に、非機能要件は「システムは <要件> とする」という形式をとり、これはシステム全体または特定の側面の全体的な特性であり、特定の機能ではありません。システムの全体的な特性は、通常、開発プロジェクトが成功するか失敗するかの違いを示します。
非機能要件は、システムの「品質属性」と呼ばれることがよくあります。非機能要件の他の用語には、「品質」、「品質目標」、「サービス品質要件」、「制約」、「非動作要件」 [3]または「技術要件」などがあります。[4]非公式には、安定性や移植性などの属性から、これらは「信頼性」と呼ばれることもあります。品質、つまり非機能要件は、主に 2 つのカテゴリに分類できます。
- 安全性、セキュリティ、使いやすさなど、操作中（実行時）に観察可能な実行品質。
- テスト可能性、保守性、拡張性、スケーラビリティなどの進化の特性は、システムの静的構造に具体化されます。[5] [6]
非機能要件を具体的かつ測定可能な方法で指定することが重要です。[7] [8]
例
システムでは、データベース内のレコード数をユーザーに表示する必要がある場合があります。これは機能要件です。この数をどの程度最新の状態にする必要があるかは、非機能要件です。数をリアルタイムで更新する必要がある場合、システム設計者は、レコード数が変化する許容範囲内で短い間隔でシステムがレコード数を表示できることを確認する必要があります。
十分なネットワーク帯域幅は、システムの非機能要件である場合があります。その他の例としては、次のものがあります。
- アクセシビリティ
- 適応性
- 監査可能性と制御
- 可用性（サービスレベル契約を参照）
- バックアップ
- 起動時間
- 容量、現在および予測
- 認証
- コンプライアンス
- 構成管理
- 適合性
- コスト、初期コスト、ライフサイクルコスト
- データの整合性
- データ保持
- 他党への依存
- 展開
- 開発環境
- 災害復旧
- ドキュメント
- 耐久性
- 効率（与えられた負荷に対するリソース消費）
- 有効性（努力に対する結果的なパフォーマンス）
- 弾性
- 感情的な要素（楽しさや夢中になれること、驚きの要素など）
- 環境保護
- 預託
- 倫理
- 悪用可能性
- 拡張性（機能の追加、次回のメジャー バージョン アップグレードでのカスタマイズの継承）
- 障害管理
- フォールトトレランス（例：運用システムの監視、測定、管理）
- 柔軟性（例：将来の要件変更への対応）
- フットプリントの削減 - exeファイルのサイズを縮小
- 統合可能性（例：コンポーネントを統合する能力）
- 国際化とローカリゼーション
- 相互運用性
- 法的およびライセンスの問題、または特許侵害の回避可能性
- 保守性（例：平均修復時間– MTTR）
- 管理
- メモリの最適化
- 変更可能性
- ネットワークトポロジ
- オープンソース
- 操作性
- パフォーマンス/ 応答時間 (パフォーマンスエンジニアリング)
- プラットフォームの互換性
- プライバシー（プライバシー法の遵守）
- ポータビリティ
- 品質（例：発見された障害、配信された障害、障害除去の有効性）
- 読みやすさ
- 信頼性（例：平均故障間隔/平均故障時間- MTBF/MTTF）
- 報告
- 回復力
- リソース制約 (プロセッサ速度、メモリ、ディスク容量、ネットワーク帯域幅など)
- 応答時間
- 再利用性
- 堅牢性
- 安全性または安全係数
- スケーラビリティ（水平、垂直）
- セキュリティ（サイバーと物理）
- ソフトウェア、ツール、標準などの互換性
- 安定性
- サポート性
- テスト可能性
- スループット
- 透明性
- 対象ユーザーコミュニティ別のユーザビリティ（ヒューマンファクター）
- ボリュームテスト
参照
- ISO/IEC 25010 :2011 国際標準化機構(ISO)
- ITソフトウェア品質コンソーシアム
- 9126 規格
- ファープス
- 要件分析
- ユーザビリティ要件
- 非機能要件フレームワーク
- アーキテクチャ上重要な要件
- SNAPポイント
参考文献
- ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). 「アーキテクチャ上重要な要件の特徴づけ」. IEEE ソフトウェア. 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.
- ^ リチャーズ、マーク、フォード、ニール (2020)。ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア社。ISBN 978-1492043454。
- ^ ステルマン、アンドリュー、グリーン、ジェニファー (2005)。応用ソフトウェアプロジェクト管理。オライリーメディア。p. 113。ISBN 978-0-596-00948-92015年2月9日時点のオリジナルよりアーカイブ。
- ^ Ambler, Scott. 「技術 (非機能) 要件: アジャイル入門」アジャイルモデリング. 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). デザインプラクティスリポジトリ. LeanPub.
- ^ Glinz, Martin (2008). 「品質要件に対するリスクベース、価値指向のアプローチ」(PDF) . IEEE ソフトウェア. 25 (2): 34–41. doi :10.1109/MS.2008.31. S2CID 19015424.
外部リンク
- Petter LH Eide (2005)。「要件の定量化と追跡可能性」。CiteSeerX 10.1.1.95.6464 。
- Dalbey, John. 「非機能要件」Csc.calpoly.edu . 2017 年10 月 3 日閲覧。
- 「サービス指向アーキテクチャにおける非機能的側面のモデリング」(PDF)。Cs.umb.edu 。2011年 7 月 24 日のオリジナル(PDF)からアーカイブ。2017 年10 月 3 日に取得。
- 「非機能要件: ユーザーストーリーは本当に役立つのか?」Methodsandtools.com。2017年10 月 3 日閲覧。
- 「非機能要件はここにあります - CISQ - IT ソフトウェア品質コンソーシアム」。it - cisq.org。2017年10 月 3 日閲覧。
- 「ソフトウェア アーキテクチャは、機能追加要件または非機能要件を満たしているか?」。2020 年 11 月 19 日。