非機能要件フレームワーク

非機能要件（NFR ）を整理するには、フレームワークが必要です。分析は、関係者が合意したNFRを表すソフトゴールから始まります。ソフトゴールとは、表現しにくいものの、ソフトウェアシステムの全体的な特性を表す目標です。例えば、特定のシステムにおけるユーザビリティ、パフォーマンス、セキュリティ、柔軟性などが挙げられます。チームがソフトゴールを収集し始めると、多くの場合、膨大な数のソフトゴールが見つかります。その数を管理しやすい量に減らすには、構造化が有効です。構造化に役立つフレームワークはいくつか存在します。

以下のフレームワークは、非機能要件（NFR）の構造として役立ちます。

目標モデリング

最終的に確定したソフトゴールは、通常、分解および精緻化されて、たとえば柔軟性ソフトゴールのような目標とサブゴールのツリー構造が明らかになります。ツリー構造が明らかになると、異なるツリー内で干渉するソフトゴールが見つかるはずです。たとえば、セキュリティ目標は一般的にユーザビリティに干渉します。これらのソフトゴールツリーは、ソフトゴールグラフ構造を形成します。この分析の最終ステップは、すべてのルートソフトゴールが満たされるように、特定のリーフソフトゴールを選択することです。^{[ 1 ]}

IVENA ^{[ 2 ]} - NFR取得のための統合的アプローチ

この手法は要求ツリーを統合している。^{[ 3 ]}

組織の状況

組織のコンテキストを説明するモデルはいくつかあり、ビジネスモデルキャンバス、OrgManle ^{[ 4 ]などがある[ 5 ]}。これらのモデルは、NFR を割り当てるための優れたフレームワークでもある。

SNAPはソフトウェア非機能評価プロセスです。ソフトウェアアプリケーションを通じたデータフローのサイズを測定することで機能要件を測定するのに対し、IFPUGのSNAPは非機能要件を測定します。

SNAPモデルは、非機能要件を測定するための4つのカテゴリと14のサブカテゴリで構成されています。非機能要件は、関連するサブカテゴリにマッピングされます。各サブカテゴリにはサイズが設定されており、要件のサイズは、そのサブカテゴリのサイズの合計となります。

SNAPサイジングプロセスは、ファンクションポイントサイジングプロセスと非常によく似ています。アプリケーション境界内で、非機能要件は関連するカテゴリとそのサブカテゴリに関連付けられます。標準化された一連の基本基準を使用して、各サブカテゴリはタイプと複雑さに応じてサイズが決定されます。このような要件のサイズは、そのサブカテゴリのサイズの合計です。これらのサイズを合計することで、ソフトウェアアプリケーションの非機能要件のサイズが算出されます。

モデルのベータテストの結果、SNAPのサイズは、ソフトウェアアプリケーションの非機能部分の開発に必要な作業量と強い相関関係があることが示された。

• SNAPポイント