高質(zhì)量需求分析

1、如何編寫高質(zhì)量 “軟件需求說明書 ”你的工程應(yīng)該有個(gè)好的起點(diǎn)。一個(gè)小組要帶領(lǐng)客戶進(jìn)入需求啟發(fā)階段而且你要寫 軟件需求說明書。這份說明有些大，但客戶會很重視，所以說明必須得到贊同?，F(xiàn)在你正在設(shè)計(jì)其中的一個(gè)特性，已經(jīng)發(fā)現(xiàn)了需求的一些問題。你可以用多種 不同的方式解釋需求 15；需求 9 的說明正好與需求 21 相反，你因該相信哪一個(gè)？ 需求 24 非常含糊，你根本不明白它的意思； 你不得不花上一個(gè)小時(shí)與 2位開發(fā)人員 討論需求 30，只因?yàn)槟銈儗ζ涓饔懈鞯睦斫?；并且，唯一能夠澄清這些問題的客戶 沒有給你們答復(fù)。你被迫破解眾多需求的含義，并且你能預(yù)料到，如果你錯(cuò)了，你 要做大量的重復(fù)工作。許多軟件需

2、求說明書（SRS）寫得非常糟糕。任何產(chǎn)品的質(zhì)量需要其原始材料 的質(zhì)量保證，糟糕的軟件需求說明書不可能產(chǎn)出優(yōu)秀的軟件。不幸的是，幾乎沒有 開發(fā)人員受過與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的 教育。而且，沒有非常多的 好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個(gè)好的借鑒，其他原因是 公司不愿意將其產(chǎn)品說明書放在公共區(qū)域。這篇文章描述了高質(zhì)量需求敘述和說明的幾個(gè)特性（特點(diǎn)）。我們將用這些觀 點(diǎn)檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會談一些如何編寫好的需求 的提示。你也許想通過這些質(zhì)量 標(biāo)準(zhǔn)評估你的工程需求。對于修訂，也許遲了，但 你會學(xué)到一些有用的東西， 并幫助你的小組在下次編寫出更好

3、的需求。不要期望能夠編寫出一份能體現(xiàn)需求應(yīng)具備的所有特性的SRSo無論你怎么細(xì) 化、分析、評論和優(yōu)化需求，都不可能達(dá)到完美。但是，如果你牢記這些特性，你 就會編寫出更好的需求，生產(chǎn)出更好的產(chǎn)品。高質(zhì)量需求敘述的特性我們?nèi)绾螐囊恍┯袉栴}的需求中分辨出好的軟件需求？這一節(jié)將分別介紹需求 敘述應(yīng)體現(xiàn)的6個(gè)特性，下一節(jié)將從整體上介紹 SRS文檔應(yīng)具備的特性。判斷每個(gè) 需求是否具備應(yīng)有的特性的一種方式是由持有不同觀點(diǎn)的工程資金管理人所作的正 規(guī)檢查。另一種有力的方法是在編寫代碼前依據(jù)需求編寫測試?yán)?。測試?yán)幽軌?明確顯現(xiàn)在需求中描述的產(chǎn)品行為（特性），能夠顯現(xiàn)缺陷、冗余和含糊之處。正確：每個(gè)需求必須精

4、確描述要交付的功能。正確性依據(jù)于需求的來源，如真 實(shí)的客戶或高級別的系統(tǒng)需求說明書。一個(gè)軟件需求與其對應(yīng)的系統(tǒng)需求說明書相 抵觸是不正確的（當(dāng)然，系統(tǒng)需求說明書本身可能不正確）。只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要 包括他們或他們的代理的關(guān)鍵所在。不包括用戶的需求檢查就會導(dǎo)致開發(fā)人員的：這是沒意義的 ”， “這可能是他們的意思 ”等眾所周知的猜測。可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。為 了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開發(fā)人員參與，在抽象階段應(yīng) 該有市場人員參與。這個(gè)開發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需

5、要需要額外的付出或者和其他的權(quán)衡。必要性：每個(gè)需求應(yīng)載明什么是客戶確實(shí)需要的，什么要順應(yīng)于外部的需求， 接口或標(biāo)準(zhǔn)。每個(gè)需求源于你認(rèn)可、具有權(quán)說明需求的原始資料，這是考慮必需的necessary ” is另外情形（譯注，此句翻譯不順，請參照原文： Another way to think of that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來 自其他用戶的意見。如果你不能標(biāo)

6、識出處，可能需求只是個(gè)鍍金的例子，沒有真正 的必須。優(yōu)先權(quán)：為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)， 需要為每個(gè)需求， 特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)?？蛻艋蚱浯矶紤?yīng)有強(qiáng)烈的責(zé)任建立優(yōu)先權(quán)。如果所有的需求都被視為同等重要，那么由于在開發(fā)中，預(yù)算削減，計(jì)劃超時(shí)或組員 的離開導(dǎo)致新的需求時(shí)， 項(xiàng)目經(jīng)理 將不能起到作用。 優(yōu)先權(quán)的作用是提供給客戶的 價(jià)值，實(shí)現(xiàn)的相關(guān)費(fèi)用，實(shí)現(xiàn)相關(guān)聯(lián)的有關(guān)技術(shù) 風(fēng)險(xiǎn)。我是用 3 種級別的優(yōu)先權(quán)：高優(yōu)先權(quán)表明需求必須體現(xiàn)在下一個(gè)產(chǎn)品版本中， 中優(yōu)先權(quán)表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu) 先權(quán)表明有它很好，但我們必須認(rèn)識到如果沒有充足的時(shí)

7、間或 資源 ，它可以被放棄 掉。明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識。自然語言極易導(dǎo)致含糊。要避免使用一些對于SRS 作者很清 楚但對于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾 個(gè)，藝術(shù)級，改善的，最大，最小等等。每寫一個(gè)需要都應(yīng)簡潔，簡單，直觀的采 用用戶熟知的語言，不要采用計(jì)算機(jī)術(shù)語。檢查需求模糊的有效方式包括需求說明 書的正規(guī)檢查，根據(jù)需求寫測試，建立用戶的假想來說明產(chǎn)品某個(gè)特定部分預(yù)期的 特性。可證實(shí)：看你是否能夠做出測試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來決定 在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。如果需求是不可驗(yàn)證

8、的，決定需求是不是正確 的實(shí)現(xiàn)就成了判斷的事。需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。任 何需求如果說產(chǎn)品將要支持什么也是不可證實(shí)的。高質(zhì)量需求說明的特征一個(gè)完整的 SRS 不僅是包括長長的功能性需求列表， 還包括外部接口描述和一 些諸如質(zhì)量屬性， 期望性能的非功能性需求。 下面描述了高質(zhì)量的 SRS 的一些特性。完整：不應(yīng)該遺漏要求和必需的信息。完整性也是一個(gè)需求應(yīng)具備的。發(fā)現(xiàn)缺 少的信息很難，因?yàn)楦静淮嬖?。?SRS 中將需求以分層目錄方式組織，將幫助評 審人員理解功能性描述的結(jié)構(gòu)， 使他們很容易指出遺失的東西。在需求抽象時(shí)，相對于系統(tǒng)功能，你過多的注意用戶的業(yè)務(wù)，將導(dǎo)致在需求的

9、 全局觀和引進(jìn)不是真正必需的需求上顯得不足。在需求抽象上，應(yīng)用用例方法會發(fā) 揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。如果你知道已缺少一些信息，使用TBD （to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出 這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有 的缺陷。一致性：一致性需求就是不要于其他的軟件需求或高級別的系統(tǒng)（商業(yè)）需求發(fā) 生沖突。需求中的不一致必須在開發(fā)開始前得到解決。只有經(jīng)過調(diào)研才能確定哪些 是正確的。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒有審定于修改相關(guān) 的部分，就可能導(dǎo)致不一致性?？尚薷男裕寒?dāng)每個(gè)需求的要求修改

10、了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。也就是說每個(gè)需求必須相對于其他需求有其單獨(dú)的標(biāo)示和分開的說明，便于 清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立 目錄表，索引，以及前后參考（照）?？勺粉櫍耗銘?yīng)能將一個(gè)軟件與其原始材料相對應(yīng)，如高級系統(tǒng)需求，用例，用 戶的提議等。也能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的 測試相對應(yīng)?？勺粉櫟男枨髴?yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫，不應(yīng)過大， 不應(yīng)是敘述性的文字和公告式的列表。需求質(zhì)量的評審這些有關(guān)需求質(zhì)量的特性的描述在理論上都是非常好的，但一個(gè)好的需求到底 是個(gè)什么樣子的呢？為了體現(xiàn)得更切合實(shí)際，我們

11、做個(gè)小練習(xí)。下面有幾個(gè)從實(shí)際 的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評估每個(gè)需求，看看有什么問題，然后 用更好的方式重寫。我將對每個(gè)例子都提出自己的分析和改進(jìn)的建議。也歡迎你提 出不同的見解。我所占優(yōu)的只是我知道每個(gè)需求的出處。因?yàn)槟阄叶疾皇钦嬲目?戶，我們只能猜測每個(gè)需求的意圖。例 1“產(chǎn)品應(yīng)在不少于每 60 秒的正常周期內(nèi)提供狀態(tài)信息 ”這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個(gè)需求有幾處含糊。我們在談?wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60 秒？，甚者每10 年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超過60秒，那 么 1 毫秒是不是太短？ “每”這

12、個(gè)詞導(dǎo)致了不確定性。問題的后果，就是需求的不可 證實(shí)。彌補(bǔ)缺陷，重寫需求的一種方法：1、狀態(tài)信息11后臺任務(wù)管理器因該以誤差上下不超過10秒的 60秒間隔，在用戶界面的 指定位置顯示狀態(tài)信息12 如果后臺進(jìn)程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù)/比13 任務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息14 后臺任務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息為了分別測試和追蹤，我將其分成了多個(gè)需求。如果將幾個(gè)需求串接在一節(jié)中， 在構(gòu)造和測試時(shí)就很容易漏掉一個(gè)。例 2“產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換”計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性表現(xiàn)在 沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？

13、或者用戶為了模仿 更改要做一些動作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個(gè)的 文檔，或其他的？這也是個(gè)模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是 一些屬性標(biāo)志或一些控制字符？問題的后果， 就是需求的不可證實(shí)。象這樣編寫需求也許更好一些： “用戶能夠在一個(gè)由特定觸發(fā)條件激活處于編輯 的文檔中在顯示和隱藏所有 HTML 標(biāo)記間切換 ”?，F(xiàn)在就很清楚，不可打印字符是HTML 標(biāo)記。由于沒有定義觸發(fā)條件，需求對設(shè)計(jì)沒有約束力。只有設(shè)計(jì)人員選定 了觸發(fā)條件后，你才能編寫測試驗(yàn)證觸發(fā)的正確操作。例3. “HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門者快速 解決錯(cuò)誤 ”。

14、單詞“快速”使其模糊，沒 有加進(jìn)錯(cuò)誤報(bào)告的定義也是其部完整。我 不知道，你怎么驗(yàn)證這個(gè)需求。找一個(gè)自稱為 HTML 的入門者，看看能不能根據(jù)錯(cuò) 誤報(bào)告快速解決錯(cuò)誤？試試這個(gè)：“ HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告， 錯(cuò)誤報(bào)告包含有在被分析文 件中出錯(cuò)的 HTML 文本和行號以及錯(cuò)誤的描述。如果沒有錯(cuò)誤，就不會產(chǎn)生錯(cuò)誤報(bào) 告”?，F(xiàn)在我們知道了，什么會被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則 留由設(shè)計(jì)人員決定。 我們還指定了一個(gè)例外： 如果沒有發(fā)現(xiàn)錯(cuò)誤， 不產(chǎn)生錯(cuò)誤報(bào)告。例 4. “如果可能，主管號碼應(yīng)通過聯(lián)機(jī)校驗(yàn)，而不是通過主全體主管號碼列表 校驗(yàn)”。真感到絕望，什么是 “如果可能 ”：如

15、果技術(shù)上可行？如果主全體主管號碼列 表可以聯(lián)機(jī)獲得？要避免象 “應(yīng)該”的這類不確切的詞?？蛻羰切枰@個(gè)功能性還是不需要。我曾看過一些需求說明書，采用諸如：應(yīng)，將，應(yīng)該/將要等一些詞描述優(yōu) 先級的細(xì)微差別。但我更喜歡用 “應(yīng)”清楚的說明需求的意圖，指明優(yōu)先級。這是修 改后的：系統(tǒng)應(yīng)校驗(yàn)輸入的主管號碼而不通過聯(lián)機(jī)的主全體主官號碼列表。如果在 列表中沒有發(fā)現(xiàn)主管號碼， 將會顯示一條錯(cuò)誤信息， 也不接受指令。在理解各個(gè)已完成的糟糕需求上，開發(fā)人員將會遇到的難題是：開發(fā)人員與客 戶將會在審核需求，未達(dá)成共識前發(fā)生激烈的爭論。詳細(xì)檢查大的需求文檔不是一件輕松的事情。我清楚有人做過，而且他們花在檢查上的每一

16、分鐘都是值得的。相 對于開發(fā)階段和用戶的抱怨電話， 在這個(gè)階段修補(bǔ)缺陷是便宜的，編寫質(zhì)量需求的方針編寫優(yōu)秀的需求是沒有公式化的方法的。這需要大量的經(jīng)驗(yàn)，要從你在過去的 文檔中發(fā)現(xiàn)的問題學(xué)習(xí)。 請?jiān)诮M織軟件需求文檔時(shí)， 嚴(yán)格遵從這些方針。句子和段落要短。采用主動語氣。使用正確的語法，拼寫，標(biāo)點(diǎn)。使用術(shù)語， 要保持一致性，并在術(shù)語表或數(shù)據(jù)字典中定義它們要看需求是否被有效的定義， 可以以開發(fā)人員的觀點(diǎn)看看。 在內(nèi)心將 “當(dāng)你們做 完了找我 ”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果 是的話，在繼續(xù)工作前，需求還需要細(xì)化。需求編寫者還要努力正確地把握細(xì)化程度。要避免包含多個(gè)需求的長的敘述段 落。有幫助的提示是編寫?yīng)毩⒌目蓽y試的需求。如果你認(rèn)為一小部分測試可以驗(yàn)證 一個(gè)需求的正確，那么它已經(jīng)正確的細(xì)化了。如果你預(yù)想到多種不同類的測試，幾 個(gè)需求可能已擠到了一起，需要拆分開。密切關(guān)注多個(gè)需求合成了單個(gè)需求。一個(gè)需求中的連接詞“和”/或”建議幾個(gè)需 求合并。不要在一個(gè)需求中使用 “和”/或”。通篇文檔細(xì)節(jié)上要保持一致。我曾看見過多個(gè)需求說明書前后不一致。如： 于紅色合法的顏色代碼