如何編寫高質量“軟件需求說明書”[2]

　　如何編寫高質量“軟件需求說明書”[2]   軟件測試

　　優先權：為了表明在一個詳細的產品版本中應包含哪些要點，需要為每個需求，特征，或用例分配實現的優先權?？蛻艋蚱浯矶紤袕娏业呢熑谓炏葯?。如果所有的需求都被視為同等重要，那么由于在開發中，預算削減，計劃超時或組員的離開導致新的需求時， 項目經理將不能起到作用。優先權的作用是提供給客戶的價值，實現的相關費用，實現相關聯的有關技術風險。

　　我是用3種級別的優先權：高優先權表明需求必須體現在下一個產品版本中，中優先權表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中，低優先權表明有它很好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。

　　明確：需求敘述的讀者應只能從其得到唯一的解釋說明，同樣，一個需求的多個讀者也應達成共識。自然語言極易導致含糊。要避免使用一些對于SRS作者很清楚但對于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔，簡單，直觀的采用用戶熟知的語言，不要采用計算機術語。檢查需求模糊的有效方式包括需求說明書的正規檢查，根據需求寫測試，建立用戶的假想來說明產品某個特定部分預期的特性。

　　可證實：看你是否能夠做出測試計劃或其他驗證方式，如檢查和實證，來決定在產品中每個需求是否正確的實現。如果需求是不可驗證的，決定需求是不是正確的實現就成了判斷的事。需求之間不一致，不可行，不明確也能導致不可證實。任何需求如果說產品將要支持什么也是不可證實的。

　　高質量需求說明的特征

　　一個完整的SRS不僅是包括長長的功能性需求列表，還包括外部接口描述和一些諸如質量屬性，期望性能的非功能性需求。下面描述了高質量的SRS的一些特性。

　　完整：不應該遺漏要求和必需的信息。完整性也是一個需求應具備的。發現缺少的信息很難，因為根本不存在。在SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西。

　　在需求抽象時，相對于系統功能，你過多的注意用戶的業務，將導致在需求的全局觀和引進不是真正必需的需求上顯得不足。在需求抽象上，應用用例方法會發揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

　　如果你知道已缺少一些信息，使用TBD(to be determined)標準標志可以突出這些缺陷，當你在構建產品的相關部分時，就可以從一個給定的需求集中解決所有的缺陷。

　　一致性：一致性需求就是不要于其他的軟件需求或高級別的系統(商業)需求發生沖突。需求中的不一致必須在開發開始前得到解決。只有經過調研才能確定哪些是正確的。修改需求時一定要謹慎，如果只審定修改的部分，沒有審定于修改相關的部分，就可能導致不一致性。

　　可修改性：當每個需求的要求修改了或維護其歷史更改時，你必須能夠審定SRS。也就是說每個需求必須相對于其他需求有其單獨的標示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關的需求分組，建立目錄表，索引，以及前后參考(照)。

原文轉自：http://www.anti-gravitydesign.com