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

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

　　你的工程應該有個好的起點。一個小組要帶領客戶進入需求啟發階段而且你要寫軟件需求說明書。這份說明有些大，但客戶會很重視，所以說明必須得到贊同。

　　現在你正在設計其中的一個特性，已經發現了需求的一些問題。你可以用多種不同的方式解釋需求15;需求9 的說明正好與需求21相反，你因該相信哪一個?需求24非常含糊，你根本不明白它的意思;你不得不花上一個小時與2位開發人員討論需求30，只因為你們對其各有各的理解;并且，唯一能夠澄清這些問題的客戶沒有給你們答復。你被迫破解眾多需求的含義，并且你能預料到，如果你錯了，你要做大量的重復工作。

　　許多軟件需求說明書(SRS)寫得非常糟糕。任何產品的質量需要其原始材料的質量保證，糟糕的軟件需求說明書不可能產出優秀的軟件。不幸的是，幾乎沒有開發人員受過與需求的抽象、分析、文檔、質檢有關的教育。而且，沒有非常多的好需求可以借鑒學習，部分原因是很少有工程可以找到一個好的借鑒，其他原因是公司不愿意將其產品說明書放在公共區域。

　　這篇文章描述了高質量需求敘述和說明的幾個特性(特點)。我們將用這些觀點檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會談一些如何編寫好的需求的提示。你也許想通過這些質量標準評估你的工程需求。對于修訂，也許遲了，但你會學到一些有用的東西，并幫助你的小組在下次編寫出更好的需求。

　　不要期望能夠編寫出一份能體現需求應具備的所有特性的SRS。無論你怎么細化、分析、評論和優化需求，都不可能達到完美。但是，如果你牢記這些特性，你就會編寫出更好的需求，生產出更好的產品。

　　高質量需求敘述的特性

　　我們如何從一些有問題的需求中分辨出好的軟件需求?這一節將分別介紹需求敘述應體現的6個特性，下一節將從整體上介紹SRS文檔應具備的特性。判斷每個需求是否具備應有的特性的一種方式是由持有不同觀點的工程資金管理人所作的正規檢查。另一種有力的方法是在編寫代碼前依據需求編寫測試例子。測試例子能夠明確顯現在需求中描述的產品行為(特性)，能夠顯現缺陷、冗余和含糊之處。

　　正確：每個需求必須精確描述要交付的功能。正確性依據于需求的來源，如真實的客戶或高級別的系統需求說明書。一個軟件需求與其對應的系統需求說明書相抵觸是不正確的(當然，系統需求說明書本身可能不正確)。

　　只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的代理的關鍵所在。不包括用戶的需求檢查就會導致開發人員的：“這是沒意義的”，“這可能是他們的意思”等眾所周知的猜測。

　　可行性：在已知的能力、有限的系統及其環境中每個需求必須是可實現的。為了避免需求的不可行性，在需求分析階段應該有一個開發人員參與，在抽象階段應該有市場人員參與。這個開發人員應能檢查在技術上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權衡。

　　必要性：每個需求應載明什么是客戶確實需要的，什么要順應于外部的需求，接口或標準。每個需求源于你認可、具有權說明需求的原始資料，這是考慮必需的另外情形(譯注，此句翻譯不順，請參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements)。跟蹤每個需求回溯到出處，如用例，系統需求，規章，或來自其他用戶的意見。如果你不能標識出處，可能需求只是個鍍金的例子，沒有真正的必須。

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