項目需求開發(fā)和管理全過程知識全套

項目需求開發(fā)和管理全過程知識1.前言1.1意圖和價值意圖：明確需求，確保利益相關(guān)者的共同理解，并調(diào)整需求、計劃和工作產(chǎn)品。價值：確保客戶的需求和期望得到滿足。1.2適用范圍本過程文檔是項目經(jīng)理需求開發(fā)人員（包括：售前市場人員、需求調(diào)研人員等）執(zhí)行需求開發(fā)與管理過程活動的依據(jù)和指導(dǎo)。本過程適用于公司所有軟件項目，且貫穿于整個生命周期。1.3名詞術(shù)語◆用戶需求是用戶對要建立的系統(tǒng)的要求描述，它主要說明用戶“要做什么”、“想做什么”的問題?！糗浖枨笠步挟a(chǎn)品需求，是軟件產(chǎn)品能否滿足用戶需求的要求描述，它主要說明軟件產(chǎn)品“能做什么”、“不能做什么”的問題。2.過程定義2.1角色和職責(zé)角色職責(zé)描述高層經(jīng)理1.評審、批準(zhǔn)用戶需求、產(chǎn)品需求等過程產(chǎn)品，并參與本過程域重要的活動；2.解決在實施本過程域中所遇到的無法解決的問題項目經(jīng)理1.為需求開發(fā)工作提供各種必要的環(huán)境和條件；2.制訂需求開發(fā)計劃，并跟蹤維護該計劃；3.負(fù)責(zé)聯(lián)系用戶和需求人員進行需求開發(fā)工作；4.參與評審本過程域的工作產(chǎn)品；5.完成或協(xié)助完成本過程域的工作產(chǎn)品；6.對需求進行變更管理、跟蹤控制；7.向高層經(jīng)理報告本過程域的實施情況；需求開發(fā)人員1.負(fù)責(zé)對市場、客戶的需求調(diào)研；2.收集、分析、細(xì)化、導(dǎo)出和描述用戶需要、期望、約束和接口，并把它們轉(zhuǎn)換成用戶需求；3.完成需求開發(fā)，編寫《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》等需求文檔；4.負(fù)責(zé)對需求的后期跟蹤；5.負(fù)責(zé)執(zhí)行需求的變更。美工1.根據(jù)用戶需求和產(chǎn)品需求，在需求開發(fā)人員的指導(dǎo)下，完成開發(fā)原型Demo的制作；2.和需求開發(fā)人員一起，向用戶進行開發(fā)原型Demo演示。項目組成員參加需求開發(fā)與管理活動的評審?？蛻?.配合并參與需求的調(diào)研活動；2.評審并確認(rèn)需求開發(fā)的所有文檔；3.對《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》、需求Demo等進行確認(rèn)；CCB1.評審需求文檔是否滿足了用戶的真實意愿。2.審批需求變更申請。CM1.為評審后的需求文檔進行配置管理。QA1.檢查和監(jiān)督需求管理活動的有效性和一致性。2.將檢查出來的問題及時通報給項目經(jīng)理及項目組成員，并跟蹤問題直到關(guān)閉。2.2入口準(zhǔn)則◆

需求開發(fā)人員已經(jīng)確定；◆初步的《項目計劃》已經(jīng)通過評審。2.3輸入◆

初步的《項目計劃》；◆《項目合同》；◆《技術(shù)解決方案》；◆

客戶原始需求文檔。2.4過程活動需求階段包括需求開發(fā)和需求管理兩個過程活動?！粜枨箝_發(fā)過程需求開發(fā)過程是獲取用戶需求并對用戶需求進行分析整理形成軟件需求的過程。需求開發(fā)過程可以包括用戶需求調(diào)研、用戶需求分析、軟件需求定義和軟件需求評審四個過程，也可以根據(jù)具體情況對該過程進行裁減。需求開發(fā)的結(jié)果文檔包括用戶需求類文檔、軟件需求類文檔、有時為了滿足軟件產(chǎn)品前期設(shè)計的需要，也會制作形成業(yè)務(wù)模型、數(shù)據(jù)字典、系統(tǒng)開發(fā)原型（Demo）文檔等。所有的需求文檔經(jīng)過用戶和開發(fā)方雙方評審認(rèn)可并簽字后，形成項目的需求基線?！粜枨蠊芾磉^程需求管理是在需求文檔基線化后，對需求實現(xiàn)的跟蹤以及當(dāng)需求發(fā)生變更時，對需求變更進行控制和管理的過程。需求管理包括變更控制、版本控制、需求跟蹤過程。需求管理同時包括變更的需求及相關(guān)需求之間的關(guān)系管理。2.4.1需求開發(fā)過程2.4.1.1用戶需求調(diào)研在項目正式立項后，項目經(jīng)理組建需求開發(fā)團隊，需求開發(fā)人員根據(jù)初步《項目計劃》、客戶原始需求文檔（包括：市場人員從客戶那里得到的初步需求文檔，投標(biāo)文件中定義的技術(shù)方案內(nèi)容等），確定需求調(diào)研時間及需求獲取相關(guān)干系人，并將此活動更新到《干系人計劃》中，同時制定出《需求調(diào)研計劃》。在識別需求獲取干系人時，需求開發(fā)人員需考慮以下幾準(zhǔn)則：◆

相關(guān)干系人要具備足夠的業(yè)務(wù)經(jīng)驗?！?/p>

相關(guān)干系人要具有較強的表達能力。◆

相關(guān)干系人至少具備初級的計算機水平。在需求開發(fā)人員開始進行用戶需求調(diào)研之前，要進行充分的事前準(zhǔn)備。需要準(zhǔn)備的工作包括：◆

需求開發(fā)人員要提前了解該行業(yè)的標(biāo)準(zhǔn)、相關(guān)文件、公司規(guī)章制度等?！?/p>

需求開發(fā)人員從組織資產(chǎn)庫中尋找類似項目的需求資料，對相關(guān)需求資料有一個深入了解，以便迅速了解可以重用的業(yè)務(wù)需求內(nèi)容，為與客戶深入、專業(yè)的需求溝通打下基礎(chǔ)?！?/p>

需求開發(fā)人員確定需求調(diào)研方式，具體方式包括：客戶主動提供的需求說明文檔，與用戶面談或電話訪談或會議訪談、參觀用戶的工作流程、向用戶群體發(fā)調(diào)查問卷、與同行專家交談、分析已經(jīng)存在的同類軟件產(chǎn)品等。◆

需求開發(fā)人員根據(jù)選定的調(diào)研方式，準(zhǔn)備好《用戶需求調(diào)查單》。需求開發(fā)人員根據(jù)《需求調(diào)研計劃》開展調(diào)研工作。調(diào)研工作需要需求開發(fā)人員和用戶協(xié)同完成。調(diào)研中需求調(diào)研人員要隨時做好記錄，事后填寫好《用戶需求調(diào)查單》，作為原始用戶需求，有進行組織會議訪談的要填寫《需求訪談會議紀(jì)要》。需求開發(fā)人員根據(jù)需求調(diào)研的訪談成果，對用戶的原始需求進行分析整理，提取需求的精華，對用戶需求進行歸納總結(jié)，把相同的需求進行歸類，把文檔盡可能的用用戶容易理解的語言撰寫（包括：用例圖/用例簡述/用例規(guī)約描述等）。按照歸納總結(jié)的用戶需求點，需求開發(fā)人員編寫《用戶需求說明書》。《用戶需求說明書》的主要內(nèi)容包括：◆需求產(chǎn)生的背景◆需求目標(biāo)要求◆需求內(nèi)容范圍◆用戶角色◆功能性需求的描述◆限制條件◆非功能性要求等。《用戶需求調(diào)查單》、《用戶需求說明書》編寫完成后，需要得到用戶和開發(fā)方雙方的共同確認(rèn)，確認(rèn)的方式開始是正式的、也可以是非正式的。一般通過內(nèi)/外部評審會議、用戶簽字或非正式的其他方式（如確認(rèn)郵件等）確認(rèn)即可。用戶需求確認(rèn)后，需求開發(fā)人員創(chuàng)建《需求跟蹤矩陣》，并將用戶需求項填入《需求跟蹤矩陣》中。用戶需求調(diào)研活動可參考《需求調(diào)研指南》。2.4.1.2用戶需求分析用戶需求分析的目的是為了明確用戶需求的具體細(xì)節(jié)以及軟件產(chǎn)品實現(xiàn)的可行性，把用戶需求合理的轉(zhuǎn)化成軟件產(chǎn)品需求。用戶需求分析的主要內(nèi)容包括：◆分析用戶需求的實現(xiàn)可行性在允許的成本、性能要求下，需求開發(fā)人員要分析每項用戶需求進行軟件產(chǎn)品實現(xiàn)的可行性，同時明確與每項需求實現(xiàn)相聯(lián)系的風(fēng)險，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙等?！舸_定需求的優(yōu)先級別應(yīng)用需求分析方法來確定系統(tǒng)特性或單項需求實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎(chǔ)確定軟件產(chǎn)品將包括哪些特性或哪類需求。◆建立業(yè)務(wù)模型（可選）有時為了滿足軟件產(chǎn)品前期設(shè)計的需要，或者需求開發(fā)人員對比較復(fù)雜的用戶需求難以理解時，一般對需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。根據(jù)用戶需求分析得到的需求描述，借助于需求分析工具建立相應(yīng)的業(yè)務(wù)模型。根據(jù)項目的實際情況，選擇不同的建模方法。如：采用結(jié)構(gòu)化的需求分析方法或采用面向?qū)ο蟮男枨蠓治龇椒?，通過UML方法來進行創(chuàng)建業(yè)務(wù)模型。建議使用RationalRose、MSVisio等建模工具進行需求的建模分析，通過分析系統(tǒng)的功能模型、結(jié)構(gòu)模型和行為模型，進行系統(tǒng)建模。建模的過程包括系統(tǒng)功能建模、系統(tǒng)數(shù)據(jù)建模和體系結(jié)構(gòu)建模，在需求開發(fā)階段應(yīng)至少完成功能建模。功能建模的方式包括靜態(tài)建模和動態(tài)建模。靜態(tài)建模要求畫出用例圖、主要的類圖和對象圖，動態(tài)建模要求畫出主要的狀態(tài)圖、時序圖、協(xié)作圖和活動圖等。另外在用例圖中，需標(biāo)明每個用例的業(yè)務(wù)描述、業(yè)務(wù)數(shù)據(jù)、業(yè)務(wù)流程、入口條件、輸出結(jié)果、異常處理等要素?！艚?shù)據(jù)字典（可選）數(shù)據(jù)字典是用戶需求中的各類實體（業(yè)務(wù)對象、數(shù)據(jù)對象、業(yè)務(wù)流程對象等）的專業(yè)化名稱解釋，它能夠保證用戶和開發(fā)方對需求溝通、理解的一致性，同時也是后續(xù)進行數(shù)據(jù)庫對象設(shè)計的最重要依據(jù)之一。2.4.1.3產(chǎn)品需求定義首先，需求開發(fā)人員進行產(chǎn)品需求定義，把用戶需求向軟件需求轉(zhuǎn)化前，要確認(rèn)《用戶需求說明書》已經(jīng)通過了用戶確認(rèn)。由需求開發(fā)人員根據(jù)《用戶需求說明書》，對用戶需求進行更加詳細(xì)的專業(yè)化定義，形成用戶需求到軟件需求的映射。完成《產(chǎn)品需求規(guī)格說明書》的編寫。當(dāng)需求開發(fā)人員或用戶不能確定需求時，可以考慮實現(xiàn)一個系統(tǒng)開發(fā)原型（DEMO），這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。系統(tǒng)如果建立原型，則需向用戶演示原型，或請用戶試用原型系統(tǒng)，記錄使用中的問題并修訂原型直至客戶滿意。原型的格式和內(nèi)容由項目經(jīng)理、美工以及客戶協(xié)商自定?！捎凇队脩粜枨笳f明書》與《產(chǎn)品需求規(guī)格說明書》在內(nèi)容上存在很多的共同之處，有時為了項目的具體需要，兩個文檔可以考慮合并成一個文檔。但合并成一個文檔時需注意：◆要明確用戶需求和產(chǎn)品需求之間的對應(yīng)關(guān)系，建立起用戶需求和產(chǎn)品需求之間的映射表（通過映射表可以建立起用戶需求和產(chǎn)品需求之間的需求跟蹤矩陣）；◆用戶需求和產(chǎn)品需求之間的對應(yīng)關(guān)系，特別是軟件產(chǎn)品無法實現(xiàn)的用戶需求內(nèi)容，要在合并文檔中明確記錄，并向用戶詳細(xì)說明情況，取得雙方的溝通一致；◆合并的文檔內(nèi)容要用用戶易于理解的語言進行表述，切勿使用軟件專業(yè)性強而用戶無法理解或理解有歧義的語言，一般考慮使用用例圖/用例規(guī)約的方式?！艉喜⒌奈臋n不僅僅給用戶看，還要滿足軟件產(chǎn)品后續(xù)設(shè)計的需要，所以內(nèi)容的描述盡可能正確、完整、易于理解、無歧義。2.4.1.4產(chǎn)品需求評審產(chǎn)品需求評審的目的是為了確保用戶和開發(fā)方雙方對需求的理解一致，消除歧義，并取得雙方之間的共同認(rèn)可。評審時由項目經(jīng)理邀請客戶、相關(guān)干系人參加，要對《產(chǎn)品需求規(guī)格說明書》中的內(nèi)容逐條逐項進行驗證，如果發(fā)現(xiàn)存在問題，則由需求開發(fā)人員繼續(xù)調(diào)研，加以修改，直至評審?fù)ㄟ^。軟件需求評審要注意如下幾點：◆明確說明用戶需求和軟件產(chǎn)品需求之間的映射關(guān)系，對軟件產(chǎn)品不能實現(xiàn)或暫時無法實現(xiàn)的用戶需求，需求開發(fā)人員要向用戶詳細(xì)說明原因，取得用戶的認(rèn)可。◆可以通過演示系統(tǒng)原型（Demo）方式，直觀形象的向用戶進行軟件產(chǎn)品需求的演示，取得用戶的認(rèn)可?！糗浖枨蟠_認(rèn)不同于用戶需求的確認(rèn)，用戶需求的確認(rèn)可以是非正式（如郵件確認(rèn)），軟件產(chǎn)品需求確認(rèn)必須是正式的，《產(chǎn)品需求規(guī)格說明書》必須得到用戶的書面確認(rèn)。產(chǎn)品需求確認(rèn)后，形成正式的軟件產(chǎn)品需求基線，作為后續(xù)需求變更控制的基礎(chǔ)。2.4.2需求管理過程需求管理過程包括：需求的變更控制、需求的實現(xiàn)跟蹤兩個方面。軟件需求包括3個不同的層次――業(yè)務(wù)需求、用戶需求和功能需求。除此之外，每個系統(tǒng)還有各種非功能需求。需求的分類是軟件需求階段必不可少的工作，它可以指導(dǎo)開發(fā)人員理解不同的行業(yè)的業(yè)務(wù)、了解用戶的真實需求，清楚這些之后確立好功能項；當(dāng)開發(fā)人員對整體需求有了明確的目標(biāo)后，就可以按部就班快速有效地進行功能項開發(fā)，一般就不會背離系統(tǒng)開發(fā)需求的初衷。1、業(yè)務(wù)需求業(yè)務(wù)需求（Businessrequirement）表示組織或客戶高層次的目標(biāo)。業(yè)務(wù)需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標(biāo)。使用前景和范圍（visionandscope）文檔來記錄業(yè)務(wù)需求，這份文檔有時也被稱作項目輪廓圖或市場需求（projectcharter或marketrequirement）文檔。2、用戶需求用戶需求（userrequirement）描述的是用戶的目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)。用例、場景描述和事件――響應(yīng)表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。3、功能需求功能需求（functionalrequirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。功能需求有時也被稱作行為需求（behavioralrequirement），因為習(xí)慣上總是用“應(yīng)該”對其進行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來通知用戶已接受其預(yù)定”。功能需求描述是開發(fā)人員需要實現(xiàn)什么。4、非功能性需求4-1、系統(tǒng)需求（systemrequirement）用于描述包含多個子系統(tǒng)的產(chǎn)品（即系統(tǒng)）的頂級需求。系統(tǒng)可以只包含軟件系統(tǒng)，也可以既包含軟件又包含硬件子系統(tǒng)。人也可以是系統(tǒng)的一部分，因此某些系統(tǒng)功能可能要由人來承擔(dān)。4-2、業(yè)務(wù)規(guī)則包括企業(yè)方針、政府條例、工業(yè)標(biāo)準(zhǔn)、會計準(zhǔn)則和計算方法等。業(yè)務(wù)規(guī)劃本身并非軟件需求，因為它們不屬于任何特定軟件系統(tǒng)的范圍。然而，業(yè)務(wù)規(guī)則常常會限制誰能夠執(zhí)行某些特定用例，或者規(guī)定系統(tǒng)為符合相關(guān)規(guī)則必須實現(xiàn)某些特定功能。有時，功能中特定的質(zhì)量屬性（通過功能實現(xiàn)）也源于業(yè)務(wù)規(guī)則。所以，對某些功能需求進行追溯時，會發(fā)現(xiàn)其來源正是一條特定的業(yè)務(wù)規(guī)則。4-3、功能需求記錄在軟件需求規(guī)格說明（SRS）中。SRS完整地描述了軟件系統(tǒng)的預(yù)期特性。SRS我們一般把它當(dāng)作文檔，其實，SRS還可以是包含需求信息的數(shù)據(jù)庫或電子表格；或者是存儲在商業(yè)需求管理工具中的信息；而對于小型項目，甚至可能是一疊索引卡片。開發(fā)、測試、質(zhì)量保證、項目管理和其他相關(guān)的項目功能都要用到SRS。除了功能需求外，SRS中還包含非功能需求，包括性能指標(biāo)和對質(zhì)量屬性的描述。4-4、質(zhì)量屬性（qualityattribute）對產(chǎn)品的功能描述作了補充，它從不同方面描述了產(chǎn)品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發(fā)人員都很重要。其他的非功能需求包括系統(tǒng)與外部世界的外部界面，以及對設(shè)計與實現(xiàn)的約束。4-5、約束（constraint）限制了開發(fā)人員設(shè)計和構(gòu)建系統(tǒng)時的選擇范圍，如局限于軟件工程學(xué)科。注：分清楚那些是業(yè)務(wù)需求、哪些是用戶需求、哪些是功能性需求和非功能性需求對軟件的開發(fā)有著重大的指導(dǎo)意義，絕不可以以偏概全，錯誤地去揣摩用戶的心思；對于開發(fā)者而言，所有軟件功能的開發(fā)我們都應(yīng)該一一征求用戶的意見，對需求有了清晰的認(rèn)識后再進行實質(zhì)性的開發(fā)工作。2.4.2.1需求變更控制1、

需求變更申請對于一、二級變更，變更申請人必須填寫《需求變更申請單》，提交項目經(jīng)理。三級變更可以不填寫《需求變更申請單》，直接告知項目經(jīng)理即可；2、

變更評估項目經(jīng)理對變更申請進行變更影響分析、評估，確定是否變更、變更影響范圍及變更時機。3、

變更決策對于三級變更，項目經(jīng)理直接審批是否變更及變更時機，并進行后續(xù)的變更實施處理；對于一、二級變更，需要提交CCB（軟件配置控制委員會）、高層經(jīng)理審批是否變更及變更時機。如果允許變更，項目經(jīng)理安排變更任務(wù)，必要時制定詳細(xì)的變更計劃。變更內(nèi)容主要有：◆更新受影響的《項目計劃》、《項目進度表》等管理文檔；◆更新受影響的各類技術(shù)文檔（需求、設(shè)計、開發(fā)、測試文檔等）；◆更新項目配置庫；如果不允許變更，則直接跳轉(zhuǎn)到“6、變更溝通存檔”步驟。4、

變更實施變更責(zé)任人根據(jù)變更任務(wù)實施變更。項目經(jīng)理或CCB進行變更后的審批及發(fā)布，通知受影響的組或個人。對于影響較小的變更可以暫時不更新基線，對于影響較大的變更（需更新基線時），由相關(guān)責(zé)任人提交《基線創(chuàng)建申請單》，審批通過后建立新的基線。5、

變更驗證項目經(jīng)理對變更進行跟蹤驗證、直到變更結(jié)果和預(yù)期相符，相關(guān)內(nèi)容進行了更新，工作產(chǎn)物符合版本管理要求為止。QA監(jiān)督變更過程活動，如有協(xié)商不一致的問題，則記錄到《不一致項問題跟蹤表》中，并提交給高層。6、

變更溝通存檔將變更后的內(nèi)容通知可能會受到影響的人員，并將變更記錄匯總歸檔，如提出的變更在變更決策時被否決，其初始記錄也應(yīng)與保存。需求變更按照嚴(yán)重程度，分為一、二、三級變更：◆一級變更是指該變更會導(dǎo)致工作量延遲超出整個工程過程階段計劃總工作量的10%（或超過10個工作日）的變更，對項目的進度、成本、質(zhì)量等關(guān)鍵要素造成嚴(yán)重影響，需要重新定義需求工作，大量開發(fā)代碼需要重新編寫?！舳壸兏侵冈撟兏鼤?dǎo)致工作量延遲整個工程過程階段計劃總工作量的5～10%（或超過5個工作日，小于10個工作日）的變更，對項目的進度、成本、質(zhì)量等關(guān)鍵要素未造成重大影響?！羧壸兏侵冈撟兏鼤?dǎo)致工作量延遲小于整個工程過程階段計劃總工作量的5%（或小于5個工作日）的變更，幾乎不會對項目的進度、成本、質(zhì)量等關(guān)鍵要素造成較大影響。三種級別的需求的變更均可以由項目經(jīng)理、需求開發(fā)人員或者相關(guān)用戶提出，需求變更提出后，交予項目經(jīng)理確認(rèn)，由項目經(jīng)理分析變更影響，初步確定變更級別。確認(rèn)為一、二級的需求變更，經(jīng)項目經(jīng)理提交CCB。如果CCB同意了該變更申請，則由項目經(jīng)理組織項目組成員和需求開發(fā)人員進行需求變更工作，即重新進行需求開發(fā)、需求確認(rèn)，更新《用戶需求說明書》和《產(chǎn)品需求規(guī)格說明書》，填寫《需求變更記錄表》，需求開發(fā)人員及時更新《需求跟蹤矩陣》。如果變更申請被拒絕，CCB則需要在變更申請中說明理由，項目則繼續(xù)按原計劃進行。確認(rèn)為三級的需求變更，需求的變更人無需填寫《需求變更申請書》，經(jīng)項目經(jīng)理確認(rèn)后將變更項填入《需求變更記錄表》中即可，然后直接進行后續(xù)的變更操作，無需再交由CCB進行評審。但當(dāng)三級變更數(shù)量達到20條以上范圍時，或累積產(chǎn)生的影響達到一、二級變更的影響時，應(yīng)當(dāng)引起項目經(jīng)理高度注意，查找問題所在，并提交用戶確認(rèn)。所有的一、二級變更項，須得到用戶的確認(rèn)簽字，三級的需求變更定期告知用戶即可，無須用戶的正式確認(rèn)簽字；但當(dāng)三級變更累積產(chǎn)生的影響達到一、二級變更的影響時，則需要提請用戶予以確認(rèn)簽字。所有的一、二級變更項經(jīng)過處理后，需要變更需求相關(guān)文檔的版本號，從VX.Y版本變更到VX.(Y+1)版本，超出整個工程過程階段計劃總工作量的20%或成本超出整個工程過程階段計劃總成本的20%以上的一級變更，從VX.Y版本直接變更到V(X+1).0版本。2.4.2.2需求跟蹤當(dāng)《用戶需求說明書》編寫完成，經(jīng)過需求評審、用戶簽字后，需求開發(fā)人員創(chuàng)建需求跟蹤矩陣，需要填寫具體用戶需求編號，需求類別，當(dāng)前狀態(tài)等。需求跟蹤矩陣創(chuàng)建完成后，需求開發(fā)人員需要在以下時機成熟時更新該矩陣：每周例會時：需求開發(fā)人員在每周例會上根據(jù)本周完成的需求或與此需求相關(guān)的工作產(chǎn)品完成情況更新《需求跟蹤矩陣》。軟件需求評審?fù)ㄟ^時：《產(chǎn)品需求規(guī)格說明書》及其附件內(nèi)容（業(yè)務(wù)模型、數(shù)據(jù)字典、系統(tǒng)Demo等）評審?fù)ㄟ^并且用戶確認(rèn)簽字后，需求開發(fā)人員更新《需求跟蹤矩陣》。項目里程碑時：在項目進入里程碑階段（需求結(jié)束、系統(tǒng)測試結(jié)束等）時，也要及時進行更新。需求開發(fā)人員更改所有相關(guān)需求文檔，以及相應(yīng)的工作產(chǎn)品，使得每一個軟件的需求均能夠與后續(xù)工作成果保持一致。需求變更時：當(dāng)需求發(fā)生變更時，項目變更或者需求開發(fā)人員發(fā)現(xiàn)需求與項目實施過程存在不符合項時，也要及時更新《需求跟蹤矩陣》。2.5輸出《用戶需求調(diào)研記錄》及《用戶需求調(diào)查單》《用戶需求說明書》《產(chǎn)品需求規(guī)格說明書》系統(tǒng)開發(fā)原型Demo、業(yè)務(wù)模型、數(shù)據(jù)字典等《需求評審報告》《需求跟蹤矩陣》《需求變更申請單》《需求變更記錄》2.6出口準(zhǔn)則項目結(jié)項。2.7過程度量№度量點執(zhí)行人度量時機|頻率存儲位置M-1需求變更數(shù)需求開發(fā)人員每周《需求跟蹤矩陣》M-2需求變更工作量需求開發(fā)人員每周《需求跟蹤矩陣》2.8裁剪說明裁剪對象類型（過程活動或工作產(chǎn)品）裁減要素（增加、刪除、修改）裁減條件產(chǎn)品業(yè)務(wù)模型、數(shù)據(jù)字典刪除用戶需求易于理解時產(chǎn)品系統(tǒng)開發(fā)原型（Demo）刪除用戶需求易于理解時3.相關(guān)指南《需求調(diào)研指南》《用例指南》附錄一：《需求調(diào)研指南》1.引言在需求調(diào)研中最常見的技術(shù)就是：1、用戶訪談2、問卷表3、小組會議上述的各種技術(shù)在特定場合都能很好發(fā)揮作用，應(yīng)該好好的考慮在何時使用哪項技術(shù)。在大多數(shù)項目中，調(diào)研需求不可能只采用某個技術(shù)。實際情況中，項目組會根據(jù)不同的用戶情況采用不同的方法。2.用戶訪談用戶訪談一般在下列情況使用◆需要與少數(shù)幾個人，進行大量的知識交流◆需求開發(fā)團隊能夠與他們集中進行面對面會談◆無法一次性集中收集所有涉眾的用戶需求用戶訪談一般會經(jīng)歷五個階段◆訪談前準(zhǔn)備◆計劃和安排訪談日程◆訪談開始和結(jié)束◆引導(dǎo)訪談◆后繼的訪談?wù)砉ぷ?.1準(zhǔn)備訪談在進行訪談前，需求分析者應(yīng)該很好的理解組織結(jié)構(gòu)，行業(yè)定位和項目范圍和項目目標(biāo)，訪談會涉及下面內(nèi)容：◆組織機構(gòu)情況（組織機構(gòu)、組織業(yè)務(wù)、發(fā)展目標(biāo)、未來規(guī)劃）◆部門目標(biāo)的陳述◆已有業(yè)務(wù)業(yè)務(wù)系統(tǒng)、程序手冊◆已有系統(tǒng)的各類業(yè)務(wù)文檔◆要建設(shè)系統(tǒng)的需求目標(biāo)、需求范圍、需求分析者應(yīng)該理解一般的行業(yè)術(shù)語（術(shù)語表）并且還要熟悉行業(yè)上的業(yè)務(wù)問題。2.2計劃訪談日程準(zhǔn)備列表，列出主要話題或問題。這些問題可以找出未意識到的重點，還能有邏輯的引導(dǎo)訪談進行。安排訪談應(yīng)遵循自上而下的進行。首先訪談組織、部門或地區(qū)的領(lǐng)導(dǎo)，然后才是他們下屬的雇員。在邀請對方進行會談時，要解釋這次會談的目的，一般會涉及哪些領(lǐng)域、哪些角色人員、以及大致需要的時間。2.3訪談開始和結(jié)束開始訪談時，先介紹你自己，陳述這次訪談的目的，談?wù)劚辉L談?wù)哧P(guān)心的事，并說明有一些簡短的會談記要，在整理后會交給對方審閱。一般被訪談?wù)哒J(rèn)為需求開發(fā)者試圖找到他們工作中的缺陷。使他們擺脫這種觀點?？梢杂懻撍麄兯煜さ娜粘９ぷ鞯倪^程。好的訪談?wù)邥尡辉L談?wù)咦鳛橹髦v人。因此，需求開發(fā)人員應(yīng)該尋找一些問題讓被訪談?wù)邔λ麄冮_誠布公：例如：“怎樣的變化將使你的工作更簡單或更有效？”這個問題暗示被訪談?wù)咛岢龈倪M意見；當(dāng)列表中的所有領(lǐng)域都討論過后，提出下面問題：“還有什么問題我們沒有討論嗎？”或是“我們還需要討論些別的內(nèi)容嗎？”這些問題鼓勵被訪談?wù)咛岢鏊袘?yīng)該被討論的問題。在訪談的內(nèi)容組織上，要至上而下、分層次進行內(nèi)容的交流討論。比如：先訪談用戶需求的背景、目標(biāo)、范圍，然后從目標(biāo)、范圍中層層展開具體的需求項，再逐項討論需求項的細(xì)節(jié)業(yè)務(wù)流程、操作人員、前后置條件等內(nèi)容。結(jié)束會談時，一般會簡短的總結(jié)討論過的問題，重點指出會談的要點，并說出你的理解。這使被訪談?wù)咧滥阏J(rèn)真傾聽了談話，而且有機會澄清誤解。在總結(jié)會談以及整個會談中，需求分析者應(yīng)采取客觀的態(tài)度，避免帶個人色彩的評論，觀察或結(jié)論。最后，你必須感謝被訪談?wù)邊⒓舆@次訪談。如有必要，詢問被訪談?wù)吣芊裨诮谠賲⒓右淮魏喍痰暮罄^訪談活動。2.4引導(dǎo)訪談在訪談中避免提封閉性的問題，因為被訪談?wù)咄ǔ喍痰幕卮鹜赀@樣的問題，然后等待下一個問題。這樣就像是偵探在審問犯人。封閉性的問題：（誰，哪里，什么時間，哪一個）：◆限制了被訪談?wù)咛峁┬畔⒌念愋?，層次和?shù)量。◆通常提供了二選一的回答，暗示了較極端或不確定性的回答。◆一般用于澄清問題，探索性提問或僅是希望得到反饋信息◆花費較少的時間得到細(xì)節(jié)信息◆比較容易做筆記◆有時只能得到很少的信息◆可能導(dǎo)致被訪談?wù)邿o法自由提供信息◆對相關(guān)術(shù)語和詞匯的要求高在開始一個議題時，一般會用開放性的問題，便于被訪談?wù)哒归_思路。然后，漸漸轉(zhuǎn)為結(jié)論性問題，這樣能幫助證實你的理解。太多的關(guān)閉性問題會導(dǎo)致收集的信息不完整，太多的開放性問題可能導(dǎo)致需求分析者的理解失誤。為了會談后的整理需要，一般會使用簡明的符號來做筆記，否則做筆記會使你分心。最好將筆記本放在被訪談?wù)咭暰€外。需求開發(fā)者的筆記有助于會談后回顧要點和會談時形成的想法。最好是會談時指定一個記錄員。使用錄音機也是個好主意。雖然會談后整理信息會耗費些時間，因為需求開發(fā)人員需要聽完整個記錄。不特別推薦使用錄音機，這會使被訪談?wù)哂斜幻{迫的感覺；而且傾聽錄音，記錄其中要點也是耗時較多的工作。無論如何，音頻視頻記錄有優(yōu)點也有缺點。認(rèn)真傾聽有助維持需求分析者和被訪談人之間的信息交流，維持相互之間適當(dāng)?shù)姆答仭ＵJ(rèn)真傾聽有五個關(guān)鍵方法：1.

詢問開放性的問題開放性問題無法簡單的用事或否來回答，應(yīng)此被訪談?wù)呔蜁峁└嗟男畔?。開放性問題一般會使用這些詞語做開頭，如什么，怎么樣或是告訴我。而不會使用諸如能夠，要作或是何時這樣的詞語。列舉一個需要詳盡解釋的問題，“告訴我，當(dāng)顧客打進電話時，什么情況發(fā)生？”開放性問題：（什么，為什么，多么）◆涉及比較寬廣，加在被訪談?wù)呱系募s束很少◆用來確定理解范圍。被訪談?wù)邥褂妹鞔_的回答或是模擬演示來傳達需求開發(fā)人員不了解的內(nèi)容◆可以得到被訪談?wù)叩男袠I(yè)詞匯，概念和可參考的知識框架◆有助于增強理解，得到一些潛在的理論2.

使用適當(dāng)?shù)谋磉_避免使用有感情傾向，讓人分心或是難以理解的語言。類似于問題存在于，討厭的處理過程或是無法控制這樣的有感情傾向的語言容易暗示某種結(jié)論。避免使用讓人分心語言。這些語言包括過多的縮寫詞或首字母縮寫，顯示自己才識的語言，有爭議性語言，俗語，俚語以及行話。3.

暗示相信被訪談?wù)呷祟悤褂谜f話的語氣，眼神接觸，面部表情，身體姿勢和身體的移動來傳達某種信息。正確使用，會使被訪談?wù)咛峁└嗟男畔?。例如，在訪談中避免眼睛接觸會被理解為缺乏興趣，或是對其他人更感興趣。適當(dāng)?shù)难凵窠佑|會傳達出感興趣，關(guān)注，開放的接受并且尊重別人的見解。

太頻繁的眼神接觸會被誤解為盯著對方。在我們的文化中，如果兩個陌生人間眼神接觸時間過長則意味著挑戰(zhàn)。在其他的一些文化中，會被認(rèn)為是侵犯隱私。點頭表示理解，暗示接受；類似的，表示關(guān)注的姿勢：端正坐著略向前傾。缺少經(jīng)驗的需求開發(fā)人員通常會犯下面的錯誤：i.靠在椅子后背上，雙手合攏抱在胸前。這種姿勢暗示了不太接受正在講述的內(nèi)容，也顯示出需求開發(fā)人員處于不安的狀態(tài)。ii.看著屋內(nèi)的物品或是直盯著窗戶，而不是看著被訪談人。這表明需求開發(fā)人員更寧愿在其他的地方做其他事，被放談?wù)咄ǔs短訪談的過程。iii.忙于做筆記或是經(jīng)常翻閱筆記。較之傾聽而言，需求開發(fā)人員對自己的記錄更感興趣會使被訪談?wù)吆闷妫降姿涗浟耸裁?。iv.坐得太遠(yuǎn)或太近。坐得太遠(yuǎn)像是暗示被訪談?wù)邥{到需求開發(fā)人員，坐得太近又顯得不恰當(dāng)?shù)赜H密，被訪談?wù)邥杏X不自在。4.

重述被訪談?wù)叩幕卮鹬厥龌卮鹗侵感枨箝_發(fā)人員用自己的語言復(fù)述被訪談?wù)叩年愂?。這顯示了兩者間進行了有效地溝通，需求開發(fā)人員理解了被訪談?wù)叩年愂?，重述回答一般用在以下場合：◆訪談?wù)呙枋鲆粋€問題時。這時，需求開發(fā)人員的復(fù)述表明聽見并理解了訪談?wù)叩膯栴}?！舢?dāng)需求開發(fā)人員想檢查他的理解是否正確時。這個技巧大多是遇到復(fù)雜的陳述時，或是多人參與時，每個人對同一問題有各自不同的見解。◆需求開發(fā)人員希望鼓勵訪談?wù)邥r。重述回答會暗示被訪談?wù)邤U展或是詳細(xì)說明他曾說過的內(nèi)容。重述回答也能克制住因某種原因，不愿配合的人。需求開發(fā)人員必須保持中立。例如，如果被訪談?wù)吲u現(xiàn)有管理模式，需求開發(fā)人員不應(yīng)該贊同他的批評或是為現(xiàn)有管理模式辯護。需求開發(fā)人員只需要表達出被訪談?wù)叩母杏X是可理解的。重述問題常見的錯誤：◆重復(fù)被訪談?wù)叩脑挘?，完全重?fù)被訪談?wù)叩脑挾皇鞘褂闷渌谋磉_方式。一段話講完后被完全重復(fù)一遍，會使被訪談?wù)吒杏X不安。◆過多重述回答將使被訪談?wù)叻中??！舾淖兓蚴峭崆辉L談?wù)哒鎸嵉囊庠?。重述?yīng)該盡可能的接近被訪談?wù)叩囊馑??！粼趶?fù)述結(jié)束時提高聲音。這個習(xí)慣會使復(fù)述變成一個問題，會暗示被訪談?wù)呋卮鹗腔蚍?，而不是讓被訪談?wù)邤U展他的解釋。這兒有個例子顯示了有效的及無效的復(fù)述；被訪談?wù)叩幕卮穑侯櫩蜎]有支付帳單，我們也會繼續(xù)銷售產(chǎn)品給他們。無效的復(fù)述：在你們處理定單前為什么不檢查顧客的信用狀態(tài)？（扭曲了被訪談?wù)叩囊馑迹┯行У膹?fù)述：系統(tǒng)也會處理有信用危險的顧客的定單。（鼓勵被訪談?wù)邤U展發(fā)揮）5.有效的使用沉默在提問結(jié)束時允許被訪談?wù)呤占硭麄兊南敕?。?dāng)被訪談?wù)呋卮鸩煌暾麜r，鼓勵他們繼續(xù)。在會談已文字記錄后，使用封閉性問題可以澄清理解。3.問卷表問卷表是需求調(diào)研時廣泛使用的另一種工具，它采用了統(tǒng)計分析的方法，顯得更科學(xué)。問卷表一般在下列情況中使用：◆需訪談的個體太多◆需要回答容易確定的細(xì)節(jié)問題◆當(dāng)你希望有個詳細(xì)的結(jié)果時準(zhǔn)備問卷表時，注意以下情況：◆使問卷表盡可能的簡短。用多個短小的問卷表替代一個長的問卷表。如果在回答了前15-20個問題后，長的問卷表會使用戶感覺厭煩，他們就不會對其余的問題做出正確的判斷。通常，一個問卷表包含的問題不超過10-15?！艄烙嫽卮饐栴}需要的時間，并在問卷表開頭標(biāo)明這個時間，以便讓回答者做出相應(yīng)的安排。◆確保問題是前后一致的，沒有讓人含混的理解?！魹榱吮ＷC不會理解含混，讓與回答者關(guān)系密切的人員來進行問卷調(diào)查，并保證他們對問題的理解是正確的?！粼谥贫▎栴}前，先確定你需要得到怎樣的答案?！舴謩e列出所有可能的答案?！粢坏┧械男枨蠛蛦栴}都準(zhǔn)備好了，把需求點當(dāng)作X軸，問題當(dāng)作Y軸。確保所有的需求能被問題覆蓋。最后，剔除掉與需求無關(guān)的問題。4.小組會議小組會議一般在下列情況中使用：◆信息平均的分布一小部分個人中◆無法個別的會見所有的涉眾◆一系列的訪談已經(jīng)結(jié)束，團隊需要在同一平臺下得到所有的回答者在小組會議中，每個人都可講出自己的想法。團隊的答案一般比個人的答案好。小組會議可以減少一部分需求沖突，繞開紛繁的情況得到需求列表如果小組會議管理不好，容易出現(xiàn)下列情況1.少數(shù)與會者控制了討論2.一部分與會者缺乏參與討論的積極性為避免這種情況，需求開發(fā)人員要推動討論的進行。要鼓勵缺乏積極性的與會者參與討論，先直接向他們提一些封閉性問題，然后逐漸轉(zhuǎn)為開放性問題。首要的技巧像提一些開放性問題，復(fù)述回答來確認(rèn)理解，建立清楚的議程，指定記錄員記錄會議等都可使用。其他一些注意事項：◆提前確定會議地點，在發(fā)出與會邀請時提供路線圖。這在一些大公司尤為重要，并不是每個人都熟悉整個辦公大樓?！籼崆爸贫ㄗ话才牛骄植夹枨箝_發(fā)人員，這樣確保所有的回答都能被聽到?！羧绻赡埽跁h開始時宣布一些希望大家遵守的基本準(zhǔn)則，如尊重別人的觀點，關(guān)閉手機等?！衾卫慰刂朴懻摰脑掝}。◆如果可能，使用錄音機，這樣能更專注于討論。◆好好的準(zhǔn)備小組會議，所做準(zhǔn)備要“N”倍于個人訪談的準(zhǔn)備，這里的“N”是指參與討論的涉眾人數(shù)?！羧绻@個會議是最終確定需求，而不是探詢需求，可采用原型演示的方法。在小組討論結(jié)束時，感謝大家抽出時間參與討論，告訴大家整理確認(rèn)需求的計劃并傳閱會議紀(jì)要。附錄二：《用例指南》1.定義與解釋用例——用例實例是系統(tǒng)執(zhí)行的一系列動作，這些動作將生成特定主角可觀測的結(jié)果值。一個用例定義一組用例實例。下面對此定義進行解釋：用例實例：以上定義所說的序列實際上是貫穿整個系統(tǒng)的某個特定事件流，即一個實例。可能會有許多事件流，而許多事件流可能非常相似。為了使用例模型便于理解性，應(yīng)該將相似的事件流組合到一個用例中。確定和說明某個用例實際上就是確定和說明一組相關(guān)的事件流。系統(tǒng)執(zhí)行：這意味著系統(tǒng)提供用例。主角和系統(tǒng)的某個用例實例進行通信?？捎^測的結(jié)果值：您可以給一個成功執(zhí)行的用例賦予一個值。用例應(yīng)該確保主角可以執(zhí)行某個具有可確定值的任務(wù)。確定用例的正確級別或粒度是非常重要的事情。正確級別是指所實現(xiàn)的用例不是太小。在某些特定的環(huán)境中，可以將一個用例當(dāng)作組織內(nèi)的一個計劃單元，該單元包括了擔(dān)任系統(tǒng)的主角角色的個人。動作：一個動作就是一個計算或算法過程。當(dāng)主角向系統(tǒng)提供信號或當(dāng)系統(tǒng)得到時間事件時，動作即被調(diào)用。動作可能包含向調(diào)用的主角或其他主角進行的信號傳輸。動作是不可分的，它要么完全執(zhí)行，要么根本不執(zhí)行。特定主角：主角是查找正確用例的關(guān)鍵，這尤其是因為主角可幫助您避開太大的用例。例如，考慮一個可視化建模工具。該應(yīng)用程序有兩個真正的主角：開發(fā)人員，他負(fù)責(zé)以該工具作為支持來進行系統(tǒng)開發(fā)；系統(tǒng)管理員，他負(fù)責(zé)管理該工具。這兩個主角對系統(tǒng)都有各自的要求，因而需要自己的用例集。系統(tǒng)的功能由不同的用例來定義，每個用例都代表了一個特定的事件流。用例說明將定義執(zhí)行用例時在系統(tǒng)中發(fā)生的事件。例如，在自動柜員機中，客戶可以從帳戶中提取現(xiàn)金、將現(xiàn)金轉(zhuǎn)入帳戶或核對帳戶余額。這些功能對應(yīng)于可以用用例來代表的事件流。每個用例本身就有一個要執(zhí)行的任務(wù)。所收集到的用例組成了所有可能的系統(tǒng)使用方法。只需注意一下用例任務(wù)的名稱，就可以對該用例任務(wù)有一個大致的了解。2.如何發(fā)現(xiàn)用例以下問題可以幫助您確定用例：◆對于已確定的各個主角，哪些任務(wù)會涉及到系統(tǒng)？◆是否需要將系統(tǒng)中發(fā)生的某些特定事件通知給此主角？◆此主角是否需要將突發(fā)變更或外部變更通知給系統(tǒng)？◆系統(tǒng)是否給業(yè)務(wù)提供了正確的行為？◆您已經(jīng)確定的用例是否可以執(zhí)行所有功能？◆哪些用例將支持和維護系統(tǒng)？◆在系統(tǒng)內(nèi)應(yīng)該修改或創(chuàng)建什么信息？有些用例不代表系統(tǒng)的主要功能，因而通常會被忽略。這些用例可能屬于以下類型：◆系統(tǒng)啟動和停止?！粝到y(tǒng)的維護。例如，添加新用戶和建立用戶簡檔?！艟S護在系統(tǒng)中存儲的數(shù)據(jù)。例如，所構(gòu)建的系統(tǒng)和遺留系統(tǒng)平行工作，所以數(shù)據(jù)需要在兩個系統(tǒng)之間達到同步。◆修改系統(tǒng)行為所需的功能。例如創(chuàng)建新報告的功能，它不僅可以創(chuàng)建硬代碼，還可以對系統(tǒng)中存儲的數(shù)據(jù)創(chuàng)建一組特定報告。3.用例如何演進在精化的早期迭代中，只對少數(shù)幾個用例（在構(gòu)架方面有重要意義的用例）進行比簡要說明更為詳細(xì)的說明。在深入到細(xì)節(jié)之前，通常應(yīng)該先編寫用例的提綱（按照分步格式）。此分步提綱應(yīng)該是您定義用例事件流結(jié)構(gòu)的首次嘗試。始終要從基本的用例流開始。一旦對基本流提綱形成了一致意見，就可以添加與基本流相關(guān)的備選流內(nèi)容。當(dāng)精化階段即將結(jié)束時，應(yīng)完成您計劃要詳細(xì)說明的所有用例。4.是否詳細(xì)說明了所有用例？模型中通常會有一些簡單的用例，它們不需要詳細(xì)的事件流說明，對它們使用分步提綱就可以了。要做出這一決定，依據(jù)的標(biāo)準(zhǔn)是：您沒有發(fā)現(xiàn)作為讀者的用戶對該用例的含義存在異議，而且設(shè)計人員和測試人員對于按分步格式提供的詳細(xì)程度感到滿意。這種簡單用例的示例之一是描述簡單的輸入或從系統(tǒng)中檢索某些數(shù)據(jù)的用例。5.用例的范圍通常很難判斷一組系統(tǒng)交互或?qū)υ捠欠駥儆谝粋€或幾個用例。請考慮回收機的使用情況?？蛻魧①A藏物品（如罐子、瓶子和箱子）插入回收機。當(dāng)插入所有的貯藏物品后，她按下某個按鈕，打印了一份收據(jù)。這樣，她就可以用這一收據(jù)換取現(xiàn)金。是否插入貯藏物品屬于一個用例，而索取收據(jù)屬于另一個用例？或者，以上過程只是一個用例？此過程有兩個動作，缺少了任何一個，另一個動作都對客戶沒有任何意義。所以，應(yīng)該將所有插入和獲取收據(jù)當(dāng)作一個完整對話，這樣才對客戶有意義。因而，從插入第一個貯藏物品到按下按鈕獲得收據(jù)的完整對話過程是一個完整的用例，也就是一個用例。此外，最好將這兩個動作連在一起，這樣就可以同時對它們進行復(fù)審、修改、測試、為它們編寫手冊，并且在一般情況下將它們當(dāng)作一個單元來管理。在大型系統(tǒng)中，明顯需要這樣處理。6.用例如何實現(xiàn)用例可以說明當(dāng)主角通過與系統(tǒng)交互來執(zhí)行該用例時在系統(tǒng)中發(fā)生的事件。至于系統(tǒng)如何在內(nèi)部利用協(xié)作對象來執(zhí)行任務(wù)，用例并不加以定義。這將由用例實現(xiàn)來說明。示例：以打電話為示例，用例會說明以下內(nèi)容：當(dāng)呼叫方拿起聽筒時，系統(tǒng)將發(fā)出一個信號，然后，系統(tǒng)會接收數(shù)字輸入、查找接收方、使接收方的電話振鈴、接通電話、傳送語音等等。在執(zhí)行系統(tǒng)中，用例實例并不對應(yīng)于實施模型中的任何特定對象（例如，代碼中類的實例）。它所對應(yīng)的是特定的事件流，該事件流由主角調(diào)用并且作為一組對象中的一個事件序列來執(zhí)行。也就是說，用例實例對應(yīng)于被實施對象的通信實例。我們將其稱為用例的實現(xiàn)。通常，相同的對象會參與多個用例的實現(xiàn)。例如，銀行業(yè)務(wù)系統(tǒng)中的“存款”用例和“取款”用例可能在它們的實現(xiàn)中同時使用某個特定的帳戶對象。這并不表示這兩個用例可以相互通信，它們只是在它們的用例實現(xiàn)中使用了相同的對象。您可以認(rèn)為一個事件流是由幾個分支流構(gòu)成的，這幾個分支流組合到一起就形成了總的事件流。您還可以在其他用例的事件流中復(fù)用某個分支流的說明。一個用例事件流說明中的分支流可能是其他用例事件流說明中所共有的分支流。在進行設(shè)計時，應(yīng)該讓相同的對象來執(zhí)行全部相關(guān)用例所共有的行為；也就是說，無論正在執(zhí)行哪個用例，只應(yīng)該有一組對象執(zhí)行來這一行為。示例：在自動取款機系統(tǒng)中，“取款”用例和“核對余額”用例的事件流中的初始分支流是相同的。這兩個用例的事件流都從檢查卡標(biāo)識和客戶的個人訪問代碼開始。7.一個用例具有許多可能的實例一個用例實例幾乎可以遵循無限多的路徑，但這些路徑仍然可以計數(shù)。路徑代表了用例事件流說明中的用例實例可以選擇的各種方案。路徑的選擇取決于事件。事件類型包括：來自主角的輸入。例如，主角可以從幾個選項中決定下一步應(yīng)該做什么。示例：在自動柜員機系統(tǒng)的“取款”用例中，如果客戶要求提取的金額大于他的帳戶金額，事件流就會有所不同。因而，用例實例將遵循不同的路徑。8.名稱每個用例都應(yīng)有一個名稱，以表明它與主角進行交互的結(jié)果。名稱應(yīng)該是“動詞+名詞”，使用便于理解的單詞。用例名稱不應(yīng)重復(fù)。示例：回收機示例中的“回收貯藏物品”用例可以具有以下的不同名稱：◆接收貯藏物品◆正在接收貯藏物品◆返回貯藏物品◆貯藏物品9.簡要說明用例的簡要說明應(yīng)反映用例的角色和目的。在撰寫說明時，應(yīng)參考用例中所涉及的主角、詞匯表，并根據(jù)需要定義新概念。示例：以下是回收機系統(tǒng)中“回收貯藏物品”用例和“添加新的瓶類型”用例的簡要說明示例：回收貯藏物品：用戶使用本機器來自動統(tǒng)計所有回收物品（瓶子、罐子以及箱子），并得到一張收據(jù)。收據(jù)將在收銀機處兌現(xiàn)。添加新的瓶類型：在“學(xué)習(xí)模式”中啟動機器，然后與返回回收物品時一樣插入5個樣本，從而將瓶子的新類型添加到機器中。這樣，回收機就能夠測量這些瓶子，并知道如何識別它們。管理人員指定新的瓶類型的返款額。10.事件流-內(nèi)容用例事件流包含用例建模工作所得到的最重要的信息。應(yīng)該清楚地說明用例的事件流，讓外行也能很容易地理解它。請記住，事件流應(yīng)該說明系統(tǒng)做什么，而不是說明為了執(zhí)行所需的行為而對系統(tǒng)進行的設(shè)計。以下提供了有關(guān)事件流內(nèi)容的指南：1)說明用例如何開始和結(jié)束2)說明在主角和用例之間交換的是什么數(shù)據(jù)3)不要詳細(xì)描述用戶界面，除非要理解系統(tǒng)行為就必須詳細(xì)了解用戶界面。例如，如果事先知道應(yīng)用程序?qū)⒒赪eb，那么最好使用一組有限的Web專用術(shù)語。否則，您的讀者就可能認(rèn)為用例文本過于抽象。您可以在術(shù)語中包括這些詞語：“導(dǎo)航”、“瀏覽”、“超鏈接”、“頁”、“提交”和“瀏覽器”。不過，引用“框架”或“Web頁”時最好不要造成對兩者之間界限進行臆測的效果。這是一項關(guān)鍵的設(shè)計決策。4)說明事件流，而不只是功能。為了做到這一點，每個動作都應(yīng)從“當(dāng)主角...時”開始5)只說明屬于該用例的事件，而不是發(fā)生在其他用例中或系統(tǒng)外部的事件6)避免不明確的術(shù)語，如“例如”、“等等”和“信息”7)詳細(xì)說明事件流，即回答所有包含“什么”的問題。請記住，測試設(shè)計人員將使用此文本來確定測試用例。如果您已經(jīng)在其他用例中使用了某些特定術(shù)語，則務(wù)必要在此用例中使用完全相同的術(shù)語，并確保它們表達相同的含義。為了管理常用術(shù)語，應(yīng)該將它們放入一個詞匯表。11.事件流-結(jié)構(gòu)事件流的兩個主要部分是基本事件流和備選事件流?；臼录鲬?yīng)包括在執(zhí)行用例時“通?！睍l(fā)生的事件。備選事件流包括與正常行為相關(guān)的可選或異常特征的行為，同時也包括正常行為的各種變形。您可以將備選事件流看作是基本事件流的“繞行道”，有些備選事件流將返回到基本事件流，而有些將結(jié)束此用例的執(zhí)行。事件流的典型結(jié)構(gòu)。直線箭頭代表基本事件流，而曲線則代表與正常行為相關(guān)的備選事件流。有些備選路徑返回到基本事件流，而其他備選路徑則結(jié)束此用例。應(yīng)該將基本事件流和備選事件流進一步構(gòu)建為步驟或分支流。為進行構(gòu)建時，您的主要目標(biāo)應(yīng)該是文本的可讀性。這里的經(jīng)驗法則是，分支流應(yīng)該是用例中的一個行為段，該行為段必須具有明確目的并且“不可分”（也就是說，要么執(zhí)行所述的全部動作，要么不一個也不執(zhí)行）。您可能會需要使用幾個級別的分支流，但應(yīng)盡量避免這樣，因為多個級別的分支流會使文本更為復(fù)雜、更難于理解。可以用活動圖來說明事件流的結(jié)構(gòu)。這種書面文本分為連續(xù)的小節(jié)，這本身就向讀者提示：分支流之間存在一定順序。為了避免誤解，始終應(yīng)該指出分支流的順序是否是固定的。這種考慮事項通常與以下內(nèi)容相關(guān)：◆業(yè)務(wù)規(guī)則。例如，在系統(tǒng)可以使某些數(shù)據(jù)可用之前，用戶必須得到授權(quán)?！粲脩艚缑嬖O(shè)計。例如，系統(tǒng)不應(yīng)強制行為的某個特定順序，該序列對于某些用戶可能是顯而易見的，但對于其他用戶卻并非如此。為了闡明備選事件流在結(jié)構(gòu)中的合適位置，需要為基本事件流的每條“繞行道”說明以下內(nèi)容：◆基本事件流中可以插入備選行為的位置。◆為使備選行為開始而需要滿足的條件?！艋臼录髦匦麻_始的方式和位置，或者用例結(jié)束的方式。示例：在回收機系統(tǒng)的“回收貯藏物品”用例中有一個備選分支流。2.1.瓶子阻塞在基本事件流“插入貯藏物品”中，如果一個瓶子被卡在入口處，入口周圍的傳感器和測量門將檢測到這個問題。傳送帶停止傳送，機器發(fā)出警報，讓操作人員來解決問題?；厥諜C將一直等待，直到操作人員指示問題已得到解決。然后，回收機從基本事件流的某一位置繼續(xù)工作。在上例中，備選事件流插入了基本事件流中的一個特定位置。有些備選事件流也可以在多個位置插入，一些備選事件流甚至可以在基本事件流中的任意位置插入。示例：在回收機系統(tǒng)的“回收貯藏物品”用例中有一個備選分支流：2.2.前面板被取走如果有人將回收機的前面板取走，將使罐子壓縮功能不可用。沒有前面板就無法啟動罐子壓縮操作。取走前面板的同時將激活向操作人員發(fā)出的警報。當(dāng)重新安裝好前面板時，回收機又將從它在基本事件流中停止的位置恢復(fù)操作。如果備選事件流非常簡單，您可能想就在基本事件流部分對其進行說明（使用某種不正式的“if-then-else"結(jié)構(gòu)）。但應(yīng)該避免這樣。太多的備選事件流將使正常行為難于識別。而且，如果在基本事件流部分包括備選路徑，將使文本更加“類似于偽代碼”，從而會降低文本的可讀性。通常，如果抽取事件流的各個部分并且分別對這些部分進行說明，就可以增加基本事件流的可讀性，并改進用例和用例模型的結(jié)構(gòu)。您可以將抽取的部分建模為：◆基本用例中的一個備選事件流（如果抽取的部分是一個簡單變量、選項或基本事件流的例外情況）。◆基本用例中的明確包含項（如果您希望將抽取的部分封裝，以便其他用例復(fù)用）?！艋居美械碾[含包含項（如果基本用例具有完整的基本事件流，即具有確定的開始和結(jié)尾）。使用擴展流的情況應(yīng)該是：您希望將其隱藏在基本用例的說明中，以降低該說明的復(fù)雜性?！艋臼录髦械姆种Я?，并可能作為另一個選項（如果以上方案都不適用）。例如，在“維護雇員信息”用例中，可能有單獨的分支流分別用于添加、刪除和修改雇員信息。12.事件流-風(fēng)格可以按照多種風(fēng)格來說明用例。作為示例，我們將以三種不同的風(fēng)格來說明“管理訂單”用例的基本事件流，它們的主要區(qū)別在于正式程度不同。第一種風(fēng)格（如下面的示例1所示）易于理解、條理清晰，所以是推薦使用的風(fēng)格。文本分為帶有編號和名稱的各個小節(jié)。這些編號便于對小節(jié)進行引用。小節(jié)名稱使讀者只需瀏覽文本的標(biāo)題就可迅速地獲得對從事件流的總體了解。在下面的示例2中，事件流的說明沒有闡明事件發(fā)生的順序。如果以這種風(fēng)格撰寫，您和其他人都可能會錯過一些與系統(tǒng)相關(guān)的重要信息。下面的示例3顯示了另外一種風(fēng)格。如果您覺得很難清楚地表示事件的序列，就可以采用這種風(fēng)格。這種偽代碼風(fēng)格更為準(zhǔn)確，但非技術(shù)人員在閱讀和理解這種文本時會有困難，尤其是在需要快速領(lǐng)會事件流時。示例1：1.1.用例開始當(dāng)主角操作員通知系統(tǒng)創(chuàng)建一個評測訂單時，用例開始。然后，系統(tǒng)將檢索所有的網(wǎng)絡(luò)元素主角、它們的測評對象以及特定操作員可以使用的相應(yīng)測評功能?？捎玫木W(wǎng)絡(luò)元素是那些正在運行的網(wǎng)絡(luò)元素和操作員有權(quán)訪問的網(wǎng)絡(luò)元素。測評功能的可用性依賴于為某一特定類型的測評對象所設(shè)置的評測功能。1.2.配置測評訂單系統(tǒng)讓操作員主角選擇要評測的網(wǎng)絡(luò)元素，然后將顯示所選網(wǎng)絡(luò)元素可以使用的測評對象。系統(tǒng)讓操作員從這些評測對象中進行選擇，然后選擇需要為每個評測對象設(shè)置的評測功能。系統(tǒng)讓操作員輸入對評測訂單的文本注釋。操作員通知系統(tǒng)完成評測訂單。系統(tǒng)將作出以下響應(yīng)：為該評測訂單生成一個唯一的名稱，并設(shè)置評測開始時間、評測重復(fù)頻率和評測持續(xù)時間的默認(rèn)值。對于每個操作員，這些默認(rèn)值都是唯一的。然后，系統(tǒng)讓操作員編輯這些默認(rèn)值。1.3.初始化訂單操作員通知系統(tǒng)初始化評測訂單。系統(tǒng)將記錄創(chuàng)建操作員的身份、創(chuàng)建日期以及測評訂單的“預(yù)定”狀態(tài)。1.4.用例結(jié)束系統(tǒng)向該操作員確認(rèn)已對測評訂單進行了初始化，其他主角在此時可以看到該測評訂單。用例說明：在這種風(fēng)格中，文本易于閱讀，事件流易于理解。在說明中應(yīng)盡量采用這種風(fēng)格。示例2：為了從網(wǎng)絡(luò)元素中收集評測數(shù)據(jù)，訂貨人可以創(chuàng)建訂單。系統(tǒng)將給該訂單分配一個唯一的名稱，并指定評測持續(xù)時間和評測開始時間和評測重復(fù)頻率的默認(rèn)值。訂貨人將能夠編輯這些默認(rèn)值。訂貨人必須進一步指定適用的評測功能、網(wǎng)絡(luò)元素和評測對象。訂貨人還可以在訂單上添加個人注釋。定義了必要的信息之后，將創(chuàng)建一個新的訂單并使用已定義的屬性、創(chuàng)建者姓名和創(chuàng)建日期來將這一新訂單初始化。該訂單的狀態(tài)將被設(shè)置為“預(yù)定”。（可能的狀態(tài)值包括：預(yù)定、執(zhí)行、完成、取消和錯誤。）然后，用戶界面將得到已創(chuàng)建新訂單的通知，同時會接收到對該新訂單的引用，該引用可用來顯示新訂單。用例說明：這種風(fēng)格具有可讀性，但事件流都不清晰。示例3：'管理訂單'（用戶身份）REPEAT<='顯示管理訂單菜單'IF(=>'創(chuàng)建訂單'（評測功能，網(wǎng)絡(luò)元素，評測對象）)THEN系統(tǒng)查找唯一的名稱、評測開始時間和持續(xù)時間的默認(rèn)值。<='顯示訂單'（默認(rèn)屬性）REPEAT=>'編輯訂單'（要更改的屬性，屬性的新值）<='屏幕刷新'（新屬性）UNTIL（定義了所有的屬性）REPEATIF(=>'編輯訂單'（要更改的屬性，屬性的新值）)THEN<='屏幕刷新'（新屬性）ELSIF(=>'保存訂單'（訂單標(biāo)識，屬性）)THEN在系統(tǒng)中創(chuàng)建訂單，并使用已定義的屬性、創(chuàng)建者的姓名、創(chuàng)建日期和“預(yù)定”狀態(tài)將訂單初始化。<='創(chuàng)建的新訂單'（訂單）ENDIFUNTIL(=>'退出')ENDIFUNTIL'退出管理訂單'用例說明：編寫員在上例中選擇了一種使用偽代碼的正式風(fēng)格。這種風(fēng)格會使讀者難于快速領(lǐng)會流程步驟，但在不容易準(zhǔn)確獲取事件流的情況下，這種風(fēng)格相當(dāng)有用。13.事件流-示例“管理訂單”用例事件流的完整說明（包括其備選流）可能如下所示：1.基本事件流1.1.用例開始當(dāng)主角操作員通知系統(tǒng)創(chuàng)建一個評測訂單時，用例開始。然后，系統(tǒng)將檢索所有的網(wǎng)絡(luò)元素主角、它們的測評對象以及特定操作員可以使用的相應(yīng)測評功能。可用的網(wǎng)絡(luò)元素是那些正在運行的網(wǎng)絡(luò)元素和操作員有權(quán)訪問的網(wǎng)絡(luò)元素。測評功能的可用性依賴于為某一特定類型的測評對象所設(shè)置的評測功能。1.2.配置測評訂單系統(tǒng)讓操作員主角選擇要評測的網(wǎng)絡(luò)元素，然后將顯示所選網(wǎng)絡(luò)元素可以使用的測評對象。系統(tǒng)讓操作員從這些測評對象中進行選擇，然后選擇需要為每個測評對象設(shè)置的測評功能。系統(tǒng)讓操作員輸入對評測訂單的文