需求工程過程課件

1、第二章需求工程過程2022/7/30第二章需求工程過程第1頁，共28頁。優(yōu)秀的團隊遇到糟糕 的需求需求問題導致的主要后果是返工重復做您認為早已做好的事情。返工的成本占了總開發(fā)成本的30%50，而對于返工的情況，70%80%是因需求錯誤引起的。從圖可以看出，在項目末期才發(fā)現(xiàn)缺陷，對其進行改正的成本要比在缺陷剛產生不久時修改的成本高得多。第二章需求工程過程第2頁，共28頁。鍍金問題開發(fā)人員為產品添加了一項需求說明中沒有提到的功能，他認為“用戶肯定會喜歡的”。這就是所謂的“鍍金問題(gold plating)”。 開發(fā)人員和需求分析員不應擅自添加特性，應該把創(chuàng)意和備選方案提交給客戶，讓他們做決定。要

2、避免鍍金問題，就應該追溯每項功能的來源，弄清楚為什么添加該功能。第二章需求工程過程第3頁，共28頁。過于抽象的需求營銷人員或經理經常喜歡只給出一個粗略的說明，他們希望開發(fā)人員在開發(fā)過程中充實它。這種方式對研究性項目或需求特別靈活的項目或許管用，但是需要緊密合作的團隊，而且僅限于開發(fā)小型系統(tǒng)。大多數(shù)情況下，這種做法的結果是使開發(fā)人員受挫，讓客戶失望。第二章需求工程過程第4頁，共28頁。忽略了某類用戶用戶所使用的產品特性、產品的使用頻率以及用戶自身的經驗水平不盡相同。因此，多數(shù)產品都擁有不同的用戶群。如果一開始沒能找出產品的所有重要用戶群，就會有某些用戶需求得不到滿足。確定所有用戶群后，還要保證獲

3、得各類用戶的需求 。第二章需求工程過程第5頁，共28頁。第二部分 需求工程過程需求工程: 對問題域及需求做調查研究和描述,設計將滿足那些需求的解系統(tǒng)的特性并用文檔說明. 需求獲取 需求分析 規(guī)格說明 人機接口 需求驗證需求獲取、分析、編寫需求規(guī)格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復。第二章需求工程過程第6頁，共28頁。需求開發(fā)過程需求開發(fā)是一個迭代的過程第二章需求工程過程第7頁，共28頁。需求工程的推薦方法列出了近50種方法，分別屬于7個類型，它們可以幫助大部分項目開發(fā)團隊更好地完成他們的需求工作。第二章需求工程過程第8頁，共28頁。知 識需求管理項目管理培訓需求分析員

4、對用戶代表和管理者進行需求培訓對開發(fā)者進行應用領域相關的培訓創(chuàng)建術語表定義需求變更控制進程成立變更控制委員會分析需求變更的影響控制需求版本并為其建立基線維護需求變更的歷史記錄跟蹤每項需求的狀態(tài)衡量需求穩(wěn)定性使用需求管理工具創(chuàng)建需求跟蹤矩陣選擇合適的開發(fā)周期根據(jù)需求制訂項目計劃重新協(xié)商權利或義務管理需求風險跟蹤需求耗費的人力物力回顧以往的教訓需求獲取需求分析編寫規(guī)格說明需求驗證定義需求開發(fā)過程定義項目前景和范圍確定用戶群選擇用戶代言人建立核心隊伍確定用例確定系統(tǒng)事件和響應舉行進一步需求獲取的討論觀察用戶如何工作檢查問題報告重用需求繪制關聯(lián)圖創(chuàng)建原型分析可行性確定需求優(yōu)先級為需求建模創(chuàng)建數(shù)據(jù)字典將

5、需求分配至各子系統(tǒng)應用質量功能調度采用SRS模板確定需求來源惟一標識每項需求記錄業(yè)務規(guī)范定義質量屬性審查需求文檔測試需求確定合格標準第二章需求工程過程第9頁，共28頁。知 識 技 能開發(fā)者也應該了解產品應用領域中的基本概念和術語。 培訓需求分析員所有將要成為分析員的團隊成員都應該接受需求工程方面的基本培訓。熟練的需求分析員應具備以下特點：耐心，思維條理性強，有良好的交際和溝通能力，理解產品應用領域，并且掌握豐富的需求工程技術。 對用戶代表和管理者進行軟件需求培訓參與軟件開發(fā)的用戶應該接受一到兩天的需求工程方面的培訓。 對開發(fā)人員進行應用領域的相關培訓為了幫助開發(fā)人員對應用領域有一個基本的理解，

6、可以安排一個研討課程，內容是客戶的業(yè)務活動、術語和產品的目標。 創(chuàng)建項目術語表定義應用領域專業(yè)名稱的術語表可以減少誤解。 第二章需求工程過程第10頁，共28頁。需求獲取需求獲取(requirement elicitation)是需求工程的主體。對于所建議的軟件產品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。需求獲取可能是軟件開發(fā)中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶開發(fā)者的合作才能成功。需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。第二章需求工程過程第11頁，共28頁。需求獲取

7、第1章討論了需求的三個層次：業(yè)務，用戶和功能。在項目中它們在不同的時間來自不同的來源，也有著不同的目標和對象，并需以不同的方式編寫成文檔。業(yè)務需求（或產品視圖和范圍）不應包括用戶需求（或使用實例），而所有的功能需求都應該源于用戶需求。同時你也需要獲取非功能需求，如質量屬性。1) 確定需求開發(fā)過程 確定如何組織需求的收集、分析、細化并核實的步驟，并將它編寫成文檔。對重要的步驟要給予一定指導，這將有助于分析人員的工作，而且也使收集需求活動的安排和進度計劃更容易進行。2) 編寫項目視圖和范圍文檔 項目視圖和范圍文檔應該包括高層的產品業(yè)務目標，所有的使用實例和功能需求都必須遵從能達到的業(yè)務需求。項目視

8、圖說明使所有項目參與者對項目的目標能達成共識。而范圍則是作為評估需求或潛在特性的參考。3) 將用戶群分類并歸納各自特點 為避免出現(xiàn)疏忽某一用戶群需求的情況，要將可能使用產品的客戶分成不同組別。他們可能在使用頻率、使用特性、優(yōu)先等級或熟練程度等方面都有所差異。詳細描述出它們的個性特點及任務狀況，將有助于產品設計。第二章需求工程過程第12頁，共28頁。4) 選擇每類用戶的產品代表 5) 建立起典型用戶的核心隊伍 6) 讓用戶代表確定使用實例 從用戶代表處收集他們使用軟件完成所需任務的描述使用實例，討論用戶與系統(tǒng)間的交互方式和對話要求。在編寫使用實例的文檔時可采用標準模版，在使用實例基礎上可得到功能

9、需求。7) 召開應用程序開發(fā)聯(lián)系（ J A D）會議 應用程序開發(fā)聯(lián)系（ J A D）會議是范圍廣的、簡便的專題討論會（ w o r k s h o p），也是分析人員與客戶代表之間一種很好的合作辦法，并能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客戶與開發(fā)人員間的合作伙伴關系付諸于實踐第二章需求工程過程第13頁，共28頁。8) 分析用戶工作流程觀察用戶執(zhí)行業(yè)務任務的過程9) 確定質量屬性和其它非功能需求 10) 通過檢查當前系統(tǒng)的問題報告來進一步完善需求11) 跨項目重用需求。調查用戶任務可能遇到的變更，或者用戶需要使用系統(tǒng)其它可能的方式。想像你自己在學習用戶的工作，你需要完成

10、什么任務？你有什么問題？從這一角度來指導需求的開發(fā)和利用。還有，探討例外的情況：什么會妨礙用戶順利完成任務？對系統(tǒng)錯誤情況的反映，用戶是如何想的？詢問問題時，以“還有什么能” ,”當時，將會發(fā)生什么”“你有沒有曾經想過” ,“有沒有人曾經”為開頭。記下每一個需求的來源，這樣向下跟蹤直到發(fā)現(xiàn)特定的客戶。第二章需求工程過程第14頁，共28頁。需求分析分析:通過對問題域的研究,獲得對該領域特性及存在于其中(需要解決)的問題特性的透徹理解并用文檔說明.需求分析（ requirement analysis）包括提煉、分析和仔細審查已收集到的需求，以確保所有的風險承擔者都明白其含義并找出其中的錯誤、遺漏或

11、其它不足的地方。分析員通過評價來確定是否所有的需求和軟件需求規(guī)格說明都達到了優(yōu)秀需求說明的要求。分析的目的在于開發(fā)出高質量和具體的需求，這樣你就能作出實用的項目估算并可以進行設計、構造和測試.通常，把需求中的一部分用多種形式來描述，如同時用文本和圖形來描述。分析這些不同的視圖將揭示出一些更深的問題，這是單一視圖無法提供的。分析還包括與客戶的交流以澄清某些易混淆的問題，并明確哪些需求更為重要。其目的是確保所有風險承擔者盡早地對項目達成共識并對將來的產品有個相同而清晰的認識。第二章需求工程過程第15頁，共28頁。1)繪制系統(tǒng)關聯(lián)圖 這種關聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。同

12、時它也明確了通過接口的信息流和物質流。 2) 創(chuàng)建用戶接口原型 當開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶接口原型一個可能的局部實現(xiàn)這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。3) 分析需求可行性 在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現(xiàn)相聯(lián)系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。 4) 確定需求的優(yōu)先級別 應用分析方法來確定使用實例、產品特性或單項需求實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，

13、在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。第二章需求工程過程第16頁，共28頁。5) 為需求建立模型 需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。6) 創(chuàng)建數(shù)據(jù)字典 數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項以確保客戶與開發(fā)小組是使用一致的定義和術語。分析和設計工具通常包括數(shù)據(jù)字典組件。7) 使用質量功能調配 質量功能調配( Q F

14、D）是一種高級系統(tǒng)技術，它將產品特性、屬性與對客戶的重要性聯(lián)系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。 期望需求；普通需求；興奮需求.第二章需求工程過程第17頁，共28頁。規(guī)格說明無論你的需求從何而來，也不管你是怎樣得到的，你都必須用一種統(tǒng)一的方式來將它們編寫成可視文檔。業(yè)務需求要寫成項目視圖和范圍文檔。用戶需求要用一種標準使用實例模板編寫成文檔。而軟件需求規(guī)格說明（ requirement specification）則包含了軟件的功能需求和非功能需求。你必須為每項需求明確建立標準的慣例，并確定在S R S中采用任何慣例，以確保S R S的統(tǒng)一風格，同時讀者也會明白怎樣

15、解釋它。第二章需求工程過程第18頁，共28頁。1)采用S R S模板 在你的組織中要為編寫軟件需求文檔定義一種標準模板。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統(tǒng)一的結構。2) 指明需求的來源 為了讓所有項目風險承擔者明白S R S中為何提供這些功能需求，要都能追溯每項需求的來源，這可能是一種使用實例或其它客戶要求，也可能是某項更高層系統(tǒng)需求、業(yè)務規(guī)范、政府法規(guī)、標準或別的外部來源。3) 為每項需求注上標號 制定一種慣例來為S R S中的每項需求提供一個獨立的可識別的標號或記號。這種慣例應當很健全，允許增加、刪除和修改。作了標號的需求使得需求能被跟蹤，記錄需求變更并為需求狀態(tài)和

16、變更活動建立度量。4) 記錄業(yè)務規(guī)范 業(yè)務規(guī)范是指關于產品的操作原則，比如誰能在什么情況下采取什么動作。將這些編寫成S R S中的一個獨立部分，或一獨立的業(yè)務規(guī)范文檔。某些業(yè)務規(guī)范將引出相應的功能需求；當然這些需求也應能追溯相應業(yè)務規(guī)范。5) 創(chuàng)建需求跟蹤能力矩陣 建立一個矩陣把每項需求與實現(xiàn)、測試它的設計和代碼部分聯(lián)系起來。這樣的需求跟蹤能力矩陣同時也把功能需求和高層的需求及其它相關需求聯(lián)系起來了。在開發(fā)過程中建立這個矩陣，而不要等到最后才去補建。第二章需求工程過程第19頁，共28頁。人機接口設計人機接口HMI面向人的或其他的系統(tǒng)第二章需求工程過程第20頁，共28頁。需求驗證驗證是為了確保需

17、求說明準確、完整地表達必要的質量特點。而且能夠滿足客戶的需要。審查需求文檔對需求文檔進行正式審查是保證軟件質量的有效手段之一。測試需求根據(jù)用戶需求推導出功能測試用例，以便記錄產品在特定條件下應有的行為。定義合格標準讓用戶描述決定產品是否滿足他們的需求并適合使用的標準。第二章需求工程過程第21頁，共28頁。1) 審查需求文檔2) 以需求為依據(jù)編寫測試用例3) 編寫用戶手冊4) 確定合格的標準第二章需求工程過程第22頁，共28頁。需 求 管 理有了項目的初步需求，就必須處理好開發(fā)過程中不可避免的來自客戶、管理層、營銷部門、開發(fā)團隊以及其他群體的變更請求。定義需求變更控制過程建立一個用于提議、分析和

18、解決需求變更的過程。成立變更控制委員會可授權由涉眾組成的小組作為變更控制委員會(CCB)來接收需求變更的請求。分析需求變更的影響對影響進行分析有助于CCB做出明智的業(yè)務決策。建立基線和控制需求文檔的版本基線是由已經被提交到一個指定版本中的實現(xiàn)(implementation)的需求組成的。第二章需求工程過程第23頁，共28頁。需 求 管 理維護需求變更的歷史記錄記錄需求規(guī)格說明變更的日期、變更的內容、變更的實施者和原因。跟蹤每項需求的狀態(tài)建立一個數(shù)據(jù)庫，為每一項功能需求保存一條記錄。衡量需求的穩(wěn)定性記錄已設為基線的需求數(shù)，以及每周提議和批準的需求的變更(增加，修改，刪除)數(shù)。使用需求管理工具商業(yè)需求管理工具可用于在數(shù)據(jù)庫