INCOSE需求編寫指南【編者按】如何寫好需求是INCOSE需求工作組編寫的需求文本化表達(dá)指南。本指南是專門講述如何在系統(tǒng)工程中對需求進(jìn)行文本化表達(dá)，其目的是從現(xiàn)有的各種標(biāo)準(zhǔn)中得出一個單一的，全面的規(guī)則，從而對需求編寫工作提出建議。如何寫好需求指南不是關(guān)于需求捕獲、抽取或發(fā)現(xiàn)的，也不是關(guān)于需求分析以及建模與設(shè)計的。它側(cè)重于如何用文本將需求表達(dá)清楚、準(zhǔn)確，以便于后續(xù)進(jìn)一步的需求分析。如何寫好需求指南是在INCOSE需求工作組的專家們基于廣泛的需求實踐提煉而成，可以應(yīng)用到更廣范圍內(nèi)知道需求過程。本指南是由何強根據(jù)INCOSE（國際系統(tǒng)工程協(xié)會）需求工作組的成果《INCOSE_RWG_Guide_for_Writing_Requirements20130126》進(jìn)行翻譯整理，《INCOSE_RWG_Guide_for_Writing_Requirements20130126》是INCOSE產(chǎn)品，僅限于INCOSE成員和那些INCOSE企業(yè)顧問委員會成員組織的員工使用。因此，本文的發(fā)布僅作學(xué)習(xí)用途，若存在任何問題請聯(lián)系管理員，我們將作相應(yīng)處理。1.為什么需要文本化需求自然語言并不是表達(dá)需求的完美的方式。要明確、準(zhǔn)確、避免歧義這很難。然而，它仍然是目前唯一的能夠涵蓋各種所需概念的通用表達(dá)方式，?？梢蕴娲鷷姹磉_(dá)需求的方式包括：?具有完善語言定義的圖形建模方法，如SysML。?模板結(jié)構(gòu)的表格格式收集和描述需求，如湯姆·吉爾的P語言（TomGilb’sPlanguage，Gilb，T.，2005）。這些其他的方法也不完善：模型尚未能覆蓋概念所需要的范圍，表格的呈現(xiàn)格式，追溯和管理也都存在問題。事實是，如果僅僅是為了補充其他的表達(dá)方式，則仍然需要文本化需求。文本的優(yōu)點是：?對可以表達(dá)的概念沒有任何限制。?句子和語法結(jié)構(gòu)提供了一種可以追蹤有意義的元素的方法。本指南僅指文本化需求的表達(dá)。2.需求條目的特點2.1C1–必要性每一條需求都是必須的?；驹恚簂如果去掉這條需求仍能夠滿足問題，那么這條需求就不是必須的l如果需求條目所要表達(dá)的意圖已經(jīng)在其他需求條目中描述了，那么這條需求就不是必須的l如果不能找到為什么需要這條需求的原因，那么這條需求也不是必須的l每一條需求都會有相應(yīng)的成本;不必要的需求可能導(dǎo)致沒有價值的額外工作，策略：l沒有什么本質(zhì)的特征可以表明需求是必須的。每一條需求都需要根據(jù)利益相關(guān)者真實的期望不斷地進(jìn)行調(diào)整。l在需求的最高層級，這一特點僅被用來在評審每一條需求時，針對相應(yīng)的需要、目標(biāo)、目的以及驅(qū)動者、約束、概念以及系統(tǒng)范圍內(nèi)的場景定義進(jìn)行確認(rèn)。如果頂層需求不能在上述范圍內(nèi)被追蹤到，那么這條需求就不是必須的。l在較低的層級，需求的必要性表現(xiàn)為可以追述到更高層級的需求。需求從一層到另一層的可追溯性能夠支持每一條獨立需求覆蓋的充分性與必要性原理。這一原理也可以幫助表達(dá)需求的必要性及需求條目的意圖。2.2C2–與實現(xiàn)無關(guān)僅描述需要，而不是需求如何被滿足?；驹恚喝绻谛枨笾忻枋鋈绾螌崿F(xiàn)至少有以下不良影響：l錯過考慮其他更好的實現(xiàn)方式的機會;l不能解決真正的問題.l如果在本層級沒有很好地溝通需要什么（“What”），那就不能正確地將需求往下一層分配策略：l只捕獲那些在任何方案中都必須正確滿足的功能、特征與約束。l一個很有用的提問——“需求用于什么目的”？如果是在需求中描述了實現(xiàn)的話，那這個問題的答案就是真正的需求。l如果是有效的需求，只是層級比較低。那就需要確定合適的層級以及在本層級描述需求。也就是說需求要跟系統(tǒng)層級匹配，不要描述太細(xì)節(jié)的內(nèi)容。支撐這一特征的規(guī)則R3-/精確/主體使需求的主題與需求所在的層級相適應(yīng).R33-/抽象/問題域詞匯如果在問題域，表達(dá)問題被解決要使用問題域的詞匯而不要涉及到解決方案R34-/抽象/解決方案域詞匯如果在解決方案域，表達(dá)系統(tǒng)層級的解決方案使用系統(tǒng)的詞匯2.3C3–清晰的（無二義性）一條需求僅能有唯一的一種解釋?；驹恚簂需求的意圖必須在編寫者、設(shè)計者以及驗證者之間按照同一種方式理解，模棱兩可會因為需求的解釋不是客戶的真實意圖而導(dǎo)致項目延期、成本增加等問題。策略：減少模棱兩可有很多方法，包括：l使用正確的語法;l使用術(shù)語中定義的術(shù)語或縮略語;l使用精確的數(shù)量詞與限定符;l使用一致的語言表達(dá)形式;l避免使用含混的術(shù)語;l避免使用代詞.精確的表達(dá)有很多好的實踐方法，包括：l每一條需求用一個單一的句子描述,使用主動語態(tài),不使用形容詞和副詞，精簡多余的表達(dá)理由、目的以及舉例的輔助信息或從句;l使用獨立的子條款來表達(dá)條件、性能或約束;支撐這一特征的規(guī)則R1-/精確/使用定冠詞使用定冠詞.R2-/精確/使用主動語態(tài)使用有明確確定的參與者的主動語態(tài).R4-/精確/使用定義過的術(shù)語只使用術(shù)語表中定義過的術(shù)語.R5-/精確/量化避免不精確的量詞.R6-/精確/單位描述數(shù)量時使用適當(dāng)?shù)膯挝?R7-/精確/避免副詞避免副詞.R8-/精確/避免形容詞避免形容詞R9-/精確/無例外條款避免例外條款.R10-/精確/無開口避免開口條款.R11-/簡明/無不定式避免多余的不定式.R12-/簡明/單獨條款針對每一種條件使用子條款.R13-/無歧義/正確的語法使用正確的語法.R14-/無歧義/正確拼寫使用正確的拼寫.R15-/無歧義/正確的標(biāo)點使用正確的標(biāo)點R16-/無歧義/連接詞使用'X和Y'，而不是'兩者都'R17-/無歧義/避免和/或r避免使用'X和/或Y'.R18-/無歧義/”/”避免使用斜線分隔符號("/").R30-/條件/明確清楚要給出明確的滿足條件，而不是僅列出條件清單.R35-/量詞/避免全稱量詞使用“每一個”而不是“全部”、“都”、“任何”等全稱量詞.2.4C4–完整一條需求要完整地描述需求本身的內(nèi)容?；驹恚盒枨笙嚓P(guān)的一系列過程，如分解、分配、驗證，依賴于對獨立描述的完整理解而不依賴于其他的描述.注意，需求可以參考其他的文檔，如，接口定義文件、標(biāo)準(zhǔn)、規(guī)則等。策略：l一條需求描述本身就應(yīng)該是一個完整的句子，對于這條需求的理解不需要參考其他需求的信息。l需求不能通過代詞被參考。例外完整性和唯一性性需要平衡，目前已經(jīng)使用模塊化方式來保證相關(guān)需求的分組。支撐這一特征的規(guī)則R6-/精確/Units描述數(shù)量時使用適當(dāng)?shù)膯挝?R7-/精確/避免副詞避免副詞.R8-/精確/避免形容詞避免形容詞R9-/精確/無例外條款避免例外條款.R10-/精確/無開口避免開口條款.R26-/完整/避免使用代詞在需求陳述中，全部重復(fù)名詞而不是使用代詞來指代.R27-/完整/使用需求標(biāo)題避免使用標(biāo)題支持子條款需求的解釋.R29-/條件/明確清楚描述適用條件必須明確，而不是從上下文進(jìn)行推斷.2.5C5–唯一性一條需求只表達(dá)單一的觀點?；驹恚悍纸狻⒎峙?、驗證和確認(rèn)等與需求相關(guān)的幾個過程的有效性依賴于需求的唯一性。策略：l一條需求只描述一個功能、特征或約束。要理解需求的可追溯性。可以使用項目標(biāo)準(zhǔn)模板來編寫需求。l雖然一條需求只包含一個功能、特征或約束，但是可能有多個從屬條件滿足需求l避免使用‘和’這樣的鏈接詞連接多個短語或句子表達(dá)多重意思。例外完整性和唯一性性需要平衡，目前已經(jīng)使用模塊化方式來保證相關(guān)需求的分組。唯一性與上下文需要平衡，有時文本并不是表述復(fù)雜行為的最好方法，這時需要參考模型或設(shè)計。支撐這一特征的規(guī)則R19-/一致/簡單句子用簡單的肯定的陳述句寫需求，各種條件與約束用子條款描述.R20-/一致/避免使用關(guān)系連接詞避免使用關(guān)系連接詞.R22-/一致/避免目的短語避免使用表達(dá)目的的短語.R23-/一致/避免括號“（）”避免使用“()”來描述子條款.R24-/一致/列舉能夠明確列舉出來的就不要用概述的方式.R47-/表達(dá)一致/風(fēng)格指南使用項目范圍的風(fēng)格指南.2.6C6–可行需求描述的內(nèi)容在本質(zhì)上是可行的?；驹恚簂本質(zhì)上不可行的需求，如，100%的可靠性，浪費時間，甚至導(dǎo)致不必要的昂貴解決方案l不切實際的問題通常都是重要的問題沒有很好地進(jìn)行量化。策略：l可行性/可達(dá)性可以通過成本、計劃、技術(shù)和風(fēng)險等方面的因素來衡量，使用現(xiàn)有的技術(shù)和工程方法可以對需求的可達(dá)性進(jìn)行評估，如果不具備可達(dá)性，那這條需求不是好的需求。。l通常來說在沒有對潛在解決方案進(jìn)行分析和考量的情況下無法確定一條需求的可行性，但是我們可以從基本面上識別出那些不可能實現(xiàn)或不切實際的需求。支撐這一特征的規(guī)則R28-/現(xiàn)實的/避免絕對避免使用絕對的不現(xiàn)實的詞.2.7C7–可驗證需求是可驗證的?；驹恚簂除非需求在某些方面是可驗證或可測試的，否則沒有辦法判斷它是否被滿足。因此對于不同類型的需求需要以不同的方式來證實。l功能需求，通常都要通過測試來驗證產(chǎn)品正確的行為，所以功能需求的行為一定要表達(dá)清楚；l而性能需求需要明確地表達(dá)與性能相關(guān)的數(shù)量。策略：需求不可驗證最常見的原因：l沒有明確的正確功能的行為、條件與狀態(tài)；l缺乏正確數(shù)量的范圍；l使用了有歧義的描述.站在驗證者的角度來想象自己如何進(jìn)行驗證(分析、檢驗、演示、測試)。要關(guān)注需求的量化與公差范圍，有兩方面原因：l1)多個需求之間可能需要權(quán)衡，以權(quán)衡空間的方式提供了公差或限制，很少有絕對的數(shù)量要求。值的范圍通常反映了提供不同性能的水平。l2)測試對于一個絕對值通常是不可能的，定義值的上下限可以讓測試更容易可以嘗試問這樣對問題：l我如何知道需求被滿足了？如果需求被正確的量化了，就會對這個問題提供一個很精確的回答。l什么是強制性的和什么樣的性能需求水平是令人滿意的？這個回答可能有多個值，在需求中所描述的公差于權(quán)衡空間。l我要驗證的是什么?如果沒有，那么重寫這條需求，表達(dá)出你真實的意圖。支撐這一特征的規(guī)則R1-/精確/使用定冠詞使用定冠詞.R2-/精確/使用主動語態(tài)使用有明確確定的參與者的主動語態(tài).R4-/精確/使用定義過的術(shù)語只使用術(shù)語表中定義過的術(shù)語.R5-/精確/量化避免不精確的量詞.R6-/精確/Units描述數(shù)量時使用適當(dāng)?shù)膯挝?R7-/精確/避免副詞避免副詞.R8-/精確/避免形容詞避免形容詞R9-/精確/無例外條款避免例外條款.R10-/精確/無開口避免開口條款.R30-/條件/明確清楚要給出明確的滿足條件，而不是僅列出條件清單條件.R36-/公差/值的范圍定義正確的數(shù)量范圍.R37-/量化/可度量的提供具體的可度量的性能目標(biāo).R38-/量化/避免無限時間明確地定義時間限制，而不是使用無限時間的關(guān)鍵詞.2.8C8–正確性需求是對利益相關(guān)者期望的正確表達(dá)?；驹恚簂這一特性是對必要性原則的補充，需求所描述的功能或性能值必須是正確的。l這一特性關(guān)系到利益相關(guān)者期望的驗證，驗證系統(tǒng)設(shè)計與構(gòu)建滿足需求。策略：確保以下內(nèi)容：l基于對高層需求的正確解釋與理解進(jìn)行需求分解與派生;l對根本目標(biāo)的正確理解(如，最小、最大);l正確的分析與假定。使用預(yù)先定義的需求驗證流程來保證需求在上下文環(huán)境中的正確性支撐這一特征的規(guī)則R6-/精確/Units描述數(shù)量時使用適當(dāng)?shù)膯挝?R36-/公差/值的范圍定義正確的數(shù)量范圍.R42-/可追蹤/外部參考針對可識別的元素參考外部文檔.2.9C9–合規(guī)需求要符合組織所選擇的適用標(biāo)準(zhǔn)?；驹恚寒?dāng)所有需求都同組織內(nèi)特定領(lǐng)域的標(biāo)準(zhǔn)相符合時，每一條需求就更容易編寫、理解與評審。策略：使用組織內(nèi)的模板寫需求。。支撐這一特征的規(guī)則R43-/表達(dá)一致/要點使用一致的慣例或約定來區(qū)分相對重要的需求.R44-/表達(dá)一致/一致的術(shù)語使用術(shù)語表定義一致的術(shù)語應(yīng)用到需求描述中.R45-/表達(dá)一致/首字母縮略語使用首字母縮略詞表來定義一致的縮略詞應(yīng)用到需求描述中.R46-/表達(dá)一致/縮略語使用縮略語列表來定義一套一致的縮略語用于需求描述.R47-/表達(dá)一致/風(fēng)格指南使用項目范圍的風(fēng)格指南.【后記】由于中英文語言環(huán)境的差異，部分需求編寫規(guī)則在中文語言環(huán)境下并不特別適用需求的多樣性意味著規(guī)則必須不斷地去適應(yīng)特定的情況?；谶@一現(xiàn)實，指南中僅僅介紹了一些基本的特征與屬性3.需求集的特點3.1C10–完整性需求集是對利益相關(guān)者期望的完整詮釋。基本原理：這個特性確保所有的特定、約束、功能等都包含在需求集中。需求集如果有遺漏的話，需要考慮兩方面問題：l是否所有需求都捕獲到了？l是否所有的需求都派生出來了？策略：對于頂層需求，完整性只能通過建模以及同客戶和所有利益相關(guān)方一起進(jìn)行評審的方式來處理。l在定義項目范圍時，要保證所有的利益相關(guān)者都被識別；l確保從所有利益相關(guān)者視角的場景都被開發(fā)了，包括在所有生命周期階段名義和非名義上的所有操作。l識別所有外部接口，確保每一個接口都被定義，每一個給定接口的互操作都被包含在接口需求中對于低層級的需求，可以通過從低層需求項高層需求的追蹤關(guān)聯(lián)來保證需求的完整性。l需求標(biāo)題的使用也有助于確保需求的所有方面。l根本目的就是通過清晰的溝通達(dá)成利益相關(guān)者最小的、充分必要的期望，而不是更多支撐這一特征的規(guī)則R40-/可追蹤/父子關(guān)系建立起每一條父需求同由其派生出來的子需求集之間的追蹤關(guān)系.3.2C11–一致性需求集是對利益相關(guān)者期望的一致性表達(dá)?；驹恚簂客戶和其他利益相關(guān)者的需求或設(shè)計約束通常會彼此沖突，如果不能在開發(fā)早期盡早發(fā)現(xiàn)并解決，會導(dǎo)致昂貴的返工。l此外，即使每一個需求是無歧義的，但是如果使用不一致的術(shù)語或縮略語也會導(dǎo)致整個需求集不一致。策略：l確保相同的或非常相似的需求不在不同的地方重復(fù)。l一個策略就是根據(jù)需求種類進(jìn)行分類，如，完全性、及時性、功能區(qū)的等；l然后使用排序和過濾的方法將多樣化的需求聯(lián)系在一起，并檢查他們的交互，權(quán)衡以及沖突；l使用術(shù)語表來保證術(shù)語和縮寫的一致性支撐這一特征的規(guī)則R4-/精確/使用定義過的術(shù)語只使用術(shù)語表中定義過的術(shù)語.R44-/表達(dá)一致/一致的術(shù)語使用術(shù)語表定義一致的術(shù)語應(yīng)用到需求描述中R45-/表達(dá)一致/首字母縮略語使用首字母縮略詞表來定義一致的縮略詞應(yīng)用到需求描述中R46-/表達(dá)一致/縮略語使用縮略語列表來定義一套一致的縮略語用于需求描述R47-/表達(dá)一致/風(fēng)格指南使用項目范圍的風(fēng)格指南3.3C12–可行需求集是對利益相關(guān)者期望的可行的表達(dá)?；驹恚簂如果不能在開發(fā)早期發(fā)現(xiàn)不可行的需求，則會在后期帶來成本和費用上的浪費。l即使每個單一的需求是可行的，也不能保證由它們組成的需求集是可行的。例如，下面是可行的單個筆記本需求：a.重量不超過1.4kg，1TB存儲容量，4GRAM，一個無線網(wǎng)網(wǎng)絡(luò)接口，一個以太網(wǎng)接口，一個USB接口，一個HDMI接口，可以從1米高空墜落沒有損壞，可以在±50°C的環(huán)境溫度下工作，零售價低于500美元。b.雖然每個需求看上去都完全可行，但即使是非專業(yè)人員乍一看，也不會輕易相信這個需求集是可行的（也就是說同時滿足所有需求）。策略：l在解決方案域，最好有多個可實現(xiàn)的解決方案，至少也要有一個；l這個解決方案在項目相關(guān)約束條件是可行的（如，成本、進(jìn)度、技術(shù)以及法規(guī)符合），并且技術(shù)成熟度和項目目標(biāo)也是匹配的。支撐這一特征的規(guī)則R28-/現(xiàn)實的/避免絕對避免使用絕對的不現(xiàn)實的詞.R31-/唯一/分類根據(jù)問題或系統(tǒng)解決的不同方面對需求進(jìn)行分類.R32-/唯一/只描述一次每一個需求只描述一次.R36-/公差/值的范圍定義正確的數(shù)量范圍.R37-/量化/可度量的提供具體的可度量的性能目標(biāo).3.4C13–有邊界需求集一定要在一個已定義的范圍內(nèi)。基本原理：l需求集要清晰地傳達(dá)設(shè)計團(tuán)隊、客戶和其他利益相關(guān)者在系統(tǒng)定義范圍內(nèi)的期望，必須包括所有必要的需求，要排除不相干的要素。l這一特點的目的就是要避免對工作范圍的誤解，防止資源消耗與浪費到系統(tǒng)范圍之外。策略：l在寫需求前開發(fā)和定義基線范圍，范圍要清晰地反應(yīng)利益相關(guān)者需求。一旦范圍基線確定（利益相關(guān)者同意），就可以根據(jù)這一范圍基線來寫需求。范圍確定的時候，要跟蹤需求到相應(yīng)的范圍內(nèi)容。l背景圖在定義范圍的時候很有用，可以顯示正在開發(fā)的系統(tǒng)與其他系統(tǒng)之間的交互，幫助確定哪些是系統(tǒng)關(guān)注的，哪些不是。支撐這一特征的規(guī)則R44-/表達(dá)一致/一致的術(shù)語使用術(shù)語表定義一致的術(shù)語應(yīng)用到需求描述中.R45-/表達(dá)一致/首字母縮略語使用首字母縮略詞表來定義一致的縮略詞應(yīng)用到需求描述中.R46-/表達(dá)一致/縮略語使用縮略語列表來定義一套一致的縮略語用于需求描述.R47-/表達(dá)一致/風(fēng)格指南使用項目范圍的風(fēng)格指南.3.5C14–結(jié)構(gòu)化需求集需要結(jié)構(gòu)化，以使同其關(guān)聯(lián)的需求子集可以被識別到?；驹恚航Y(jié)構(gòu)良好的需求文檔可以幫助讀者對整個需求集的理解，而不會給讀者帶來過分認(rèn)知的負(fù)擔(dān)。策略：l使用功能層次分解的方法對需求集進(jìn)行認(rèn)知分組。這種分組盡量不要超過7個子類，每個子類的選擇要按照自然實體選擇（不能隨意選擇）l組織應(yīng)該針對其不同領(lǐng)域的系統(tǒng)開發(fā)需要定義相應(yīng)的需求文檔模板。l應(yīng)用需求管理工具來配置對相關(guān)需求的識別確認(rèn)。例外完整性和唯一性需要平衡，目前已經(jīng)使用模塊化方式來保證相關(guān)需求的分組支撐這一特點的規(guī)則R47-/表達(dá)一致/風(fēng)格指南使用項目范圍的風(fēng)格指南.R48-/模塊化/依賴關(guān)系將具有相互依賴關(guān)系的需求分為一組.R49-/模塊化/關(guān)聯(lián)需求將關(guān)聯(lián)的需求分為一組.4.需求說明書的屬性4.1A1–與需要(need)相符不同層級需求之間的滿足關(guān)聯(lián)關(guān)系要被記錄?；驹恚哼@個特性的目的是多方面的：l輔助理解一個解決方案究竟是如何解決問題的；l避免產(chǎn)生過度設(shè)計的解決方案；l避免產(chǎn)生缺乏設(shè)計的解決方案；l在復(fù)雜的多層次需求集之間應(yīng)用變更管理流程。策略：追蹤每一條需求，看其是否滿足其上層需求。例外唯一性和上下文信息需要平衡，有時文本并不是表述復(fù)雜行為的最好方法，這時需要參考模型或設(shè)計（同C5）支撐這一特點的規(guī)則R32-/唯一/只描述一次每一個需求只描述一次.R39-/可追蹤/唯一參考為每一條需求提供唯一參考.R40-/可追蹤/父子關(guān)系建立起每一條父需求同由其派生出來的子需求集之間的追蹤關(guān)系.R42-/可追蹤/外部參考4.2A2–與設(shè)計相符需求和設(shè)計之間的關(guān)聯(lián)關(guān)系要被記錄?；驹恚簂需求和設(shè)計的關(guān)聯(lián)有助于分析需求變更對設(shè)計產(chǎn)生的影響l需求和設(shè)計的關(guān)聯(lián)有助于驗證設(shè)計和實現(xiàn)是否滿足需求策略：追蹤與需求關(guān)聯(lián)的每個設(shè)計及其工作產(chǎn)物。支撐這一特點的規(guī)則R25-/一致/上下文當(dāng)需求涉及復(fù)雜的行為時，應(yīng)該參考設(shè)計或模型.R32-/唯一/只描述一次每一個需求只描述一次..R40-/可追蹤/父子關(guān)系建立起每一條父需求同由其派生出來的子需求集之間的追蹤關(guān)系.R41-/可追蹤/驗證產(chǎn)物每個需求都應(yīng)該鏈接需求驗證產(chǎn)物R42-/可追蹤/外部參考針對可識別的元素參考外部文檔.4.3A3–與證據(jù)相符需求和驗證產(chǎn)物之間的關(guān)聯(lián)關(guān)系要被記錄?；驹恚盒枨蠛万炞C產(chǎn)物的關(guān)聯(lián)有助于分析需求變更對驗證產(chǎn)生的影響。策略：追蹤與需求關(guān)聯(lián)的所有驗證和確認(rèn)活動及其工作產(chǎn)物。支撐這一特點的規(guī)則R32-/唯一/只描述一次每一個需求只描述一次.R41-/可追蹤/驗證產(chǎn)物每個需求都應(yīng)該鏈接需求驗證產(chǎn)物R43-/表達(dá)一致/要點使用一致的慣例或約定來區(qū)分相對重要的需求.R47-/表達(dá)一致/風(fēng)格指南使用項目范圍的風(fēng)格指南.4.4A4–優(yōu)先級需求要有優(yōu)先級?；驹恚涸谟邢薜臈l件下（時間、資源等）不能實現(xiàn)所有需求的情況下，要考慮實現(xiàn)優(yōu)先級最高的需求策略：根據(jù)對項目成功影響大小來定義需求的優(yōu)先級，例如需求的重要性、緊急程度等。支撐這一特征的規(guī)則R43-/表達(dá)一致/要點使用一致的慣例或約定來區(qū)分相對重要的需求.5.獨立需求條目規(guī)則5.1精確5.1.1R1-/精確/使用定冠詞使用定冠詞。詳細(xì)描述：定冠詞'the'，不定冠詞'a'。l使用不定冠詞容易導(dǎo)致歧義。例如，如果需求中使用'auser'，那就不知道是否是指任意一個用戶還是一個特定用戶。l這可能導(dǎo)致驗證的混亂，例如，babies是嬰兒食品的用戶，但是，如果測試機構(gòu)試圖去驗證ababy可以訂購、接收、開啟與服務(wù)（甚至是獨立地消費），那么系統(tǒng)一定是失敗的；另一方面，如果需求所指的‘用戶’，在術(shù)語表中一定有明確的定義。l這里主要是說明，如果我們在需求中使用一些“泛指”，會導(dǎo)致歧義發(fā)生。舉例：不正確的：Thesystemshallprovideatimedisplay.{問題在于會混淆一些事，是在任何時候顯示嗎？是一次性顯示嗎？寫需求的人最可能的意思是想要系統(tǒng)持續(xù)地顯示當(dāng)前時間，但是，如果開發(fā)者提供一個持續(xù)顯示'10：00am'（或者一次性顯示任意時間），他們會說（盡管不合理），他們滿足了需求。很顯然，他們并沒有真正滿足客戶的需求}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C7-可驗證5.1.2R2-/精確/使用主動語態(tài)使用可明確識別參與者的主動語態(tài)。詳細(xì)描述：主動語態(tài)要求參與者/實體完成活動是句子的主體，如果系統(tǒng)的參與者/實體不明確，就不清楚誰來完成這個活動，進(jìn)而，需求驗證就會很困難。舉例：l不正確的：必須確認(rèn)客戶的身份.{這條需求的問題在于沒有確定Who/What負(fù)責(zé)確認(rèn)客戶的身份.}l正確的：會計系統(tǒng)必須確認(rèn)客戶的身份.{注意：如果存在不同的解釋的話，'會計系統(tǒng)','身份,'確認(rèn)'以及'客戶'必須在術(shù)語表中定義}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C7-可驗證5.1.3R3-/精確/需求主體與層級匹配使需求的主體與需求所在的層級相適應(yīng)。詳細(xì)描述：l需求的主體要能表明需求的層級。用"系統(tǒng)必須..."來表達(dá)系統(tǒng)需求;用"子系統(tǒng)必須..."來表達(dá)子系統(tǒng)需求。l在寫需求的時候有必要問一下需求的主語是否正確？或者是否需要描述需求到更高或更低層級？還要問是否是驗證需求滿足的合適的層級？舉例：l系統(tǒng)需求用"<…系統(tǒng)>必須..."來表述.l子系統(tǒng)需求用"<…子系統(tǒng)>必須..."來表述.下述需求特點是通過這條規(guī)則來呈現(xiàn)的C2-與實現(xiàn)無關(guān)5.1.4R4-/精確/使用定義過的術(shù)語只使用術(shù)語表中定義過的術(shù)語。詳細(xì)描述：l大多數(shù)語言都很豐富，幾乎每一個字都有大量的同義詞，每一個都有很微妙的不同的意義。在需求中，隱含的意思最有可能導(dǎo)致歧義以及難以驗證。使用術(shù)語表可以讓需求的讀者能夠準(zhǔn)確地知道作者所選擇的每一個詞匯的意思。l在需求文本中應(yīng)該使用一致認(rèn)同的術(shù)語表來識別術(shù)語，如：英文術(shù)語可以大寫，多個英文單詞組成的詞可以加“_”（如：Current_Time）；中文術(shù)語可以加粗或者添加術(shù)語標(biāo)記符號（此為譯者給的建議）。舉例：l不正確的：arrivalsboard應(yīng)該不斷地顯示當(dāng)前時間{問題就在于'current'含糊不清，在哪個時區(qū)？什么樣的精度？用什么樣的形式？}l正確的：‘到港顯示牌’必須顯示‘當(dāng)前時間’{注意，‘到港顯示牌’以及‘當(dāng)前時間’必須在術(shù)語表中定義，后者還應(yīng)該明確所依據(jù)的精度、形式與時區(qū)}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C7-可驗證C11-一致性5.1.5R5-/精確/量化避免不精確的量化描述。詳細(xì)描述：l需求應(yīng)該精確量化。避免使用模糊量化的詞，如：‘一些’，‘任何’，‘很多’，‘幾’，‘大約’，‘幾乎總是’，‘幾乎’，‘接近’，‘近似’，‘重要的’，‘靈活的’，‘可擴(kuò)展的’，‘典型的’，‘足夠’，‘適當(dāng)?shù)摹?，‘有效的’，‘合理的’，‘熟練的’等。l另外還應(yīng)該注意避免使用未指定的單位和為指定的值的范圍舉例：l不正確的：飛行信息系統(tǒng)必須顯示當(dāng)前的高度，分辨率“大約”1米.{這條需求的問題就是不精確。在距離1米這個上下文中“大約”是什么?誰來確定這個“大約”具體是多少？如何去驗證這個“大約”}l正確的：飛行信息系統(tǒng)必須顯示當(dāng)前的高度±1米.{注意：如果存在其他可能的解釋，那么“當(dāng)前高度”必須要定義在術(shù)語表中}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C7-可驗證5.1.6R6-/精確/單位描述數(shù)量時使用適當(dāng)?shù)膯挝?。詳?xì)描述：l所有數(shù)字都應(yīng)該有某種明確的單位舉例：l不能接受的：電路板的存儲溫度不超過30度l正確的：電路板的存儲溫度不超過30攝氏度.5.1.7R7-/精確/避免使用含糊的副詞避免使用含糊的副詞。詳細(xì)描述：l在需求描述過程中有時候會使用副詞來修飾（限定）活動。要避免使用含糊的副詞，如：經(jīng)常'，'大約'，'充分的'，'有代表性的'，'典型的'等含糊的副詞導(dǎo)致需求含糊不清、不可驗證，不能準(zhǔn)確地表達(dá)利益相關(guān)者的期望舉例：l不正確的：飛行信息系統(tǒng)必須經(jīng)常在線.l正確的：飛行信息系統(tǒng)必須具有至少YY小時內(nèi)至少XX%的有效性{注意：'有效性'必須在術(shù)語表中進(jìn)行定義因為它有很多的測量計算方法}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C4-完整C7-可驗證5.1.8R8-/精確/避免使用含糊的形容詞避免使用含糊的形容詞。詳細(xì)描述：l在需求描述過程中有時候會使用形容詞來修飾（限定）實體.如'輔助的'，'相關(guān)的'，'日常的'，'普通的'，'一般的'，'通常的'等含糊的形容詞導(dǎo)致需求含糊不清、不可驗證，不能準(zhǔn)確地表舉例：l不正確的：飛行信息系統(tǒng)必須顯示“相關(guān)飛機”的航跡信息{這條需求的問題在于沒有明確相關(guān)飛機是什么，此外，這個描述允許由開發(fā)者去確定什么是相關(guān)的;而這種決定是客戶來完成的，應(yīng)該由客戶來明確需求}l正確的：飛行信息系統(tǒng)必須顯示處于機場20KM范圍內(nèi)的每一架飛機的航跡{這樣，需要顯示航跡信息的飛機就非常明確。注意：‘飛機’、‘航跡信息’、‘機場’都應(yīng)該在術(shù)語表中進(jìn)行定義.}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C4-完整C7-可驗證5.1.9R9-/精確/無免責(zé)條款避免免責(zé)條款。詳細(xì)描述：l免責(zé)條款總是會給供應(yīng)商一些借口而不是去滿足要求。這些免責(zé)條款通常提供模糊的條件或可能性,使用的詞語可能有'只要可能'，'盡可能少'，'盡可能多'，'如果證明有必要'，'盡可能'以及'如果可行'。免責(zé)條款會導(dǎo)致模棱兩可、無法驗證的需求，不能反映準(zhǔn)確的涉眾期望。舉例：l不正確的：GPS必須有“足夠的”空間來顯示用戶的位置.l正確的：GPS必須顯示用戶的位置下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C4-完整C7-可驗證5.1.10R10-/精確/無開放條款避免開放條款。詳細(xì)描述：l開放條款告訴讀者這里還有更多的要求，但是沒有具體說明到底是什么。l要避免使用以下的詞語：'包括但不限于'，'等等'。l開放條款會導(dǎo)致模棱兩可、無法驗證的需求，不能反映準(zhǔn)確的涉眾期望。l使用開放條款也違反了“onethought”準(zhǔn)則.如果有更多的必須的情況需要說明，那么就必須明確地描述出來。舉例：不正確的：ATM必須顯示客戶帳號、賬戶余額等等。正確的：(分解成多條需求，把這些要求都完整地列舉出來)：lATM必須顯示客戶賬號.lATM必須顯示客戶賬戶余額.lATM必須顯示客戶賬戶類型.lATM必須顯示客戶賬戶透支限制.lATM必須顯示客戶.......下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C4-完整C7-可驗證5.2簡明扼要5.2.1R11-/簡明/避免助動詞“能”避免使用多余的助動詞“能”、“能夠”。詳細(xì)描述：l有時候會看到一條需求使用了助動詞“能”“能夠”來描述一個基本動作，如"系統(tǒng)必須設(shè)計成能……"，就不如簡單地描述成"系統(tǒng)必須……"。l類似還有一種描述如：“系統(tǒng)必須具備……的能力”或者“系統(tǒng)提供……的能力”。l我們必須事先考慮到驗證，如果系統(tǒng)具備“一次”做某事的能力，但是其余的99次都失敗了，那么是否滿足需求？很顯然，No.舉例：l不正確的：武器子系統(tǒng)必須有能力存儲所有的武器l正確的：武器子系統(tǒng)必須存儲所有的武器.備注：我國有能力多次把衛(wèi)星、把人送上太空，但是現(xiàn)在還不能生產(chǎn)完全自主知識產(chǎn)權(quán)的汽車。前者就是一種能力，做100個零件，只要有一個兩件滿足就可以了。這跟生產(chǎn)上的“試制”與“批產(chǎn)”是一個道理（此為譯者注）下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.2.2R12-/簡明/單獨條款使用單獨的子條款分別對應(yīng)每一種情況。詳細(xì)描述：每個需求都應(yīng)該有一個主要的動詞來描述基本的功能與需要，主要的句子可輔以子條款來說明條件、性能值和約束條件。每一個條件使用單一的、明確的可識別子條款來表示。舉例：l導(dǎo)航信標(biāo)必須為每個海事用戶在港/靠港操縱提供增強數(shù)據(jù)，8-20米精度，至少99.7%的時間內(nèi)。l這里基本功能是一個不可分割的條款，后面跟著子條款描述性能：l8-20米精度，至少99.7%的時間內(nèi)l——兩個量（準(zhǔn)確性和可靠性）不是獨立可核實的，所以依然在一起作為一個單一的需求下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.3無歧義5.3.1R13-/無歧義/正確的語法使用正確的語法。詳細(xì)描述：不正確的語法讓人云里霧里，尤其在不同語言之間的表達(dá)更需要注意。舉例：l不正確的：TheWeapon_Subsystemshallstoringthelocationofallordnance.{Thegrammaticalerrorleadstouncertaintyaboutthemeaning.}l正確的：TheWeapon_SubsystemshallstorethelocationofallOrdnance.{Notethat'Ordnance'mustbedefinedintheglossarytobeexplicitaboutthetypesofweaponsandammunition.}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.3.2R14-/無歧義/正確拼寫正確拼寫。詳細(xì)描述：不正確的拼寫導(dǎo)致混淆。舉例：l不正確的：TheWeapon_Subsystemshallstorethelocationofallordinance（條例）.{這里由于拼寫上的失誤，不太可能武器子系統(tǒng)會關(guān)注規(guī)則}l正確的：TheWeapon_SubsystemshallstorethelocationofallOrdnance（軍火）.{注意，術(shù)語表中的‘軍火’必須明確武器和彈藥的類型}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.3.3R15-/無歧義/正確標(biāo)點符號使用正確的標(biāo)點符號。詳細(xì)描述：不正確的標(biāo)點符號會導(dǎo)致需求子條款之間混淆舉例：l不正確的：導(dǎo)航信標(biāo)必須為每個海事用戶提供增強數(shù)據(jù)，致力于為在港/靠港（HHA）用戶在99.7%的時間內(nèi)提供8-20米的精度。{這句話大問題就在于‘，’上，它把讀者的主意力引到精度上而不是增量數(shù)據(jù)上}l正確的：導(dǎo)航信標(biāo)必須為在港/靠港（HHA）用戶在在99.7%的時間內(nèi)提供8-20米精度的增強數(shù)據(jù).l{逗號的位置清楚地表明了數(shù)據(jù)的精度與可用性。另外，在需求條款中，標(biāo)點符號也多，引起歧義的可能性就越大}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.3.4R16-/無歧義/使用定義過的術(shù)語Usetheconstruct'XandY'insteadof'bothXandY'。詳細(xì)描述：要表達(dá)'X和Y'兩者都……的意思，最好不要添加‘Both’，添加‘Both’容易讓讀者想到其他不同的意思。舉例：l不正確的：TheEngine_Management_SystemshalldisengagetheSpeed_Control_SubsystemwhenboththeCruise_ControlisengagedandtheDriverisapplyingtheAccelerator.l正確的：TheEngine_Management_SystemshalldisengagetheSpeed_Control_Subsystemwhen[theCruise_ControlisengagedANDtheDriverisapplyingtheAccelerator].發(fā)動機管理系統(tǒng)在‘巡航控制’中并且司機加速的時候必須解除‘速度控制子系統(tǒng)’下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.3.5R17-/無歧義/避免'和''或'避免使用'X和/或Y'。詳細(xì)描述：'和/或'最常見的解釋是要表達(dá)一種包容性，要么X或Y，要么兩者，如果是這個意圖，應(yīng)該寫成兩條需求。舉例：不正確的：當(dāng)離合器分離和/或司機使用制動器時，發(fā)動機管理系統(tǒng)必須解除速度控制子系統(tǒng)。正確的應(yīng)該是兩條需求：l當(dāng)離合器分離時，發(fā)動機管理系統(tǒng)必須解除速度控制子系統(tǒng)。l當(dāng)司機使用制動器時,發(fā)動機管理系統(tǒng)必須解除速度控制子系統(tǒng)。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.3.6R18-/無歧義/避免'/'符號避免使用"/"符號。詳細(xì)描述："/"符號有很多可能的含義，在需求中應(yīng)該避免。"/"符號（如和/或）會導(dǎo)致需求模棱兩可，不能準(zhǔn)確反映客戶的需要。舉例：不正確的：GPS在振動/沖擊中必須保留100%的功能正確的(分解成兩條需求)：lGPS在受到振動強度為XX（單位）持續(xù)時間ZZ（單位）的振動時必須保留100%的功能。lGPS在遭受到強度為XX（單位）持續(xù)時間ZZ（單位）的單一沖擊時必須保留100%的功能。5.4一致5.4.1R19-/一致/簡單句子用簡單的肯定的陳述句寫需求，各種條件與約束用子條款描述。詳細(xì)描述：l使用單一主體、一個主要的動作詞匯以及一個單一的對象編寫一個簡單的肯定陳述句，可以使用一個或多個子條款定義框架與限制。l在ISO/IEC29148中，一個典型的功能需求的句型是‘當(dāng)<…條件>，<主語>必須<動作><對象><可選限制條款>’。l使用這種風(fēng)格，并不意味著所有的需求都要采用這種標(biāo)準(zhǔn)的句型“…必須…”。還有其他兩種通用的形式：1)有些格式保留標(biāo)準(zhǔn)的形式“<主語>必須....”在動詞后跟上條件(‘<主語>必須,當(dāng)<……條件>,<動作><對象><可選限制條款>’)。2)另一種方法保留“<……（主語）>必須....”,將句子的條件放在最后。(‘<……（主語）>必須<動作><動作對象><可選限制條件>,當(dāng)<……條件>’)。這保留了主、謂、賓之間的緊密關(guān)系。舉例：正確的：l當(dāng)鍋爐中水溫小于85°C時，‘控制子系統(tǒng)’必須在3秒內(nèi)打開‘輸入閥’。不正確的：l控制子系統(tǒng)將關(guān)閉輸入閥，直到鍋爐中水溫降至85°C，再重新打開它。{這里的問題就是這個句子中包含了兩條需求。此外，還包含了代詞分別指代了不同的事物，容易造成混淆(見Rule24)，}正確的(分解為兩條需求并量化性能)：l當(dāng)鍋爐水溫超過85°C時，控制子系統(tǒng)必須在3秒內(nèi)關(guān)閉輸入閥。l當(dāng)鍋爐水溫低于85°C時，控制子系統(tǒng)必須在3秒內(nèi)開啟輸入閥。例外條款l每一個需求都必須有一個主要動詞表達(dá)的主要條款，然而，額外的子條款和輔助的動詞可以用來限制需求的性能屬性。l這樣的子條款不能去孤立地驗證，因為它們?nèi)绻x開主條款可能不可理解。如果子條款需要分別驗證的話，那么就應(yīng)該作為一個獨立的需求來表達(dá)。l如，“'救護(hù)車控制系統(tǒng)'必須將事件詳細(xì)信息傳遞給司機”一個只有一個主要動詞的完整的、易于理解的描述。可以增加輔助條款去約束'救護(hù)車控制系統(tǒng)'在將事件詳細(xì)信息傳遞給司機的同時，保持同呼叫者的溝通。l注意，如果性能屬性需要分別驗證，那么他們應(yīng)該在單獨的需求中用子條款來表達(dá)。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C5-唯一性5.4.2R20-/一致/避免使用關(guān)系連接詞避免使用關(guān)系連接詞。詳細(xì)描述：關(guān)系連接詞是指可以連接句子的詞語，如：'和'，'或'，'然后'，'如果不'，'但是'，'/'，'也'，'然而'，'是否'，'同時'，'反之'，'另一方面'以及'其他方面'，它們存在于一條需求中，通常都應(yīng)該分解為多個需求。舉例：l不正確的：用戶要么被信任要么不被信任。{其目的是用戶應(yīng)該被分為兩種類型}l正確的：安全系統(tǒng)必須將用戶分類[要么被信任或不被信任]l正確的：安全系統(tǒng)必須將用戶分為以下兩種類型之一：被信任，不被信任。5.4.3R21-/一致/約定的,慣例的連接詞表達(dá)可以使用一些約定的或慣例連接詞方式來表達(dá)一個邏輯命題組合。詳細(xì)描述：l有時候，由幾件事達(dá)成一個正確的活預(yù)期的結(jié)果，這個時候使用連接詞是沒辦法避免的。這通常是當(dāng)作符合條件進(jìn)行定義的。l這種情況下在需求文檔中使用連接詞，需要按照約定俗成的、一致認(rèn)同的方式來定義l慣例：1.將連接詞使用斜體字來表明作者要將這些條件組合在一起發(fā)揮作用的意圖。2.使用方括號[]定義這些組合條件，也使用方括號來控制他們的范圍。。舉例：l不正確的：當(dāng)鍋爐中水溫超過95oC時，控制器的值應(yīng)該接近Valv1，Valv2或者Valv3。l正確的：當(dāng)鍋爐中水溫超過95oC時，控制器的值應(yīng)該接近：[[Valv1和Valv2]或者Valv3二者之一].{在這個例子中,允許在句末使用[]來表述具體的條件范圍}5.4.4R22-/一致/避免使用表明目的的短語避免在需求中使用表明目的的短語。詳細(xì)描述：l需求文檔中不要額外地出現(xiàn)表明存在目的的短語，如：“為了……”，“以便于……”l這些額外的信息會被納入到需求說明文檔中，那么是不是還需要去驗證到底是不是這個目舉例：l不正確的：為了滿足審計需要，數(shù)據(jù)庫必須保留至少過去10年的賬戶余額信息。l正確的：審計系統(tǒng)必須保留至少過去10年的賬戶余額關(guān)聯(lián)信息。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C5-唯一性5.4.5R23-/一致/避免括號"()"避免使用括號‘（）’來表述從屬信息。詳細(xì)描述：l如果需求文檔中包含‘（）’，通常都是多余的信息可以刪除或者用作溝通的基本原理。其他時候（）里的內(nèi)容都會引起歧義。l如果為了某些特定目的使用括號‘（）’需要在需求文檔的開始約定。舉例：l不正確的：當(dāng)水溫85°C時（通常在沸騰周期的末期），”控制單元”必須切斷鍋爐的電源。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C5-唯一性5.4.6R24-/一致/列舉能夠明確列舉出來的就不要用概述的方式。詳細(xì)描述：如果能給出條目清單，就把每一條寫出來，概要性的描述容易模棱兩可。舉例：不正確的：l軟件包（如，HLT算法，選擇控制、數(shù)據(jù)訪問）應(yīng)該被作為維護(hù)文檔記錄正確的(3條需求)：l維護(hù)文檔必須包括每一種HLT算法的描述。l維護(hù)文檔必須包括選擇控制的描述。l維護(hù)文檔必須包括數(shù)據(jù)訪問的描述。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C5-唯一性5.4.7R25-/一致/上下文當(dāng)需求涉及復(fù)雜的行為時，應(yīng)該參考設(shè)計或模型。詳細(xì)描述：有時候試圖用語言來描述復(fù)雜的需求會發(fā)現(xiàn)很困難，那么最好的方法就是用圖形或模型來描述。舉例：l不正確的：控制系統(tǒng)必須在溫度超過95°C的5秒鐘之內(nèi)關(guān)閉閥門A和閥門B，相互間在2秒內(nèi)完成.l正確的：當(dāng)產(chǎn)品溫度超過95°C時，控制系統(tǒng)必須按照圖6的說明及時地關(guān)閉輸入閥{注意，在這個假定中，時序圖本身不能出現(xiàn)混亂}下述需求特點是通過這條規(guī)則來呈現(xiàn)的A2-與設(shè)計相符引起需求歧義的幾方面原因：1.描述不充分引起歧義l如果水箱水位保持100米以上的時間超過4秒，就關(guān)閉水泵｛在這個例子中，很多人一開始看不出這條需求的問題，因為多數(shù)人都不是流體專業(yè)的，因為流體依靠壓力差流動，因此，客戶是要表達(dá)“……最小水位100米……”，“……最大水位100米……”，還是“……中位水位100米……”。這是描述不充分引起的歧義。同樣的歧義問題還可能出現(xiàn)在其他不同的專業(yè)，比如對電壓與電流的描述。因此，比較有效的方法是讓其他同事和利益相關(guān)者一起來審查需求。需求編寫本身也是需要要專業(yè)知識的。｝2.語義二義性引起歧義l如果汽車的一個窗戶損壞，且車內(nèi)監(jiān)控系統(tǒng)探測到入侵者，或車門沒用車鑰匙被打開，安保系統(tǒng)將發(fā)出警報｛在這個例子中，到底是［A且B］或C還是A且［B或C］？當(dāng)我們使用R17規(guī)則時，不將需求拆分為兩條需求后就可以避免歧義。｝3.指代二義性引起歧義l顧客將訪問卡插入到讀卡器中并在鍵盤上輸入個人識別碼（PIN）。若它無效，系統(tǒng)將拒絕訪問。｛在這個例子中的“它無效”到底是訪問卡還是PIN？需求中必須明確地描述清楚，如果讓設(shè)計者去確定，這是會導(dǎo)致嚴(yán)重的安全問題的。如果設(shè)計者將“它”理解為訪問卡，那么撿到卡的人也可以訪問了；如果“它”是PIN，那么訪問卡與讀卡器還有必要嗎？除了增加成本外似乎沒有其他作用。｝4.語法二義性引起歧義l導(dǎo)航系統(tǒng)必須顯示最后5個目的地和起點。｛在這個例子中的“最后5個”是只約束目的地，還是約束目的地與起點？在需求中必須將這些描述清楚。｝5.對術(shù)語理解的不一致導(dǎo)致歧義l所有中型車輛都必須裝備一個導(dǎo)航系統(tǒng)。｛在這個例子中的“中型車輛”對不同的利益團(tuán)體有不同的解讀，為了避免歧義，必須將“中型車輛”作為5.5完整5.5.1R26-/完整/避免使用代詞重復(fù)的名詞使用完整的名稱而不是使用代詞，使用代詞往往需要參考其他的需求條目才能理解。詳細(xì)描述：l'它'，'這'，'那'，'他'，'她'，'他們'等這些代詞，我們在寫故事的時候通常使用以避免重復(fù)；l但是在寫需求條目的時候，代詞會在不同的需求條目之間交叉參考，這必須避免。l在必要的時候就重復(fù)名詞。舉例：不正確的：控制器必須發(fā)送給司機他整天的路線.正確的：控制系統(tǒng)必須將整天的‘駕駛路線’發(fā)送給司機。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C4-完整5.5.2R27-/完整/完整使用需求標(biāo)題避免使用代詞去指代需求標(biāo)題或者省略主語去說明子需求，而應(yīng)該完整使用標(biāo)題。詳細(xì)描述：這是一個非常常見的錯誤，對于子條款習(xí)慣于承前省略主語或者用代詞指代。但是在需求文檔描述中，必須完整地使用標(biāo)題。舉例：需求標(biāo)題：警報器需求l不正確的：其報警時間不超過20分鐘.l正確的：：警報器報警時間不超過20分鐘。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C4-完整5.6現(xiàn)實的5.6.1R28-/現(xiàn)實的/避免絕對避免使用一些不可達(dá)成的絕對事物。詳細(xì)描述：絕對的事物，比如'100%可靠'，這是永遠(yuǎn)也不可能達(dá)成的。預(yù)想到驗證，如何證實100%可靠?即便你能夠構(gòu)建這樣一套系統(tǒng)，如何去做出來?舉例：不正確的：系統(tǒng)必須100%有效.正確的：系統(tǒng)有效性必須≥98%.下述需求特點是通過這條規(guī)則來呈現(xiàn)的C6-可行性C12-可行性（需求集）5.7條件5.7.1R29-/條件/明確清楚描述適用條件必須明確，而不是從上下文進(jìn)行推斷。詳細(xì)描述：有時需求僅適用于某些特定條件。如果是這樣的話，條件必須在每一條需求中重復(fù)，而不能在文檔的某一段落進(jìn)行分離地描述。舉例：１．不正確的：在火災(zāi)事件中：l所有電磁防火門磁栓必須切斷電源.l所有安全入口必須設(shè)置為自由進(jìn)入模式.l所有火災(zāi)逃生門必須解鎖.2．正確的：l在火災(zāi)事件中，安全系統(tǒng)必須切斷所有電磁防火門磁栓的電源.l在火災(zāi)事件中，安全系統(tǒng)必須設(shè)置所有的安全入口為自由進(jìn)入模式.l在火災(zāi)事件中，安全系統(tǒng)必須解鎖所有火災(zāi)逃生門。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C4-完整5.7.2R30-/條件/明確的清單要給出明確的滿足條件，而不是僅列出條件清單。詳細(xì)描述：當(dāng)在需求中給出條件清單時，是否滿足所有條件還是只滿足其中之一，需求的措辭一定要使其清晰。舉例：1．不正確的：在下面情況下，審計員必須能夠改變活動項的狀態(tài)：l審計員原創(chuàng)的item;l審計員是活動參與者;l審計員是評審者.２．正確的：審計系統(tǒng)應(yīng)該允許審計員在以下‘任一’情況出現(xiàn)時能夠改變活動性的狀態(tài)：l審計員原創(chuàng)的item;l審計員是活動參與者;l審計員是評審者.３．正確的：審計系統(tǒng)應(yīng)該允許審計員在以下情況‘全部’符合時時能夠改變活動性的狀態(tài)：l審計員原創(chuàng)的item;l審計員是活動參與者;l審計員是評審者.下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的C7-可驗證5.8唯一5.8.1R31-/唯一/分類根據(jù)問題或系統(tǒng)解決的不同方面對需求進(jìn)行分類。詳細(xì)描述：以不同的方式進(jìn)行需求分類，可以通過重組的方式幫助識別潛在的重復(fù)需求與沖突，需求分組也可以幫助發(fā)現(xiàn)遺漏的需求。舉例：可以以多種方式進(jìn)行分類。在需求管理中，數(shù)據(jù)庫中的字段可以將每個需求歸為一個或多個類型；一份報告就可以獲得某種特定類型的所有需求，可以識別出需求的重復(fù)、沖突或缺失。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C12-可行性5.8.2R32-/唯一/只描述一次每一個需求只描述一次。詳細(xì)描述：應(yīng)該小心避免同樣的需求多次描述，或者以不同的形式重復(fù)。找到使用略有不同的措辭描述的類似需求比較困難，統(tǒng)一使用已定義的、分類術(shù)語可以幫助避免。舉例：l文檔副本可以通過文字匹配去查找，藥找出不同表達(dá)之間的相似性比較困難。l例如："系統(tǒng)必須提供財務(wù)往來報告"和"系統(tǒng)必須提供財務(wù)報告"有重疊，前者是后者的子集，可以通過分類來避免重復(fù)，建立需求子集進(jìn)行比較下述需求特點是通過這條規(guī)則來呈現(xiàn)的C12-可行性A1-與需要相符A2-與設(shè)計相符A3-與證據(jù)相符5.9抽象5.9.1R33-/抽象/問題域詞匯在問題域，要表達(dá)需求解決的問題就使用問題域的詞匯而不要涉及解決方案域詞匯。詳細(xì)描述：1、每個系統(tǒng)都必須有捕獲需要解決的問題而不涉及解決方案的需求2、對每個需求，你可以問一下“為了什么目的？”（注意，這里的問題不同于簡單的問“為什么？”，要盡量去發(fā)掘目的，而不是簡單的因果響應(yīng)。）這個問題的答案有可能幫你完成三件事：l1）重新描述需要解決問題的需求。l2）確定是否在正確的需求層級。l3）識別滿足了哪一個高層級需求。舉例：不正確的：l交通信號燈用于控制交叉路口交通{交通信號燈是一個解決方案}正確的(多個需求)：l‘交通控制系統(tǒng)’允許行人在路口通過馬路{這是一個激勵目標(biāo)}l‘交通控制系統(tǒng)’允許車輛在白天正常交通狀況下東西向穿過交叉路口，最長等候時間2分鐘。{注意，‘行人’、‘車輛’、‘交叉路口’都應(yīng)該在術(shù)語表中定義}。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C2-與實現(xiàn)無關(guān)5.9.2R34-/抽象/解決方案詞匯在解決方案域，使用解決方案與詞匯表達(dá)系統(tǒng)級解決方案。詳細(xì)描述：系統(tǒng)需求必須提供一個高層總體解決方案規(guī)范。第一級進(jìn)行架構(gòu)布局，子系統(tǒng)被作為黑盒放在下一個層級闡述。舉例：不正確的：l通過按交通燈支柱上的按鈕來表明行人存在，然后交通燈變?yōu)榧t燈讓行人通過。{這個需求太細(xì)節(jié)了}正確的：l‘交通控制系統(tǒng)’允許行人發(fā)出想要過馬路的信號{這個需求允許自由地去決定最佳的解決方案，有可能采用自動監(jiān)測手段而不是使用按鈕}。下述需求特點是通過這條規(guī)則來呈現(xiàn)的5.10量詞5.10.1R35-/量詞/避免全稱量詞使用“每一個”而不是“全部”、“都”、“任何”等全稱量詞。詳細(xì)描述：使用'全部','兩者都','任何'容易混淆，因為不容易區(qū)分活動的發(fā)生是針對整個集合還是集合中的每一個元素。'全部'還難于驗證，除非這里的'全部'能夠在一個封閉的集合里進(jìn)行清晰的定義。舉例：不正確的：操作記錄器必須記錄任何由系統(tǒng)產(chǎn)生的警告信息.正確的：操作記錄器必須記錄每一條由系統(tǒng)產(chǎn)生的警告信息.{注意：警告信息必須定義.}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3-清晰的5.11公差5.11.1R36-/公差/值的范圍定義正確的數(shù)量范圍。詳細(xì)描述：當(dāng)涉及到定義性能，單點值很少并且難以測量時，你可以問問自己下面的問題：如果性少一點或多一點，我還會買嗎？ifyes那么就改變以反映這一需求。它可以幫助我們考慮欠在的目標(biāo)：你想要最小化、最大化或者優(yōu)化什么嗎？這個問題的答案有助于確定是否有一個上限、下限或者上下限。舉例：不正確的：泵站必須維持120L/s的水流量30分鐘{這個需求的問題就在于我們不知道如果解決方案提供了比指定數(shù)量更多或更少是否正確？}正確的：泵站必須維持120±10L/s的水流量至少30分鐘{現(xiàn)在我們就知道正確的流量性能范圍，以及最少30分鐘的時間是正確的}。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C7-可驗證C8-正確性C12-可行性5.12量化5.12.1R37-/量化/可度量的提供具體的可度量的性能目標(biāo)。詳細(xì)描述：有些詞如'迅速','快','常規(guī)','最大','最小','最優(yōu)','名義上的','易于使用','迅速關(guān)閉','高速','中等大小','最佳實踐',以及'用戶友好的'等，這些都是模棱兩可不可測量的詞匯，需要替換成具體的數(shù)量。舉例：不正確的：系統(tǒng)必須使用最小的功率.正確的：統(tǒng)的功耗必須低于現(xiàn)有解決方案的50%.{這既考慮了潛在目標(biāo)——減少功耗，又提供了一個可衡量的目標(biāo)}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C7-可驗證C12-可行性5.12.2R38-/量化/避免無時間限制明確地定義時間限制，而不是使用無限時間的關(guān)鍵詞。詳細(xì)描述：有些詞語沒有明確的時間，如，‘最后’、‘終于’，這些詞都必須用明確的時間限制來取代。舉例：不正確的：持續(xù)運轉(zhuǎn)的水泵‘最終’必須將水箱中的水全部抽空正確的：水泵必須將水箱中至少99%的水在不超過3天的持續(xù)運轉(zhuǎn)中排出。下述需求特點是通過這條規(guī)則來呈現(xiàn)的C7-可驗證5.13可追蹤5.13.1R39-/可追蹤/唯一參考為每一條需求提供唯一參考。詳細(xì)描述：對需求跟蹤的實現(xiàn)得益于每一個需求都一個不隨時間變化的唯一參考碼或ID。在所有的需求管理工具中，工具會給每一個需求都會分配一個唯一的ID，每個ID只用一次，即便這條需求后來被刪除，這個ID也不會再被重用。舉例：不允許使用Word文檔的章節(jié)編號作為需求的ID，因為插入一個新的章節(jié)，后面的文檔章節(jié)編號會改變。下述需求特點是通過這條規(guī)則來呈現(xiàn)的A1-與需要相符5.13.2R40-/可追蹤/父子關(guān)系建立起每一條父需求同由其派生出來的子需求集之間的追蹤關(guān)系。詳細(xì)描述：父子關(guān)系可以從一個父需求向下跟蹤到由其派生出來的多個子需求，反之亦然，向上跟蹤可以回到這樣的問題“這些解決方案是為了滿足哪些需求？”根本目標(biāo)是要確定子需求集是否必要，是否足夠滿足父需求。父子關(guān)系可以是多對多的，也就是說，一個子需求可以服務(wù)于滿足多個父需求。父子關(guān)系也可以追蹤不同需求層級之間的需求分配，多數(shù)情況下需求分配需要同需求分解一致，n級需求的子需求要分配到n+1級。但是，往往在同一個需求分配層級會被分解成不同的部分。舉例：正確的追蹤：系統(tǒng)需求：‘交通控制系統(tǒng)’必須允許行人發(fā)出想要過馬路的信息。追蹤到