XXX 有限公司

　需求活動指南

　文檔修訂記錄 版本編號 *變化 狀態(tài) 簡要說明 日期 變更人 批準(zhǔn)日期 批準(zhǔn)人 V1.0 A

　 *變化狀態(tài)：A——增加，M——修改，D——刪除

　 目 錄 1 1

　前言 ......................................................................................................................................................... 1

　1.1

　目的 ................................................................................................................................................. 1

　1.2

　適用范圍 ......................................................................................................................................... 1

　1.3

　讀者對象 ......................................................................................................................................... 1

　2 2

　需求活動的重要性 性 .................................................................................................................................. 2

　2.1

　需求是項目能否成功的根本原因 ................................................................................................. 2

　2.2

　了解客戶/ 用戶 ................................................................................................................................ 2

　2.3

　需求活動中的主要問題與對策 ..................................................................................................... 3

　2.3.1

　產(chǎn)品與集成項目是否都需要需求開發(fā)與管理活動

　............................................................. 3

　2.3.2

　知識與技能問題

　..................................................................................................................... 3

　2.3.3

　態(tài)度問題

　................................................................................................................................. 3

　2.3.4

　合作關(guān)系

　................................................................................................................................. 3

　2.3.5

　用戶說不清楚需求

　................................................................................................................. 4

　2.3.6

　雙方誤解需求

　......................................................................................................................... 4

　2.3.7

　開發(fā)人員寫不好需求文檔

　..................................................................................................... 4

　2.3.8

　用戶經(jīng)常變更需求

　................................................................................................................. 4

　3 3

　需求開發(fā) ................................................................................................................................................. 6

　3.1

　需求調(diào)查 ......................................................................................................................................... 6

　3.1.1

　調(diào)查準(zhǔn)備

　................................................................................................................................. 6

　3.1.2

　調(diào)查活動實施

　......................................................................................................................... 6

　3.1.3

　調(diào)查記錄與輸出

　...................................................................................... 錯誤 ! 未定義書簽。

　3.2

　需求分析 ......................................................................................................................................... 6

　3.2.1

　問答法

　..................................................................................................................................... 6

　3.2.2

　建模法

　..................................................................................................................................... 7

　3.3

　需求定義 ......................................................................................................................................... 7

　3.3.1

　正確性 (Accuracy) ................................................................................................................... 7

　3.3.2

　完備 (Complete) ....................................................................................................................... 8

　3.3.3

　一致性 (Consistent) ................................................................................................................. 8

　3.3.4

　無歧義性 (Unambiguous) ........................................................................................................ 8

　3.3.5

　可驗證 (Verifiable) ................................................................................................................... 8

　3.3.6

　可修改性 (Adaptable) .............................................................................................................. 8

　3.3.7

　必要性 (Necessary) .................................................................................................................. 8

　3.3.8

　可跟蹤性

　................................................................................................................................. 9

　3.3.9

　可實現(xiàn) (Attainable) .................................................................................................................. 9

　3.3.10

　可理解性

　................................................................................................................................. 9

　3.3.11

　確定優(yōu)先級別

　......................................................................................................................... 9

　3.3.12

　注意事項

　............................................................................................................................... 10

　3.4

　需求確認 ....................................................................................................................................... 10

　3.4.1

　需求評審

　............................................................................................................................... 10

　3.4.2

　需求承諾

　............................................................................................................................... 10

　 4 4

　需求管理活動......................................................................................................................................... 11

　4.1

　需求跟蹤活動 ................................................................................................................................ 11

　4.2

　需求變更活動 ................................................................................................................................ 11

　4.2.1

　需求變更的來源

　.................................................................................................................... 11

　4.3

　需求變更控制 ............................................................................................................................... 12

　4.4

　需求狀態(tài)跟蹤活動 ....................................................................................................................... 12

　5 5

　附錄 ....................................................................................................................................................... 12

　5.1

　引用文檔/ 參考資料 ...................................................................................................................... 12

　5.2

　術(shù)語表 ........................................................................................................................................... 12

　1 1 前言 1.1 目的 定義和描述需求活動的過程指南，指導(dǎo)需求開發(fā)、需求管理活動的實施。

　本文檔可以作為《需求管理過程》的擴展和補充內(nèi)容。

　1.2 適用范圍 本文檔對需求指南活動的描述適用于各種領(lǐng)域、各種類型的開發(fā)和測試模式的需求管理的相關(guān)活動； 本文檔的適用范圍為組織中的各項目。

　錯誤! ! 未找到引用源。

　1.3 讀者對象 本文檔的對象適用于開發(fā)和測試過程中的相關(guān)人員，特別是需求開發(fā)與需求管理人員；包括有關(guān)部門總監(jiān)、項目經(jīng)理、需求分析人員、系統(tǒng)分析人員、SQA 人員等相關(guān)人員。

　2 2 需求活動的重要性

　2.1 需求是項目能否成功的根本原因 項目開發(fā)的目標(biāo)是：

　在預(yù)算內(nèi)按時開發(fā)出符合客戶真正需要的高質(zhì)量的軟件系統(tǒng)。簡單的講，成功的軟件項目就是指那些可以達成這個目標(biāo)的項目。調(diào)查顯示（ESPITI 1995），與項目管理、軟件測試、文檔管理、編碼等問題比較起來，需求規(guī)格說明與管理客戶需求兩個問題被 3800 位被調(diào)查從業(yè)人員列為產(chǎn)業(yè)中最重要的問題。數(shù)據(jù)表明：

　? 需求缺陷可能是最常見的缺陷； ? 需求缺陷可能是修改花費最昂貴的錯誤（可能消耗整個項目的 25%～40%）；參見下圖：

　由此可以直觀的體會到，需求的開發(fā)與管理活動是決定項目是否成功的根本因素。

　2.2 了解客戶/ 用戶 客戶（customer）泛指與開發(fā)組織簽訂開發(fā)合同的組織或人；可以是代理商（往往代表許多最終用戶）、組織的信息管理部門，也可以指本組織內(nèi)的系統(tǒng)工程組、營業(yè)人員等。用戶（user）是對使用（操作）系統(tǒng)的人一種泛稱，可細分為最終用戶（the end user）和間接用戶（或稱為關(guān)系人）。

　掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶�？蛻襞c最終用戶可能是同一個人也可能不是同一個人。如果軟件是面向企業(yè)用戶的，那么客戶與最終用戶通常不是同一個人；例如日文印刷社排版系統(tǒng)的客戶可以看成是印刷社的系統(tǒng)工程部，而最終用戶則是印刷社的制作部門。

　軟件開發(fā)方與客戶打交道的主要目的是：一是獲取需求，二是簽合同�？蛻羲�說的需求一般比較宏觀，更詳細的需求應(yīng)該從最終用戶那里獲取。

　如果項目規(guī)模比較大，那么開發(fā)方與最終用戶的來往就比較多。如從最終用戶那里獲取詳細的需求，請最終用戶試驗軟件，對最終用戶進行培訓(xùn)等等。

　階 段 需求時間 設(shè)計 編碼 單元測試 驗收測試 維護 在生命周期不同階段修復(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)品沒有賣出之前，并不存在真正的用戶。由于用戶是未知的，究竟該向誰調(diào)查需求？由誰來確認需求？其實，雖然待開發(fā)的產(chǎn)品尚未有真正的用戶，但必定有潛在的目標(biāo)用戶。開發(fā)人員可以向潛在的用戶們調(diào)查需求，請他們來確認需求。如果因條件限制，無法直接與潛在的用戶溝通，可以通過角色扮演等方法，詳見 3.1.2 節(jié)； 2.3.2 知識與技能問題 由于專業(yè)和職業(yè)的原因，多數(shù)軟件開發(fā)人員不擅長與用戶交流。有些人技術(shù)很出色，但與用戶在一起時有勁使不出；所以公司不能期望他們能夠無師自通地把需求開發(fā)工作做好，最好最快的解決辦法是培訓(xùn)。作為項目的領(lǐng)導(dǎo)，既然要把那么重要的工作（需求開發(fā)）交給開發(fā)人員去做，就要舍得花錢對開發(fā)人員進行需求開發(fā)培訓(xùn)，幫助他們把需求開發(fā)工作做好。

　即使需求分析人員對需求調(diào)查、需求分析、需求定義已經(jīng)有了豐富的經(jīng)驗，但他們的知識仍然可能不夠用。應(yīng)用領(lǐng)域的知識是無邊無際、不斷更新的，任何人都不可能是“萬事通”。當(dāng)需求分析人員缺乏應(yīng)用領(lǐng)域知識時，首先要有勇氣做事，否則連實踐的機會都沒有；其次應(yīng)當(dāng)趕緊補習(xí)應(yīng)用領(lǐng)域知識，不論是通過自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。如果可能的話，開發(fā)組最好請既懂軟件又懂應(yīng)用領(lǐng)域知識的行家來幫忙。

　如果需求分析人員完全不了解應(yīng)用領(lǐng)域，而用戶幾乎是個計算機盲，并且雙方都不愿意主動了解對方領(lǐng)域的事情，這種狀況下的需求開發(fā)很難成功。

　2.3.3 態(tài)度問題 相當(dāng)多的開發(fā)人員習(xí)慣于被動地對待需求開發(fā)。每當(dāng)遇到麻煩、挫折時，他們會發(fā)牢騷，找出一堆用戶的毛病。這是普遍現(xiàn)象，并不是開發(fā)人員懶惰所造成的，而是不正確的觀念誤導(dǎo)了他們：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應(yīng)當(dāng)開發(fā)什么嗎？如果用戶說不清楚需求，或經(jīng)常變更需求，這類問題是用戶產(chǎn)生的，應(yīng)當(dāng)由他們自己負責(zé)。

　用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設(shè)法解決的。可悲的是開發(fā)人員把這些問題當(dāng)成了借口，不愿主動攻克問題，導(dǎo)致需求問題擴散到整個軟件開發(fā)過程，產(chǎn)生太多的后患。

　其實需求分析人員的工作就是在有限的時間內(nèi)獲取準(zhǔn)確而細致的用戶需求，如果做不到就是失職，不要找借口。

　2.3.4 合作關(guān)系 如果需求分析人員不具備較強的交流、溝通能力，無法與用戶建立良好的合作關(guān)系，那么即使他們有過硬的專業(yè)知識與行業(yè)背景，在需求開發(fā)過程中也會很疲憊。

　倘若用戶不能很好地配合需求分析人員，那并不表示他有問題。因為用戶有自己的想法：

　? 我回答了你們的問題，講了該講的。

　? 我們付錢給你們，難道還要我伺候你們不成？ ? 我還要干自己的事情，別再打擾我。

　? 你們自己想辦法把活干好吧…… 對于一些競標(biāo)項目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產(chǎn)品，他不會投入很多精力來協(xié)助你搞需求開發(fā)。

　開發(fā)方與用戶的合作關(guān)系對需求開發(fā)而言是至關(guān)重要的。對于重大的、復(fù)雜的項目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關(guān)系，這樣風(fēng)險太大。推薦一種方法：開發(fā)方和用戶方在開展需求開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權(quán)利與義務(wù)”，即以協(xié)議的方式確

　定合作關(guān)系。“好話”和“丑話”都說在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。

　表 4-1 列舉了用戶在需求工程中的“權(quán)利與義務(wù)”，項目組可以根據(jù)實際情況適當(dāng)?shù)匦薷摹?/p>

　用戶的權(quán)利 1. 有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析人員和相關(guān)人員。

　2. 有權(quán)要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂的需求文檔。

　3. 有權(quán)審查需求文檔，并對有爭議的需求作出決策。如果認為需求文檔不能準(zhǔn)確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。

　4. 如果用戶想要變更需求，有權(quán)要求開發(fā)方對該變更將產(chǎn)生的影響作出真實可信的評估，以便用戶決定是否變更需求。

　用戶的義務(wù) 1. 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。

　2. 樂意接受需求分析人員的采訪，在不泄漏機密的前提下，盡可能地回答需求分析人員的問題。

　3. 在不泄漏機密的前提下，盡可能地向需求分析人員提供與需求相關(guān)的材料。

　4. 與需求分析人員共同評審需求文檔，確保需求文檔準(zhǔn)確地反映用戶真實的意愿。

　5. 不輕易變更需求。如果需要變更需求的話，按照“需求變更控制規(guī)程”執(zhí)行，而非強迫開發(fā)方接受。

　2.3.5 用戶說不清楚需求 用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛的大問題。

　有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當(dāng)然說不清楚需求。開發(fā)人員可能覺得奇怪：用戶自己都不知道要什么，為什么還要我們開發(fā)軟件？這種現(xiàn)象有些時候是正常的，例如開發(fā)方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導(dǎo)用戶“消費”。有些用戶雖然心里明白想要什么，但卻說不清楚需求；或者用戶的描述開發(fā)人員無法理解。

　需求分析人員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，否則會連累整個開發(fā)團隊的。無論是什么原因?qū)е掠脩粽f不清楚需求，需求分析人員必須設(shè)法搞清楚用戶真正的需求，這是需求分析人員的職責(zé)，也是職業(yè)的挑戰(zhàn)。

　2.3.6 雙方誤解需求 人們在交流的時候，經(jīng)常會發(fā)生“問非所求，答非所問”的事情。有時用戶會把開發(fā)人員的建議或答復(fù)給想歪了，反之亦然。

　同時用戶表達的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析人員誤解了需求，那會導(dǎo)致后續(xù)的不少開發(fā)人員將錯就錯、白干活。

　不論是復(fù)雜的項目還是簡單的項目，需求分析人員和用戶都有可能誤解需求；所以需求驗證工作必不可少。

　2.3.7 開發(fā)人員寫不好需求文檔 開發(fā)人員寫不好需求文檔的主要原因如下：

　? 需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。

　? 開發(fā)人員寫作能力比較差，雖然在調(diào)查過程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來。軟件開發(fā)人員的寫作能力可能遠不及其開發(fā)能力。提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習(xí)寫文檔，熟能生巧。另外，公司應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。

　2.3.8 用戶經(jīng)常變更需求 需求變更通常會對項目的進度、人力資源、經(jīng)費產(chǎn)生很大的影響，這是開發(fā)商非常畏懼的問題。

　如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方應(yīng)當(dāng)好好反省，認真學(xué)習(xí)需求開發(fā)和管理的方法，避免再犯相似的錯誤。相關(guān)活動的描述詳見 4.2 節(jié)。

　3 3 需求開發(fā)

　3.1 需求調(diào)查 活動包括調(diào)查準(zhǔn)備、搜集客戶需求資料、對客戶的需求/需要文件化、整理客戶的實際需求/需要；評審客戶需求/要求。

　3.1.1 調(diào)查準(zhǔn)備 首先應(yīng)確定產(chǎn)品的用戶群或產(chǎn)品的服務(wù)對象；并對需求分析人員進行業(yè)務(wù)技能培訓(xùn)、對用戶代表進行需求階段相關(guān)知識的培訓(xùn)。

　3.1.2 調(diào)查 活動實施 需求調(diào)查工作圍繞三項展開：調(diào)查什么？通過什么方式去調(diào)查？“何人”在“何時”調(diào)查？ ? 需求分析人員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。問題表可以有多份，隨著調(diào)查的深入，問題表將不斷地被細化。根據(jù)經(jīng)驗，用戶通常沒有耐心回答復(fù)雜的“論述題”，所以問題表應(yīng)當(dāng)以“選擇題”和“是非題”為主。制定問題表最簡便的方法就是從《用戶需求說明書》的模板中提取需求問題。

　? 需求分析人員應(yīng)當(dāng)確定需求調(diào)查的方式，例如：

　? 與用戶交談，向用戶提問題； ? 參觀用戶的工作流程，觀察用戶的操作；

　? 向用戶群體發(fā)調(diào)查問卷； ? 與同行、專家交談，聽取他們的意見；

　? 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求；

　? 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求； ? 從 Internet 上搜查相關(guān)資料； ? 需求分析人員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等，撰寫需求調(diào)查計劃。要特別留意的是不要漏掉典型的用戶。

　另外，如果有些事情現(xiàn)場就能分析清楚，那么不要拖延到以后做。在調(diào)查需求的同時應(yīng)當(dāng)進行必要的需求分析，建議采用“問答分析法”，盡可能確定每個需求的基本要素，如“是什么”、“為什么”等。

　3.2 需求分析 對客戶需求進行詳細分析，解決有關(guān)客戶需求/要求中存在的問題。對于不一致的問題要進行討論達成一定的共識，確定客戶需求/要求和將處理客戶需求的軟件項目之間建立對客戶需求的共同理解。

　由項目經(jīng)理等組織分析討論有關(guān)項目的具體客戶需求、SOW。

　需求分析的方法有很多種，主要有問答（比較適合于需求調(diào)查階段）和建模（比較適合于需求定義階段）方法：

　3.2.1 問答法 每個需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。

　其它常見的問題有：

　? 需求存在二義性嗎？

　? 需求文檔的上下文有矛盾嗎？ ? 需求完備嗎？ ? 需求是必要的嗎？ ? 需求可實現(xiàn)嗎？ ? 需求可驗證嗎？ ? 需求的優(yōu)先級確定了嗎？ 3.2.2 建模法 在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇?rdquo;。

　1) 結(jié)構(gòu)化分析法

　文獻[Pressmen99, p206-p214]對結(jié)構(gòu)化分析方法作了高度概括，參見下圖：

　? “數(shù)據(jù)字典”是中心，它包含了軟件中所有數(shù)據(jù)對象的描述。

　? “實體－關(guān)系圖”是用圖形符號來標(biāo)識數(shù)據(jù)對象以及它們之間的關(guān)系。

　? “數(shù)據(jù)流圖”指明了數(shù)據(jù)在系統(tǒng)中移動時如何被變換。

　? “狀態(tài)－變遷圖”表示了系統(tǒng)存在的各種狀態(tài)以及它們之間的變遷方式。

　2) 面向?qū)ο蠓治龇ǎ?OOAD ）

　UML（統(tǒng)一建模語言）吸取了各種 OOAD 方法的精髓，對于 OOAD 中的語義、圖形表示法和使用規(guī)則作了完整而詳細的定義；成為 OOAD 建模語言的國際標(biāo)準(zhǔn)。UML 的建模能力超過了以往任何一種 OOAD 方法，當(dāng)然其復(fù)雜性也隨之膨脹。

　真正使 UML 流行的是 Rational 公司基于 UML 的建模工具 Rose。Rose 易學(xué)易用，它能交互式地構(gòu)建類圖、用例圖、構(gòu)件圖、部署圖、狀態(tài)圖、活動圖、順序圖、協(xié)作圖等等。

　3.3 需求定義 經(jīng)過調(diào)查與分析，確定下來的需求必須以文檔方式表達，定義分配給軟件的需求的文檔就是《需求規(guī)格說明書》；《需求規(guī)格說明書》的表達形式根據(jù)產(chǎn)品/項目的實際情況不同，通常是指由《需求列表》、《需求規(guī)格說明書》、需求式樣文檔、輔助性質(zhì)的系統(tǒng)測試用例（關(guān)鍵用例）等共同組成的一組說明性文檔。具體可以參見軟件需求規(guī)格說明模板。

　《需求規(guī)格說明書》必須具有：正確性、完備性、一致性、無歧義性、可驗證性、可修改性、必要性、可跟蹤性、可實現(xiàn)性、可理解性、有優(yōu)先級別的。

　3.3.1 正確性(Accuracy) 是指《需求規(guī)格說明書》應(yīng)當(dāng)正確地反映用戶的真實意圖，即當(dāng)且僅當(dāng)每個需求項都代表了要構(gòu)造系統(tǒng)所要完成的事物；“正確”是《需求規(guī)格說明書》最重要的屬性。比較困難是開發(fā)者和用戶自己都不確定用戶究竟“想要什么”和“不要什么”；為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行驗證；驗證的基礎(chǔ)在于需求項是否對目標(biāo)達成有貢獻。

　數(shù)據(jù)字典 實體－關(guān)系圖 數(shù)據(jù)流圖 狀態(tài)－變遷圖

　3.3.2 完備(Complete) 是指《需求規(guī)格說明書》中沒有遺漏一些必要的需求，即 當(dāng)且僅當(dāng)該文檔描述了用戶關(guān)心的所有有意義的需求，包括功能、性能、設(shè)計約束、屬性或外部接口有關(guān)的需求 （IEEE 830-1993, 4.3.3, 1994）。不完備的《需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預(yù)期的任務(wù)。

　1) 非功能性需求的完備性

　建議創(chuàng)建一個遵循前面提供的適用性、可靠性、性能和可支持性指南的一個簡單的檢查列表，其覆蓋了在尋找設(shè)計約束是會問到的所有問題；并且關(guān)于非功能需求描述的數(shù)字化也是非常重要的。

　2) 功能性需求的完備性

　請應(yīng)用領(lǐng)域的專家參與到功能性評審是非常有效的保證功能性需求的方法；開發(fā)人員同時也應(yīng)該注意那些用戶固有的或他們認為顯而易見的需求。

　3) 通過原型開發(fā)保證完備性

　用例描述、需求評審以及采用迭代方法為系統(tǒng)建立原型是有效的保證，越接近真正的使用，用戶對開發(fā)組提供的產(chǎn)品就越有經(jīng)驗，開發(fā)組也可以及時發(fā)現(xiàn)需求定義中的問題。特別需要重視的是，邊緣條件、異常處理等問題。

　3.3.3 一致性(Consistent) 是指《需求規(guī)格說明書》中各個需求項之間不會發(fā)生矛盾，即 當(dāng)且僅當(dāng)需求定義中沒有單個需求項的子集與另一個子集沖突 （IEEE 830-1993, 4.3.4.1, 1994）。矛盾常常潛伏在需求文檔的上下文中。

　例如：HR 系統(tǒng)需求的一部分可能要求“35 歲以上的員工每年有 15 個工作日的帶薪年休假”，而另外的章節(jié)可能要求“所有入司 10 年以上的員工每年有 10 個工作日的帶薪年休假”，那么同時滿足這兩個條件的員工該如何確定休假期限？ 3.3.4 無歧義性(Unambiguous) 是指每個需求項有唯一的含義，即 當(dāng)且僅當(dāng)需求只有一種解釋 （IEEE 830-1993, 4.3.2, 1994）。如果需求存在二義性，將會導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。

　為了使需求無二義性，在做成《需求規(guī)格說明書》時措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。

　3.3.5 可驗證(Verifiable) 《需求規(guī)格說明書》中的各項需求對 用戶方而言應(yīng)當(dāng)都是可驗證的，即 當(dāng)且僅當(dāng)所包含的各個需求組件是可驗證的（斷定一條需求是可驗證當(dāng)且僅當(dāng)存在一個有限的、合理的過程，人或設(shè)備怾用它來確定所開發(fā)的軟件系統(tǒng)真正滿足該需求）

　（IEEE 830-1993, 4.3.6, 1994）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。

　3.3.6 可修改性(Adaptable) 當(dāng)且僅當(dāng)需求規(guī)格說明的結(jié)構(gòu)和風(fēng)格是：可以對其中每個需求項的很容易地、完整地、一致地進行變更；同時保持已存在的需求規(guī)格定義的結(jié)構(gòu)和風(fēng)格 （IEEE 830-1993, 4.3.7, 1994）。這要求需求說明中具有最小的冗余并且以恰當(dāng)?shù)哪夸�、索引以及交叉引用的能力很好地組織；并且應(yīng)根據(jù)項目的規(guī)模和復(fù)雜性進行權(quán)衡。

　3.3.7 必要性(Necessary) 《需求規(guī)格說明書》中的各項需求對用戶而言應(yīng)當(dāng)都是必要的。

　“必要”往前一步，要么是“畫蛇添足”要么是“錦上添花”。

　? “畫蛇添足”顯然是壞事，會導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需

　求規(guī)格說明書中“畫蛇添足”的那些需求。

　? “錦上添花”可能是好事，會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在《需求規(guī)格說明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級。

　如果左邊的圓代表用戶需求的全域，右邊的圓代表需求；則正確的需求是兩個圓重疊的區(qū)域，即區(qū)域 B；必要性就是保證 C 區(qū)域保持最小的冗余；完備性就是盡量減少因失誤帶來的區(qū)域 A 內(nèi)容的增加。

　3.3.8 可跟蹤性 指 當(dāng)且僅當(dāng)需求的各個需求模塊的來歷是清晰的，并且存在一種機制使得在未來的開發(fā)工作中引用該需求項是可行 （IEEE 830-1993, 4.3.8, 1994）。在實踐中，這通常意味著需求必須以唯一的編號或標(biāo)記被標(biāo)識。

　需求變更的可能性，導(dǎo)致了可跟蹤性的重要。當(dāng)需要增加或刪除需求項的特征時，需要回溯到用戶處重新協(xié)商有關(guān)預(yù)算或進度時，這種能力將是非常必要的。

　3.3.9 可實現(xiàn)(Attainable) 《需求規(guī)格說明書》中的各項需求對 開發(fā)方而言應(yīng)當(dāng)都是可實現(xiàn)的。“可實現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時間、費用、質(zhì)量等約束。

　對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應(yīng)事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。

　3.3.10 可理解性 如果用戶和開發(fā)人員都能完全理解單個需求項和需求整體的全部功能，那么《需求規(guī)格說明書》就是可理解的。當(dāng)系統(tǒng)分析人員細化需求定義，即產(chǎn)生詳細需求時，各種描述講更加詳細和明確，更多的開始采用技術(shù)性詞匯；因此文檔做成人員必須理解所有讀者的專業(yè)詞匯、術(shù)語和文化。另外用戶是否能從整體上理解系統(tǒng)的行為也非常重要，通常可以利用用例來描述運行環(huán)境輔助理解。

　3.3.11 確定優(yōu)先級別 理論上講，軟件的所有需求都應(yīng)當(dāng)被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。優(yōu)先級就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。

　開發(fā)人員、客戶以及其他風(fēng)險承擔(dān)人應(yīng)該根據(jù)對客戶的重要性以及穩(wěn)定性 （IEEE 830-1993, 4.3.8, 1994）給每個需求項分級。

　用戶需求

　 A

　 B

　C

　 陳述的需求

　3.3.12 注意事項 《需求規(guī)格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”。“怎么做”是系統(tǒng)設(shè)計和實現(xiàn)階段的事情。

　目前的開發(fā)組中，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計、編程等工作從頭做到尾；所以他們在調(diào)查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調(diào)查、定義需求時想好了“怎么做”，當(dāng)然應(yīng)該寫下來；關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明里面，而是記錄在其它文檔里（如概要設(shè)計文檔）。

　3.4 需求確認 需求確認是指開發(fā)方和客戶方共同對需求文檔如《用戶需求說明書》和《需求規(guī)格說明書》進行評審，雙方對需求達成共識后作出承諾�！队脩粜枨笳f明書》和《需求規(guī)格說明書》可以分開也可以放在一起進行需求確認，視項目的具體情況而定。

　需求確認包含兩個重要工作：“需求評審”和“需求承諾”。

　3.4.1 需 需 求評審 1) 概述

　對工作成果的技術(shù)評審有兩類方式，一類是正式技術(shù)評審，另一類是非正式技術(shù)評審。對于任何重要的工作成果，都應(yīng)該至少執(zhí)行一次正式技術(shù)評審，建議在正式技術(shù)評審之前進行若干次非正式技術(shù)評審。

　需求評審的規(guī)程與其它重要工作成果（如系統(tǒng)設(shè)計文檔、源代碼）的評審規(guī)程非常相似，主要區(qū)別在于評審人員的組成不同。前者由開發(fā)方和客戶方的代表共同組成（由項目經(jīng)理主持，部門經(jīng)理、質(zhì)量工程師、客戶代表及有關(guān)人員參加），而后者通常來源于開發(fā)方內(nèi)部。

　2)

　 注意事項

　? 避免需求評審的“虎頭蛇尾”；應(yīng)該嚴(yán)格的檢查需求規(guī)格說明文檔中的每個需求項，每行文字和每張圖表，因為認真評審一個小時可能會避免未來數(shù)十天的“開發(fā)”或“返工”；因此評審前應(yīng)提前要求參與評審人員熟悉需求規(guī)格說明文檔，并按照確認單進行初步確認，然后帶著問題參與評審過程。

　? 需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易；但是需要更注意需求項之間的一致性。

　? 在需求評審時主要解決的問題是應(yīng)該作什么？當(dāng)然討論其實現(xiàn)性時也允許開發(fā)人員談如何做，但不要談實現(xiàn)的細節(jié)，只要讓大家確信可以實現(xiàn)就行。

　? 評審的對象只是需求，不是真理；所以評審過程中的意見分歧是非常正常的，“換位思考”是解決分歧的有效手段，更容易達到雙贏的結(jié)果。一旦對某個問題長時間無法達成共識，評審主持人必須終止無限期的爭議，并改而討論確定解決該問題的任務(wù)分配；相關(guān)內(nèi)容必須記錄在評審報告中。

　3.4.2 需求承諾 與客戶一起評審《需求規(guī)格說明書》（如有確實的用戶代表需包含用戶代表在內(nèi)），項目組和用戶代表必須對需求達成一致，并取得用戶代表的認可和批準(zhǔn)。如果用戶代表同意《需求規(guī)格說明書》，需要簽字認可。

　承諾應(yīng)包括如下內(nèi)容：

　? 需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上； ? 雙方同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展； ? 若需求發(fā)生變化，將按照“變更控制規(guī)程”執(zhí)行；需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等。

　 4 4 需求管理活動 4.1 需求跟蹤活動 參見《需求管理過程》第 3.2 節(jié)的相關(guān)內(nèi)容。

　4.2 需求變更活動 4.2.1 需求變更的來源 1) 變更原因分析 對大多數(shù)項目而言，需求發(fā)生若干次變更似乎是不可避免的。需求發(fā)生變更的起因主要有：

　? 隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。例如：

　? 變更發(fā)生在用戶需求規(guī)格說明書或機能式樣書中，由于操作性的關(guān)系，GUI 方面的設(shè)計需要在后期被作為需求的形式固定下來； ? 變更發(fā)生在設(shè)計中，例如對于需求的某種修改和限定，使得系統(tǒng)可以更容易做成； ? 變更發(fā)生在編碼中，例如在實際實現(xiàn)中才發(fā)現(xiàn)的某些限制等。

　? 市場或業(yè)務(wù)發(fā)生了變化，原先的需求定義內(nèi)容可能跟不上當(dāng)前的市場或業(yè)務(wù)需要，因此要變更需求。

　2) 變更影響分析 提出需求變更的動機是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項目開發(fā)組而言，變更需求的影響在于：

　? 使得變更前的開發(fā)工作和成果失效； ? 使變更需求項相關(guān)的開發(fā)活動返工； ? 要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)組要為此付出較重的代價。

　3) 降低變更風(fēng)險 ? 在需求開發(fā)活動中與客戶/用戶充分溝通；

　? 向用戶介紹開發(fā)流程，明確穩(wěn)定的需求對開發(fā)過程的重要意義，參見下表：

　項目開發(fā)工作

　項目開發(fā)組織

　客戶/ / 用戶

　需求是產(chǎn)品后續(xù)開發(fā)工作的基礎(chǔ)； 需求是產(chǎn)品維護工作的參考； 對用戶的承諾； 關(guān)系到項目開發(fā)工作的投入、交付期限和產(chǎn)品質(zhì)量 關(guān)系到能否按期獲取所需產(chǎn)品； 需求文檔 作為合同的附件，關(guān)系到雙方的利益； 是產(chǎn)品驗收的依據(jù)； ? 由于需求定義不確切、頻繁變更會給開發(fā)過程帶來沖擊；而且需求變更越晚提出，對開發(fā)過程與成本的壓力越大； ? 需求變更會影響到項目進度與質(zhì)量，所以變更應(yīng)該慎重。

　? 吸收用戶參與需求開發(fā)，交流采用文檔方式； ? 項目開發(fā)合同、需求評審報告中明確開發(fā)中對需求變更的應(yīng)對條款，并經(jīng)雙方批準(zhǔn)； ? 對于項目自身具有需求不確定的特點，建議采用快速原型模型和螺旋模型等適合的生命周期模型； ? 項目策劃活動中，根據(jù)需求變更的風(fēng)險，提高開發(fā)計劃的可調(diào)節(jié)性； ? 嚴(yán)格實施需求變更控制。

　4.3 需求變更控制 1)

　需求變更控制的動機是：

　? 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。

　? 如果需求變更帶來的壞處大于好處，那么拒絕變更。

　2)

　由于需求文檔是重要的配置項，需求的變更應(yīng)當(dāng)遵循配置管理中的變更控制規(guī)程。

　4.4 需求狀態(tài)跟蹤活動 參見《需求管理過程》第 3.4 節(jié)的相關(guān)內(nèi)容。

　5 5 附錄

　5.1 引用文檔/ 參考資料 ? 引用文檔 ? 《需求管理方針》

　 ? 《需求管理過程》

　 ? 參考資料：

　? Paulk, Mark C., et al. Capability Maturity Model for Software, Version 1.1 CMU/SEI-93-TR-24 ? Paulk, Mark C., et al. Key Practices of the Capability Maturity Model,Version 1.1, CMU/SEI-93-TR-25 ? 《基于軟件能力成熟度模型的軟件過程改進》，鄭人杰等編著，清華大學(xué)出版社，2003 年3 月 ? Dean Leffingwell and Don Widrig: Managing Software Requirements:A Unified Approach 5.2 術(shù)語表 ? SOW：

　Statement Of Works， 工作內(nèi)容陳述 其它參見《需求管理過程》相關(guān)

相關(guān)熱詞搜索：需求 指南 活動