軟件需求管理部分完整版課件

1、需求開發(fā)面臨的特殊難題需求開發(fā)：是針對一個新軟件或系統(tǒng)開發(fā)項目的情況，這種項目有時也稱為零起點項目(green-field project)。大多數組織的主要精力集中于維護現存的遺留系統(tǒng)，或者為已有的商業(yè)產品構建新的版本；其他組織也很少是從零開始構建一個新系統(tǒng)，而是對商用現貨產品進行集成、定制和擴充，以滿足自己的需要。第1頁，共59頁。1開始捕獲信息缺少精確的需求文檔，那么維護人員就必須進行逆向工程，通過代碼來理解系統(tǒng)，將此看作是軟件考古學(software archaeology)。構建一個包含當前系統(tǒng)部分的需求表示可達到以下3個有用的目標：消除知識鴻溝，使將來的維護人員能更好地理解所做的變

2、更。收集當前系統(tǒng)的一些信息當前系統(tǒng)在以前缺乏良好的書面文檔。提供一個指標，表明當前的系統(tǒng)測試集對系統(tǒng)功能的覆蓋率。第2頁，共59頁。定義質量需求軟件的質量屬性和性能目標是選擇解決方案時所要考慮的用戶需求的另一個方面。我們至少要研究下面幾個屬性：性能 易使用性靈活性互操作性完整性第3頁，共59頁。盡早地而且要經常地設定優(yōu)先級客戶和開發(fā)人員協(xié)同工作，共同選定功能實現的順序，這樣增量開發(fā)才會取得成功。開發(fā)團隊的目標是，將可用的功能和對質量的改進有規(guī)律地交到用戶手中，因此，開發(fā)人員必須了解每次增量開發(fā)計劃實現哪些功能。第4頁，共59頁。設定需求優(yōu)先級每一個受資源限制的軟件項目都必須對要求的產品功能定義

3、相對優(yōu)先級。設定優(yōu)先級有助于項目經理解決沖突、安排階段性交付，并且做出必要的取舍。討論設定需求優(yōu)先級的重要性，提出一個簡單的優(yōu)先級劃分方案，并介紹更嚴格的基于價值、成本和風險的優(yōu)先級分析方案。第5頁，共59頁。5需求和進度安排注意：不要迫于壓力而許下自己明知道不可能做到的諾言，這是避免最后兩敗俱傷的秘訣。 第6頁，共59頁。需求管理第7頁，共59頁。需求管理的原則和實踐需求管理包括在項目開發(fā)過程中維護需求約定的完整性、準確性以及保持需求約定是最新約定的所有活動，如圖所示。第8頁，共59頁。8第9頁，共59頁。軟件需求管理需求管理所要完成的任務 需求管理模型 管理變更 需求風險管理 需求跟蹤 需

4、求管理工具 第10頁，共59頁。需求管理所要完成的任務 需求管理的首要任務在于使開發(fā)人員和用戶雙方對于需求都有一個明確的認識。 需求模型實際是最終產品的抽象化表現。用戶需求的滿足程度是衡量設計優(yōu)劣的標準。優(yōu)秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發(fā)揮的余地。對開發(fā)項目進行任務劃分，將整體開發(fā)任務細化為多個子模塊，從而使這些子模塊能夠平行開發(fā)而無需太多的干預。需求管理在開發(fā)周期中是自始至終存在的。需求管理必須始終保持更新。 需求管理同項目管理是密不可分的。 第11頁，共59頁。需求管理的任務明確需求并達成共識； 建立關聯，根據不同需求設計相應解決辦

5、法； 進行系統(tǒng)優(yōu)化，提出設計方案； 監(jiān)控和解決可能出現的問題以及需要做出的改變； 控制不同開發(fā)任務的開展； 對最終產品做出評測； 監(jiān)控可能出現的重復開發(fā)； 提出項目實施時間表； 確定最終用戶界面。 第12頁，共59頁。里程碑與項目管理 一項需求的滿足就意味著一塊里程碑的確立。里程碑構造機制的基本方法之一就是進程管理 。需求管理在開發(fā)周期中是自始至終存在的。需求管理必須始終保持更新，它構成了技術管理的基礎。 需求管理同項目管理是密不可分的 。第13頁，共59頁。需求管理模型 不同的需求組合起來，構成了一套完整的需求模型。需求管理的一項重要工作就是在整個項目的不同任務之間建立聯系。需求管理包括在工

6、程進展過程中維持需求約定集成性和精確性的所有活動。需求管理的關鍵過程領域。需求管理的步驟。 第14頁，共59頁。需求管理的主要活動 控制對需求基線的變動。保持項目計劃與需求一致?？刂茊蝹€需求和需求文檔的版本情況。管理需求和聯系鏈之間的聯系或管理單個需求和其它項目可交付品之間的依賴關系。跟蹤基線中需求的狀態(tài)。 第15頁，共59頁。需求開發(fā)與需求管理的分界中程在線信息產業(yè)培訓網第16頁，共59頁。需求基線管理為何需要：頻繁的需求變更會破壞開發(fā)的節(jié)奏，使整個項目開發(fā)的進度陷入混亂和失控的狀態(tài)，而且會變成一個“救火隊”式的工作，整天都在處理突發(fā)事件.主要思想：將所有現在的、將來的需求進行優(yōu)先級評估，然

7、后分解成為不同的組，每次迭代都選擇其中優(yōu)先級最高的部分進行開發(fā)，然后在迭代完成之前，開發(fā)工作不響應變更，這些劃入的需求項就是需求基線的組成部分 第17頁，共59頁。需求基線管理-操作思路我們應該在分析的基礎上，將需求整合成為用例或功能項，然后對其進行優(yōu)先級、依賴性進行綜合性評估優(yōu)先級判斷：業(yè)務人員確定業(yè)務決定，技術人員確定技術決策；“滿意度/不滿意度”模型依賴性是指對于某些功能，在實現上有必須的依賴關系，即當某些功能沒有實現時，另外的功能無法開始，這就需要對其進行調整第18頁，共59頁。需求變更管理需求變更是一定存在的，而需求變更管理并不是指逃避它，更不是說要避免它，它實際上是希望控制變更 在

8、基線內的需求不響應變更，為開發(fā)人員提供一個安靜的工作時間狀態(tài) 專門的需求變更管理來對所有的需求變更進行響應，了解需求變更的關鍵意圖、新產生的工作量，從而良好地進行重新計劃，以便能夠有效地解決其對整個開發(fā)帶來的麻煩 第19頁，共59頁。對待軟件項目管理的組織必須確保做到以下幾點：在提交提議的需求變更之前要對其進行仔細的評估。請合適的人員就需求變更做出周全合理的業(yè)務決策。將已批準的變更傳達給受此影響的所有人員。項目以一致的方式將需求變更包含進來。采用一致的變更控制方法，就可以避免相關問題，避免開發(fā)工作的返工和浪費時間等情況的發(fā)生。第20頁，共59頁。變更控制委員會變更控制委員會，有時也稱為配置控制

9、委員會(configuration control board，CCB)，已被證實是軟件開發(fā)領域公認的最佳實踐(McConnell 1996)。CCB是由人組成的團體，可以由一個小組擔任，也可以由多個不同的小組擔任，這些人共同決定將哪些已提議的需求變更和新提議的特性在產品中付諸實現。CCB也決定所報告的缺陷中哪些需要糾正，什么時候糾正。CCB可以評審和批準對項目中任何基線工作產品所做的變更，項目需求文檔只是其中的一個樣例。第21頁，共59頁。CCB的組成CCB的成員應該能代表需要參與制定決策的所有小組，當然這些決策制定只能是在CCB的權力范圍之內?？煽紤]從下面這些部門中選擇CCB代表：項目或程

10、序管理部門產品管理或需求分析部門開發(fā)部門測試或質量保證部門市場或客戶代表編寫用戶文檔的部門技術支持或幫助部門配置管理部門第22頁，共59頁。CCB規(guī)章CCB規(guī)章描述了CCB的目的、權力范圍、成員構成、運作規(guī)程和決策的制定過程等(Sorensen 1999)。CCB的權力范圍規(guī)定了哪些決策由CCB決定，哪些決策則必須上報給高一級CCB或者由管理層來決定。1. 制定決策決策制定過程的描述應該確定：CCB成員或主要角色的人數，這是制定決策的法定人數。所采用的決策規(guī)則是投票、少數服從多數、協(xié)商決定或其他方法。第23頁，共59頁。CCB規(guī)章CCB主席是否可以否決CCB的集體決策。級別高的CCB或其他人是

11、否必須認可CCB做出的決策。2. 交流狀態(tài)CCB做出決策之后，應該指派專人對變更數據庫中的變更請求狀態(tài)進行更新。3. 重新協(xié)商原先的約定在接受一個重大的需求變更之前，為了適應這一變更，需要同管理部門和客戶重新協(xié)商原先的約定(Humphrey 1997)。協(xié)商的內容可能包括，要求推遲產品交付時間，要求增派人手，或者要求推遲實現尚未實現的優(yōu)先級較低的需求等。第24頁，共59頁。變更需要付出代價：影響分析對軟件實施大的功能增強，則需要進行影響分析(impact analysis)。但是，即使是小的變更請求，也可能潛伏著難以預料的復雜性。影響分析是需求管理的一個關鍵方面(Arnold和Bohner 1

12、996)。通過對影響進行分析，可以準確地理解提議的變更所涉及到的問題，有助于項目團隊就批準哪些提議做出周全合理的業(yè)務決策。影響分析:通過對所提議的變更進行檢查，確定可能必須創(chuàng)建、修改或廢棄哪些部分，并估計與實現這些變更相關的工作量。第25頁，共59頁。影響分析的過程影響分析有3個方面：1.理解進行變更可能涉及的問題。變更常常會產生大量的連鎖反應，產品包括的功能太多會降低其性能，甚至會到令人難以接受的地步。2.確定如果團隊將提議的變更包括到產品中，可能必須對哪些文件、模型和文檔進行修改。3.確定實現變更所需執(zhí)行的任務，并估計完成這些任務所需的工作量。注意:跳過影響分析并不能改變任務的規(guī)模，只會使

13、規(guī)模令人感到驚奇，而軟件方面令人驚奇卻很少是好消息。第26頁，共59頁。影響分析報告模板圖是一個推薦的報告模板，表示對每個需求變更造成的潛在影響的分析結果。如果采用標準模板，CCB成員就可以輕松地找到他們所需的信息，作出合理的決策。 第27頁，共59頁。需求的變化是永恒的。因而，對于需求變更應該正確對待，盡量將其負面影響降低。需求變更可能來自解決方案提供商、客戶或產品供應商等外部因素，也可能來源于項目組內部。變更都是有代價的，應該評估一下變更的代價及其對項目的影響。在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來的風險降低到最低。切忌在項目設計之前試圖消除需求變更。第28頁，共59頁。需求

14、變更的原因 因競爭、成本等因素，工期已經確定且極不合理.用戶在需求期提不出需求、或用戶的需求不明確.項目組對業(yè)務不熟悉、或者沒有與用戶密切結合、需求分析工作不細致.項目組沒有很好地實施需求管理.第29頁，共59頁。需求變更的惡性循環(huán) 第30頁，共59頁。需求變更的因素 第31頁，共59頁。需求變更的代價 第32頁，共59頁。減少需求變更 第33頁，共59頁。需求變更的過程管理 認識到變更不可避免，為變更制訂計劃。確認需求基線。建立控制變更的唯一渠道。使用變更控制系統(tǒng)來捕獲變更。分層次地管理變更。 第34頁，共59頁?；谂渲霉芾淼男枨蠊芾肀苊庑枨笤谖词跈嗲闆r下變更，或在有潛在破壞性的情況下不受

15、限制地隨意變更。保護隊需求文檔的修正。方便對文檔以前版本的檢索或重建。支持系統(tǒng)以增量的方式改進基線。避免對文檔的同時更新和沖突。 第35頁，共59頁?；€管理 需求基線(requirement baseline)是團隊成員已經承諾將在某一特定產品版本中實現的功能性和非功能性需求的一組集合?；€：已經通過正式評審和批準的某規(guī)約或產品，它可以作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程的改變。IEEE基線是一個軟件配置管理的概念 。在軟件工程的范圍內，基線是軟件開發(fā)中的里程碑，其標志是有一個或多個軟件配置項的交付，且已經經過正式技術評審而獲得認可。 配置管理組或委員會（CCB）按照需求基線

16、，對整個項目的進程進行控制和把握 。第36頁，共59頁。需求狀態(tài)的變化 第37頁，共59頁。需求管理過程注意如果項目中無人負責執(zhí)行需求管理活動，那么就不要指望需求管理能夠運作。第38頁，共59頁。需求版本控制版本控制是管理需求規(guī)格說明和其他項目文檔必不可少的一個方面。需求文檔的每一個版本都必須惟一地標識出來。為了盡量減少混亂、沖突和誤傳，應該指派一個人專門負責更新需求，并確保只要需求有所變更就相應地改變其版本標識號。最簡單的版本控制機制是，根據標準約定，對每一個軟件需求規(guī)格說明版本進行手工標識。還有一種更復雜的技術，可以把需求文檔存儲在版本控制工具中。版本控制最有用的方法是將需求存儲在商業(yè)需求

17、管理工具的數據庫中 。第39頁，共59頁。需 求 屬 性應該考慮為每個需求指定如下一些屬性：需求創(chuàng)建的日期。需求的當前版本號。創(chuàng)建需求的作者。負責確保該需求得到滿足的人員。需求的擁有者或一組涉眾列表。需求狀態(tài)。需求的最初來源。創(chuàng)建需求的理由。需求涉及的子系統(tǒng)。需求涉及的產品版本號。使用的驗證方法或驗收測試的標準。需求實現的優(yōu)先級。需求的穩(wěn)定性。 注意如果選擇的需求屬性太多，那么開發(fā)團隊會望而生畏，結果是他們絕不可能提供所有需求的全部屬性值，也無法有效地使用這些屬性信息。第40頁，共59頁。跟蹤需求狀態(tài)表列出了若干可能的需求狀態(tài)。有些跟蹤人員還添加了另外兩個狀態(tài)： “已設計(Designed)”

18、和“已交付(Delivered)。狀 態(tài) 定 義 已提議(Proposed) 該需求已被有相應權限的人提出 已批準(Approved) 該需求已經被分析，它對項目的影響已進行了估計，并且已經被分配到某一特定版本的基線中。關鍵涉眾已同意包含這一需求，軟件開發(fā)團隊已承諾實現這一需求 已實現(Implemented) 實現這一需求的代碼已完成了設計、編碼和單元測試。這一需求已被跟蹤到相關的設計元素和編碼元素 已驗證(Verified) 已在集成產品中確認了這一需求的功能實現是正確的。這一需求已被跟蹤到相關的測試用例。這一需求目前可以被認為是已完成了 已刪除(Deleted) 已批準的需求又從需求基線

19、中取消了。要解釋清楚為什么要刪除這一需求，以及是誰決定刪除的 已否決(Rejected) 需求已被提議，但并不計劃在下一版本中實現它。要解釋清楚為什么要否決這一需求，以及是誰決定否決的 第41頁，共59頁。評估需求管理的工作量如果跟蹤在需求管理上投入了多少工作量，我們就可以評估工作量是太少，還是正合適，或者是太多，并且可以對當前過程和未來的計劃做出相應的調整。將下面這些活動中所投入的工作量加起來，就可以算出需求管理的工作量：提交需求變更和提議新的需求。評估已提議的變更，包括進行影響分析。變更控制委員會的活動。更新需求文檔或數據庫。向受影響的小組或個人傳達需求變更。跟蹤并報告需求狀態(tài)。收集需求的

20、跟蹤信息。第42頁，共59頁。需求風險管理第43頁，共59頁。所謂風險就是可能給項目的成功帶來某些損失或威脅的情況。由于需求在軟件項目中具有十分重要的地位，所以精明的項目管理者應盡早確定與需求相關的風險并積極主動地控制它們。典型的需求風險包括：誤解需求。用戶的參與不恰當。項目范圍和目標不確定或隨意進行變更。對需求不斷進行變更等。第44頁，共59頁。44軟件風險管理基本原理對外部實體的依賴就是一種常見的風險來源。項目管理一直面臨各種風險的挑戰(zhàn)：評估不準確、管理人員拒絕開發(fā)人員的準確評估、對項目狀態(tài)不了解以及進行了人員調整等原因所引起的風險。技術風險威脅著高度復雜或很前沿的開發(fā)項目。知識的缺乏是風

21、險的另一種來源，另外還有參與者對所用的技術或項目應用領域經驗不足。經常變更的或強制執(zhí)行的一些政府規(guī)定可能會使最好的項目規(guī)劃徹底作廢。第45頁，共59頁。風險管理的要素風險管理(risk management)就是使用某些工具和步驟把項目風險限制在一個可接受的范圍內。風險管理提供了一種標準的方法，可以指出風險因素并將其編寫成文檔，評估這些風險的潛在威脅，并提出減少這些風險因素的戰(zhàn)略。第46頁，共59頁。風險管理包括圖所示的這些活動。風險評估(risk assessment)是一個對項目進行檢查以確定潛在風險領域的過程。風險避免(riskavoidance)是處理風險的一種方法，也就是盡量不要做冒

22、險的事。第47頁，共59頁。編寫項目風險文檔圖展示了一個模板，用于對單個風險編寫文檔。第48頁，共59頁。制定風險管理計劃對于小型項目，可以把控制風險的計劃包括在軟件項目管理計劃內。但對一個大型項目，則應該編寫一個單獨的風險管理計劃，詳細說明打算采用哪些方法來識別、評估、編檔和跟蹤風險。這一計劃還應該包括風險管理活動的角色和職責。要建立起周期性進行風險監(jiān)控的措施。 注意：不要想當然地以為，在識別出了風險并采取了降低風險的相應活動之后，風險就會處于您的控制之下。接下來還要實行風險管理活動。第49頁，共59頁。與需求有關的風險 無足夠用戶參與用戶需求的不斷增加 模棱兩可的需求 不必要的特性過于精簡

23、的規(guī)格說明 忽略了用戶分類 不準確的計劃 第50頁，共59頁。風險管理是我們的好幫手即使不能控制項目可能遇到的所有風險，風險管理也能幫助我們看清形勢，做出合理的決策。第51頁，共59頁。風險管理的措施明確你當前項目面臨的一些與需求有關的風險，不要把當前的問題當作風險，一定要是那些還未發(fā)生的事情。將風險因素編寫成文檔，為每項風險推薦至少一種可能的降低風險的方法。第52頁，共59頁。風險管理的措施召集代表開發(fā)、市場、客戶和管理各方面的涉眾召開風險“集體研討”會議。第53頁，共59頁。需求跟蹤需求跟蹤提供了一個表明與合同或說明一致的方法。更進一步，需求跟蹤可以改善產品質量，降低維護成本，而且很容易實現重用。需求跟蹤鏈使你能跟蹤一個需求使用期限的全過程。通用的跟蹤模型顯示了我們要在軟件開發(fā)的不同層面全面地跟蹤需求。 第54頁，共59頁。需求跟蹤的定義IEEE，1994 開發(fā)過程的兩個或多個產品之間能夠建立關系的程度，尤其是那些具有前