需求管理計劃

1、需求管理計劃1 簡介21.1 目的21.2 范圍21.3 定義、首字母縮寫詞與縮略語21.4 參考資料21.5 概述22 需求工件與需求類型33 需求屬性33.1 特性屬性33.1.1 狀態(tài)33.1.2 利益33.1.3 工作量33.1.4 風險33.1.5 穩(wěn)定性33.1.6 目標發(fā)布版33.1.7 職責分配43.1.8 原因43.2 涉眾請求的屬性43.2.1 狀態(tài)43.2.2 利益43.2.3 工作量43.2.4 請求類別43.2.5 風險43.2.6 原因53.3 用例的屬性53.3.1 用例分級53.3.2 風險53.3.3 原因53.3.4 用例圖形說明53.4 用例詳細需求53.

2、4.1 用例分級53.4.2 用例圖形說明53.4.3 用例書面說明53.5 補充需求的屬性53.5.1 狀態(tài)53.5.2 利益53.5.3 風險53.5.4 原因63.5.5 書面說明64 可追蹤性標準61 簡介11目的本文檔說明塔防游戲的需求文檔、需求類型以及各自的需求屬性，同時指定出于對此項目需求進行評測、報告和控制等目的而要收集并使用的信息和控制機制。b5E2RGbCAP12范圍輸入：涉眾請求、業(yè)務規(guī)則、用例模型及主角輸出：游戲功能、游戲關卡13定義、首字母縮寫詞與縮略語無14參考資料UML與系統(tǒng)分析設計可視化面向對象建模技術-標準建模語言UML教程 劉超 張莉遍著15概述管理計劃包含

3、了需求工件與需求類型（主要分析需求的類型有哪些，并對其進行解釋），需求屬性（主要介紹不同需求類型的需求屬性有哪些，并解釋），可追蹤性標準（主要對于已確定的每一需求類型，列出確定可追蹤性時使用的標準（應追蹤至的對象）。p1EanqFDPw2 需求工件與需求類型件（文檔類型）需求類型說明涉眾請求 (STR)涉眾請求 (STRQ)涉眾的關鍵請求，包括變更請求前景 (VIS)特性 (FEAT)系統(tǒng)的這一發(fā)布版的狀況或功能用例模型用例 (UC)該發(fā)布版的用例，記錄在 Rational Rose中用例 (UC)用例詳細需求 (UC)在用例規(guī)約中列出的各項詳細需求補充規(guī)約 (SS)補充需求 (SUPP)未記

4、錄在用例模型中的非功能性需求系統(tǒng)構架負責確定用例的優(yōu)先級。用例闡釋者詳細用例說明，詳細說明軟件需求。系統(tǒng)分析員主要負責確定前景，功能分析，獲取常用詞匯，查找主角和用例，獲取涉眾請求，制定需求管理計劃。用戶界面設計員主要負責用戶界面建模，設計用戶界面原型。3 需求屬性31特性的屬性311狀態(tài)在經(jīng)過項目管理團隊的商談和復審后設置。用于在確立項目基線的過程中對進度進行跟蹤。已提出用于說明正在進行討論但尚未經(jīng)過“正式渠道”（由項目團隊、產(chǎn)品管理部門和用戶或客戶群的代表所組成的工作組）復審和驗收的特性。已批準被認為是有用、可行并已獲得正式渠道批準，準備實施的功能。已并入在特定時間點并入產(chǎn)品基線中的特性。

5、312利益由營銷經(jīng)理、產(chǎn)品經(jīng)理或業(yè)務分析員設置。并非所有需求都同等重要。通過按照各項需求對最終用戶的相對利益來劃分其等級，可以促使客戶、分析員和開發(fā)團隊成員相互交換意見。用于管理規(guī)模并確定開發(fā)的優(yōu)先級。DXDiTa9E3d313工作量由開發(fā)團隊設置。由于有些特性所需的時間和資源多于其他特性，所以在評測復雜程度并預計在給定時間范圍內能否完成哪些工作時，最佳的方式就是估計團隊工作周數(shù)或個人工作周數(shù)、所需的代碼行數(shù)或功能點數(shù)。用于管理規(guī)模并確定開發(fā)的優(yōu)先級。RTCrpUDGiT314風險由開發(fā)團隊根據(jù)項目遭遇意外事件的可能性來設置，這些事件包括超支、工期延誤，甚或是項目取消。雖然可以對風險級別進行細

6、分，但大多數(shù)項目經(jīng)理都認為將風險歸為高、中、低就足夠了。通過評測項目團隊估計進度的不確定性（范圍），一般都可以間接地對風險進行評估。5PCzVD7HxA315穩(wěn)定性由分析員和開發(fā)團隊設置，設置的依據(jù)是特性發(fā)生變化的可能性或團隊對特性的理解發(fā)生變化的可能性。用于協(xié)助確定開發(fā)優(yōu)先級并確定下一步需要繼續(xù)征集的特性。jLBHrnAILg316目標發(fā)布版記錄將首次包括指定特性的產(chǎn)品版本。該字段可用于將前景文檔中的特性分配給特定的基線發(fā)布版。如果將其與狀態(tài)字段結合，您的團隊就可以提出、記錄和討論發(fā)布版的各種特性，而此時還不必前進到開發(fā)階段。只有狀態(tài)被設置為“已并入”且目標發(fā)布版已確定的特性才將被實施。管理

7、規(guī)模時，可以增加目標發(fā)布版本號，這樣該項特性雖然仍保留在前景文檔中，但將安排在以后發(fā)布。xHAQX74J0X317職責分類在許多項目中，特性會被分配給各個“特性團隊”，它們負責進一步獲取需求，并編寫軟件需求3和實施方案。這一簡單的下拉列表將幫助項目團隊中的每位成員更好地理解他們的職責。LDAYtRyKfE318原因此文本字段用于跟蹤所需特性的來源。需求的提出總會有一定的原因。此字段記錄相應的解釋或對相應解釋的引用。例如，引用可以是產(chǎn)品需求規(guī)約的頁碼及行號，或是某次重要的客戶訪談錄像的會議記錄標號。Zzz6ZB2Ltk32涉眾請求的屬性321狀態(tài)在經(jīng)過項目管理團隊的商談和復審后設置。用于在確立項

8、目基線的過程中對進度進行全程跟蹤。已提出用于說明正在進行討論但尚未經(jīng)過“正式渠道”（例如由項目團隊、產(chǎn)品管理部門和用戶或客戶群的代表所組成的工作組）復審和驗收的涉眾請求。已批準被認為是有用、可行并已獲得正式渠道批準，準備實施的涉眾請求。已實現(xiàn)在特定時間點產(chǎn)品質量測試通過的。322利益由營銷經(jīng)理、產(chǎn)品經(jīng)理或業(yè)務分析員設置。并非所有需求都同等重要。通過按照各項需求對最終用戶的相對利益來劃分其等級，可以促使客戶、分析員和開發(fā)團隊成員相互交換意見。用于管理規(guī)模并確定開發(fā)的優(yōu)先級。dvzfvkwMI1關鍵關鍵的涉眾請求。不實現(xiàn)這些請求就無法使系統(tǒng)滿足客戶的需要。所有關鍵的涉眾請求都必須在發(fā)布時實現(xiàn)，否則

9、將錯過預定的發(fā)布時間。非關鍵可以通過其他方式來實現(xiàn)這方面的涉眾請求。如果遺漏了某項非關鍵涉眾請求，可能會影響客戶或用戶滿意度，甚至會影響收入，但發(fā)布并不會因為缺少某一項非必要質量標準而延期。323工作量由聯(lián)合測試團隊（由9人小組人員組成）設置。由于有些涉眾請求所需實現(xiàn)起來復雜程度要比其他涉眾請求要大，所以在評測涉眾請求實現(xiàn)起來的復雜程度并預計在測試過程中所需的時間，最佳的方式就是估計團隊工作周數(shù)或個人工作周數(shù)。用于管理規(guī)模并確定測試的優(yōu)先級。rqyn14ZNXI324請求類別包括：變更請求，質量請求，特性請求，成本請求。325風險由測試及開發(fā)團隊根據(jù)項目遭遇意外事件的可能性來設置，這些事件包括

10、超支、工期延誤，甚或是項目取消。雖然可以對風險級別進行細分，但大多數(shù)項目經(jīng)理都認為將風險歸為高、中、低就足夠了。通過評測項目團隊估計進度的不確定性（范圍），一般都可以間接地對風險進行評估。EmxvxOtOco326原因此文本字段用于跟蹤所需涉眾請求的來源。需求的提出總會有一定的原因。此字段記錄相應的解釋或對相應解釋的引用。例如，引用可以是產(chǎn)品需求規(guī)約的頁碼及行號，或是某次重要的客戶訪談錄像的會議記錄標號。SixE2yXPq533用例的屬性331用例分級關鍵關鍵的用例。不實現(xiàn)這些請求就無法使系統(tǒng)滿足客戶的需要。所有關鍵的用例都必須在發(fā)布時實現(xiàn)，否則將錯過預定的發(fā)布時間。非關鍵可以通過其他方式來實

11、現(xiàn)這方面的用例。如果遺漏了某項非關鍵用例，可能會影響客戶或用戶滿意度，甚至會影響收入，但發(fā)布并不會因為缺少某一項非必要質量標準而延期。332風險由測試及開發(fā)團隊根據(jù)項目遭遇意外事件的可能性來設置，這些事件包括超支、工期延誤，甚或是項目取消。雖然可以對風險級別進行細分，但大多數(shù)項目經(jīng)理都認為將風險歸為高、中、低就足夠了。通過評測項目團隊估計進度的不確定性（范圍），一般都可以間接地對風險進行評估。6ewMyirQFL333原因此文本字段用于跟蹤所需涉眾請求的來源。需求的提出總會有一定的原因。此字段記錄相應的解釋或對相應解釋的引用。例如，引用可以是產(chǎn)品需求規(guī)約的頁碼及行號，或是某次重要的客戶訪談錄像

12、的會議記錄標號。kavU42VRUs334用例圖形說明34用例詳細需求341用例分級關鍵關鍵的用例。不實現(xiàn)這些請求就無法使系統(tǒng)滿足客戶的需要。所有關鍵的用例都必須在發(fā)布時實現(xiàn)，否則將錯過預定的發(fā)布時間。非關鍵可以通過其他方式來實現(xiàn)這方面的用例。如果遺漏了某項非關鍵用例，可能會影響客戶或用戶滿意度，甚至會影響收入，但發(fā)布并不會因為缺少某一項非必要質量標準而延期。342用例圖形說明包括：用例圖，活動圖，交互圖，類圖等。343用例書面說明對用例圖等圖形說明做書面的闡述，解釋標志和含義。35補充需求的屬性351狀態(tài)在經(jīng)過項目管理團隊的商談和復審后設置。用于在確立項目基線的過程中對進度進行跟蹤。352利

13、益由營銷經(jīng)理、產(chǎn)品經(jīng)理或業(yè)務分析員設置。并非所有需求都同等重要。通過按照各項需求對最終用戶的相對利益來劃分其等級，可以促使客戶、分析員和開發(fā)團隊成員相互交換意見。用于管理規(guī)模并確定開發(fā)的優(yōu)先級。y6v3ALoS89353風險由開發(fā)團隊根據(jù)項目遭遇意外事件的可能性來設置，這些事件包括超支、工期延誤，甚或是項目取消。雖然可以對風險級別進行細分，但大多數(shù)項目經(jīng)理都認為將風險歸為高、中、低就足夠了。通過評測項目團隊估計進度的不確定性（范圍），一般都可以間接地對風險進行評估。M2ub6vSTnP354原因此文本字段用于跟蹤所需特性的來源。需求的提出總會有一定的原因。此字段記錄相應的解釋或對相應解釋的引用

14、。例如，引用可以是產(chǎn)品需求規(guī)約的頁碼及行號，或是某次重要的客戶訪談錄像的會議記錄標號。0YujCfmUCw355書面說明說明補充需求的類型，含義等。4 可追蹤性標準對于上述確定的每一需求類型，應列出確定可追蹤性時使用的標準（應追蹤至的對象）?？勺粉櫺杂兄陂_發(fā)者了解和管理諸如業(yè)務規(guī)則和涉眾請求等需求內容如何轉換為一系列關鍵的涉眾用戶需要和系統(tǒng)特性（在前景文檔中規(guī)定）?？勺粉櫺赃€可用于跟蹤這些詳細規(guī)約如何轉化為設計、如何測試，以及用戶文檔是如何記錄的。eUts8ZQVRd任何開發(fā)流程都隱含有一定量的可追蹤性。這些可追蹤性通常由流程中工件之間的正式關系提供。用例可追蹤至用例段（每個用例由一個用例段

15、集組成。這種關系允許我們追蹤哪些用例段組成了哪一個用例）和主角（這種關系允許我們查看哪一個用例包含哪些主角）。sQsAEJkW5T需要追蹤至產(chǎn)品特性（每一種需要由一個特性集實現(xiàn)。這種關系允許追蹤每個特性的業(yè)務利益）。產(chǎn)品特性追蹤至軟件需求（每個特性由一個軟件需求集實現(xiàn)；這種關系允許追蹤每個軟件需求的業(yè)務利益，并在產(chǎn)品特性級別進行軟件需求規(guī)模管理）；GMsIasNXkA需要至用例（在這種情況下，需要直接追蹤到用例。假設用例在產(chǎn)品和規(guī)模管理中可以扮演產(chǎn)品特性的角色）。產(chǎn)品特性至用例（可選的可追蹤性鏈接。產(chǎn)品特性可直接追蹤至用例。這一選項允許在編寫用例段之前為用例分配產(chǎn)品特性，在產(chǎn)品特性級別對用例模

16、型執(zhí)行影響分析，反之亦然）。TIrRGchYzg產(chǎn)品特性到用例段（產(chǎn)品特性追蹤至用例段。它允許在特性的基礎上管理用例模型的規(guī)模，并有利于在比用例本身更合適的級別上進行特性集與用例模型之間的影響分析；追蹤至用例的所有產(chǎn)品特性還必須追蹤至用例段之一）。7EqZcWLZNX產(chǎn)品特性到軟件需求（產(chǎn)品特性還追蹤至補充規(guī)約里的軟件需求。沒有追蹤至用例模型的所有產(chǎn)品特性必須追蹤到補充規(guī)約中的至少一個軟件需求）。lzq7IGf02E軟件需求至用例（功能性軟件需求追蹤至用例；非功能性軟件需求的一個子集也追蹤至用例；這種關系允許根據(jù)用例的需求和業(yè)務利益對用例模型進行高級規(guī)模規(guī)劃和評估。注意：所有局部功能需求必須追蹤至用例或詞匯表。如果無法以該方式將它們反映出來，那么它們將得不到實施）。zvpgeqJ1hk軟件需求至用例段（追蹤到用例的軟件需求必須還能夠追蹤至用例的用例段之一。這種關系允許根據(jù)對用例提出的需求驗證用例的用例段。追蹤至用例的所有軟件需求必須由用例內其中的一個段實現(xiàn)。雙重可追蹤性允許我們在考慮所需的用例段之前對用例段進行驗證，并為用例本身分配軟件需求。某些段可能沒有與之匹配的軟件需求。注意：追蹤至用例的所有功能性需求必須還能夠追蹤到用例的某一個段。如果無法以該方式將它們反