【正文】 “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒有真正的必須。客戶或其代理都應(yīng)有強(qiáng)烈的責(zé)任建立優(yōu) 先權(quán)。優(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)。明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。要避免使用一些對(duì)于SRS 作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。檢查需求模糊的有效方式包括需求說明書的正規(guī)檢查，根據(jù)需求寫測(cè)試，建立用戶的假想來說明產(chǎn)品某個(gè)特定部 分預(yù)期的特性。如果需求是不可驗(yàn)證的，決定需求是不 是正確的實(shí)現(xiàn)就成了判斷的事。任何需求如果說產(chǎn)品將要支持什么也是不可證實(shí)的。下面描述了高質(zhì)量的SRS的一些特性。完整性也是一個(gè)需求應(yīng)具備的。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。在需求抽象上，應(yīng)用用例方法會(huì)發(fā)揮很好的作用。如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。需求中的不一致必須在開發(fā)開始前得到解決。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。也就是說每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開的說明，便于清晰的查閱。可追蹤：你應(yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)，如高級(jí)系統(tǒng)需求，用例，用戶的提議等?？勺粉櫟男枨髴?yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫，不應(yīng)過大，不應(yīng)是敘述性的文字和公告式的列表。下面有幾個(gè) 從實(shí)際的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評(píng)估每個(gè)需求，看看有什么問題，然后用更好的方式重寫。也歡 迎你提出不同的見解。因?yàn)槟阄叶疾皇钦嬲目蛻簦覀冎荒懿聹y(cè)每個(gè)需求的意圖。這個(gè)需 求有幾處含糊。問題的后果，就是需求的不可證實(shí)。如果將幾個(gè)需求串接在一節(jié)中，在構(gòu)造和測(cè)試時(shí)就很容易漏掉一個(gè)。它的不完整性 表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問題的后果，就是需求的不可證實(shí)。現(xiàn)在就很清楚，不可 打印字符是HTML標(biāo)記。只有設(shè)計(jì)人員選定了觸發(fā)條件后，你才能編寫測(cè)試驗(yàn)證觸發(fā)的正確操作。單詞“快速”使其模糊，沒有加進(jìn)錯(cuò)誤報(bào)告的定義也是其部完整。找一個(gè)自稱為HTML的入門者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤？試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描述?，F(xiàn)在我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則留由設(shè)計(jì)人員決定。例4．“如果可能，主管號(hào)碼應(yīng)通過聯(lián)機(jī)校驗(yàn)，而不是通過主全體主管號(hào)碼列表校驗(yàn)”。客戶是需要這個(gè)功能性還是不需要。但我更喜歡用“應(yīng)”清楚的說明需求的意圖，指明優(yōu)先級(jí)。如果在列表中沒有發(fā)現(xiàn)主管號(hào)碼，將會(huì)顯示一條錯(cuò)誤信息，也不接受指令。詳細(xì)檢查大的需求文檔 不是一件輕松的事情。相對(duì)于開發(fā)階段和用戶的抱怨電話，在這個(gè)階段修補(bǔ)缺陷是便宜的，編寫質(zhì)量需求的方針編寫優(yōu)秀的需求是沒有公式化的方法的。請(qǐng)?jiān)诮M織軟件需求文檔時(shí)，嚴(yán)格遵從這些方針。采用主動(dòng)語氣。使用術(shù)語，要保持一致性，并在術(shù)語表或數(shù)據(jù)字典中定義它們要看需求是否被有效的定義，可以以開發(fā)人員的觀點(diǎn)看看。換句話說，你 是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細(xì)化。要避免包含多個(gè)需求的長的敘述段落。如果你認(rèn)為一小部分測(cè)試可以驗(yàn)證一個(gè)需求的正確，那么它已經(jīng)正確的細(xì)化了。密切關(guān)注多個(gè)需求合成了單個(gè)需求。不要在一個(gè)需求中使用“和”/“或”。我曾看見過多個(gè)需求說明書前后不一致。避免在SRS中過多的申述需求。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。并且要記住，沒有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠(yuǎn)不知道你會(huì)得到什么。一個(gè)小組要帶領(lǐng)客戶進(jìn)入需求啟發(fā)階段而且你要寫軟件需求說明書?，F(xiàn)在你正在設(shè)計(jì)其中的一個(gè)特性，已經(jīng)發(fā)現(xiàn)了需求的一些問題。你被迫破解眾多需求的含義，并且你能預(yù)料到，如果你錯(cuò)了，你要做大量的重復(fù)工作。任何產(chǎn)品的質(zhì)量需要其原始材料的質(zhì)量保證，糟糕的軟件需求說明書不可能產(chǎn)出優(yōu)秀的軟件。而且，沒有非常多的好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個(gè)好的借鑒，其他原因是公司不愿意將其產(chǎn)品說明書放在公共區(qū)域。我們將用這些觀點(diǎn)檢查一些有缺陷的需求，帶著痛楚重新編寫。你也許想通過這些質(zhì)量標(biāo)準(zhǔn)評(píng)估你的工程需求。不要期望能夠編寫出一份能體現(xiàn)需求應(yīng)具備的所有特性的SRS。但是，如果你牢記這些特性，你就會(huì)編寫出更好的需求，生產(chǎn)出更好的產(chǎn)品。判斷每個(gè)需求是否具備應(yīng)有的特性的一種方式是由持有不同觀點(diǎn)的工程資金管理人所作的正規(guī)檢查。測(cè)試?yán)幽軌蛎鞔_顯現(xiàn)在需求中描述的產(chǎn)品行為（特性），能夠顯現(xiàn)缺陷、冗余和含糊之處。正確性依據(jù)于需求的來源，如真實(shí)的客戶或高級(jí)別的系統(tǒng)需求說明書。只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。這個(gè)開發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權(quán)衡。每個(gè)需求源于你認(rèn)可、具有權(quán)說明需求的原始資料，這是考慮必需的另外情形（譯注，此句翻譯不順，請(qǐng)參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒有真正的必須。客戶或其代理都應(yīng)有強(qiáng)烈的責(zé)任建立優(yōu)先權(quán)。優(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)。明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。要避免使用一些對(duì)于SRS作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。檢查需求模糊的有效方式包括需求說明書的正規(guī)檢查，根據(jù)需求寫測(cè)試，建立用戶的假想來說明產(chǎn)品某個(gè)特定部分預(yù)期的特性。如果需求是不可驗(yàn)證的，決定需求是不是正確的實(shí)現(xiàn)就成了判斷的事。任何需求如果說產(chǎn)品將要支持什么也是不可證實(shí)的。下面描述了高質(zhì)量的SRS的一些特性。完整性也是一個(gè)需求應(yīng)具備的。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。在需求抽象上，應(yīng)用用例方法會(huì)發(fā)揮很好的作用。如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。需求中的不一致必須在開發(fā)開始前得到解決。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。也就是說每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開的說明，便于清晰的查閱?？勺粉櫍耗銘?yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)，如高級(jí)系統(tǒng)需求，用例，用戶的提議等。可追蹤的需求應(yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫，不應(yīng)過大，不應(yīng)是敘述性的文字和公告式的列表。下面有幾個(gè)從實(shí)際的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評(píng)估每個(gè)需求，看看有什么