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

如何編寫高質量「軟件需求說明書 」 日期：2006年2月20日 做者： 人氣：2194 查看:[大字體 中字體 小字體] 你的工程應該有個好的起點。一個小組要帶領客戶進入需求啓發階段並且你要寫軟件需求說明書。這份說明有些大，但客戶會很重視，因此說明必須獲得贊同。 　　如今你正在設計其中的一個特性，已經發現了需求的一些問題。你能夠用多種不一樣的方式解釋需求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）。跟蹤每一個需求回溯到出處，如用例，系統需求，規章，或來自其餘用戶的意見。若是你不能標識出處，可能需求只是個鍍金的例子，沒有真正的必須。

　　優先權：爲了代表在一個詳細的產品版本中應包含哪些要點，須要爲每一個需求，特徵，或用例分配實現的優先權。客戶或其代理都應有強烈的責任創建優先權。若是全部的需求都被視爲同等重要，那麼因爲在開發中，預算削減，計劃超時或組員的離開致使新的需求時， 項目經理將不能起到做用。優先權的做用是提供給客戶的價值，實現的相關費用，實現相關聯的有關技術風險。

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

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

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

高質量需求說明的特徵

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

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

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

　　若是你知道已缺乏一些信息，使用TBD（to be determined）標準標誌能夠突出這些缺陷，當你在構建產品的相關部分時，就能夠從一個給定的需求集中解決全部的缺陷。

　　一致性：一致性需求就是不要於其餘的軟件需求或高級別的系統（商業）需求發生衝突。需求中的不一致必須在開發開始前獲得解決。只有通過調研才能肯定哪些是正確的。修改需求時必定要謹慎，若是隻審定修改的部分，沒有審定於修改相關的部分，就可能致使不一致性。

　　可修改性：當每一個需求的要求修改了或維護其歷史更改時，你必須可以審定SRS。也就是說每一個需求必須相對於其餘需求有其單獨的標示和分開的說明，便於清晰的查閱。經過良好的組織可使需求易於修改，如：將相關的需求分組，創建目錄表，索引，以及先後參考（照）。

　　可追蹤：你應能將一個軟件與其原始材料相對應，如高級系統需求，用例，用戶的提議等。也可以將軟件需求與設計元素，源代碼，用於構造實現和驗證需求的測試相對應。可追蹤的需求應該具備獨立標示，細密和結構化的編寫，不該過大，不該是敘述性的文字和公告式的列表。

　　需求質量的評審

　　這些有關需求質量的特性的描述在理論上都是很是好的，但一個好的需求究竟是個什麼樣子的呢？爲了體現得更切合實際，咱們作個小練習。下面有幾個從實際的工程選出的需求，依據上面的質量標準，評估每一個需求，看看有什麼問題，而後用更好的方式重寫。我將對每一個例子都提出本身的分析和改進的建議。也歡迎你提出不一樣的看法。我所佔優的只是我知道每一個需求的出處。由於你我都不是真正的客戶，咱們只能猜想每一個需求的意圖。

　　例1．「產品應在很多於每60秒的正常週期內提供狀態信息」

　　這個需求是不完整的：狀態信息是什麼，如何顯示給用戶。這個需求有幾處含糊。咱們在談論產品的哪部分？狀態信息間隔真的假定爲很多於60秒？，甚者每10年顯示一條新的狀態信息也能夠？也許它的意圖是消息間隔不該超過60秒，那麼1毫秒是否是過短？「每」這個詞致使了不肯定性。問題的後果，就是需求的不可證明。

　　彌補缺陷，重寫需求的一種方法：

　　一、狀態信息 　　1．1後臺任務管理器因該以偏差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態信息 　　1．2若是後臺進程處理正常，那麼應該顯示任務已完成的百分數/比 　　1．3任務完成時，應顯示相關的信息 　　1．4後臺任務出錯應該顯示錯誤信息

　　爲了分別測試和追蹤，我將其分紅了多個需求。若是將幾個需求串接在一節中，在構造和測試時就很容易漏掉一個。

　　例2．「產品應瞬間在顯示和隱藏不可打印字符間切換」

　　計算機在瞬間不能作任何事，因此這個需求不切實可行。它的不完整性表如今沒有聲明觸發狀態切換的條件。軟件要在某些條件下更改本身？或者用戶爲了模仿更改要作一些動做？並且，在文檔中改變顯示的範圍是多大：選中的文本，整個的文檔，或其餘的？這也是個模糊的問題。不可打印字符合隱藏字符同樣嗎？或者是一些屬性標誌或一些控制字符？問題的後果，就是需求的不可證明。

　　象這樣編寫需求也許更好一些：「用戶可以在一個由特定觸發條件激活處於編輯的文檔中在顯示和隱藏全部HTML標記間切換」。如今就很清楚，不可打印字符是HTML標記。因爲沒有定義觸發條件，需求對設計沒有約束力。只有設計人員選定了觸發條件後，你才能編寫測試驗證觸發的正確操做。

　　例3．「HTML分析器能夠產生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤」。單詞「快速」使其模糊，沒　　有加進錯誤報告的定義也是其部完整。我不知道，你怎麼驗證這個需求。找一個自稱爲HTML的入門者，看看能不能根據錯誤報告快速解決錯誤？

　　試試這個：「HTML分析器能夠產生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。若是沒有錯誤，就不會產生錯誤報告」。如今咱們知道了，什麼會被加到出錯報告中，可是出錯報告是個什麼樣子，則留由設計人員決定。咱們還指定了一個例外：若是沒有發現錯誤，不產生錯誤報告。

　　例4．「若是可能，主管號碼應經過聯機校驗，而不是經過主全體主管號碼列表校驗」。真感到絕望，什麼是「若是可能」：若是技術上可行？若是主全體主管號碼列表能夠聯機得到？要避免象「應該」的這類不確切的詞。客戶是須要這個功能性仍是不須要。我曾看過一些需求說明書，採用諸如：應，將，應該/將要等一些詞描述優先級的細微差異。但我更喜歡用「應」清楚的說明需求的意圖，指明優先級。這是修改後的：系統應校驗輸入的主管號碼而不經過聯機的主全體主官號碼列表。若是在列表中沒有發現主管號碼，將會顯示一條錯誤信息，也不接受指令。

　　在理解各個已完成的糟糕需求上，開發人員將會遇到的難題是：開發人員與客戶將會在審覈需求，未達成共識前發生激烈的爭論。詳細檢查大的需求文檔不是一件輕鬆的事情。我清楚有人作過，並且他們花在檢查上的每一分鐘都是值得的。相對於開發階段和用戶的抱怨電話，在這個階段修補缺陷是便宜的，

　　編寫質量需求的方針

　　編寫優秀的需求是沒有公式化的方法的。這須要大量的經驗，要從你在過去的文檔中發現的問題學習。請在組織軟件需求文檔時，嚴格聽從這些方針。

　　句子和段落要短。採用主動語氣。使用正確的語法，拼寫，標點。使用術語，要保持一致性，並在術語表或數據字典中定義它們

　　要看需求是否被有效的定義，能夠以開發人員的觀點看看。在心裏將「當大家作完了找我」這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你是否須要SRS的編寫者的額外解釋幫助開發人員很好的理解需求，以便於設計和實現？若是是的話，在繼續工做前，需求還須要細化。

　　需求編寫者還要努力正確地把握細化程度。要避免包含多個需求的長的敘述段落。有幫助的提示是編寫獨立的可測試的需求。若是你認爲一小部分測試能夠驗證一個需求的正確，那麼它已經正確的細化了。若是你預想到多種不一樣類的測試，幾個需求可能已擠到了一塊兒，須要拆分開。

　　密切關注多個需求合成了單個需求。一個需求中的鏈接詞「和」/「或」建議幾個需求合併。不要在一個需求中使用「和」/「或」。

　　通篇文檔細節上要保持一致。我曾看見過多個需求說明書先後不一致。如：「對於紅色合法的顏色代碼應是R」及「對於綠色合法的顏色代碼應是G」就有能夠以分散的需求分離開，而「產品應能對來自語音編輯指示作出反應」應做爲一個子系統，不該做爲單個的功能性需求。

　　避免在SRS中過多的申述需求。在多處包含相同的需求可使文檔更易於閱讀，但也會給文檔的維護增長困難。文檔的多份文本要在同一時間內所有更新，避免不一致性。

　　若是你聽從了這些方針，你可以儘早地常常正式或非正式的審查需求，這些需求對於產品的構造，系統測試以及最後的客戶滿意，都會成爲好的奠定石。而且要記住，沒有高質量的需求，軟件就象一盒巧克力，你永遠不知道你會獲得什麼

（出處：DelphiFans.com）