怎樣編寫高質量“軟件需求說明書”

怎樣編寫高質量

“軟件需求說明

書”

如何編寫高質量”軟件需求說明書”

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

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

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

這篇文章描述了高質量需求敘述和說明的幾個特性(特點)。我們將用這些觀點檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會談一些如何編寫好的需求的提示。你可能想經(jīng)過這些質量

標準評估你的工程需求。對于修訂，可能遲了，但你會學到一些有用的東西，并幫助你的小組在下次編寫出更好的需求。

不要期望能夠編寫出一份能體現(xiàn)需求應具備的所有特性的SRS。無論你怎么細化、分析、評論和優(yōu)化需求，都不可能達到完美?？墒牵绻憷斡涍@些特性,你就會編寫出更好的需求,生產出更好的產品。

高質量需求敘述的特性

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

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

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

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

必要性:每個需求應載明什么是客戶確實需要的，什么要順應于外部的需求，接口或標準。每個需求源于你認可、具有權說明需求的原始資料，這是考慮必須的另外情形(譯注，此句翻譯不順，請參照原文：Anotherwaytothinkof"necessary"isthateachrequirementoriginatedfromasourceyourecognizeashavingtheauthoritytospecifyrequirements)。跟蹤每個需求回溯到出處,如用例，系統(tǒng)需求,規(guī)章,或來自其它用戶的意見。如果你不能標識出處,可能需求只是個鍍金的例子，沒有真正的必須。

優(yōu)先權:為了表明在一個詳細的產品版本中應包含哪些要點，需要為每個需求，特征，或用例分配實現(xiàn)的優(yōu)先權。客戶或其代理都應有強烈的責任建立優(yōu)先權。如果所有的需求都被視為同等重要，那么由于在開發(fā)中，預算削減，計劃超時或組員的離開導致新的需求時，項目經(jīng)理將不能起到作用。優(yōu)先權的作用是提供給客戶的價值，實現(xiàn)的相關費用，實現(xiàn)相關聯(lián)的有關技術風險。

我是用3種級別的優(yōu)先權:高優(yōu)先權表明需求必須體現(xiàn)在下一個產品版本中，中優(yōu)先權表明需求是必須的,可是如果需要能夠推遲到晚一些的產品版本中，低優(yōu)先權表明有它很好,但我們必須認識到如果沒有充分的時間或資源，它能夠被放棄掉。

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

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

高質量需求說明的特征

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

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

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

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

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

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

可追蹤:你應能將一個軟件與其原始材料相對應，如高級系統(tǒng)需求,用例,用戶的提議等。也能夠將軟件需求與設計元素，源代碼,用于構造實現(xiàn)和驗證需求的測試相對應?？勺粉櫟男枨髴摼哂歇毩耸?細密和結構化的編寫，不應過大，不應是敘述性的文字和公告式的列表。

需求質量的評審

這些有關需求質量的特性的描述在理論上都是非常好的，但一個好的需求到底是個什么樣子的呢?為了體現(xiàn)得更切合實際，我們做個小練習。下面有幾個從實