需求活動指南范文1

1、第 PAGE39 頁 共 NUMPAGES39 頁需求活動指南-范文1XXX 有限公司需求活動指南文檔修訂記錄 版本編號 *變化 狀態(tài) 簡要說明 日期 變更人 批準日期 批準人 V1.0 A*變化狀態(tài)：A增加，M修改，D刪除目 錄 1 1前言 1目的 1適用范圍 1讀者對象 12 2需求活動的重要性 性 2需求是項目能否成功的根本原因 2了解客戶/ 用戶 2需求活動中的主要問題與對策 3產(chǎn)品與集成項目是否都需要需求開發(fā)與管理活動 3知識與技能問題 3態(tài)度問題 3合作關系 3用戶說不清楚需求 4雙方誤解需求 4開發(fā)人員寫不好需求文檔 4用戶經(jīng)常變更需求 43 3需求開發(fā) 6需求調查 6調查準備

2、6調查活動實施 6調查記錄與輸出 錯誤 ! 未定義書簽。需求分析p 6問答法 6建模法 7需求定義 7正確性 (Accuracy) 7完備 (Complete) 8一致性 (Consistent) 8無歧義性 (Unambiguous) 8可驗證 (Verifiable) 8可修改性 (Adaptable) 8必要性 (Necessary) 8可跟蹤性 9可實現(xiàn) (Attainable) 9可理解性 9確定優(yōu)先級別 9注意事項 10需求確認 10需求評審 10需求承諾 104 4需求管理活動 11需求跟蹤活動 11需求變更活動 11需求變更的來 11需求變更控制 12需求狀態(tài)跟蹤活動 125

3、5附錄 12引用文檔/ 參考資料 12術語表 121 1 前言 1.1 目的 定義和描述需求活動的過程指南，指導需求開發(fā)、需求管理活動的實施。本文檔可以作為需求管理過程的擴展和補充內容。1.2 適用范圍 本文檔對需求指南活動的描述適用于各種領域、各種類型的開發(fā)和測試模式的需求管理的相關活動； 本文檔的適用范圍為組織中的各項目。錯誤! ! 未找到引用。1.3 讀者對象 本文檔的對象適用于開發(fā)和測試過程中的相關人員，特別是需求開發(fā)與需求管理人員；包括有關部門總監(jiān)、項目經(jīng)理、需求分析p 人員、系統(tǒng)分析p 人員、SQA 人員等相關人員。2 2 需求活動的重要性2.1 需求是項目能否成功的根本原因 項目

4、開發(fā)的目標是：在預算內按時開發(fā)出符合客戶真正需要的高質量的軟件系統(tǒng)。簡單的講，成功的軟件項目就是指那些可以達成這個目標的項目。調查顯示（ESPITI 1995），與項目管理、軟件測試、文檔管理、編碼等問題比較起來，需求規(guī)格說明與管理客戶需求兩個問題被 3800 位被調查從業(yè)人員列為產(chǎn)業(yè)中最重要的問題。數(shù)據(jù)表明： 需求缺陷可能是最常見的缺陷； 需求缺陷可能是修改花費最昂貴的錯誤（可能消耗整個項目的 25%40%）；參見下圖：由此可以直觀的體會到，需求的開發(fā)與管理活動是決定項目是否成功的根本因素。2.2 了解客戶/ 用戶 客戶（customer）泛指與開發(fā)組織簽訂開發(fā)合同的組織或人；可以是代理商（

5、往往代表許多最終用戶）、組織的信息管理部門，也可以指本組織內的系統(tǒng)工程組、營業(yè)人員等。用戶（user）是對使用（操作）系統(tǒng)的人一種泛稱，可細分為最終用戶（the end user）和間接用戶（或稱為關系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶?？蛻襞c最終用戶可能是同一個人也可能不是同一個人。如果軟件是面向企業(yè)用戶的，那么客戶與最終用戶通常不是同一個人；例如日文印刷社排版系統(tǒng)的客戶可以看成是印刷社的系統(tǒng)工程部，而最終用戶則是印刷社的制作部門。軟件開發(fā)方與客戶打交道的主要目的是：一是獲取需求，二是簽合同?？蛻羲f的需求一般比較宏觀，更詳細的需求應該從最終用戶那里獲取。如果項目

6、規(guī)模比較大，那么開發(fā)方與最終用戶的來往就比較多。如從最終用戶那里獲取詳細的需求，請最終用戶試驗軟件，對最終用戶進行培訓等等。階 段 需求時間 設計 編碼 單元測試 驗收測試 維護 在生命周期不同階段修復缺陷的相對成本統(tǒng)計（Davis 1993）0.1 0.2 0.5 1 2 5 20 2.3 需求活動中的主要問題與對策 2.3.1 產(chǎn)品與集成項目是否都需要需求開發(fā)與管理活動 由于合同項目的客戶是已知的，需求開發(fā)和需求管理的各項活動可以有的放矢地開展。但是對于自主研發(fā)的產(chǎn)品而言，在產(chǎn)品沒有賣出之前，并不存在真正的用戶。由于用戶是未知的，究竟該向誰調查需求？由誰來確認需求？其實，雖然待開發(fā)的產(chǎn)品尚

7、未有真正的用戶，但必定有潛在的目標用戶。開發(fā)人員可以向潛在的用戶們調查需求，請他們來確認需求。如果因條件限制，無法直接與潛在的用戶溝通，可以通過角色扮演等方法，詳見 3.1.2 節(jié)； 2.3.2 知識與技能問題 由于專業(yè)和職業(yè)的原因，多數(shù)軟件開發(fā)人員不擅長與用戶交流。有些人技術很出色，但與用戶在一起時有勁使不出；所以公司不能期望他們能夠無師自通地把需求開發(fā)工作做好，最好最快的解決辦法是培訓。作為項目的領導，既然要把那么重要的工作（需求開發(fā)）交給開發(fā)人員去做，就要舍得花錢對開發(fā)人員進行需求開發(fā)培訓，幫助他們把需求開發(fā)工作做好。即使需求分析p 人員對需求調查、需求分析p 、需求定義已經(jīng)有了豐富的經(jīng)

8、驗，但他們的知識仍然可能不夠用。應用領域的知識是無邊無際、不斷更新的，任何人都不可能是“萬事通”。當需求分析p 人員缺乏應用領域知識時，首先要有勇氣做事，否則連實踐的機會都沒有；其次應當趕緊補習應用領域知識，不論是通過自學還是培訓的方式，否則他很難與用戶交流。如果可能的話，開發(fā)組最好請既懂軟件又懂應用領域知識的行家來幫忙。如果需求分析p 人員完全不了解應用領域，而用戶幾乎是個計算機盲，并且雙方都不愿意主動了解對方領域的事情，這種狀況下的需求開發(fā)很難成功。2.3.3 態(tài)度問題 相當多的開發(fā)人員習慣于被動地對待需求開發(fā)。每當遇到麻煩、挫折時，他們會發(fā)牢騷，找出一堆用戶的毛病。這是普遍現(xiàn)象，并不是開

9、發(fā)人員懶惰所造成的，而是不正確的觀念誤導了他們：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應當開發(fā)什么嗎？如果用戶說不清楚需求，或經(jīng)常變更需求，這類問題是用戶產(chǎn)生的，應當由他們自己負責。用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設法解決的?？杀氖情_發(fā)人員把這些問題當成了借口，不愿主動攻克問題，導致需求問題擴散到整個軟件開發(fā)過程，產(chǎn)生太多的后患。其實需求分析p 人員的工作就是在有限的時間內獲取準確而細致的用戶需求，如果做不到就是失職，不要找借口。2.3.4 合作關系 如果需求分析p 人員不具備較強的交流、溝通能力，無法與用戶建立

10、良好的合作關系，那么即使他們有過硬的專業(yè)知識與行業(yè)背景，在需求開發(fā)過程中也會很疲憊。倘若用戶不能很好地配合需求分析p 人員，那并不表示他有問題。因為用戶有自己的想法： 我回答了你們的問題，講了該講的。 我們付錢給你們，難道還要我伺候你們不成？ 我還要干自己的事情，別再打擾我。 你們自己想辦法把活干好吧 對于一些競標項目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產(chǎn)品，他不會投入很多精力來協(xié)助你搞需求開發(fā)。開發(fā)方與用戶的合作關系對需求開發(fā)而言是至關重要的。對于重大的、復雜的項目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關系，這樣風險太大。推薦一種方法：開發(fā)方和用戶方在開展需求

11、開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權利與義務”，即以協(xié)議的方式確定合作關系?！昂迷挕焙汀俺笤挕倍颊f在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關于需求工程的培訓，這樣的培訓將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。表 4-1 列舉了用戶在需求工程中的“權利與義務”，項目組可以根據(jù)實際情況適當?shù)匦薷?。用戶的權?1. 有權要求開發(fā)方派遣資質合格的需求分析p 人員和相關人員。2. 有權要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂的需求文檔。3. 有權審查需求文檔，并對有爭議的需求作出決策。如

12、果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。4. 如果用戶想要變更需求，有權要求開發(fā)方對該變更將產(chǎn)生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶的義務 1. 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。2. 樂意接受需求分析p 人員的采訪，在不泄漏機密的前提下，盡可能地回答需求分析p 人員的問題。3. 在不泄漏機密的前提下，盡可能地向需求分析p 人員提供與需求相關的材料。4. 與需求分析p 人員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。5. 不輕易變更需求。如果需要變更需求的話，按照“需求變更控制規(guī)程”

13、執(zhí)行，而非強迫開發(fā)方接受。2.3.5 用戶說不清楚需求 用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛的大問題。有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當然說不清楚需求。開發(fā)人員可能覺得奇怪：用戶自己都不知道要什么，為什么還要我們開發(fā)軟件？這種現(xiàn)象有些時候是正常的，例如開發(fā)方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導用戶“消費”。有些用戶雖然心里明白想要什么，但卻說不清楚需求；或者用戶的描述開發(fā)人員無法理解。需求分析p 人員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，否則會連累整個開發(fā)團隊的。無論是什么原因導致用戶說不清楚需求，需求分析p 人員

14、必須設法搞清楚用戶真正的需求，這是需求分析p 人員的職責，也是職業(yè)的挑戰(zhàn)。2.3.6 雙方誤解需求 人們在交流的時候，經(jīng)常會發(fā)生“問非所求，答非所問”的事情。有時用戶會把開發(fā)人員的建議或答復給想歪了，反之亦然。同時用戶表達的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析p 人員誤解了需求，那會導致后續(xù)的不少開發(fā)人員將錯就錯、白干活。不論是復雜的項目還是簡單的項目，需求分析p 人員和用戶都有可能誤解需求；所以需求驗證工作必不可少。2.3.7 開發(fā)人員寫不好需求文檔 開發(fā)人員寫不好需求文檔的主要原因如下： 需求調查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。 開發(fā)人員寫作能力

15、比較差，雖然在調查過程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來。軟件開發(fā)人員的寫作能力可能遠不及其開發(fā)能力。提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習寫文檔，熟能生巧。另外，公司應當提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。2.3.8 用戶經(jīng)常變更需求 需求變更通常會對項目的進度、人力資、經(jīng)費產(chǎn)生很大的影響，這是開發(fā)商非常畏懼的問題。如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導致產(chǎn)品的部分內容需要重新開發(fā)。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方應當好好反省

16、，認真學習需求開發(fā)和管理的方法，避免再犯相似的錯誤。相關活動的描述詳見 4.2 節(jié)。3 3 需求開發(fā)3.1 需求調查 活動包括調查準備、搜集客戶需求資料、對客戶的需求/需要文件化、整理客戶的實際需求/需要；評審客戶需求/要求。3.1.1 調查準備 首先應確定產(chǎn)品的用戶群或產(chǎn)品的服務對象；并對需求分析p 人員進行業(yè)務技能培訓、對用戶代表進行需求階段相關知識的培訓。3.1.2 調查 活動實施 需求調查工作圍繞三項展開：調查什么？通過什么方式去調查？“何人”在“何時”調查？ 需求分析p 人員應當起草需求調查問題表，將調查重點鎖定在該問題表內，否則調查工作將變得漫無邊際。問題表可以有多份，隨著調查的深

17、入，問題表將不斷地被細化。根據(jù)經(jīng)驗，用戶通常沒有耐心回答復雜的“論述題”，所以問題表應當以“選擇題”和“是非題”為主。制定問題表最簡便的方法就是從用戶需求說明書的模板中提取需求問題。 需求分析p 人員應當確定需求調查的方式，例如： 與用戶交談，向用戶提問題； 參觀用戶的工作流程，觀察用戶的操作； 向用戶群體發(fā)調查問卷； 與同行、專家交談，聽取他們的意見； 分析p 已經(jīng)存在的同類軟件產(chǎn)品，提取需求； 從行業(yè)標準、規(guī)則中提取需求； 從 Inter 上搜查相關資料； 需求分析p 人員與被調查者建立聯(lián)系，確定調查的時間、地點、人員等，撰寫需求調查計劃。要特別留意的是不要漏掉典型的用戶。另外，如果有些事

18、情現(xiàn)場就能分析p 清楚，那么不要拖延到以后做。在調查需求的同時應當進行必要的需求分析p ，建議采用“問答分析p 法”，盡可能確定每個需求的基本要素，如“是什么”、“為什么”等。3.2 需求分析p 對客戶需求進行詳細分析p ，解決有關客戶需求/要求中存在的問題。對于不一致的問題要進行討論達成一定的共識，確定客戶需求/要求和將處理客戶需求的軟件項目之間建立對客戶需求的共同理解。由項目經(jīng)理等組織分析p 討論有關項目的具體客戶需求、SOW。需求分析p 的方法有很多種，主要有問答（比較適合于需求調查階段）和建模（比較適合于需求定義階段）方法：3.2.1 問答法 每個需求都應當用陳述句說明“是什么”，如果

19、“是什么”的內涵不夠清晰，則應補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。其它常見的問題有： 需求存在二義性嗎？ 需求文檔的上下文有矛盾嗎？ 需求完備嗎？ 需求是必要的嗎？ 需求可實現(xiàn)嗎？ 需求可驗證嗎？ 需求的優(yōu)先級確定了嗎？ 3.2.2 建模法 在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析p 方法主要有兩大類：“結構化分析p 法”和“面向對象

20、分析p 法”。1) 結構化分析p 法文獻Pressmen99, p206-p214對結構化分析p 方法作了高度概括，參見下圖： “數(shù)據(jù)字典”是中心，它包含了軟件中所有數(shù)據(jù)對象的描述。 “實體關系圖”是用圖形符號來標識數(shù)據(jù)對象以及它們之間的關系。 “數(shù)據(jù)流圖”指明了數(shù)據(jù)在系統(tǒng)中移動時如何被變換。 “狀態(tài)變遷圖”表示了系統(tǒng)存在的各種狀態(tài)以及它們之間的變遷方式。2) 面向對象分析p 法（ OOAD ）UML（統(tǒng)一建模語言）吸取了各種 OOAD 方法的精髓，對于 OOAD 中的語義、圖形表示法和使用規(guī)則作了完整而詳細的定義；成為 OOAD 建模語言的國際標準。UML 的建模能力超過了以往任何一種 OO

21、AD 方法，當然其復雜性也隨之膨脹。真正使 UML 流行的是 Rational 公司基于 UML 的建模工具 Rose。Rose 易學易用，它能交互式地構建類圖、用例圖、構件圖、部署圖、狀態(tài)圖、活動圖、順序圖、協(xié)作圖等等。3.3 需求定義 經(jīng)過調查與分析p ，確定下來的需求必須以文檔方式表達，定義分配給軟件的需求的文檔就是需求規(guī)格說明書；需求規(guī)格說明書的表達形式根據(jù)產(chǎn)品/項目的實際情況不同，通常是指由需求列表、需求規(guī)格說明書、需求式樣文檔、輔助性質的系統(tǒng)測試用例（關鍵用例）等共同組成的一組說明性文檔。具體可以參見軟件需求規(guī)格說明模板。需求規(guī)格說明書必須具有：正確性、完備性、一致性、無歧義性、可

22、驗證性、可修改性、必要性、可跟蹤性、可實現(xiàn)性、可理解性、有優(yōu)先級別的。3.3.1 正確性(Accuracy) 是指需求規(guī)格說明書應當正確地反映用戶的真實意圖，即當且僅當每個需求項都代表了要構造系統(tǒng)所要完成的事物；“正確”是需求規(guī)格說明書最重要的屬性。比較困難是開發(fā)者和用戶自己都不確定用戶究竟“想要什么”和“不要什么”；為確保需求是正確的，開發(fā)方和用戶必須對需求規(guī)格說明書進行驗證；驗證的基礎在于需求項是否對目標達成有貢獻。數(shù)據(jù)字典 實體關系圖 數(shù)據(jù)流圖 狀態(tài)變遷圖 3.3.2 完備(Complete) 是指需求規(guī)格說明書中沒有遺漏一些必要的需求，即 當且僅當該文檔描述了用戶關心的所有有意義的需求

23、，包括功能、性能、設計約束、屬性或外部接口有關的需求 （IEEE 830-1993, 4.3.3, 1994）。不完備的需求規(guī)格說明書將導致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。1) 非功能性需求的完備性建議創(chuàng)建一個遵循前面提供的適用性、可靠性、性能和可支持性指南的一個簡單的檢查列表，其覆蓋了在尋找設計約束是會問到的所有問題；并且關于非功能需求描述的數(shù)字化也是非常重要的。2) 功能性需求的完備性請應用領域的專家參與到功能性評審是非常有效的保證功能性需求的方法；開發(fā)人員同時也應該注意那些用戶固有的或他們認為顯而易見的需求。3) 通過原型開發(fā)保證完備性用例描述、需求評審以

24、及采用迭代方法為系統(tǒng)建立原型是有效的保證，越接近真正的使用，用戶對開發(fā)組提供的產(chǎn)品就越有經(jīng)驗，開發(fā)組也可以及時發(fā)現(xiàn)需求定義中的問題。特別需要重視的是，邊緣條件、異常處理等問題。3.3.3 一致性(Consistent) 是指需求規(guī)格說明書中各個需求項之間不會發(fā)生矛盾，即 當且僅當需求定義中沒有單個需求項的子集與另一個子集沖突 （IEEE 830-1993, 4.3.4.1, 1994）。矛盾常常潛伏在需求文檔的上下文中。例如：HR 系統(tǒng)需求的一部分可能要求“35 歲以上的員工每年有 15 個工作日的帶薪年休假”，而另外的章節(jié)可能要求“所有入司 10 年以上的員工每年有 10 個工作日的帶薪年休

25、假”，那么同時滿足這兩個條件的員工該如何確定休假期限？ 3.3.4 無歧義性(Unambiguous) 是指每個需求項有唯一的含義，即 當且僅當需求只有一種解釋 （IEEE 830-1993, 4.3.2, 1994）。如果需求存在二義性，將會導致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。為了使需求無二義性，在做成需求規(guī)格說明書時措詞應當準確，切勿模棱兩可。3.3.5 可驗證(Verifiable) 需求規(guī)格說明書中的各項需求對 用戶方而言應當都是可驗證的，即 當且僅當所包含的各個需求組件是可驗證的（斷定一條需求是可驗證當且僅當存在一個有限的、合理的過程，人或設備怾用它來確定所開發(fā)的軟件系統(tǒng)真正滿足

26、該需求）（IEEE 830-1993, 4.3.6, 1994）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。3.3.6 可修改性(Adaptable) 當且僅當需求規(guī)格說明的結構和風格是：可以對其中每個需求項的很容易地、完整地、一致地進行變更；同時保持已存在的需求規(guī)格定義的結構和風格 （IEEE 830-1993, 4.3.7, 1994）。這要求需求說明中具有最小的冗余并且以恰當?shù)哪夸?、索引以及交叉引用的能力很好地組織；并且應根據(jù)項目的規(guī)模和復雜性進行權衡。3.3.7 必要性(Necessary) 需求規(guī)格說明書中的各項需求對用戶而言應當都是必要的。“必要”往前一步，

27、要么是“畫蛇添足”要么是“錦上添花”。 “畫蛇添足”顯然是壞事，會導致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求。 “錦上添花”可能是好事，會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在需求規(guī)格說明書中將那些“錦上添花”的需求設置為較低的優(yōu)先級。如果左邊的圓代表用戶需求的全域，右邊的圓代表需求；則正確的需求是兩個圓重疊的區(qū)域，即區(qū)域 B；必要性就是保證 C 區(qū)域保持最小的冗余；完備性就是盡量減少因失誤帶來的區(qū)域 A 內容的增加。3.3.8 可

28、跟蹤性 指 當且僅當需求的各個需求模塊的來歷是清晰的，并且存在一種機制使得在未來的開發(fā)工作中引用該需求項是可行 （IEEE 830-1993, 4.3.8, 1994）。在實踐中，這通常意味著需求必須以唯一的編號或標記被標識。需求變更的可能性，導致了可跟蹤性的重要。當需要增加或刪除需求項的特征時，需要回溯到用戶處重新協(xié)商有關預算或進度時，這種能力將是非常必要的。3.3.9 可實現(xiàn)(Attainable) 需求規(guī)格說明書中的各項需求對 開發(fā)方而言應當都是可實現(xiàn)的?！翱蓪崿F(xiàn)”意味著在技術上是可行的，并且滿足時間、費用、質量等約束。對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應事先與用戶協(xié)

29、商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。3.3.10 可理解性 如果用戶和開發(fā)人員都能完全理解單個需求項和需求整體的全部功能，那么需求規(guī)格說明書就是可理解的。當系統(tǒng)分析p 人員細化需求定義，即產(chǎn)生詳細需求時，各種描述講更加詳細和明確，更多的開始采用技術性詞匯；因此文檔做成人員必須理解所有讀者的專業(yè)詞匯、術語和文化。另外用戶是否能從整體上理解系統(tǒng)的行為也非常重要，通常可以利用用例來描述運行環(huán)境輔助理解。3.3.11 確定優(yōu)先級別 理論上講，軟件的所有需求都應當被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資”等限制。優(yōu)先級就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一

30、般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。開發(fā)人員、客戶以及其他風險承擔人應該根據(jù)對客戶的重要性以及穩(wěn)定性 （IEEE 830-1993, 4.3.8, 1994）給每個需求項分級。用戶需求ABC陳述的需求 3.3.12 注意事項 需求規(guī)格說明書的重點是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設計和實現(xiàn)階段的事情。目前的開發(fā)組中，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設計、編程等工作從頭做到尾；所以他們在調查、分析p 、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調查、定義需求時想好了“怎么做”，當然應該寫下來；關鍵是不要將“怎么做”寫到需求規(guī)格說明里面，而是記

31、錄在其它文檔里（如概要設計文檔）。3.4 需求確認 需求確認是指開發(fā)方和客戶方共同對需求文檔如用戶需求說明書和需求規(guī)格說明書進行評審，雙方對需求達成共識后作出承諾。用戶需求說明書和需求規(guī)格說明書可以分開也可以放在一起進行需求確認，視項目的具體情況而定。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。3.4.1 需 需 求評審 1) 概述對工作成果的技術評審有兩類方式，一類是正式技術評審，另一類是非正式技術評審。對于任何重要的工作成果，都應該至少執(zhí)行一次正式技術評審，建議在正式技術評審之前進行若干次非正式技術評審。需求評審的規(guī)程與其它重要工作成果（如系統(tǒng)設計文檔、代碼）的評審規(guī)程非常相似，

32、主要區(qū)別在于評審人員的組成不同。前者由開發(fā)方和客戶方的代表共同組成（由項目經(jīng)理主持，部門經(jīng)理、質量工程師、客戶代表及有關人員參加），而后者通常開發(fā)方內部。2)注意事項 避免需求評審的“虎頭蛇尾”；應該嚴格的檢查需求規(guī)格說明文檔中的每個需求項，每行文字和每張圖表，因為認真評審一個小時可能會避免未來數(shù)十天的“開發(fā)”或“返工”；因此評審前應提前要求參與評審人員熟悉需求規(guī)格說明文檔，并按照確認單進行初步確認，然后帶著問題參與評審過程。 需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易；但是需要更注意需求項之間的一致性。 在需求評審時

33、主要解決的問題是應該作什么？當然討論其實現(xiàn)性時也允許開發(fā)人員談如何做，但不要談實現(xiàn)的細節(jié)，只要讓大家確信可以實現(xiàn)就行。 評審的對象只是需求，不是真理；所以評審過程中的意見分歧是非常正常的，“換位思考”是解決分歧的有效手段，更容易達到雙贏的結果。一旦對某個問題長時間無法達成共識，評審主持人必須終止無限期的爭議，并改而討論確定解決該問題的任務分配；相關內容必須記錄在評審報告中。3.4.2 需求承諾 與客戶一起評審需求規(guī)格說明書（如有確實的用戶代表需包含用戶代表在內），項目組和用戶代表必須對需求達成一致，并取得用戶代表的認可和批準。如果用戶代表同意需求規(guī)格說明書，需要簽字認可。承諾應包括如下內容：

34、需求文檔建立在雙方對需求的共同理解基礎之上； 雙方同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展； 若需求發(fā)生變化，將按照“變更控制規(guī)程”執(zhí)行；需求的變更將導致雙方重新協(xié)商成本、資和進度等。4 4 需求管理活動 4.1 需求跟蹤活動 參見需求管理過程第 3.2 節(jié)的相關內容。4.2 需求變更活動 4.2.1 需求變更的來 1) 變更原因分析p 對大多數(shù)項目而言，需求發(fā)生若干次變更似乎是不可避免的。需求發(fā)生變更的起因主要有： 隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。例如： 變更發(fā)生在用戶需求規(guī)格說明書或機能式樣書中，由于操作性的關系，GUI 方面的設計需要在后期被作為需求的形式固定下來； 變更發(fā)生在設計中，例如對于需求的某種修改和限定，使得系統(tǒng)可以更容易做成； 變更發(fā)生在編碼中，例如在實際實現(xiàn)中才發(fā)現(xiàn)的某些限制等。 市場或業(yè)務發(fā)生了變化，原先的需求定義內容可能跟不上當前