【正文】 整性。基本原理：這個特性確保所有的特定、約束、功能等都包含在需求集中。策略：使用組織內(nèi)的模板寫需求。 正確的分析與假定。支撐這一特征的規(guī)則R1 /精確/使用定冠詞使用定冠詞.R2 /精確/使用主動語態(tài)使用有明確確定的參與者的主動語態(tài).R4 /精確/使用定義過的術(shù)語只使用術(shù)語表中定義過的術(shù)語.R5 /精確/量化避免不精確的量詞.R6 /精確/Units描述數(shù)量時使用適當?shù)膯挝?R7 /精確/避免副詞避免副詞.R8 /精確/避免形容詞避免形容詞R9 /精確/無例外條款避免例外條款.R10 /精確/無開口避免開口條款.R30 /條件/明確清楚要給出明確的滿足條件，而不是僅列出條件清單條件.R36 /公差/值的范圍定義正確的數(shù)量范圍.R37 /量化/可度量的提供具體的可度量的性能目標.R38 /量化/避免無限時間明確地定義時間限制，而不是使用無限時間的關(guān)鍵詞.值的范圍通常反映了提供不同性能的水平。 使用了有歧義的描述.站在驗證者的角度來想象自己如何進行驗證 而性能需求需要明確地表達與性能相關(guān)的數(shù)量。 除非需求在某些方面是可驗證或可測試的，否則沒有辦法判斷它是否被滿足。 通常來說在沒有對潛在解決方案進行分析和考量的情況下無法確定一條需求的可行性，但是我們可以從基本面上識別出那些不可能實現(xiàn)或不切實際的需求。 不切實際的問題通常都是重要的問題沒有很好地進行量化。C6 –可行需求描述的內(nèi)容在本質(zhì)上是可行的。例外完整性和唯一性性需要平衡，目前已經(jīng)使用模塊化方式來保證相關(guān)需求的分組。可以使用項目標準模板來編寫需求?；驹恚悍纸?、分配、驗證和確認等與需求相關(guān)的幾個過程的有效性依賴于需求的唯一性。 需求不能通過代詞被參考?；驹恚盒枨笙嚓P(guān)的一系列過程，如分解、分配、驗證，需求可以參考其他的文檔，如，接口定義文件、標準、規(guī)則等。和/或兩者都39。X 使用獨立的子條款來表達條件、性能或約束。 避免使用代詞.精確的表達有很多好的實踐方法，包括： 使用一致的語言表達形式。 使用術(shù)語中定義的術(shù)語或縮略語。 需求的意圖必須在編寫者、設(shè)計者以及驗證者之間按照同一種方式理解，模棱兩可會因為需求的解釋不是客戶的真實意圖而導致項目延期、成本增加等問題。也就是說需求要跟系統(tǒng)層級匹配，不要描述太細節(jié)的內(nèi)容。 一個很有用的提問——“需求用于什么目的”？如果是在需求中描述了實現(xiàn)的話，那這個問題的答案就是真正的需求。 不能解決真正的問題.C2 –與實現(xiàn)無關(guān)僅描述需要，而不是需求如何被滿足。 在較低的層級，需求的必要性表現(xiàn)為可以追述到更高層級的需求。 每一條需求都會有相應(yīng)的成本?；驹恚壕渥雍驼Z法結(jié)構(gòu)提供了一種可以追蹤有意義的元素的方法。這些其他的方法也不完善：模型尚未能覆蓋概念所需要的范圍，表格的呈現(xiàn)格式，追溯和管理也都存在問題。然而，它仍然是目前唯一的能夠涵蓋各種所需概念的通用表達方式。本指南是由 何強 根據(jù)INCOSE（國際系統(tǒng)工程協(xié)會）需求工作組的成果《INCOSE_RWG_Guide_for_Writing_Requirements 20130126》進行翻譯整理，《INCOSE_RWG_Guide_for_Writing_Requirements 20130126》是INCOSE產(chǎn)品，僅限于INCOSE成員和那些INCOSE企業(yè)顧問委員會成員組織的員工使用。本指南是專門講述如何在系統(tǒng)工程中對需求進行文本化表達，其目的是從現(xiàn)有的各種標準中得出一個單一的，全面的規(guī)則，從而對需求編寫工作提出建議。. . . .INCOSE需求編寫指南20151017如何寫好需求指南不是關(guān)于需求捕獲、抽取或發(fā)現(xiàn)的，也不是關(guān)于需求分析以及建模與設(shè)計的。因此，本文的發(fā)布僅作學習用途，若存在任何問題請聯(lián)系管理員，我們將作相應(yīng)處理?？梢蕴娲鷷姹磉_需求的方式包括：?具有完善語言定義的圖形建模方法，如SysML。事實是，如果僅僅是為了補充其他的表達方式，則仍然需要文本化需求。本指南僅指文本化需求的表達。 如果去掉這條需求仍能夠滿足問題，那么這條需求就不是必須的不必要的需求可能導致沒有價值的額外工作，增加成本與不必要的風險策略： 在需求的最高層級，這一特點僅被用來在評審每一條需求時，針對相應(yīng)的需要、目標、目的以及驅(qū)動者、約束、概念以及系統(tǒng)范圍內(nèi)的場景定義進行確認。需求從一層到另一層的可追溯性能夠支持每一條獨立需求覆蓋的充分性與必要性原理?；驹恚喝绻谛枨笾忻枋鋈绾螌崿F(xiàn)至少有以下不良影響： 如果在本層級沒有很好地溝通需要什么（“What”），那就不能正確地將需求往下一層分配策略：支撐這一特征的規(guī)則R3 /精確/主體使需求的主題與需求所在的層級相適應(yīng).R33 /抽象/問題域詞匯如果在問題域，表達問題被解決要使用問題域的詞匯而不要涉及到解決方案R34 /抽象/解決方案域詞匯如果在解決方案域，表達系統(tǒng)層級的解決方案使用系統(tǒng)的詞匯策略：減少模棱兩可有很多方法，包括： 每一條需求用一個單一的句子描述,和R17 /無歧義/避免和/或r避免使用Y39。策略：例外完整性和唯一性性需要平衡，目前已經(jīng)使用模塊化方式來保證相關(guān)需求的分組。策略：唯一性與上下文需要平衡，有時文本并不是表述復雜行為的最好方法，這時需要參考模型或設(shè)計?；驹恚翰呗裕褐芜@一特征的規(guī)則R28 /現(xiàn)實的/避免絕對避免使用絕對的不現(xiàn)實的詞.因此對于不同類型的需求需要以不同的方式來證實。策略：需求不可驗證最常見的原因：(分析、檢驗、演示、測試)。 什么是強制性的和什么樣的性能需求水平是令人滿意的？這個回答可能有多個值，在需求中所描述的公差于權(quán)衡空間。C8 –正確性需求是對利益相關(guān)者期望的正確表達。 這一特性關(guān)系到利益相關(guān)者期望的驗證，驗證系統(tǒng)設(shè)計與構(gòu)建滿足需求。 對根本目標的正確理解使用預先定義的需求驗證流程來保證需求在上下文環(huán)境中的正確性支撐這一特征的規(guī)則R6 /精確/Units描述數(shù)量時使用適當?shù)膯挝?R36 /公差/值的范圍定義正確的數(shù)量范圍.R42 /可追蹤/外部參考針對可識別的元素參考外部文檔.支撐這一特征的規(guī)則R43 /表達一致/要點使用一致的慣例或約定來區(qū)分相對重要的需求.R44 /表達一致/一致的術(shù)語使用術(shù)語表定義一致的術(shù)語應(yīng)用到需求描述中.R45 /表達一致/首字母縮略語使用首字母縮略詞表來定義一致的縮略詞應(yīng)用到需求描述中.R46 /表達一致/縮略語使用縮略語列表來定義一套一致的縮略語用于需求描述.R47 /表達一致/風格指南使用項目范圍的風格指南.【后記】由于中英文語言環(huán)境的差異，部分需求編寫規(guī)則在中文語言環(huán)境下并不特別適用需求的多樣性意味著規(guī)則必須不斷地去適應(yīng)特定的情況。需求集如果有遺漏的話，需要考慮兩方面問題： 在定義項目范圍時，要保證所有的利益相關(guān)者都被識別；C11 –一致性需求集是對利益相關(guān)者期望的一致性表達。 此外，即使每一個需求是無歧義的，但是如果使用不一致的術(shù)語或縮略語也會導致整個需求集不一致。 一個策略就是根據(jù)需求種類進行分類，如，完全性、及時性、功能區(qū)的等；支撐這一特征的規(guī)則R4 /精確/使用定義過的術(shù)語只使用術(shù)語表中定義過的術(shù)語.R44 /表達一致/一致的術(shù)語使用術(shù)語表定義一致的術(shù)語應(yīng)用到需求描述中R45 /表達一致/首字母縮略語使用首字母縮略詞表來定義一致的縮略詞應(yīng)用到需求描述中R46 /表達一致/縮略語使用縮略語列表來定義一套一致的縮略語用于需求描述R47 /表達一致/風格指南使用項目范圍的風格指南50176。策略：C13 –有邊界需求集一定要在一個已定義的范圍內(nèi)。 這一特點的目的就是要避免對工作范圍的誤解，防止資源消耗與浪費到系統(tǒng)范圍之外。范圍確定的時候，要跟蹤需求到相應(yīng)的范圍內(nèi)容。C14 –結(jié)構(gòu)化需求集需要結(jié)構(gòu)化，以使同其關(guān)聯(lián)的需求子集可以被識別到。這種分組盡量不要超過7個子類，每個子類的選擇要按照自然實體選擇（不能隨意選擇）例外完整性和唯一性需要平衡，目前已經(jīng)使用模塊化方式來保證相關(guān)需求的分組支撐這一特點的規(guī)則R47 /表達一致/風格指南使用項目范圍的風格指南.R48 /模塊化/依賴關(guān)系將具有相互依賴關(guān)系的需求分為一組.R49 /模塊化/關(guān)聯(lián)需求將關(guān)聯(lián)的需求分為一組. 避免產(chǎn)生過度設(shè)計的解決方案；例外唯一性和上下文信息需要平衡，有時文本并不是表述復雜行為的最好方法，這時需要參考模型或設(shè)計（同C5）支撐這一特點的規(guī)則R32 /唯一/只描述一次每一個需求只描述一次.R39 /可追蹤/唯一參考為每一條需求提供唯一參考.R40 /可追蹤/父子關(guān)系建立起每一條父需求同由其派生出來的子需求集之間的追蹤關(guān)系.R42 /可追蹤/外部參考針對可識別的元素參考外部文檔. 需求和設(shè)計的關(guān)聯(lián)有助于驗證設(shè)計和實現(xiàn)是否滿足需求策略：追蹤與需求關(guān)聯(lián)的每個設(shè)計及其工作產(chǎn)物。策略：追蹤與需求關(guān)聯(lián)的所有驗證和確認活動及其工作產(chǎn)物。策略：根據(jù)對項目成功影響大小來定義需求的優(yōu)先級，例如需求的重要性、緊急程度等。39。a39。39。 這里主要是說明，如果我們在需求中使用一些“泛指”，會導致歧義發(fā)生。（或者一次性顯示任意時間），他們會說（盡管不合理），他們滿足了需求。舉例：會計系統(tǒng)39。 需求的主體要能表明需求的層級。 在寫需求的時候有必要問一下需求的主語是否正確？或者是否需要描述需求到更高或更低層級？還要問是否是驗證需求滿足的合適的層級？舉例： 子系統(tǒng)需求用 …子系統(tǒng)詳細描述：arrivals board應(yīng)該不斷地顯示當前時間}詳細描述： 另外還應(yīng)該注意避免使用未指定的單位和為指定的值的范圍舉例：1米. {注意：如果存在其他可能的解釋，那么“當前高度”必須要定義在術(shù)語表中}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3 清晰的C7 可驗證 不能接受的：電路板的存儲溫度不超過30度 在需求描述過程中有時候會使用副詞來修飾（限定）活動。 39。39。 正確的：飛行信息系統(tǒng)必須具有至少YY小時內(nèi)至少XX%的有效性{注意：必須在術(shù)語表中進行定義因為它有很多的測量計算方法}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3 清晰的C4 完整C7 可驗證如39。39。39。等含糊的形容詞導致需求含糊不清、不可驗證，不能準確地表達利益相關(guān)者的期望。注意：‘飛機’、‘航跡信息’、‘機場’都應(yīng)該在術(shù)語表中進行定義.}下述需求特點是通過這條規(guī)則來呈現(xiàn)的C3 清晰的C4 完整C7 可驗證這些免責條款通常提供模糊的條件或可能性,盡可能少39。如果證明有必要39。39。舉例：R10/精確/無開放條款避免開放條款。 要避免使用以下的詞語：39。如果有更多的必須的情況需要說明，那么就必須明確地描述出來。(分解成多條需求，把這些要求都完整地列舉出來)： ATM必須顯示客戶賬戶透支限制.詳細描述： 不正確的：武器子系統(tǒng)必須有能力存儲所有的武器R12/簡明/單獨條款使用單獨的子條款分別對應(yīng)每一種情況。 導航信標必須為每個海事用戶在港/靠港操縱提供增強數(shù)據(jù)，820米精度，%的時間內(nèi)。 ——兩個量（準確性和可靠性