通常、要件には複数の詳細レベルがあります。たとえば、通常、詳細レベルを 0 (大まかなミッション ステートメント) から 4 (技術的詳細) の範囲に区別します。
そのため、SAN が少なくとも x の帯域幅容量で動作するように指定すると、その規模では大きな数値になります。主なアイデア (システムは応答性が高く、クライアントがせっかちになり、競合他社に移るのを防ぐため....) をより測定可能な目的 (上記のようなもの) に分解してください。
Stephen Withall は、彼の著書「Software Requirement Patterns」に良い例を書き留めています。第 9 章、191 ページ以降を参照してください。それほど高価ではありません。彼はそれを、応答時間、スループット、動的キャパシティ、静的キャパシティ、および可用性に関する推奨事項に分解します。
もちろん、それはソフトウェアです!基本的に、特定の状況下でシステム全体が何を主張するかを定義することから始めることをお勧めします: いつ測定を開始しますか? (例: クライアント要求がネットワーク ゲートウェイに届いたとき); 私たちの影響力を超えている平均ネットワーク遅延はどれくらいだと思いますか? いくつの異なるクライアントから測定し、何個の異なる自律システムからこれらが接触しますか? 正確にどのような種類のタスクを実行し、どの種類のリソースに対して非常に要求が厳しいでしょうか? いつ測定を停止しますか?関係するすべてのハードウェアで完全なシステム テストを本当に行っているのでしょうか。実行時にどのようなネットワーク監視を提供しますか? 等
問題を解決できない可能性がある転送速度/ IOPS などの単位に値を割り当てるだけの場合よりも、これが役立つはずです。後でネットワーク ハードウェアのパフォーマンスが期待を下回ったことがわかった場合は、簡単に交換できます。特にホスティングを外部パートナーに提供する場合。ただし、ソフトウェアの交換は容易ではありません。
満たさなければならない要件または制約と、実際に提供する技術ソリューションの一部を区別してください。もっと解決策があるかもしれません。速度は要件です (漠然としていますが)。ハードウェアのアーキテクチャはソリューションです。