你的工程應該有個(gè)好的起點(diǎn)。一個(gè)小組要帶領(lǐng)客戶(hù)進(jìn)入需求啟發(fā)階段而且你要寫(xiě)軟件需求說(shuō)明書(shū)。這份說(shuō)明有些大，但客戶(hù)會(huì )很重視，所以說(shuō)明必須得到贊同。
現在你正在設計其中的一個(gè)特性，已經(jīng)發(fā)現了需求的一些問(wèn)題。你可以用多種不同的方式解釋需求15；需求9 的說(shuō)明正好與需求21相反，你因該相信哪一個(gè)？需求24非常含糊，你根本不明白它的意思；你不得不花上一個(gè)小時(shí)與2位開(kāi)發(fā)人員討論需求30，只因為你們對其各有各的理解；并且，唯一能夠澄清這些問(wèn)題的客戶(hù)沒(méi)有給你們答復。你被迫破解眾多需求的含義，并且你能預料到，如果你錯了，你要做大量的重復工作。
許多軟件需求說(shuō)明書(shū)（SRS）寫(xiě)得非常糟糕。任何產(chǎn)品的質(zhì)量需要其原始材料的質(zhì)量保證，糟糕的軟件需求說(shuō)明書(shū)不可能產(chǎn)出優(yōu)秀的軟件。不幸的是，幾乎沒(méi)有開(kāi)發(fā)人員受過(guò)與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的教育。而且，沒(méi)有非常多的好需求可以借鑒學(xué)習，部分原因是很少有工程可以找到一個(gè)好的借鑒，其他原因是公司不愿意將其產(chǎn)品說(shuō)明書(shū)放在公共區域。
這篇文章描述了高質(zhì)量需求敘述和說(shuō)明的幾個(gè)特性（特點(diǎn)）。我們將用這些觀(guān)點(diǎn)檢查一些有缺陷的需求，帶著(zhù)痛楚重新編寫(xiě)。而且我會(huì )談一些如何編寫(xiě)好的需求的提示。你也許想通過(guò)這些質(zhì)量標準評估你的工程需求。對于修訂，也許遲了，但你會(huì )學(xué)到一些有用的東西，并幫助你的小組在下次編寫(xiě)出更好的需求。
不要期望能夠編寫(xiě)出一份能體現需求應具備的所有特性的SRS。無(wú)論你怎么細化、分析、評論和優(yōu)化需求，都不可能達到完美。但是，如果你牢記這些特性，你就會(huì )編寫(xiě)出更好的需求，生產(chǎn)出更好的產(chǎn)品。
高質(zhì)量需求敘述的特性
我們如何從一些有問(wèn)題的需求中分辨出好的軟件需求？這一節將分別介紹需求敘述應體現的6個(gè)特性，下一節將從整體上介紹SRS文檔應具備的特性。判斷每個(gè)需求是否具備應有的特性的一種方式是由持有不同觀(guān)點(diǎn)的工程資金管理人所作的正規檢查。另一種有力的方法是在編寫(xiě)代碼前依據需求編寫(xiě)測試例子。測試例子能夠明確顯現在需求中描述的產(chǎn)品行為（特性），能夠顯現缺陷、冗余和含糊之處。
正確：每個(gè)需求必須精確描述要交付的功能。正確性依據于需求的來(lái)源，如真實(shí)的客戶(hù)或高級別的系統需求說(shuō)明書(shū)。一個(gè)軟件需求與其對應的系統需求說(shuō)明書(shū)相抵觸是不正確的（當然，系統需求說(shuō)明書(shū)本身可能不正確）。
只有用戶(hù)的代表能夠決定用戶(hù)需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶(hù)的需求檢查就會(huì )導致開(kāi)發(fā)人員的：“這是沒(méi)意義的”，“這可能是他們的意思”等眾所周知的猜測。
可行性：在已知的能力、有限的系統及其環(huán)境中每個(gè)需求必須是可實(shí)現的。為了避免需求的不可行性，在需求分析階段應該有一個(gè)開(kāi)發(fā)人員參與，在抽象階段應該有市場(chǎng)人員參與。這個(gè)開(kāi)發(fā)人員應能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權衡。
必要性：每個(gè)需求應載明什么是客戶(hù)確實(shí)需要的，什么要順應于外部的需求，接口或標準。每個(gè)需求源于你認可、具有權說(shuō)明需求的原始資料，這是考慮必需的另外情形（譯注，此句翻譯不順，請參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個(gè)需求回溯到出處，如用例，系統需求，規章，或來(lái)自其他用戶(hù)的意見(jiàn)。如果你不能標識出處，可能需求只是個(gè)鍍金的例子，沒(méi)有真正的必須。
優(yōu)先權：為了表明在一個(gè)詳細的產(chǎn)品版本中應包含哪些要點(diǎn)，需要為每個(gè)需求，特征，或用例分配實(shí)現的優(yōu)先權?？蛻?hù)或其代理都應有強烈的責任建立優(yōu)先權。如果所有的需求都被視為同等重要，那么由于在開(kāi)發(fā)中，預算削減，計劃超時(shí)或組員的離開(kāi)導致新的需求時(shí)， 項目經(jīng)理將不能起到作用。優(yōu)先權的作用是提供給客戶(hù)的價(jià)值，實(shí)現的相關(guān)費用，實(shí)現相關(guān)聯(lián)的有關(guān)技術(shù)風(fēng)險。
我是用3種級別的優(yōu)先權：高優(yōu)先權表明需求必須體現在下一個(gè)產(chǎn)品版本中，中優(yōu)先權表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu)先權表明有它很好，但我們必須認識到如果沒(méi)有充足的時(shí)間或資源，它可以被放棄掉。
明確：需求敘述的讀者應只能從其得到唯一的解釋說(shuō)明，同樣，一個(gè)需求的多個(gè)讀者也應達成共識。自然語(yǔ)言極易導致含糊。要避免使用一些對于SRS作者很清楚但對于讀者不清楚的主觀(guān)詞匯，如：用戶(hù)友好性，容易，簡(jiǎn)單，快速，有效，幾個(gè)，藝術(shù)級，改善的，最大，最小等等。每寫(xiě)一個(gè)需要都應簡(jiǎn)潔，簡(jiǎn)單，直觀(guān)的采用用戶(hù)熟知的語(yǔ)言，不要采用計算機術(shù)語(yǔ)。檢查需求模糊的有效方式包括需求說(shuō)明書(shū)的正規檢查，根據需求寫(xiě)測試，建立用戶(hù)的假想來(lái)說(shuō)明產(chǎn)品某個(gè)特定部分預期的特性。
可證實(shí)：看你是否能夠做出測試計劃或其他驗證方式，如檢查和實(shí)證，來(lái)決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現。如果需求是不可驗證的，決定需求是不是正確的實(shí)現就成了判斷的事。需求之間不一致，不可行，不明確也能導致不可證實(shí)。任何需求如果說(shuō)產(chǎn)品將要支持什么也是不可證實(shí)的。
高質(zhì)量需求說(shuō)明的特征
一個(gè)完整的SRS不僅是包括長(cháng)長(cháng)的功能性需求列表，還包括外部接口描述和一些諸如質(zhì)量屬性，期望性能的非功能性需求。下面描述了高質(zhì)量的SRS的一些特性。
完整：不應該遺漏要求和必需的信息。完整性也是一個(gè)需求應具備的。發(fā)現缺少的信息很難，因為根本不存在。在SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西。
在需求抽象時(shí)，相對于系統功能，你過(guò)多的注意用戶(hù)的業(yè)務(wù)，將導致在需求的全局觀(guān)和引進(jìn)不是真正必需的需求上顯得不足。在需求抽象上，應用用例方法會(huì )發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。
如果你知道已缺少一些信息，使用TBD（to be determined）標準標志可以突出這些缺陷，當你在構建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。
一致性：一致性需求就是不要于其他的軟件需求或高級別的系統（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開(kāi)發(fā)開(kāi)始前得到解決。只有經(jīng)過(guò)調研才能確定哪些是正確的。修改需求時(shí)一定要謹慎，如果只審定修改的部分，沒(méi)有審定于修改相關(guān)的部分，就可能導致不一致性。
可修改性：當每個(gè)需求的要求修改了或維護其歷史更改時(shí)，你必須能夠審定SRS。也就是說(shuō)每個(gè)需求必須相對于其他需求有其單獨的標示和分開(kāi)的說(shuō)明，便于清晰的查閱。通過(guò)良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立目錄表，索引，以及前后參考（照）。
可追蹤：你應能將一個(gè)軟件與其原始材料相對應，如高級系統需求，用例，用戶(hù)的提議等。也能夠將軟件需求與設計元素，源代碼，用于構造實(shí)現和驗證需求的測試相對應?？勺粉櫟男枨髴摼哂歇毩耸?，細密和結構化的編寫(xiě)，不應過(guò)大，不應是敘述性的文字和公告式的列表。 需求質(zhì)量的評審
這些有關(guān)需求質(zhì)量的特性的描述在理論上都是非常好的，但一個(gè)好的需求到底是個(gè)什么樣子的呢？為了體現得更切合實(shí)際，我們做個(gè)小練習。下面有幾個(gè)從實(shí)際的工程選出的需求，依據上面的質(zhì)量標準，評估每個(gè)需求，看看有什么問(wèn)題，然后用更好的方式重寫(xiě)。我將對每個(gè)例子都提出自己的分析和改進(jìn)的建議。也歡迎你提出不同的見(jiàn)解。我所占優(yōu)的只是我知道每個(gè)需求的出處。因為你我都不是真正的客戶(hù)，我們只能猜測每個(gè)需求的意圖。
例1．“產(chǎn)品應在不少于每60秒的正常周期內提供狀態(tài)信息”
這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶(hù)。這個(gè)需求有幾處含糊。我們在談?wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應超過(guò)60秒，那么1毫秒是不是太短？“每”這個(gè)詞導致了不確定性。問(wèn)題的后果，就是需求的不可證實(shí)。
彌補缺陷，重寫(xiě)需求的一種方法：
1、狀態(tài)信息
1．1后臺任務(wù)管理器因該以誤差上下不超過(guò)10秒的60秒間隔，在用戶(hù)界面的指定位置顯示狀態(tài)信息
1．2如果后臺進(jìn)程處理正常，那么應該顯示任務(wù)已完成的百分數/比
1．3任務(wù)完成時(shí)，應顯示相關(guān)的信息
1．4后臺任務(wù)出錯應該顯示錯誤信息
為了分別測試和追蹤，我將其分成了多個(gè)需求。如果將幾個(gè)需求串接在一節中，在構造和測試時(shí)就很容易漏掉一個(gè)。
例2．“產(chǎn)品應瞬間在顯示和隱藏不可打印字符間切換”
計算機在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性表現在沒(méi)有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶(hù)為了模仿更改要做一些動(dòng)作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個(gè)的文檔，或其他的？這也是個(gè)模糊的問(wèn)題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問(wèn)題的后果，就是需求的不可證實(shí)。
象這樣編寫(xiě)需求也許更好一些：“用戶(hù)能夠在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換”?，F在就很清楚，不可打印字符是HTML標記。由于沒(méi)有定義觸發(fā)條件，需求對設計沒(méi)有約束力。只有設計人員選定了觸發(fā)條件后，你才能編寫(xiě)測試驗證觸發(fā)的正確操作。
例3．“HTML分析器可以產(chǎn)生HTML標記錯誤報告，幫助HTML入門(mén)者快速解決錯誤”。單詞“快速”使其模糊，沒(méi) 有加進(jìn)錯誤報告的定義也是其部完整。我不知道，你怎么驗證這個(gè)需求。找一個(gè)自稱(chēng)為HTML的入門(mén)者，看看能不能根據錯誤報告快速解決錯誤？
試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒(méi)有錯誤，就不會(huì )產(chǎn)生錯誤報告”?，F在我們知道了，什么會(huì )被加到出錯報告中，但是出錯報告是個(gè)什么樣子，則留由設計人員決定。我們還指定了一個(gè)例外：如果沒(méi)有發(fā)現錯誤，不產(chǎn)生錯誤報告。
例4．“如果可能，主管號碼應通過(guò)聯(lián)機校驗，而不是通過(guò)主全體主管號碼列表校驗”。真感到絕望，什么是“如果可能”：如果技術(shù)上可行？如果主全體主管號碼列表可以聯(lián)機獲得？要避免象“應該”的這類(lèi)不確切的詞?？蛻?hù)是需要這個(gè)功能性還是不需要。我曾看過(guò)一些需求說(shuō)明書(shū)，采用諸如：應，將，應該/將要等一些詞描述優(yōu)先級的細微差別。但我更喜歡用“應”清楚的說(shuō)明需求的意圖，指明優(yōu)先級。這是修改后的：系統應校驗輸入的主管號碼而不通過(guò)聯(lián)機的主全體主官號碼列表。如果在列表中沒(méi)有發(fā)現主管號碼，將會(huì )顯示一條錯誤信息，也不接受指令。
在理解各個(gè)已完成的糟糕需求上，開(kāi)發(fā)人員將會(huì )遇到的難題是：開(kāi)發(fā)人員與客戶(hù)將會(huì )在審核需求，未達成共識前發(fā)生激烈的爭論。詳細檢查大的需求文檔不是一件輕松的事情。我清楚有人做過(guò)，而且他們花在檢查上的每一分鐘都是值得的。相對于開(kāi)發(fā)階段和用戶(hù)的抱怨電話(huà)，在這個(gè)階段修補缺陷是便宜的，
編寫(xiě)質(zhì)量需求的方針
編寫(xiě)優(yōu)秀的需求是沒(méi)有公式化的方法的。這需要大量的經(jīng)驗，要從你在過(guò)去的文檔中發(fā)現的問(wèn)題學(xué)習。請在組織軟件需求文檔時(shí)，嚴格遵從這些方針。
句子和段落要短。采用主動(dòng)語(yǔ)氣。使用正確的語(yǔ)法，拼寫(xiě)，標點(diǎn)。使用術(shù)語(yǔ)，要保持一致性，并在術(shù)語(yǔ)表或數據字典中定義它們
要看需求是否被有效的定義，可以以開(kāi)發(fā)人員的觀(guān)點(diǎn)看看。在內心將“當你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來(lái)。換句話(huà)說(shuō)，你是否需要SRS的編寫(xiě)者的額外解釋幫助開(kāi)發(fā)人員很好的理解需求，以便于設計和實(shí)現？如果是的話(huà)，在繼續工作前，需求還需要細化。
需求編寫(xiě)者還要努力正確地把握細化程度。要避免包含多個(gè)需求的長(cháng)的敘述段落。有幫助的提示是編寫(xiě)獨立的可測試的需求。如果你認為一小部分測試可以驗證一個(gè)需求的正確，那么它已經(jīng)正確的細化了。如果你預想到多種不同類(lèi)的測試，幾個(gè)需求可能已擠到了一起，需要拆分開(kāi)。
密切關(guān)注多個(gè)需求合成了單個(gè)需求。一個(gè)需求中的連接詞“和”/“或”建議幾個(gè)需求合并。不要在一個(gè)需求中使用“和”/“或”。
通篇文檔細節上要保持一致。我曾看見(jiàn)過(guò)多個(gè)需求說(shuō)明書(shū)前后不一致。如：“對于紅色合法的顏色代碼應是R”及“對于綠色合法的顏色代碼應是G”就有可以以分散的需求分離開(kāi)，而“產(chǎn)品應能對來(lái)自語(yǔ)音編輯指示做出反應”應作為一個(gè)子系統，不應作為單個(gè)的功能性需求。
避免在SRS中過(guò)多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會(huì )給文檔的維護增加困難。文檔的多份文本要在同一時(shí)間內全部更新，避免不一致性。
如果你遵從了這些方針，你能夠盡早地經(jīng)常正式或非正式的審查需求，這些需求對于產(chǎn)品的構造，系統測試以及最后的客戶(hù)滿(mǎn)意，都會(huì )成為好的奠基石。并且要記住，沒(méi)有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠不知道你會(huì )得到什么。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
