XXX 有限公司

　需求活動(dòng)指南

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

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

　 目 錄 1 1

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

　1.1

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

　1.2

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

　1.3

　讀者對(duì)象 ......................................................................................................................................... 1

　2 2

　需求活動(dòng)的重要性 性 .................................................................................................................................. 2

　2.1

　需求是項(xiàng)目能否成功的根本原因 ................................................................................................. 2

　2.2

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

　2.3

　需求活動(dòng)中的主要問題與對(duì)策 ..................................................................................................... 3

　2.3.1

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

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

　2.3.2

　知識(shí)與技能問題

　..................................................................................................................... 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)查活動(dòng)實(shí)施

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

　3.1.3

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

　...................................................................................... 錯(cuò)誤 ! 未定義書簽。

　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

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

　3.3.5

　可驗(yàn)證 (Verifiable) ................................................................................................................... 8

　3.3.6

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

　3.3.7

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

　3.3.8

　可跟蹤性

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

　3.3.9

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

　3.3.10

　可理解性

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

　3.3.11

　確定優(yōu)先級(jí)別

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

　3.3.12

　注意事項(xiàng)

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

　3.4

　需求確認(rèn) ....................................................................................................................................... 10

　3.4.1

　需求評(píng)審

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

　3.4.2

　需求承諾

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

　 4 4

　需求管理活動(dòng)......................................................................................................................................... 11

　4.1

　需求跟蹤活動(dòng) ................................................................................................................................ 11

　4.2

　需求變更活動(dòng) ................................................................................................................................ 11

　4.2.1

　需求變更的來源

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

　4.3

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

　4.4

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

　5 5

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

　5.1

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

　5.2

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

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

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

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

　錯(cuò)誤! ! 未找到引用源。

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

　2 2 需求活動(dòng)的重要性

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

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

　? 需求缺陷可能是最常見的缺陷； ? 需求缺陷可能是修改花費(fèi)最昂貴的錯(cuò)誤（可能消耗整個(gè)項(xiàng)目的 25%～40%）；參見下圖：

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

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

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

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

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

　階 段 需求時(shí)間 設(shè)計(jì) 編碼 單元測(cè)試 驗(yàn)收測(cè)試 維護(hù) 在生命周期不同階段修復(fù)缺陷的相對(duì)成本統(tǒng)計(jì)（Davis 1993）

　0.1 ～0.2 0.5 1 2 5 20

　2.3 需求活動(dòng)中的主要問題與對(duì)策 2.3.1 產(chǎn)品與集成項(xiàng)目是否都需要需求開發(fā)與管理活動(dòng) 由于合同項(xiàng)目的客戶是已知的，需求開發(fā)和需求管理的各項(xiàng)活動(dòng)可以有的放矢地開展。但是對(duì)于自主研發(fā)的產(chǎn)品而言，在產(chǎn)品沒有賣出之前，并不存在真正的用戶。由于用戶是未知的，究竟該向誰(shuí)調(diào)查需求？由誰(shuí)來確認(rèn)需求？其實(shí)，雖然待開發(fā)的產(chǎn)品尚未有真正的用戶，但必定有潛在的目標(biāo)用戶。開發(fā)人員可以向潛在的用戶們調(diào)查需求，請(qǐng)他們來確認(rèn)需求。如果因條件限制，無(wú)法直接與潛在的用戶溝通，可以通過角色扮演等方法，詳見 3.1.2 節(jié)； 2.3.2 知識(shí)與技能問題 由于專業(yè)和職業(yè)的原因，多數(shù)軟件開發(fā)人員不擅長(zhǎng)與用戶交流。有些人技術(shù)很出色，但與用戶在一起時(shí)有勁使不出；所以公司不能期望他們能夠無(wú)師自通地把需求開發(fā)工作做好，最好最快的解決辦法是培訓(xùn)。作為項(xiàng)目的領(lǐng)導(dǎo)，既然要把那么重要的工作（需求開發(fā)）交給開發(fā)人員去做，就要舍得花錢對(duì)開發(fā)人員進(jìn)行需求開發(fā)培訓(xùn)，幫助他們把需求開發(fā)工作做好。

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

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

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

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

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

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

　倘若用戶不能很好地配合需求分析人員，那并不表示他有問題。因?yàn)橛脩粲凶约旱南敕ǎ?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　2.3.6 雙方誤解需求 人們?cè)诮涣鞯臅r(shí)候，經(jīng)常會(huì)發(fā)生“問非所求，答非所問”的事情。有時(shí)用戶會(huì)把開發(fā)人員的建議或答復(fù)給想歪了，反之亦然。

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

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

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

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

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

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

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

　3 3 需求開發(fā)

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

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

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

　? 需求分析人員應(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)查的時(shí)間、地點(diǎn)、人員等，撰寫需求調(diào)查計(jì)劃。要特別留意的是不要漏掉典型的用戶。

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

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

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

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

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

　其它常見的問題有：

　? 需求存在二義性嗎？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　2) 功能性需求的完備性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　用戶需求

　 A

　 B

　C

　 陳述的需求

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

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

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

　需求確認(rèn)包含兩個(gè)重要工作：“需求評(píng)審”和“需求承諾”。

　3.4.1 需 需 求評(píng)審 1) 概述

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

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

　2)

　 注意事項(xiàng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　項(xiàng)目開發(fā)工作

　項(xiàng)目開發(fā)組織

　客戶/ / 用戶

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

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

　4.3 需求變更控制 1)

　需求變更控制的動(dòng)機(jī)是：

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

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

　2)

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

　4.4 需求狀態(tài)跟蹤活動(dòng) 參見《需求管理過程》第 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 ? 《基于軟件能力成熟度模型的軟件過程改進(jìn)》，鄭人杰等編著，清華大學(xué)出版社，2003 年3 月 ? Dean Leffingwell and Don Widrig: Managing Software Requirements:A Unified Approach 5.2 術(shù)語(yǔ)表 ? SOW：

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

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