非機能要件の特定
要件は、一般に機能的または非機能的と見なされます。 機能的な要件は、ソリューションが実行する必要がある内容またはその動作を説明し、非機能要件は、パフォーマンス要件などのソリューションの非動作の側面を説明します。 このトピックでは、非機能要件に関する考慮事項について説明します。
多くの場合、非機能要件は、コンピューターの経年期間、ネットワーク帯域幅、ネットワーク ファイアウォール、インターネット セキュリティ ソフトウェア、コンプライアンス担当者など、制御できない要素に依存しています。 したがって、依存関係に対処できるかどうかを左右する要因を特定する必要があります。また、配送スケジュールに悪影響を及ぼす可能性のある依存関係が存在する可能性もあります。 顧客がハードウェアを交換する必要がある場合、遅延が発生する可能性があります。 顧客が古いブラウザーしか使用できないレガシー アプリケーションを所有しており、最新のブラウザーを使用できない場合には、パフォーマンス目標が影響を受けます。 目標は、プロジェクトの早い段階でこれらの問題点を特定することです。事前に対処しておかないと、顧客はアプリケーションに欠陥があると認識する恐れがあります。
また、この状況では、多くの場合、クライアントの IT チームとの技術的検出セッションが必要になります。 技術的な内容の高度な話し合いによって業務に支障を及ぼすことは、適切ではありません。
非機能要件では、ユーザーは直接関心を持たないかもしれないが、ソリューションの提案されたアーキテクチャと運用上の実行可能性をサポートするためには重要な要素をキャプチャします。 非機能要件は、通常、ユーザーの採用や、ソリューションの認識される満足度に影響を及ぼします。 機能的な要件と同様に、非機能要件は優先順位を付ける必要があり、順位に従って段階的に提供することができます。
一般的な非機能要件タイプには、次のようなものが挙げられます。
可用性
コンプライアンス/規制
データ保存/所在地
パフォーマンス (応答時間など)
プライバシー
回復時間
セキュリティ
スケーラビリティ
非機能要件の例
次に挙げるのは、適切に構成された非機能要件の例です。
モバイル以外の内部ユーザーの画面読み込みの平均時間は 3 秒未満です。
外部ポータルでは、ケースの送信を実行している 100 人のユーザーに同時に対処できる必要があります。
次に挙げるのは、適切に表現されていない非機能要件の例です。
アプリ内のすべてのスクリーンをできるだけ速く読み込む必要があります。
外部ポータルはピーク時のトラフィックを処理できる必要があります。
システムは、災害発生後に回復可能である必要があります。
実現可能性
すべての要件が実行可能でなければなりませんが、多くの場合、非機能要件はより具体的です。したがって、予算とリソースの実態をさらに考慮することが適切です。 たとえば、中核となるアプリの可用性が 99.9% の場合は、99.999% の可用性を指定しても現実的ではありません。 さらに、十分な予算があれば達成可能だが、要件を満たす予算がない要件を指定する可能性があります。
コンプライアンスの測定
非機能要件に測定が含まれる場合は、コンプライアンスの測定方法と比較方法を指定する必要があります。 たとえば、フォームの読み込み時間の要件が 3 秒である場合は、キャンパス内専用にするか、モバイル ユーザーを含めるかを決定します。
演習: 非機能要件の検索
非機能要件タイプの一覧を確認します。
可用性
コンプライアンス/規制
データ保存/所在地
パフォーマンス (応答時間など)
プライバシー
回復時間
セキュリティ
スケーラビリティ
これらの非機能要件のうち、Woodgrove Bank で問題になると考えられるものを特定します。 予想される懸念事項のタイプと、その懸念事項の対処方法を検討します。 これまで考えていなかった懸案事項が他にも存在するかどうかを評価します。