通常,需求的細節級別不止一個。例如,您通常將細節級別劃分爲從0(粗略任務語句)到4(技術細節)的範圍。
因此,如果您指定您的SAN應該至少以x的帶寬容量運行,那麼這將是該規模上的高數。確保分解你的主要想法(系統應該是有響應的,以防止客戶變得不耐煩並離開競爭對手......)變成更可衡量的目標(如上所述)。
Stephen Withall在他的書「Software Requirement Patterns」中寫下了很好的例子。參見第9章第191頁然後,它並不昂貴。 他將其分解爲建議,並引用響應時間,吞吐量,動態容量,靜態容量和可用性。
當然,這是軟件!因爲基本上,你可能會被建議首先定義整個系統在特定情況下聲明的內容:我們什麼時候開始測量? (例如,當客戶端請求進入網絡網關時);我們認爲什麼樣的平均網絡延遲超出了我們的影響?從我們測量多少個不同的客戶,以及這些客戶與多少個不同的自主系統進行聯繫?他們執行的是哪種類型的任務,以及哪種資源會特別苛刻?我們什麼時候停止測量?我們是否真的在涉及所有硬件的情況下進行完整的系統測試我們將在運行時提供哪種網絡監控?等
這應該比你如果只給一個單位如傳輸速率/ IOPS這可能甚至不能解決你的問題的單位賦值更多的幫助。如果您發現網絡硬件的性能低於您的預期,那麼交換相當容易。特別是如果你把你的託管給外部合作伙伴。但是,該軟件不易交換。
務必區分您必須符合的要求或約束條件,以及實際上是您提供的技術解決方案的一部分。可能有更多的解決方案。速度是一個要求(儘管如此)。硬件架構是一個解決方案。