例1．“產品應在不少于每60秒的正常周期內提供狀態(tài)信息”

　　這個需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個需求有幾處含糊。我們在談論產品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應超過60秒，那么1毫秒是不是太短？“每”這個詞導致了不確定性。問題的后果，就是需求的不可證實。

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

　　1、狀態(tài)信息

　　2．后臺任務管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息

　　3．如果后臺進程處理正常，那么應該顯示任務已完成的百分數/比

　　4．任務完成時，應顯示相關的信息

　　后臺任務出錯應該顯示錯誤信息

　　為了分別測試和追蹤，我將其分成了多個需求。如果將幾個需求串接在一節(jié)中，在構造和測試時就很容易漏掉一個。

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

　　計算機在瞬間不能做任何事，所以這個需求不切實可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個的文檔，或其他的？這也是個模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可證實。

　　象這樣編寫需求也許更好一些：“用戶能夠在一個由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換”?，F(xiàn)在就很清楚，不可打印字符是HTML標記。由于沒有定義觸發(fā)條件，需求對設計沒有約束力。只有設計人員選定了觸發(fā)條件后，你才能編寫測試驗證觸發(fā)的正確操作。

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

　　試試這個：“HTML分析器可以產生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不會產生錯誤報告”?，F(xiàn)在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設計人員決定。我們還指定了一個例外：如果沒有發(fā)現(xiàn)錯誤，不產生錯誤報告。

　　例4．“如果可能，主管號碼應通過聯(lián)機校驗，而不是通過主全體主管號碼列表校驗”。真感到絕望，什么是“如果可能”：如果技術上可行？如果主全體主管號碼列表可以聯(lián)機獲得？要避免象“應該”的這類不確切的詞?？蛻羰切枰@個功能性還是不需要。我曾看過一些需求說明書，采用諸如：應，將，應該/將要等一些詞描述優(yōu)先級的細微差別。但我更喜歡用“應”清楚的說明需求的意圖，指明優(yōu)先級。這是修改后的：系統(tǒng)應校驗輸入的主管號碼而不通過聯(lián)機的主全體主官號碼列表。如果在列表中沒有發(fā)現(xiàn)主管號碼，將會顯示一條錯誤信息，也不接受指令。

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

    編寫質量需求的方針

　　編寫優(yōu)秀的需求是沒有公式化的方法的。這需要大量的經驗，要從你在過去的文檔中發(fā)現(xiàn)的問題學習。請在組織軟件需求文檔時，嚴格遵從這些方針。

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

　　要看需求是否被有效的定義，可以以開發(fā)人員的觀點看看。在內心將“當你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求，以便于設計和實現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細化。

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

　　密切關注多個需求合成了單個需求。一個需求中的連接詞“和”/“或”建議幾個需求合并。不要在一個需求中使用“和”/“或”。

　　通篇文檔細節(jié)上要保持一致。我曾看見過多個需求說明書前后不一致。如：“對于紅色合法的顏色代碼應是R”及“對于綠色合法的顏色代碼應是G”就有可以以分散的需求分離開，而“產品應能對來自語音編輯指示做出反應”應作為一個子系統(tǒng)，不應作為單個的功能性需求。

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

　　如果你遵從了這些方針，你能夠盡早地經常正式或非正式的審查需求，這些需求對于產品的構造，系統(tǒng)測試以及最后的客戶滿意，都會成為好的奠基石。并且要記住，沒有高質量的需求，軟件就象一盒巧克力，你永遠不知道你會得到什么。