需求工程過程

需求工程過程第1頁，課件共43頁，創(chuàng)作于2023年2月迭代模型與瀑布模型的差別第2頁，課件共43頁，創(chuàng)作于2023年2月需求開發(fā)過程需求開發(fā)是一個(gè)迭代的過程第3頁，課件共43頁，創(chuàng)作于2023年2月需求工程的推薦方法列出了近50種方法，分別屬于7個(gè)類型，它們可以幫助大部分項(xiàng)目開發(fā)團(tuán)隊(duì)更好地完成他們的需求工作。第4頁，課件共43頁，創(chuàng)作于2023年2月知識需求管理項(xiàng)目管理培訓(xùn)需求分析員對用戶代表和管理者進(jìn)行需求培訓(xùn)對開發(fā)者進(jìn)行應(yīng)用領(lǐng)域相關(guān)的培訓(xùn)創(chuàng)建術(shù)語表定義需求變更控制進(jìn)程成立變更控制委員會分析需求變更的影響控制需求版本并為其建立基線維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性使用需求管理工具創(chuàng)建需求跟蹤矩陣選擇合適的開發(fā)周期根據(jù)需求制訂項(xiàng)目計(jì)劃重新協(xié)商權(quán)利或義務(wù)管理需求風(fēng)險(xiǎn)跟蹤需求耗費(fèi)的人力物力回顧以往的教訓(xùn)需求獲取需求分析編寫規(guī)格說明需求驗(yàn)證定義需求開發(fā)過程定義項(xiàng)目前景和范圍確定用戶群選擇用戶代言人建立核心隊(duì)伍確定用例確定系統(tǒng)事件和響應(yīng)舉行進(jìn)一步需求獲取的討論觀察用戶如何工作檢查問題報(bào)告重用需求繪制關(guān)聯(lián)圖創(chuàng)建原型分析可行性確定需求優(yōu)先級為需求建模創(chuàng)建數(shù)據(jù)字典將需求分配至各子系統(tǒng)應(yīng)用質(zhì)量功能調(diào)度采用SRS模板確定需求來源惟一標(biāo)識每項(xiàng)需求記錄業(yè)務(wù)規(guī)范定義質(zhì)量屬性審查需求文檔測試需求確定合格標(biāo)準(zhǔn)第5頁，課件共43頁，創(chuàng)作于2023年2月知識技能開發(fā)者也應(yīng)該了解產(chǎn)品應(yīng)用領(lǐng)域中的基本概念和術(shù)語。培訓(xùn)需求分析員所有將要成為分析員的團(tuán)隊(duì)成員都應(yīng)該接受需求工程方面的基本培訓(xùn)。熟練的需求分析員應(yīng)具備以下特點(diǎn)：耐心，思維條理性強(qiáng)，有良好的交際和溝通能力，理解產(chǎn)品應(yīng)用領(lǐng)域，并且掌握豐富的需求工程技術(shù)。對用戶代表和管理者進(jìn)行軟件需求培訓(xùn)參與軟件開發(fā)的用戶應(yīng)該接受一到兩天的需求工程方面的培訓(xùn)。對開發(fā)人員進(jìn)行應(yīng)用領(lǐng)域的相關(guān)培訓(xùn)為了幫助開發(fā)人員對應(yīng)用領(lǐng)域有一個(gè)基本的理解，可以安排一個(gè)研討課程，內(nèi)容是客戶的業(yè)務(wù)活動、術(shù)語和產(chǎn)品的目標(biāo)。創(chuàng)建項(xiàng)目術(shù)語表定義應(yīng)用領(lǐng)域?qū)I(yè)名稱的術(shù)語表可以減少誤解。第6頁，課件共43頁，創(chuàng)作于2023年2月需求獲取需求獲取(requirementelicitation)是需求工程的主體。對于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不同用戶類的需要和限制的過程。需求獲取可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶—開發(fā)者的合作才能成功。需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個(gè)必不可少的結(jié)果是對項(xiàng)目中描述的客戶需求的普遍理解。第7頁，課件共43頁，創(chuàng)作于2023年2月需求獲取第1章討論了需求的三個(gè)層次：業(yè)務(wù)，用戶和功能。在項(xiàng)目中它們在不同的時(shí)間來自不同的來源，也有著不同的目標(biāo)和對象，并需以不同的方式編寫成文檔。業(yè)務(wù)需求（或產(chǎn)品視圖和范圍）不應(yīng)包括用戶需求（或使用實(shí)例），而所有的功能需求都應(yīng)該源于用戶需求。同時(shí)你也需要獲取非功能需求，如質(zhì)量屬性。1)確定需求開發(fā)過程確定如何組織需求的收集、分析、細(xì)化并核實(shí)的步驟，并將它編寫成文檔。對重要的步驟要給予一定指導(dǎo)，這將有助于分析人員的工作，而且也使收集需求活動的安排和進(jìn)度計(jì)劃更容易進(jìn)行。2)編寫項(xiàng)目視圖和范圍文檔

項(xiàng)目視圖和范圍文檔應(yīng)該包括高層的產(chǎn)品業(yè)務(wù)目標(biāo)，所有的使用實(shí)例和功能需求都必須遵從能達(dá)到的業(yè)務(wù)需求。項(xiàng)目視圖說明使所有項(xiàng)目參與者對項(xiàng)目的目標(biāo)能達(dá)成共識。而范圍則是作為評估需求或潛在特性的參考。3)將用戶群分類并歸納各自特點(diǎn)為避免出現(xiàn)疏忽某一用戶群需求的情況，要將可能使用產(chǎn)品的客戶分成不同組別。他們可能在使用頻率、使用特性、優(yōu)先等級或熟練程度等方面都有所差異。詳細(xì)描述出它們的個(gè)性特點(diǎn)及任務(wù)狀況，將有助于產(chǎn)品設(shè)計(jì)。第8頁，課件共43頁，創(chuàng)作于2023年2月4)選擇每類用戶的產(chǎn)品代表

5)建立起典型用戶的核心隊(duì)伍

6)讓用戶代表確定使用實(shí)例從用戶代表處收集他們使用軟件完成所需任務(wù)的描述—使用實(shí)例，討論用戶與系統(tǒng)間的交互方式和對話要求。在編寫使用實(shí)例的文檔時(shí)可采用標(biāo)準(zhǔn)模版，在使用實(shí)例基礎(chǔ)上可得到功能需求。7)召開應(yīng)用程序開發(fā)聯(lián)系（JAD）會議應(yīng)用程序開發(fā)聯(lián)系（JAD）會議是范圍廣的、簡便的專題討論會（workshop），也是分析人員與客戶代表之間一種很好的合作辦法，并能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客戶與開發(fā)人員間的合作伙伴關(guān)系付諸于實(shí)踐第9頁，課件共43頁，創(chuàng)作于2023年2月8)分析用戶工作流程觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過程9)確定質(zhì)量屬性和其它非功能需求10)通過檢查當(dāng)前系統(tǒng)的問題報(bào)告來進(jìn)一步完善需求11)跨項(xiàng)目重用需求。調(diào)查用戶任務(wù)可能遇到的變更，或者用戶需要使用系統(tǒng)其它可能的方式。想像你自己在學(xué)習(xí)用戶的工作，你需要完成什么任務(wù)？你有什么問題？從這一角度來指導(dǎo)需求的開發(fā)和利用。還有，探討例外的情況：什么會妨礙用戶順利完成任務(wù)？對系統(tǒng)錯誤情況的反映，用戶是如何想的？詢問問題時(shí)，以“還有什么能??”,”當(dāng)??時(shí)，將會發(fā)生什么”“你有沒有曾經(jīng)想過??”,“有沒有人曾經(jīng)??”為開頭。記下每一個(gè)需求的來源，這樣向下跟蹤直到發(fā)現(xiàn)特定的客戶。第10頁，課件共43頁，創(chuàng)作于2023年2月需求分析分析:通過對問題域的研究,獲得對該領(lǐng)域特性及存在于其中(需要解決)的問題特性的透徹理解并用文檔說明.需求分析（requirementanalysis）包括提煉、分析和仔細(xì)審查已收集到的需求，以確保所有的風(fēng)險(xiǎn)承擔(dān)者都明白其含義并找出其中的錯誤、遺漏或其它不足的地方。分析員通過評價(jià)來確定是否所有的需求和軟件需求規(guī)格說明都達(dá)到了優(yōu)秀需求說明的要求。分析的目的在于開發(fā)出高質(zhì)量和具體的需求，這樣你就能作出實(shí)用的項(xiàng)目估算并可以進(jìn)行設(shè)計(jì)、構(gòu)造和測試.通常，把需求中的一部分用多種形式來描述，如同時(shí)用文本和圖形來描述。分析這些不同的視圖將揭示出一些更深的問題，這是單一視圖無法提供的。分析還包括與客戶的交流以澄清某些易混淆的問題，并明確哪些需求更為重要。其目的是確保所有風(fēng)險(xiǎn)承擔(dān)者盡早地對項(xiàng)目達(dá)成共識并對將來的產(chǎn)品有個(gè)相同而清晰的認(rèn)識。第11頁，課件共43頁，創(chuàng)作于2023年2月1)繪制系統(tǒng)關(guān)聯(lián)圖這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡單模型。同時(shí)它也明確了通過接口的信息流和物質(zhì)流。2)創(chuàng)建用戶接口原型當(dāng)開發(fā)人員或用戶不能確定需求時(shí)，開發(fā)一個(gè)用戶接口原型—一個(gè)可能的局部實(shí)現(xiàn)—這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價(jià)原型將使項(xiàng)目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。3)分析需求可行性在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性，明確與每項(xiàng)需求實(shí)現(xiàn)相聯(lián)系的風(fēng)險(xiǎn)，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙。4)確定需求的優(yōu)先級別應(yīng)用分析方法來確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。當(dāng)允許需求變更時(shí)，在特定的版本中加入每一項(xiàng)變更，并在那個(gè)版本計(jì)劃中作出需要的變更。第12頁，課件共43頁，創(chuàng)作于2023年2月5)為需求建立模型需求的圖形分析模型是軟件需求規(guī)格說明極好的補(bǔ)充說明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。6)創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項(xiàng)以確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語。分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。7)使用質(zhì)量功能調(diào)配質(zhì)量功能調(diào)配(QFD）是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。期望需求；普通需求；興奮需求.第13頁，課件共43頁，創(chuàng)作于2023年2月規(guī)格說明無論你的需求從何而來，也不管你是怎樣得到的，你都必須用一種統(tǒng)一的方式來將它們編寫成可視文檔。業(yè)務(wù)需求要寫成項(xiàng)目視圖和范圍文檔。用戶需求要用一種標(biāo)準(zhǔn)使用實(shí)例模板編寫成文檔。而軟件需求規(guī)格說明（requirementspecification）則包含了軟件的功能需求和非功能需求。你必須為每項(xiàng)需求明確建立標(biāo)準(zhǔn)的慣例，并確定在SRS中采用任何慣例，以確保SRS的統(tǒng)一風(fēng)格，同時(shí)讀者也會明白怎樣解釋它。第14頁，課件共43頁，創(chuàng)作于2023年2月1)采用SRS模板在你的組織中要為編寫軟件需求文檔定義一種標(biāo)準(zhǔn)模板。該模板為記錄功能需求和各種其它與需求相關(guān)的重要信息提供了統(tǒng)一的結(jié)構(gòu)。2)指明需求的來源為了讓所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者明白SRS中為何提供這些功能需求，要都能追溯每項(xiàng)需求的來源，這可能是一種使用實(shí)例或其它客戶要求，也可能是某項(xiàng)更高層系統(tǒng)需求、業(yè)務(wù)規(guī)范、政府法規(guī)、標(biāo)準(zhǔn)或別的外部來源。3)為每項(xiàng)需求注上標(biāo)號制定一種慣例來為SRS中的每項(xiàng)需求提供一個(gè)獨(dú)立的可識別的標(biāo)號或記號。這種慣例應(yīng)當(dāng)很健全，允許增加、刪除和修改。作了標(biāo)號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態(tài)和變更活動建立度量。4)記錄業(yè)務(wù)規(guī)范業(yè)務(wù)規(guī)范是指關(guān)于產(chǎn)品的操作原則，比如誰能在什么情況下采取什么動作。將這些編寫成SRS中的一個(gè)獨(dú)立部分，或一獨(dú)立的業(yè)務(wù)規(guī)范文檔。某些業(yè)務(wù)規(guī)范將引出相應(yīng)的功能需求；當(dāng)然這些需求也應(yīng)能追溯相應(yīng)業(yè)務(wù)規(guī)范。5)創(chuàng)建需求跟蹤能力矩陣建立一個(gè)矩陣把每項(xiàng)需求與實(shí)現(xiàn)、測試它的設(shè)計(jì)和代碼部分聯(lián)系起來。這樣的需求跟蹤能力矩陣同時(shí)也把功能需求和高層的需求及其它相關(guān)需求聯(lián)系起來了。在開發(fā)過程中建立這個(gè)矩陣，而不要等到最后才去補(bǔ)建。第15頁，課件共43頁，創(chuàng)作于2023年2月人機(jī)接口設(shè)計(jì)人機(jī)接口HMI面向人的或其他的系統(tǒng)第16頁，課件共43頁，創(chuàng)作于2023年2月需求驗(yàn)證驗(yàn)證是為了確保需求說明準(zhǔn)確、完整地表達(dá)必要的質(zhì)量特點(diǎn)。而且能夠滿足客戶的需要。審查需求文檔對需求文檔進(jìn)行正式審查是保證軟件質(zhì)量的有效手段之一。測試需求根據(jù)用戶需求推導(dǎo)出功能測試用例，以便記錄產(chǎn)品在特定條件下應(yīng)有的行為。定義合格標(biāo)準(zhǔn)讓用戶描述決定產(chǎn)品是否滿足他們的需求并適合使用的標(biāo)準(zhǔn)。第17頁，課件共43頁，創(chuàng)作于2023年2月1)審查需求文檔2)以需求為依據(jù)編寫測試用例3)編寫用戶手冊4)確定合格的標(biāo)準(zhǔn)第18頁，課件共43頁，創(chuàng)作于2023年2月需求管理有了項(xiàng)目的初步需求，就必須處理好開發(fā)過程中不可避免的來自客戶、管理層、營銷部門、開發(fā)團(tuán)隊(duì)以及其他群體的變更請求。定義需求變更控制過程建立一個(gè)用于提議、分析和解決需求變更的過程。成立變更控制委員會可授權(quán)由涉眾組成的小組作為變更控制委員會(CCB)來接收需求變更的請求。分析需求變更的影響對影響進(jìn)行分析有助于CCB做出明智的業(yè)務(wù)決策。建立基線和控制需求文檔的版本基線是由已經(jīng)被提交到一個(gè)指定版本中的實(shí)現(xiàn)(implementation)的需求組成的。第19頁，課件共43頁，創(chuàng)作于2023年2月需求管理維護(hù)需求變更的歷史記錄記錄需求規(guī)格說明變更的日期、變更的內(nèi)容、變更的實(shí)施者和原因。跟蹤每項(xiàng)需求的狀態(tài)建立一個(gè)數(shù)據(jù)庫，為每一項(xiàng)功能需求保存一條記錄。衡量需求的穩(wěn)定性記錄已設(shè)為基線的需求數(shù)，以及每周提議和批準(zhǔn)的需求的變更(增加，修改，刪除)數(shù)。使用需求管理工具商業(yè)需求管理工具可用于在數(shù)據(jù)庫中存儲各種類型的需求。創(chuàng)建需求跟蹤矩陣建立一個(gè)表，把每項(xiàng)功能需求和實(shí)現(xiàn)它的設(shè)計(jì)和代碼部分、驗(yàn)證它的測試部分聯(lián)系起來。第20頁，課件共43頁，創(chuàng)作于2023年2月項(xiàng)目管理軟件項(xiàng)目管理方法和項(xiàng)目的需求過程密切相關(guān)。應(yīng)根據(jù)需要實(shí)現(xiàn)的需求來規(guī)劃項(xiàng)目資源、進(jìn)度和承諾。選擇合適的軟件開發(fā)生命周期組織應(yīng)該定義多種開發(fā)生命周期，以適應(yīng)不同的項(xiàng)目類型和不同程度的需求不確定性(McConnell1996)。根據(jù)需求制訂項(xiàng)目計(jì)劃當(dāng)范圍和詳細(xì)的需求變得清楚時(shí)，應(yīng)反復(fù)斟酌項(xiàng)目的計(jì)劃和進(jìn)度表。第21頁，課件共43頁，創(chuàng)作于2023年2月項(xiàng)目管理需求變更時(shí)重新討論項(xiàng)目承諾將新的需求合并到項(xiàng)目中時(shí)，應(yīng)估計(jì)一下你是否仍然可以利用可用資源兌現(xiàn)當(dāng)前的進(jìn)度和質(zhì)量承諾。管理與需求相關(guān)的風(fēng)險(xiǎn)以及編寫風(fēng)險(xiǎn)文檔確定與需求相關(guān)的風(fēng)險(xiǎn)并將它們編寫成文檔是項(xiàng)目風(fēng)險(xiǎn)管理活動的一部分。跟蹤需求工程的投入記錄下你的團(tuán)隊(duì)在需求開發(fā)和管理活動上投入的工作量。從其他項(xiàng)目的需求工程中積累經(jīng)驗(yàn)組建一個(gè)學(xué)術(shù)研究組織專門管理項(xiàng)目回顧(也稱為項(xiàng)目的審閱)以收集有價(jià)值的信息。第22頁，課件共43頁，創(chuàng)作于2023年2月開始新實(shí)踐將本章中描述的需求工程方法，按照對大多數(shù)項(xiàng)目的相對影響以及實(shí)現(xiàn)的相對難度進(jìn)行分組。

第23頁，課件共43頁，創(chuàng)作于2023年2月影響難度高中低高

l

定義需求開發(fā)過程

l

以

需求為基礎(chǔ)制定計(jì)劃

l

重新討論項(xiàng)目承諾

l

確定用例

l

指定質(zhì)量屬性

l

確定需求優(yōu)先級

l

采用SRS模板

l

定義變更控制過程

l

建立CCB

l

審查需求文檔

l

給子系統(tǒng)分配需求

l

記錄業(yè)務(wù)規(guī)則

l

在

應(yīng)用領(lǐng)域培養(yǎng)開發(fā)者

l

定義項(xiàng)目前景和范圍

l

用戶群分類

l

繪制關(guān)聯(lián)圖

l

確定需用求來源

l

建立需求基線和控制版本

l

對用戶群和管理者進(jìn)行需求培訓(xùn)

l

為需求建立模型

l

管理需求風(fēng)險(xiǎn)

l

使用需求管理工具

l

創(chuàng)

建需求跟蹤能力矩陣

l

召開需求獲取討論會

l

培訓(xùn)需求分析員

l

選擇用戶代言人

l

建立核心隊(duì)伍

l

創(chuàng)建原型

l

定義合格標(biāo)準(zhǔn)

l

進(jìn)行變更影響分析

l

選擇適當(dāng)?shù)拈_發(fā)周期

l

分析可行性

l

創(chuàng)建術(shù)語表

l

編寫數(shù)據(jù)字典

l

觀察用戶執(zhí)行工作的過程

l

確定系統(tǒng)事件及響應(yīng)

l

為每項(xiàng)需求注上惟一的標(biāo)號

l

測試需求

l

跟蹤需求狀態(tài)

l

回顧過去的經(jīng)驗(yàn)教訓(xùn)

低

l

重用需求

l

應(yīng)用質(zhì)量功能調(diào)配

l

衡量需求穩(wěn)定性

l

維

護(hù)需求變更的歷史記錄

l

跟蹤投入需求工程中的工作量

l

檢查問題報(bào)告

第24頁，課件共43頁，創(chuàng)作于2023年2月需求過程的改進(jìn)第25頁，課件共43頁，創(chuàng)作于2023年2月1需求與其他項(xiàng)目過程的聯(lián)系需求是每個(gè)軟件項(xiàng)目成功的核心所在，它支持其他技術(shù)活動和管理活動。對需求開發(fā)方法和需求管理方法的變更會對項(xiàng)目的其他過程產(chǎn)生影響，反之亦然。圖1演示了需求和其他過程之間的某些連接，下面簡要介紹一下這些過程之間的接口。項(xiàng)目規(guī)劃

需求是項(xiàng)目規(guī)劃過程的基

礎(chǔ)。第26頁，課件共43頁，創(chuàng)作于2023年2月需求與其他項(xiàng)目過程的聯(lián)系

項(xiàng)目跟蹤和控制項(xiàng)目跟蹤包括監(jiān)視每一個(gè)需求的狀態(tài)。變更控制將一組需求集確定為基線之后，以后的所有變更都應(yīng)該通過一個(gè)預(yù)先定義好的變更控制過程來完成，這一過程有助于確保：理解所提議的變更產(chǎn)生的影響。由合適的人選作出接受變更的正式?jīng)Q定。所有受變更影響的人得到關(guān)于發(fā)生變更的通知。根據(jù)需要對項(xiàng)目資源和所做出的承諾進(jìn)行調(diào)整。保持需求文檔是最新版本，并且是準(zhǔn)確的。系統(tǒng)測試用戶需求和功能性需求是系統(tǒng)測試必不可少的參考依據(jù)。構(gòu)造通過跟蹤需求，可以對從每條需求中衍生出來的特定的軟件設(shè)計(jì)和編碼元素編寫文檔。編寫用戶文檔產(chǎn)品需求是用戶文檔編寫過程的依據(jù)。第27頁，課件共43頁，創(chuàng)作于2023年2月2需求和各涉眾組圖2展示了與軟件開發(fā)組有聯(lián)系的某些項(xiàng)目涉眾，也展示了他們對項(xiàng)目需求工程活動產(chǎn)生的某些影響。第28頁，課件共43頁，創(chuàng)作于2023年2月2需求和各涉眾組當(dāng)軟件開發(fā)團(tuán)隊(duì)變更其需求過程時(shí)，與其他項(xiàng)目涉眾進(jìn)行溝通的接口也會發(fā)生變化。下面列出了可能會遇到的一些抵制情況：變更控制過程可能會被看作是開發(fā)工作的障礙而被丟棄，因此變更工作很難實(shí)施。有些開發(fā)人員認(rèn)為編寫和評審需求文檔純粹是浪費(fèi)時(shí)間的官僚做法，妨礙他們的“真正”工作，即編寫代碼。如果用于客戶支持的費(fèi)用與開發(fā)過程沒有聯(lián)系，那么開發(fā)團(tuán)隊(duì)可能會缺少變更需求的動力。如果改進(jìn)需求過程的目標(biāo)之一是通過創(chuàng)建高質(zhì)量的產(chǎn)品來減少技術(shù)支持費(fèi)用，那么技術(shù)支持經(jīng)理可能會感到很不安。忙碌的客戶有時(shí)會聲稱，他們沒有時(shí)間去從事需求工作。第29頁，課件共43頁，創(chuàng)作于2023年2月3軟件過程改進(jìn)的基本原則應(yīng)該牢記下面4條軟件過程改進(jìn)的原則(Wiegers1996a)：1.過程改進(jìn)應(yīng)該是不斷演化的、連續(xù)的、周期性的不要期望一次就能改進(jìn)全部過程，要知道在第1次嘗試變更時(shí)，可能無法解決所有問題。2.只有人們和組織具有變更的動機(jī)時(shí)才可能實(shí)施變更下面列出了一些典型的問題，也許能為需求過程的變更提供驅(qū)動力：項(xiàng)目超出了最后期限，原因是需求比預(yù)期的擴(kuò)展了很多，也復(fù)雜了很多。開發(fā)人員頻繁加班，原因是直到開發(fā)后期才發(fā)現(xiàn)了引起誤解的需求和表達(dá)不明確的需求。系統(tǒng)測試工作前功盡棄，原因是測試人員并沒有弄清楚產(chǎn)品應(yīng)該做什么。雖然正確的功能都實(shí)現(xiàn)了，但是用戶不滿意，這是由于性能不好、易使用性差或存在其他質(zhì)量缺陷。維護(hù)費(fèi)用很高，因?yàn)榭蛻舻膶Ξa(chǎn)品的許多增強(qiáng)要求沒有在需求獲取階段確定下來。開發(fā)組織名譽(yù)受損，因?yàn)榭蛻舨唤邮芙桓兜能浖?。?0頁，課件共43頁，創(chuàng)作于2023年2月3.過程變更要有的放矢在開始運(yùn)用更好的過程之前，一定要明確變更的目標(biāo)是什么(PotterandSakry2002)。4.將改進(jìn)活動視作小型項(xiàng)目項(xiàng)目的總體計(jì)劃應(yīng)該包括過程改進(jìn)的資源和任務(wù)。與所有項(xiàng)目一樣，改進(jìn)項(xiàng)目也要執(zhí)行計(jì)劃、跟蹤、測量和報(bào)告，只是規(guī)模相應(yīng)地縮小了。第31頁，課件共43頁，創(chuàng)作于2023年2月4過程改進(jìn)周期圖3是一個(gè)有效的過程改進(jìn)周期。這一方法反映了您在執(zhí)行下一個(gè)任務(wù)之前先清楚自己所處位置的重要性；反映了繪制過程路線圖的必要性，以及以往的經(jīng)驗(yàn)在持續(xù)的過程改進(jìn)中的重要性。第32頁，課件共43頁，創(chuàng)作于2023年2月4.1評估當(dāng)前采用的方法所有改進(jìn)活動的第1步都是評估組織當(dāng)前所使用的方法，找出這些方法的優(yōu)點(diǎn)和缺陷。評估當(dāng)前過程的方法有多種。如果我們已經(jīng)試過前幾章末尾的“下一步”，實(shí)際上已經(jīng)開始對需求方法及其結(jié)果進(jìn)行了非正式評估了。設(shè)計(jì)結(jié)構(gòu)化問卷表是一種更系統(tǒng)的方法，它能夠以較低的費(fèi)用對當(dāng)前過程進(jìn)行評估。與團(tuán)隊(duì)成員進(jìn)行面談和討論，可以更準(zhǔn)確更全面地了解當(dāng)前的過程。我們可以采用問卷表來審查組織當(dāng)前采用的需求工程方法。這種自我評估法有助于我們確定哪些需求過程最需要改進(jìn)。第33頁，課件共43頁，創(chuàng)作于2023年2月4.2規(guī)劃改進(jìn)活動戰(zhàn)略性計(jì)劃描述了組織的總體軟件過程改進(jìn)，戰(zhàn)術(shù)性的活動計(jì)劃則描述需要改進(jìn)的專門領(lǐng)域。需求管理改進(jìn)計(jì)劃，它包括下面這些活動條目：1.起草一個(gè)需求變更控制過程草案。2.評審并修訂變更控制過程。3.在項(xiàng)目A中試驗(yàn)變更控制過程。4.根據(jù)試驗(yàn)的反饋信息，修訂變更控制過程。5.評估問題跟蹤工具，并從中選擇一種工具來支持變更控制過程。6.購買并定制問題跟蹤工具以支持變更控制過程。7.在組織中使用新的變更控制過程和工具。第34頁，課件共43頁，創(chuàng)作于2023年2月4.3建立、實(shí)驗(yàn)并實(shí)現(xiàn)新過程實(shí)現(xiàn)活動計(jì)劃意味著開發(fā)一些過程，并相信這些過程比當(dāng)前的工作方式會帶來更好的結(jié)果，但不要期望新的過程第1次試用就很完美。請牢記下面這些關(guān)于指導(dǎo)過程實(shí)驗(yàn)的建議：選擇實(shí)驗(yàn)參與者，他們將嘗試新方法并提供有用的反饋信息。使改進(jìn)過程的結(jié)果容易解釋。確定需要了解實(shí)驗(yàn)情況和實(shí)驗(yàn)原因的有關(guān)涉眾?？紤]在不同的項(xiàng)目中實(shí)驗(yàn)新過程的不同部分，這樣可以使更多的人嘗試新方法，因此提高了了解程度，增加了反饋信息，更易于大家接受。詢問實(shí)驗(yàn)參與者。第35頁，課件共43頁，創(chuàng)作于2023年2月4.4評估結(jié)果過程改進(jìn)周期的最后一步是評估完成的活動和取得的成果，這種評估有助于團(tuán)隊(duì)在未來的改進(jìn)活動中做得更好。評估內(nèi)容包括判斷實(shí)驗(yàn)進(jìn)行得是否順利，在解決新過程的不確定性方面是否有效，下一次指導(dǎo)過程實(shí)驗(yàn)時(shí)是否需要做些變更。同時(shí)還要考慮新過程的總體執(zhí)行情況是否順利，包括新過程或模板的可用性是否有效地傳達(dá)給了每一個(gè)人，參與者是否理解并成功地應(yīng)用了新過程，下次工作中是否需要有所變更等。其中關(guān)鍵的一步是，評估新實(shí)現(xiàn)的過程是否帶來了期望的結(jié)果。第36頁，課件共43頁，創(chuàng)作于2023年2月5需求工程過程資產(chǎn)高性能項(xiàng)目在需求工程的各個(gè)階段(需求獲取、需求分析、編寫需求規(guī)格說明、需求確認(rèn)和需求管理)都有有效的過程。為了更方便地執(zhí)行這些過程，每個(gè)組織都必須有一個(gè)過程資產(chǎn)(processassets)集合(Wiegers1998c)。過程資產(chǎn)包括表1中所描述的文檔類型。類型描述檢查清單

一張列表清單，它列舉了活動、可交付產(chǎn)品或需要引起注意或驗(yàn)證的其他條目。檢查清單是幫助記憶的一種方法，可以確保忙碌的人們不會遺漏重要的細(xì)節(jié)

范例

一種特定工作產(chǎn)品類型的代表。項(xiàng)目團(tuán)隊(duì)創(chuàng)建工作產(chǎn)品時(shí)應(yīng)將優(yōu)秀范例積累起來

計(jì)劃

概括說明如何達(dá)到目標(biāo)和達(dá)到目標(biāo)需要哪些準(zhǔn)備

政策

是一種指導(dǎo)原則，它陳述了管理層對行為、動作和交付工件的期望。過程應(yīng)該滿足這些政策

步驟

一步一步描述完成某個(gè)活動的任務(wù)序列，描述要執(zhí)行的任務(wù)并確定執(zhí)行這些任務(wù)的

項(xiàng)目角色。不要包括教程信息。指導(dǎo)文檔可以為過程或步驟提供教程信息和幫助提

示

過程描述

用文檔對為達(dá)到某些目的而執(zhí)行的一組活動進(jìn)行定義。過程描述可能包括過程目標(biāo)、關(guān)鍵里程碑、參與者、交流步驟、輸入和輸出數(shù)據(jù)、與這一過程相關(guān)聯(lián)的制品、以及對這一過程進(jìn)行剪裁以適應(yīng)不同的項(xiàng)目所用的方法(Caputo1998)

模板

所使用的一種模式，可用來指導(dǎo)產(chǎn)生完整的工作產(chǎn)品。關(guān)鍵項(xiàng)目文檔的模板可以提醒我們有可能遺漏的一些問題。結(jié)構(gòu)良好的模板會提供許多“欄目槽(slot)”，用于捕獲和組織信息。內(nèi)嵌在模板中的指導(dǎo)文本有助于文檔作者有效地使用它

第37頁，課件共43頁，創(chuàng)作于2023年2月5.1需求開發(fā)過程資產(chǎn)需求開發(fā)過程這一過程描述了如何確定涉眾、