軟件項(xiàng)目中的需求管理系統(tǒng)設(shè)計(jì)與開發(fā)(軟件工程課程設(shè)計(jì))

1、軟件項(xiàng)目中的需求管理系統(tǒng)設(shè)計(jì)與開發(fā)軟件工程課程設(shè)計(jì) 目錄摘要 : 錯(cuò)誤!未定義書簽。【 Abstract】 錯(cuò)誤!未定義書簽。 TOC o 1-5 h z HYPERLINK l bookmark2 o Current Document 引言 3 HYPERLINK l bookmark4 o Current Document 第一章 需求及需求管理概述4 HYPERLINK l bookmark6 o Current Document 軟件需求的定義4 HYPERLINK l bookmark8 o Current Document 關(guān)于“需求”的解釋 4 HYPERLINK l bookm

2、ark10 o Current Document 需求的層次 4 HYPERLINK l bookmark12 o Current Document 需求管理的概念5 HYPERLINK l bookmark14 o Current Document 需求管理的概念 5 HYPERLINK l bookmark16 o Current Document .需求管理目標(biāo)及需求管理要點(diǎn) 5 HYPERLINK l bookmark18 o Current Document 小結(jié) 6 HYPERLINK l bookmark20 o Current Document 第二章項(xiàng)目及項(xiàng)目背景簡介7 HY

3、PERLINK l bookmark22 o Current Document “廈門*公司墓石cad設(shè)計(jì)系統(tǒng)”項(xiàng)目背景介紹 7 HYPERLINK l bookmark24 o Current Document “廈門*公司墓石cad設(shè)計(jì)系統(tǒng)”項(xiàng)目介紹 7 HYPERLINK l bookmark34 o Current Document 第三章需求獲取階段的控制和管理 12 HYPERLINK l bookmark61 o Current Document 概述 12 HYPERLINK l bookmark37 o Current Document 前提 12 HYPERLINK l b

4、ookmark39 o Current Document 約定 12 HYPERLINK l bookmark41 o Current Document 獲取需求規(guī)格說明書 13 HYPERLINK l bookmark43 o Current Document 調(diào)研前的準(zhǔn)備 13 HYPERLINK l bookmark45 o Current Document 調(diào)研過程 13 HYPERLINK l bookmark47 o Current Document 整體調(diào)研 14 HYPERLINK l bookmark49 o Current Document 具體業(yè)務(wù)調(diào)研 14 HYPERL

5、INK l bookmark51 o Current Document 對(duì)需求說明書的確認(rèn) 15 HYPERLINK l bookmark53 o Current Document 總結(jié) 15 HYPERLINK l bookmark55 o Current Document 編制開發(fā)計(jì)劃 16 HYPERLINK l bookmark57 o Current Document 小結(jié) 16 HYPERLINK l bookmark59 o Current Document 第四章項(xiàng)目開發(fā)過程中的需求管理 18 HYPERLINK l bookmark96 o Current Document

6、概述 18 HYPERLINK l bookmark63 o Current Document 選擇開發(fā)策略 18 HYPERLINK l bookmark65 o Current Document 系統(tǒng)原型設(shè)計(jì)開發(fā) 19 HYPERLINK l bookmark67 o Current Document 溝通 20 HYPERLINK l bookmark69 o Current Document 在軟件項(xiàng)目開發(fā)過程中主要溝通的方面 20 HYPERLINK l bookmark71 o Current Document 可以選擇的溝通方式 20 HYPERLINK l bookmark73

7、 o Current Document 小結(jié) 20變更控制 21前言 21 HYPERLINK l bookmark78 o Current Document 變更產(chǎn)生的原因 21 HYPERLINK l bookmark80 o Current Document 在軟件項(xiàng)目中如何控制變更 22 HYPERLINK l bookmark82 o Current Document 拒絕的方法 22 HYPERLINK l bookmark84 o Current Document 客戶提出需求變更 23 HYPERLINK l bookmark86 o Current Document 版本控制

8、 24 HYPERLINK l bookmark88 o Current Document 資料留存 24 HYPERLINK l bookmark90 o Current Document 復(fù)用策略 25 HYPERLINK l bookmark92 o Current Document 小結(jié) 25 HYPERLINK l bookmark94 o Current Document 第五章 總結(jié) 27概述 27 HYPERLINK l bookmark98 o Current Document 如何做好需求分析和變更管理?27引言人們常問：“需求、設(shè)計(jì)、編程、測試四者究竟哪個(gè)重要？”這個(gè)問題

9、并不好回答。四者都是軟件開發(fā)過程中必不可少的環(huán)節(jié)，只做好其中一個(gè)環(huán)節(jié)并不能產(chǎn)生好的系統(tǒng)，但是做壞了其中任何一個(gè)環(huán)節(jié)，必定對(duì)系統(tǒng)產(chǎn)生壞的影響。若站在風(fēng)險(xiǎn)管理的角度講，我認(rèn)為需求開發(fā)與管理是最重要的環(huán)節(jié)。因?yàn)樾枨笫钱a(chǎn)品的根源，需求工作的優(yōu)劣對(duì)產(chǎn)品的影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。Frederick Brooks 在他 1987 年經(jīng)典文章“No Silver Bullet ”中闡述了需求的重要性：“開發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說明開發(fā)什么。最困難的概念性工作是編寫出詳細(xì)的需求，包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。此工作一旦做錯(cuò)，將會(huì)給系統(tǒng)帶來極大

10、的損害，并且以后對(duì)它修改也極為困難?！睂?duì)于一個(gè)軟件項(xiàng)目，開發(fā)和實(shí)現(xiàn)用戶所真正需要的產(chǎn)品是非常重要的。軟件產(chǎn)品的成功與否很大程度上取決于對(duì)需求的管理。像我下面要介紹的項(xiàng)目一一“廈門*公司墓石cad設(shè)計(jì)系統(tǒng)”的成功，我覺得首先就要?dú)w功于我們對(duì)它進(jìn)行了有效的需求管理。但是，談到軟件產(chǎn)品的需求管理，我們認(rèn)為遇到了一個(gè)非常棘手的問題。實(shí)際上由于面對(duì)的客戶和市場環(huán)境的不同，需求可以變得非常復(fù)雜，這種復(fù)雜往往又是動(dòng)態(tài)的和難以描述的?？蛻舻男枨笸呛芨爬ǖ模袝r(shí)又是很具體的?？蛻粲袝r(shí)會(huì)說:“我們需要一個(gè)整體解決方案”，有時(shí)又說:“圖紙上的作者要這樣寫”。顯然這樣的需求無法被我們完全接受?？蛻舻囊箫@然是重要

11、的，產(chǎn)品應(yīng)該以客戶為導(dǎo)，如何把客戶的需求變成我們技術(shù)人員能夠接受的功能說明書，相反如何在產(chǎn)品開發(fā)前就讓客戶認(rèn)可最終的產(chǎn)品，或者使用戶的需要與產(chǎn)品之間不應(yīng)有過大的偏差。此外，軟件項(xiàng)目的需求管理，涉及到用戶、市場、產(chǎn)品與開發(fā)等各種職能和角色，涉及到客戶的需求、項(xiàng)目開發(fā)的時(shí)間和資源；如何平衡各方面的要求，從整體上實(shí)現(xiàn)客戶需要的產(chǎn)品，對(duì)需求進(jìn)行有效的管理和控制。對(duì)需求管理的方法和應(yīng)用進(jìn)行系統(tǒng)的分析，提出一些利于實(shí)際操作的方法是十分必要的。第一章 需求及需求管理概述軟件需求的定義寬泛地講，需求來源于用戶的一些“需要 ”，這些 “需要 ”被分析、確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)當(dāng) ”

12、做什么。IEEE 軟件工程標(biāo)準(zhǔn)詞匯表(1997年 )中定義需求為:(1)用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力(3)一種反映上面(1)或 (2)所描述的條件或權(quán)能的文檔說明。關(guān)于“需求”的解釋工EEE公布的定義包括從用戶角度(系統(tǒng)的外部行為)，以及從開發(fā)者角度(一些內(nèi)部特性) 來闡述需求。關(guān)鍵的問題是一定要編寫需求文檔。另外一種定義認(rèn)為需求是“用戶所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開發(fā)工作的說明”下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性：需求是指明必須實(shí)現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過

13、程中對(duì)系統(tǒng)的約束。上述需求定義的一種解釋如下：所謂需求，應(yīng)該是來源于用戶調(diào)查即客戶的需要，來源于某個(gè)特定行業(yè)的一些抽象的提煉；并參照行業(yè)規(guī)范進(jìn)行業(yè)務(wù)分析的結(jié)果，考慮用戶自身的特性與要求。這些從客戶處獲得的“需要”，被分析、確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)當(dāng)”做什么或?qū)τ谀：牟糠植蛔鍪裁础６⒉皇峭ㄟ^一些零碎的郵件，或者與用戶的對(duì)話，收集的一些零亂的資料，就說，我已經(jīng)做好了需求，而這一種情況，恰恰就是導(dǎo)致失敗的因素。需求的層次軟件需求包括三個(gè)不同的層次業(yè)務(wù)需求、用戶需求和功能需求(也包括非功能需求)。業(yè)務(wù)需求 (business requirement) 反映了組織機(jī)構(gòu)或

14、客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項(xiàng)目視圖與范圍文檔中予以說明。用戶需求(user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用用例文檔或方案腳本說明中予以說明。功能需求(functional requirement) 定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。需求管理的概念需求管理的概念需求管理的定義如下：顧名思義，需求管理是完整管理模式中的一環(huán)，同其他特性諸如完整性、一致性等不可分割，彼此相關(guān)而成一體。一套需求管理應(yīng)當(dāng)是已知系統(tǒng)需求的完整體現(xiàn)，

15、每部分解決方案都是對(duì)總體需求一定比例的滿足（甚至是充分滿足），僅僅解決部分需求是沒有意義的。對(duì)關(guān)鍵需求的疏忽很可能是災(zāi)難性的。不同的需求組合起來，構(gòu)成了一套完整的需求模型。用戶需求決定了系統(tǒng)設(shè)計(jì)所要解決的問題，所要帶來的結(jié)果。可以說，需求管理指明了系統(tǒng)開發(fā)所要做和必須做的每一件事，指明了所有設(shè)計(jì)應(yīng)該提供的功能和必然受到的制約。用通俗的話來說，需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個(gè)使客戶與項(xiàng)目團(tuán)隊(duì)對(duì)不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程。我認(rèn)為需求管理的目的是在顧客和將處理顧客需求的軟件項(xiàng)目組之間建立對(duì)顧客需求的共同理解，并對(duì)此需求進(jìn)行有效的控制，使項(xiàng)目走向成功。需求管

16、理的過程，從需求獲取開始貫穿于整個(gè)項(xiàng)目生命周期，力圖實(shí)現(xiàn)最終產(chǎn)品同需求的最佳結(jié)合。通過對(duì)需求管理在項(xiàng)目進(jìn)程中實(shí)施的不同任務(wù)進(jìn)行分析，我們可以看出需求管理所起的作用。.需求管理目標(biāo)及需求管理要點(diǎn)需求管理的目標(biāo)是:使軟件需求受控，并建立供軟件工程和管理使用的基線。使軟件計(jì)劃、產(chǎn)品和活動(dòng)與軟件需求保持一致?？刂菩枨笞兏ＷC項(xiàng)目進(jìn)度。需求管理要點(diǎn): 要明確和建立需求來源渠道，既為了避免需求蔓延，又要避免忽視客戶需求、重復(fù)勞動(dòng)、和不嚴(yán)肅的承諾；建立需求管理小組，對(duì)需求進(jìn)行評(píng)審，如需求對(duì)系統(tǒng)的影響范圍等；對(duì)需求變更進(jìn)行管理，對(duì)于不同等級(jí)的需求，采取不同的測量；需求文檔要進(jìn)行版本控制。需求亦有基線和分支，

17、并要和代碼、文檔等其它產(chǎn)品的基線和分支保持一致；需求文檔中的 SRS 要其有唯一編號(hào)，可以通過項(xiàng)目號(hào) +SRS編號(hào)，唯一定位具體的需求；在后續(xù)的代碼、文檔等數(shù)據(jù)中引用需求要確保和需求文檔保持一致；需求管理小組要嚴(yán)格控制進(jìn)人設(shè)計(jì)和開發(fā)之后的需求變更，并根據(jù)變更頻率，改進(jìn)項(xiàng)目需求分析過程。要正確對(duì)待用戶提出的新的需求以及需求變更，不能老報(bào)著“顧客是上帝”的心理，一味地答應(yīng)用戶的新需求。1.3. 小結(jié)這一章主要講述了需求和需求管理的定義，并著重解釋了需求管理的概念、目標(biāo)、流程等，我們可能有一些疑問：需求和需求管理有什么用？沒有開發(fā)出一行代碼，在整個(gè)軟件工程過程中浪費(fèi)這么多時(shí)間豈不是無用功嗎?下面就需

18、求及需求管理的重要性進(jìn)行一下闡述。首先我們要樹立一個(gè)概念：需求是根本，是我們一切開發(fā)活動(dòng)的依據(jù)。由于忽略需求過程造成的項(xiàng)目返工是惡性的，后果不堪設(shè)想，大量的項(xiàng)目在需求階段就注定了它的失敗。以下是兩個(gè)需求過程不科學(xué)的典型例子:開發(fā)人員在用戶處呆了兩三天就埋頭開發(fā)；.用戶告訴開發(fā)人員我要開發(fā)一個(gè)xx系統(tǒng)，但是我很忙，你先開發(fā)一個(gè)讓我看著，開發(fā) 人員就盲目答應(yīng)。上面的這兩種態(tài)度都意味著項(xiàng)目的不成功，應(yīng)該說上面的開發(fā)人員和用戶都應(yīng)該對(duì)此負(fù)責(zé)。需求是開發(fā)者和用戶交互的一個(gè)過程，任何一方的不投人都會(huì)導(dǎo)致項(xiàng)目的失敗。當(dāng)然，由于用戶不是專業(yè)人士，開發(fā)者有權(quán)利告訴用戶應(yīng)該采用何種態(tài)度來對(duì)待項(xiàng)目的需求。所有最成功

19、的項(xiàng)目都有一個(gè)重要的特性：用戶非常的支持。評(píng)判一個(gè)軟件項(xiàng)目成功的標(biāo)準(zhǔn)是看它是否解決了用戶的問題，而用戶的問題就是體現(xiàn)為用戶的需求，需求也就順理成章的成為項(xiàng)目的成功標(biāo)準(zhǔn)。而需求階段的一個(gè)不慎都有可能導(dǎo)致軟件實(shí)現(xiàn)階段的大量返工，而需求的不慎不是說你小心就可以的，因?yàn)楹芏嘈枨笫请[性的，連用戶都不清楚自己的需求。這時(shí)候就需要一種科學(xué)的方法來幫助軟件項(xiàng)目組實(shí)施需求過程，。是不是我們在項(xiàng)目開始之前將所有的需求搞明白就可以使項(xiàng)目開發(fā)成功?我們姑且不討論這種做法是否可行，只假設(shè)我們做到了這一點(diǎn)，可不幸的是：客戶的需求是變化的，并且是一定要變化的。怎么辦?全盤接受?全盤否定?這兩種做法都是項(xiàng)目失敗的種子。解決這

20、些問題的辦法就是用需求管理的辦法，顧名思義，就是要把需求“管理”起來，讓它為我所控制，從而順利地完成整個(gè)項(xiàng)目?？梢哉f，軟件項(xiàng)目中絕大多數(shù)失敗是需求的失敗:或者是需求開發(fā)的失敗，或者是需求管理的失敗。所以，我們討論在軟件項(xiàng)目中進(jìn)行需求管理就是十分必要的了。以下的章節(jié)，我將結(jié)合實(shí)際中的一個(gè)項(xiàng)目來具體談一下小組軟件項(xiàng)目中的需求管理問題。第二章 項(xiàng)目及項(xiàng)目背景簡介“廈門*公司墓石cad設(shè)計(jì)系統(tǒng)”項(xiàng)目背景介紹廈門*公司員工一直以來都是使用一套叫“雅”的設(shè)計(jì)系統(tǒng)進(jìn)行墓石設(shè)計(jì)，該系統(tǒng)由該 公司從日本購進(jìn)，成本較高。而且由于其是由日本人開發(fā)，好多使用方法不符合*公司習(xí)慣,致使該公司員工設(shè)計(jì)效率低下，不能很好的

21、適應(yīng)市場需求。為了適合*公司員工的工作需要，提高其工作效率，降低其開發(fā)成本，該公司迫切需要 一套適合自己的開發(fā)設(shè)計(jì)系統(tǒng)。經(jīng)過多方面考慮和挑選，最終選擇委托給我們小組來進(jìn)行新 的系統(tǒng)的設(shè)計(jì)和開發(fā)?！皬B門*公司墓石cad設(shè)計(jì)系統(tǒng)”項(xiàng)目介紹該項(xiàng)目是autocad的二次開發(fā)項(xiàng)目，使用ObjectARX開發(fā)包以及VC6.0進(jìn)行開發(fā)。各模塊 最終生成各自的ARX模塊，相對(duì)而言比較獨(dú)立。下面我主要介紹一下系統(tǒng)的總體功能以及整體工作流程。系統(tǒng)總體功能如下：各子模塊如下:建立模型哥力選在，苴曲鼾門定, H他功能,川裳陽*粉，部 H-.IV，5T 工材ffl如郁R比評(píng)段L A 口iiH生&樂赭度a江 不征世41里

22、加林世號(hào)工招M明降中成的外榭 回血墓行苦卜的葩抨，技 風(fēng)，沛寸內(nèi)地T 都牌錄;虬仃覘忖人鵬萍豺金A部忖咋超用tt胤月速杵W喃村理Hq冊器周祖蓊燈蝌史出r曼i *樂期idtk產(chǎn)問世tkr-ittu A ulr，4T 承京伴快速而H化!H部Hft分類,賦屬性其他動(dòng)工配材打種再抨拓材命名 r一卡升熨&示皂未調(diào)號(hào)顯不皇未能顯示，塌號(hào)劃除、手動(dòng)編號(hào)王自動(dòng)編號(hào)衛(wèi)他甘杷除*外聞f類刪期用沈村市仙計(jì)部景觀設(shè)定地板林咕出工洎染精度設(shè)定部村打科選肝緊觀端轉(zhuǎn)turn添加,罪除,修改地根村選掙背盤能加M除.修背景選桿太陽無注定工環(huán)埴此設(shè)定用R坐注定工鋌lh光澤世定;-比粘度強(qiáng)正工局部郵材空史民而科種胃的第卻用疏.修墳

23、出圖紙2D圖入庫修改功能2d圖修域系統(tǒng)的整體流程圖如下:H始護(hù):!牛1比公關(guān).皓年巾4但I(xiàn)：獷，&Hi Hm紂i市第三章 需求獲取階段的控制和管理概述需求獲取階段，即需求開發(fā)階段，也可以叫需求分析階段。在這個(gè)階段，要對(duì)客戶提出的需求進(jìn)行提煉、分析，最后形成客戶認(rèn)可的需求規(guī)格說明書。在需求獲取階段還要編制一份開發(fā)計(jì)劃。前提需求獲取的前提是:用戶與公司簽定開發(fā)合同或者是需求調(diào)研合同。需求分析階段是完成由公司的銷售人員為重點(diǎn)轉(zhuǎn)變?yōu)楣鞠到y(tǒng)開發(fā)部門為重點(diǎn)過程中的第一步。對(duì)于用戶來講已經(jīng)對(duì)多家開發(fā)商進(jìn)行了挑選,最終明確一家開發(fā)商，并簽訂了開發(fā)合同?，F(xiàn)在要進(jìn)行提供具體需求并明確需求的過程明確告訴開發(fā)商要開

24、發(fā)一個(gè)具有什么功能、什么特性的軟件產(chǎn)品。這個(gè)前提是不可或缺的，在沒有簽定合同之前什么事情都會(huì)發(fā)生。在今年春節(jié)以前，我曾經(jīng)遇到過這么一件事情:廈門的一家旅游公司，升級(jí)自己的門戶網(wǎng)站，由于各種原因，決定不進(jìn)行招標(biāo)，直接選擇廈門*軟件公司進(jìn)行開發(fā)。當(dāng)需求已經(jīng)談完，合同已經(jīng)到了談?wù)摷?xì)節(jié)的時(shí)候，合同突然被另外一家公司搶走了。進(jìn)行需求調(diào)研的另外一個(gè)前提是甲乙雙方簽定了需求調(diào)研合同。這個(gè)情況一般發(fā)生在甲方在幾家公司之間做選擇時(shí)。從上面的情況可以看出，進(jìn)行需求調(diào)研的前提就是有合同保障，否則就會(huì)像我上面說的那樣，會(huì)造成不必要的損失。約定用戶對(duì)于其用什么系統(tǒng)平臺(tái)，已經(jīng)大概知道，并且已經(jīng)認(rèn)可。如WEB服務(wù)器的操作系

25、統(tǒng)是 WINDOWS 2000 server ， 數(shù)據(jù)庫服務(wù)器是redhat linux ， WEB 服務(wù)器的軟件是Apache， EJB中間件服務(wù)器是Weblogic/Websphere ，數(shù)據(jù)庫軟件是ORACLE/SQL server 等等?？蛻舴?wù)器的軟硬件配置要經(jīng)過客戶的認(rèn)可，并寫入需求，簽字確認(rèn)，否則如果以后用戶要提出更改，有可能會(huì)對(duì)我們的開發(fā)造成很大的影響造成不必要的損失。像“廈門*公司墓石cad設(shè)計(jì)系統(tǒng)”這個(gè)項(xiàng)目中，在進(jìn)行需求分析時(shí)，我們就和客戶約定好我們的平臺(tái)是搭建在autocad2002 上的， 所以我們的開發(fā)、測試等活動(dòng)都是在autocad2002的基礎(chǔ)上進(jìn)行。當(dāng)我們的項(xiàng)目

26、快接近尾聲時(shí)，客戶突然又提出要我們設(shè)計(jì)的系統(tǒng)能夠兼容MDT6和autocad2004。我們進(jìn)行了詳細(xì)的分析，因?yàn)?autocad2004和autocad2002的內(nèi)核已經(jīng)有很大的差別，如果要兼容的話大量的模塊都要返工，這就意味著我們要進(jìn)行重新設(shè)計(jì)開發(fā)，開發(fā)進(jìn)度會(huì)落后很多。所以我們就拿簽字的需求文檔去跟客戶談，跟他們講清楚我們開發(fā)困難等一些原因，而且由于我們開始也有簽字約定，所以客戶也就答應(yīng)了。最終我們就只有兼容MDT6。如果我們當(dāng)時(shí)沒有約定，客戶堅(jiān)持他們的意見，那后果真的是不堪設(shè)想了。所用技術(shù)體系一般情況下在進(jìn)行需求分析前最好是明確的，不然就要求系統(tǒng)分析人員了解所有的技術(shù)體系。不然運(yùn)氣好，系統(tǒng)

27、分析人員所了解的技術(shù)體系和用戶相求的相同，進(jìn)行了正確分析; 如果運(yùn)氣不好可能會(huì)把一些認(rèn)為可以簡單實(shí)現(xiàn)而實(shí)際實(shí)現(xiàn)卻很難的需求答應(yīng)下來。在所用技術(shù)體系大概范圍已經(jīng)明確的情況下，選擇合適的系統(tǒng)分析人員。要求系統(tǒng)分析人員對(duì)相應(yīng)技術(shù)體系有一定的了解，以便在相應(yīng)的分析時(shí)有所依據(jù)。不同的技術(shù)體系有一定的局限性，而有些需求對(duì)某些技術(shù)體系有一定的難度。如WAP（ 手機(jī)上網(wǎng)）是不太可能實(shí)現(xiàn)打印。雖然沒有絕對(duì)不能實(shí)現(xiàn)的用戶業(yè)務(wù)需求，但一般情況下開發(fā)協(xié)議上明確的費(fèi)用，已經(jīng)決定系統(tǒng)功能做到什么程度。獲取需求規(guī)格說明書調(diào)研前的準(zhǔn)備在需求調(diào)研過程中，應(yīng)該做好三種準(zhǔn)備，保持兩種心態(tài)，做到五種提高:三種準(zhǔn)備：調(diào)研前應(yīng)該將所有項(xiàng)

28、目前期資料進(jìn)行匯總，與相關(guān)的前期銷售人員進(jìn)行交流，以便對(duì)項(xiàng)目有一個(gè)基本輪廓的認(rèn)識(shí)。2）做好調(diào)研前使用資料的準(zhǔn)備，如需求調(diào)研模板，需求調(diào)研問題列表等。3）做好不怕一切困難的準(zhǔn)備。兩種心態(tài)：保持一種和客戶平等合作的心態(tài)，確定需求調(diào)研是為了給客戶解決問題，探討問題而不是接受問題，更不是來指導(dǎo)工作的。2）平靜面對(duì)需求變更的心態(tài)，在需求調(diào)研過程中，往往雙方對(duì)需求理解不一致，造成需求調(diào)研前后矛盾，應(yīng)當(dāng)心平氣和的去引導(dǎo)客戶，達(dá)到需求理解基本一致。五種提高：1）首先提高自己業(yè)務(wù)知識(shí)，對(duì)于CAD制圖，墓石設(shè)計(jì)的標(biāo)準(zhǔn)業(yè)務(wù)應(yīng)該基本熟悉。2）其次應(yīng)該努力的去熟悉用戶的行業(yè)，學(xué)習(xí)用戶使用的術(shù)語，標(biāo)準(zhǔn)，以便能夠準(zhǔn)確的理解

29、用戶。這就需要我們閱讀用戶所在行業(yè)的資料、文章，盡量多選取一些整體性介紹的文章，這樣可以在短時(shí)間內(nèi)能夠?qū)υ撔袠I(yè)有一個(gè)全面的認(rèn)識(shí)，這樣我們就能夠較好的和用戶進(jìn)行交流了。3）需求調(diào)研中，學(xué)會(huì)盡量不使用專業(yè)術(shù)語，而采用淺顯易懂的口頭語言來解釋軟件開發(fā)中的術(shù)語，以便用戶能夠很好的理解，提高自己的溝通交流能力。4）提高自己的速記能力，文字表述以及歸納能力，能迅速的記錄需求調(diào)研核心的問題，總結(jié)歸納形成原始的需求調(diào)研資料。提高自己的總結(jié)能力，書寫一份完整的、前后一致的、可追蹤的需求報(bào)告。調(diào)研過程在調(diào)研的過程中應(yīng)該對(duì)會(huì)議進(jìn)行記錄。這項(xiàng)工作一般由開發(fā)商的需求分析人員進(jìn)行，并在每日會(huì)議結(jié)束后，當(dāng)場宣布本次會(huì)議的結(jié)

30、果，并由參加會(huì)議人員進(jìn)行簽字。第二日復(fù)印或發(fā)送電子文件給參加會(huì)議人員及相關(guān)人員。以便做到有據(jù)可查，明確過程。開發(fā)商系統(tǒng)開發(fā)人員每周對(duì)用戶提供開發(fā)周報(bào)，告訴用戶當(dāng)前開發(fā)的進(jìn)展、是否有問題、 是否需要用戶協(xié)助等，這是一個(gè)好的加強(qiáng)雙方溝通的方法。注意:在調(diào)研過程的中系統(tǒng)開發(fā)人員的變更會(huì)對(duì)計(jì)劃產(chǎn)生重大的影響，不要簡單認(rèn)為是人員更換的問題。因?yàn)樵谡{(diào)研過程中對(duì)業(yè)務(wù)的理解，不是通過看看文檔就可以達(dá)到。3天通過討論達(dá)到對(duì)需求理解的程序，9天對(duì)文檔的學(xué)習(xí)也不一定能達(dá)到。整體調(diào)研對(duì)于調(diào)研過程中的整體調(diào)研，一定要讓用戶各部門的主管以及用戶全體人員（含用戶IT人員 ）參加，第一個(gè)目的是了解用戶的整體需求細(xì)節(jié)，第二個(gè)目

31、的使用戶人員從各自的角度也了解到用戶方要做一個(gè)什么樣的系統(tǒng)。需求提供者如果是一個(gè)人，他知道自己要一個(gè)什么樣的系統(tǒng)。但如果是多人，在開發(fā)商系統(tǒng)分析人員進(jìn)行調(diào)研前，每人也不過是計(jì)劃自己的需求而已，即使有時(shí)溝通，一般也是在討論而不是進(jìn)行結(jié)論。使業(yè)務(wù)需求并不是很明確。整體調(diào)研的其中一個(gè)目的就是把用戶的多人需求組成一個(gè)整體，整體調(diào)研過程也是一個(gè)用戶人員溝通并整合需求的一個(gè)過程。用戶方多人在進(jìn)行開發(fā)商需求確認(rèn)前，業(yè)務(wù)互相有分歧是相當(dāng)正常的，開發(fā)商系統(tǒng)分析人員必須要在需求調(diào)研過程中，使其達(dá)成一致。一般情況下需明確以下問題:當(dāng)前整體業(yè)務(wù)需求的目的要求提供的需求功能列表已經(jīng)定義的需求規(guī)則將來發(fā)展的設(shè)想明確服務(wù)器

32、、客戶機(jī)的軟、硬件及性能要求（容量、速度、可操作性等）用戶目前相關(guān)的技術(shù)人員和業(yè)務(wù)人員情況將來最終系統(tǒng)操作人員的技術(shù)及業(yè)務(wù)人員情況用戶需求的系統(tǒng)及用戶本身或其它系統(tǒng)的接口要求用戶的其它要求具體業(yè)務(wù)調(diào)研對(duì)于整體調(diào)研過后就要進(jìn)行各個(gè)具體業(yè)務(wù)需求的調(diào)研，對(duì)于具體需求調(diào)研如果是用戶提供的現(xiàn)有的文檔，開發(fā)商的需求分析人員（或系統(tǒng)分析人員）只是對(duì)業(yè)務(wù)進(jìn)行了解及進(jìn)行修改為需求分析人員（系統(tǒng)分析人員）及業(yè)務(wù)人員全可以看懂的需求說明書，那么這個(gè)過程就比較容易。只要系統(tǒng)分析人員把業(yè)務(wù)文檔看懂看明白，并且對(duì)于一些難理解的業(yè)務(wù)描述修改為易懂（有些業(yè)務(wù)名詞有一定的專業(yè)性就要進(jìn)行額外的說明）、明確進(jìn)出的單據(jù)（數(shù)據(jù)項(xiàng)）就可

33、以。當(dāng)然編寫需求說明書具體的細(xì)節(jié)可以參見其他的眾多的書籍及文件模版了。如果用戶對(duì)于自己的需求在調(diào)研開始并沒有完全明確，需要進(jìn)行引導(dǎo)及細(xì)化，那么這個(gè)過程就比較麻煩了。對(duì)于用戶本身需求不明情況下，對(duì)于業(yè)務(wù)要先從基本業(yè)務(wù)進(jìn)行細(xì)化，對(duì)于不明業(yè)務(wù)或不確定業(yè)務(wù)在后面進(jìn)行。對(duì)于進(jìn)出的單據(jù)（數(shù)據(jù)項(xiàng)）只需明確單據(jù)的進(jìn)出的必須數(shù)據(jù)源就可以，如果做到細(xì)節(jié)，由用戶在需求調(diào)研期確定單個(gè)數(shù)據(jù)項(xiàng)，是不太可能的只是設(shè)計(jì)單據(jù)的樣式、風(fēng)格就不是短時(shí)間可以完成的。對(duì)于報(bào)表也只能明確基本報(bào)表要求及數(shù)據(jù)項(xiàng)。一般這種情況使用原型法進(jìn)行，先做一個(gè)簡單的，在簡單的上面再進(jìn)行完善。對(duì)于用戶本身需求不明情況下的調(diào)研要做每日（或 2到 3天最多3

34、天為間隔）的工作（分析進(jìn) 展 ）記錄，由雙方簽字，因?yàn)檎{(diào)研過程會(huì)出現(xiàn)為用戶要求添加一支新業(yè)務(wù)，對(duì)新業(yè)務(wù)進(jìn)行分析后，因某些原因發(fā)現(xiàn)不能添加。這個(gè)過程的結(jié)果是一個(gè)0，但為證明是0這結(jié)果可能花了很長的時(shí)間。要記錄這個(gè)過程，說明調(diào)研過程中做了什么事情，有時(shí)有些人可能會(huì)說為什么這么長時(shí)間才出這點(diǎn)東西，到時(shí)以便說明原因。關(guān)于選取開發(fā)模型有時(shí)開發(fā)模型的選取不是很容易判斷的，這里面有時(shí)不單是需求及開發(fā)的問題，對(duì)于開發(fā)商有開發(fā)周期、開發(fā)費(fèi)用的問題，對(duì)于用戶同樣有內(nèi)部計(jì)劃、公司發(fā)展計(jì)劃等因素進(jìn)行影響。一般來說對(duì)于應(yīng)用開發(fā)為客戶開發(fā)軟件，客戶在開發(fā)及測試完畢軟件后就要實(shí)際開始使用，那么就使用瀑布模型。當(dāng)然在需求明確

35、的情況下自然也要使用瀑布模型對(duì)于自主開發(fā)及客戶需求不明并有較長的設(shè)計(jì)時(shí)間可以用演化模型。而螺旋模型適合于大型軟件開發(fā)，吸收了“演化”概念，不過有時(shí)也用于用戶需求不明的情況下。當(dāng)然還有其他開發(fā)模型，沒有在本文討論。名詞定義:?瀑布模型: 規(guī)定了各項(xiàng)軟件工程活動(dòng)。包括:制定開發(fā)計(jì)劃、進(jìn)行需求分析和說明、軟件設(shè)計(jì)、程序編碼、測試及維護(hù)。特點(diǎn) :自上而下，相互銜接的固定次序，如瀑布流水、逐級(jí)下落。?演化模型: 第一次只是試驗(yàn)開發(fā)，其目標(biāo)只在于探索可行性，弄清軟件需求;第二次則在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品，通常把一次得到的試驗(yàn)性產(chǎn)品稱“原型”特點(diǎn) :減少由于軟件需求不明確而給開發(fā)帶來的風(fēng)險(xiǎn)。?螺旋模

36、型: 將瀑布模型及演化螺旋模型結(jié)合起來，并且加人被兩種模型都忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了兩者的不足。對(duì)需求說明書的確認(rèn)需求規(guī)格說明書完成后，先由需求分析人員（系統(tǒng)開發(fā)人員）對(duì)編寫的文檔進(jìn)行內(nèi)部審核及修訂，特別是文字問題。內(nèi)部審核后將需求規(guī)格說明書交由用戶業(yè)務(wù)人員進(jìn)行確認(rèn)，明確需求分析人員（系統(tǒng)開發(fā)人員）已經(jīng)了解業(yè)務(wù)需求，并進(jìn)行簽字確認(rèn)。對(duì)需求規(guī)格說明書的簽字確認(rèn)，主要表明經(jīng)過雙方的努力，對(duì)系統(tǒng)的功能界定已經(jīng)取得了初步的共識(shí)，形成了開發(fā)的一個(gè)基線。以后的開發(fā)、驗(yàn)收、需求更改要圍繞著這個(gè)基線進(jìn)行?？偨Y(jié)需求調(diào)研是對(duì)合同中規(guī)定的用戶需求確認(rèn)的過程。在這個(gè)過程中，不但要詳細(xì)、正確地了解客戶的真正需求，最后形

37、成需求規(guī)格文檔，還要考慮到整個(gè)項(xiàng)目開發(fā)的成本等因素。一般在項(xiàng)目簽定合同之前，用戶已經(jīng)提交了一個(gè)粗略的需求清單，這個(gè)清單是簽定合同的基礎(chǔ)。但是不能以這個(gè)清單作為項(xiàng)目開發(fā)的基礎(chǔ)，這有如下的原因:、客戶提出的需求清單是很簡單的，沒有確定細(xì)節(jié)，不能作為系統(tǒng)開發(fā)的依據(jù)、在客戶提出的需求清單中，有些名詞的意思和開發(fā)人員通常理解的是不一樣的。這些要逐一進(jìn)行澄清。例如，在一個(gè)網(wǎng)站項(xiàng)目的需求調(diào)研中，客戶原來提出一項(xiàng)“廣告”的需求。按照一般的理解，廣告功能有各種各樣的形式，可能做的很復(fù)雜。可與客戶實(shí)際一了解，原來客戶所說的廣告只是我們通常所說的“友情鏈接”而已。另外一個(gè)，客戶提出一個(gè)“客戶端”的需求 （這個(gè)單詞的

38、意義上講的范圍就比較大了），實(shí)際上這是對(duì)客戶以彈出窗口的形式進(jìn)行提醒罷了。試想，如果對(duì)這些雙方有分歧的地方，不進(jìn)行澄清的后果有多可怕。、 需求調(diào)研的成果之一就是形成客戶認(rèn)可的需求規(guī)格說明書。這是對(duì)客戶提出需求進(jìn)行提煉、總結(jié)、歸納的過程。是進(jìn)行設(shè)計(jì)、開發(fā)時(shí)的依據(jù)，也是很重要的。、 需求調(diào)研中要考慮項(xiàng)目的成本控制問題。對(duì)于用戶來說，既然已經(jīng)簽定了合同，總工程款已經(jīng)確定，當(dāng)然希望獲得的功能越多越好 ; 而對(duì)于開發(fā)商來說，功能不斷擴(kuò)充、項(xiàng)目延期是最可怕的事情。這就需要把客戶一些不切實(shí)際的想法消滅掉。另外，要向客戶解釋清楚哪些功能不能實(shí)現(xiàn)。這些都是需求分析人員的工作。、 需求調(diào)研過程是為客戶解決問題的過

39、程。通過與客戶密切交流，解決客戶心中的疑慮，為客戶提供完善的解決方案。最終要讓用戶滿意。備注:讓用戶滿意并不是答應(yīng)用戶提出的所有要求。、 需求調(diào)研過程要對(duì)整個(gè)系統(tǒng)的擴(kuò)展性進(jìn)行考慮。客戶的想法會(huì)改變，業(yè)務(wù)會(huì)改變，甚至業(yè)務(wù)部門也會(huì)改變，這些在系統(tǒng)設(shè)計(jì)中都要通盤考慮。編制開發(fā)計(jì)劃需求規(guī)格說明書編制完成后，就可以編制出這個(gè)系統(tǒng)的開發(fā)計(jì)劃。開發(fā)計(jì)劃的內(nèi)容如下:）項(xiàng)目名稱）項(xiàng)目委托方與承接方）項(xiàng)目組成員4）項(xiàng)目實(shí)施進(jìn)度計(jì)劃）項(xiàng)目開發(fā)實(shí)施步驟）項(xiàng)目任務(wù)分配及資源）項(xiàng)目風(fēng)險(xiǎn)及資源）項(xiàng)目風(fēng)險(xiǎn)分析及管理）承接方需委托方配合的工作）雙方關(guān)于項(xiàng)目管理的約定再上面這些內(nèi)容中，最主要的是編制“項(xiàng)目實(shí)施進(jìn)度計(jì)劃”。編制開發(fā)

40、計(jì)劃不但要考慮功能需求多少，客戶對(duì)時(shí)間的要求，還要考慮公司開發(fā)人員情況，其他項(xiàng)目情況等等。小結(jié)在需求獲取階段，通過與客戶進(jìn)行交流，弄清楚客戶的真正需求。綜合考慮客戶需求、項(xiàng)目成本，時(shí)間進(jìn)度等情況，形成最初版本的需求說明書、項(xiàng)目開發(fā)計(jì)劃書。這是整個(gè)項(xiàng)目的開始階段，直接決定了以后項(xiàng)目開發(fā)的成本、進(jìn)度完成情況。對(duì)這個(gè)階 段進(jìn)行有效的管理，就顯得尤其重要了。步就進(jìn)入項(xiàng)目開發(fā)進(jìn)行完需求調(diào)研，獲得了得到用戶簽字確認(rèn)的需求規(guī)格說明書，下一步就進(jìn)入項(xiàng)目開發(fā)階段，簽字確認(rèn)的需求規(guī)格說明書將成為我們一切開發(fā)活動(dòng)的依據(jù)。第四章 項(xiàng)目開發(fā)過程中的需求管理概述在軟件項(xiàng)目或產(chǎn)品開發(fā)過程中，一般地來講，把與需求直接相關(guān)的活

41、動(dòng)統(tǒng)稱為需求工程。站在需求工程的角度來說，可以分為兩大部分，即需求開發(fā)與需求管理。需求開發(fā)過程在需求獲取階段已經(jīng)完成; 而軟件項(xiàng)目開發(fā)開始后，怎樣對(duì)需求變更、版本進(jìn)行控制就屬于需求管理的范疇。在目前來說，需求工程是國內(nèi)大學(xué)軟件工程教育最薄弱的環(huán)節(jié)之一，那么，在這種教育模式下誕生的軟件工程師會(huì)存在一種這樣的習(xí)慣：他們在開發(fā)產(chǎn)品時(shí)并不清楚究竟該做什么，但卻在一直忙碌不停地開發(fā)。這個(gè)現(xiàn)象，差不多成了國內(nèi)軟件業(yè)的瘤疾。而對(duì)于需求的管理而言，在整個(gè)開發(fā)過程中，對(duì)小組項(xiàng)目起著至關(guān)重要的作用;我們的軟件工程師卻在埋怨用戶需求的不斷變化，而站在用戶的角度來說，你們的項(xiàng)目進(jìn)度為何總是拖后。需求管理是完整管理模式

42、中的一環(huán)，同其他特性:諸如完整性、一致性等不可分割，彼此相關(guān)而成一體。一套需求管理應(yīng)當(dāng)是已知系統(tǒng)需求的完整體現(xiàn)，每部分解決方案都是對(duì)總體需求一定比例的滿足（甚至是充分滿足），僅僅解決部分需求是沒有意義的。對(duì)關(guān)鍵需求的疏忽很可能是災(zāi)難性的，試想一架飛機(jī)的安全設(shè)計(jì)不過關(guān)將會(huì)帶來什么樣的后果。不同的需求組合起來，構(gòu)成了一套完整的需求模型。用戶需求決定了系統(tǒng)設(shè)計(jì)所要解決的問題，所要帶來的結(jié)果。可以說，需求管理指明了系統(tǒng)開發(fā)所要做和必須做的每一件事，指明了所有設(shè)計(jì)應(yīng)該提供的功能和必然受到的制約。需求管理的過程，從需求獲取開始貫于整個(gè)軟件項(xiàng)目生命周期，力圖實(shí)現(xiàn)最終產(chǎn)品同需求的最佳結(jié)合。通過對(duì)需求管理在小組

43、軟件項(xiàng)目進(jìn)程中實(shí)施的不同任務(wù)進(jìn)行分析，我們可以看出需求管理所起的作用。需求管理本就是一個(gè)動(dòng)態(tài)的過程，離開了能動(dòng)的、變化的系統(tǒng)進(jìn)程而空談需求管理，無異于紙上談兵。根據(jù)我的經(jīng)驗(yàn)，開發(fā)過程開始后，作為軟件項(xiàng)目的需求經(jīng)理，主要做以下工作：）根據(jù)項(xiàng)目特點(diǎn)，選擇開發(fā)模型；設(shè)計(jì)系統(tǒng)頁面原型，并指導(dǎo)美工制作出頁面；擔(dān)負(fù)開發(fā)項(xiàng)目組與客戶之間的橋梁，承擔(dān)絕大部分與客戶交流的任務(wù)；控制需求的變更；對(duì)需求文檔進(jìn)行版本控制。按照上面的步驟，需求經(jīng)理一步一步將存在紙面上的系統(tǒng)（需求規(guī)格說明）變成了可運(yùn)行的系統(tǒng)；并保證不因外部因素（如客戶提出新需求、開發(fā)人員錯(cuò)誤理解需求）致使項(xiàng)目進(jìn)人不可控制的境地: 保證系統(tǒng)實(shí)現(xiàn)客戶需要的

44、功能，在規(guī)定的時(shí)間內(nèi)，不突破預(yù)算地完成整個(gè)項(xiàng)目。選擇開發(fā)策略選擇開發(fā)策略的問題，在“具體業(yè)務(wù)調(diào)研”中已經(jīng)涉及到，那些只是在需求調(diào)研階段的設(shè)想。到軟件項(xiàng)目開發(fā)過程中，這些設(shè)想就變成實(shí)實(shí)在在的策略了。針對(duì)于不同的小組軟件項(xiàng)目，選擇不同的軟件開發(fā)模型。對(duì)于網(wǎng)站項(xiàng)目而言，主要有如下特點(diǎn)：、 公司開發(fā)網(wǎng)站項(xiàng)目有豐富的經(jīng)驗(yàn)和代碼積累，網(wǎng)站項(xiàng)目中很多功能都有現(xiàn)成的代 碼，只做小小的改動(dòng)，就可以拿來用；、2 、由于對(duì)網(wǎng)站項(xiàng)目開發(fā)經(jīng)驗(yàn)豐富，一般在需求調(diào)研階段會(huì)得到良好的需求規(guī)格說明書。所以對(duì)于網(wǎng)站項(xiàng)目開發(fā)，可以選擇“瀑布模型”。對(duì)于采用瀑布模型的網(wǎng)站軟件項(xiàng)目，主要采取下述的開發(fā)策略：將軟件生存期劃分為若干階段，

45、根據(jù)不同階段工作的特點(diǎn)，運(yùn)用不同的方法、技術(shù)和工具來完成該階段的任務(wù)。軟件人員遵循嚴(yán)格的規(guī)范，在每一階段工作結(jié)束時(shí)都要進(jìn)行嚴(yán)格的階段評(píng)審和確認(rèn)，以得到該階段的一致、完整和無多義性的文檔，把這些文檔作為階段結(jié)束的標(biāo)志“凍結(jié)”起來，并以它們作為下一階段工作的基礎(chǔ)，從而保證軟件的質(zhì)量。但是，有時(shí)很難得到一個(gè)完整準(zhǔn)確的規(guī)格說明。特別是對(duì)于一些大型的軟件項(xiàng)目，或是原來沒有開發(fā)過的項(xiàng)目，在開發(fā)的早期，用戶往往對(duì)系統(tǒng)只有一個(gè)模糊的想法，很難完全準(zhǔn)確地表達(dá)對(duì)系統(tǒng)的全面要求，軟件人員對(duì)于所要解決的應(yīng)用問題認(rèn)識(shí)更是模糊不清。經(jīng)過詳細(xì)的討論和分析，也許能得到一份較好的規(guī)格說明，但很難期望該規(guī)格說明能將系統(tǒng)的各個(gè)方面

46、都描述得完整、準(zhǔn)確，并與實(shí)際環(huán)境相符。很難通過它在邏輯上推斷出（不是在實(shí)際運(yùn)行中判斷評(píng)價(jià)）系統(tǒng)運(yùn)行的效果，以此達(dá)到各方對(duì)系統(tǒng)的共同理解。隨著開發(fā)工作向前推進(jìn)，用戶可能會(huì)產(chǎn)生新的要求，或因環(huán)境變化，要求系統(tǒng)也隨之變化；開發(fā)者又可能在設(shè)計(jì)與實(shí)現(xiàn)的過程中遇到一些沒有預(yù)料到的實(shí)際困難，需要以改變需求來擺脫困境。因此規(guī)格說明難以完善、需求的變更、以及通信中的模糊和誤解，都會(huì)成為軟件開發(fā)順利推進(jìn)的障礙。盡管在傳統(tǒng)軟件生存期管理中通過加強(qiáng)評(píng)審和確認(rèn)，全面測試來緩解上述問題，但還不能從根本上解決這些問題。在這種情況下，需要采用快速原型法進(jìn)行開發(fā)?！皬B門*公司墓石cad設(shè)計(jì)系統(tǒng)”就屬于這種情況，而且有一個(gè)現(xiàn)成的

47、原型（客戶目前使 用的“雅”）供我們參考。由于我們原來沒有開發(fā)過這種系統(tǒng)，對(duì)于這個(gè)系統(tǒng)的業(yè)務(wù)不是很了解，所以要采用演化模型進(jìn)行開發(fā)。系統(tǒng)原型設(shè)計(jì)開發(fā)對(duì)于采用瀑布模型進(jìn)行開發(fā)的系統(tǒng)來說，各模塊設(shè)計(jì)主要是根據(jù)需求規(guī)格說明書規(guī)定的功能要求，以及客戶的要求，制作出可進(jìn)行變成的模塊。其中，最重要的是確定系統(tǒng)的整體構(gòu)架等。整體構(gòu)架由客戶確認(rèn)后，就可以進(jìn)而制作出各子模塊的設(shè)計(jì)開發(fā)。對(duì)于采用演化模型進(jìn)行開發(fā)的系統(tǒng)來說，系統(tǒng)原型的開發(fā)主要有如下作用：? 增進(jìn)軟件人員和用戶對(duì)系統(tǒng)服務(wù)需求的理解，使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。對(duì)于系統(tǒng)用戶來說，要他們想象最終系統(tǒng)是什么樣的，或者描述當(dāng)前有什

48、么要求，都是很困難的。但是對(duì)他們來說，評(píng)價(jià)一個(gè)系統(tǒng)的原型要比寫出規(guī)格說明容易得多。當(dāng)用戶看到原型的執(zhí)行不是他們原來想象的那樣時(shí)，原型化方法允許并鼓勵(lì)他們改變原來的要求。由于這種方法能在早期就明確用戶的要求。因此可防止以后由于不能滿足用戶要求而造成的返工，從而避免了不必要的經(jīng)濟(jì)損失，縮短了開發(fā)周期。?原型化方法提供了一種有力的學(xué)習(xí)手段。通過原型演示，用戶可以親身體驗(yàn)早期的開發(fā)過程，獲得關(guān)子計(jì)算機(jī)和所開發(fā)系統(tǒng)的專門知識(shí)，對(duì)使用者培訓(xùn)有積極作用。軟件開發(fā)者也可以獲得用戶對(duì)系統(tǒng)的確切要求，學(xué)習(xí)到應(yīng)用范圍的專業(yè)知識(shí)，使開發(fā)工作做得更好。?原型可以作為理解和確認(rèn)軟件需求規(guī)格說明的工具。?軟件原型的最終版本

49、，有的可以原封不動(dòng)地成為產(chǎn)品，有的略加修改就可以成為最終系統(tǒng)的一個(gè)組成部分，這樣有利于建成最終系統(tǒng)。在系統(tǒng)原型開發(fā)階段，應(yīng)該注意以下問題：對(duì)各功能實(shí)現(xiàn)的每一個(gè)細(xì)節(jié)要做細(xì)致的檢查，看是否符合需求規(guī)格說明書的要求。要及時(shí)與客戶進(jìn)行溝通，特別是制作出系統(tǒng)原型后，要及時(shí)讓客戶進(jìn)行確認(rèn)，然后再進(jìn) 行下面的開發(fā)。溝通在軟件項(xiàng)目開發(fā)過程中主要溝通的方面在軟件項(xiàng)目開發(fā)過程中，與客戶及項(xiàng)目組成員保持及時(shí)有效的溝通十分重要。在以下方面需要與客戶及時(shí)交流：?制作系統(tǒng)原型時(shí)要將客戶的意見反映給開發(fā)者，將開發(fā)人員的意見提交給客戶進(jìn)行參考。并將制作好的原型及時(shí)提交給客戶審核；?當(dāng)客戶提交意見時(shí)，要將項(xiàng)目組討論的結(jié)果及時(shí)提

50、交給客戶。在必要的時(shí)候，要對(duì)結(jié)果再進(jìn)行溝通；?將開發(fā)組人員的意見提交給客戶，并取得客戶的支持。這個(gè)過程有時(shí)候也需要反復(fù)幾次；?各種文檔的準(zhǔn)備，需要和客戶溝通、確認(rèn)。有時(shí)候客戶對(duì)文檔有特殊要求時(shí)，需要往返幾次；?驗(yàn)收、上線運(yùn)行等問題需要和客戶溝通、確認(rèn)可以選擇的溝通方式根據(jù)現(xiàn)有的物質(zhì)、技術(shù)條件，溝通方式大體有以下幾種：?面談。一些問題要和開發(fā)人員當(dāng)面探討，一般不涉及到其他人、其它模塊，并且開發(fā)者本人能夠確定的。?座談。一般是項(xiàng)目開發(fā)小組、相關(guān)的領(lǐng)導(dǎo)一塊討論一些牽扯面比較大的問題。?郵件。不論是和開發(fā)人員溝通，還是和客戶溝通，郵件都是最常用的方式。可以用郵件傳送文件資料，做正式的任務(wù)下達(dá)等。這要求

51、溝通雙方都有免費(fèi)或者公司的郵件服務(wù)器，并且雙方都樂意使用這種方式（不能有一方不愿意打字）。?聊天工具。主要使用MSN等。主要用于日常溝通，當(dāng)溝通雙方打字速度都比較快時(shí)， 是一個(gè)好的辦法，成本低。但是遇到一方不會(huì)打字時(shí)，就不是好的選擇了。?電話。當(dāng)用打字的辦法不能準(zhǔn)確表達(dá)意思時(shí)，就要選擇電話方式了。?傳真。主要用于比較重要的文件傳輸?shù)龋珉p方簽定的協(xié)議。在整個(gè)項(xiàng)目過程中，我們主要通過面談和電話的方式和客戶進(jìn)行溝通，個(gè)人覺得，如果方便的話，還是面談比較好，可以和客戶進(jìn)行詳細(xì)的探討。小結(jié)溝通，可以說已經(jīng)變得無比的重要。在軟件業(yè)，溝通可以說是快速學(xué)習(xí)和掌握新知識(shí)，達(dá)到技術(shù)上的更高層次的最佳途徑。小組員

52、的溝通，可以很好的加強(qiáng)團(tuán)隊(duì)組織的凝聚力?？赡芨玫淖屝〗M軟件項(xiàng)目良性的進(jìn)行。而培養(yǎng)這種氣氛，形成有效的溝通，這也是項(xiàng)目管理的基本內(nèi)容。協(xié)調(diào)幾個(gè)人的工作比自己完成一段編碼更重要。如果小組成員在協(xié)調(diào)上出了漏洞，可能導(dǎo)致很大的問題，所以項(xiàng)目負(fù)責(zé)人必須隨時(shí)監(jiān)控各開發(fā)人員的工作，包括內(nèi)容是否 與要求發(fā)生偏差，進(jìn)度是否滯后等等。在需求分析結(jié)束以后，甲乙雙方要建立可以直接聯(lián)系的渠道，以盡早地對(duì)需求變動(dòng)問題進(jìn)行溝通。并在項(xiàng)目需求分析完成后，和客戶明確項(xiàng)目的哪些部分可以在日后的進(jìn)度中能修 改，修改的限度，哪些不能修改。例如，應(yīng)用背景、功能要求方面應(yīng)該是在需求分析階段確 定，日后不能做修改。而性能、界面及接口等可

53、以在日后作有限度的修改。盡早溝通、主動(dòng)溝通就是其中的兩個(gè)原則，實(shí)踐證明它們非常關(guān)鍵。盡早溝通要求項(xiàng)目經(jīng)理要有前瞻性，定期和項(xiàng)目成員建立溝通，不僅容易發(fā)現(xiàn)當(dāng)前存在的問題，很多潛在問題也能暴露出來。在項(xiàng)目中出現(xiàn)問題井不可怕，可怕的是問題沒被發(fā)現(xiàn)。溝通得越晚，暴露得越遲，帶來的損失越大。主動(dòng)溝通說到底是對(duì)溝通的一種態(tài)度。在小組軟件項(xiàng)目中，我們極力提倡主動(dòng)溝通，尤其是當(dāng)已經(jīng)明確了必須要去溝通的時(shí)候。當(dāng)溝通是小組軟件項(xiàng)目經(jīng)理面對(duì)用戶或上級(jí)、團(tuán)隊(duì) 成員面對(duì)項(xiàng)目經(jīng)理時(shí)，主動(dòng)溝通不僅能建立緊密的聯(lián)系，更能表明你對(duì)項(xiàng)目的重視和參與， 會(huì)使溝通的另一方滿意度大大提高，對(duì)整個(gè)小組軟件項(xiàng)目非常有利。變更控制前言不被控

54、制的變更是小組軟件項(xiàng)目陷人混亂、不能按進(jìn)度執(zhí)行或軟件質(zhì)量低劣的共同原因。為了使開發(fā)組織能夠嚴(yán)格控制小組軟件項(xiàng)目應(yīng)確保以下事項(xiàng)：?應(yīng)仔細(xì)評(píng)估已建議的變更。?選擇合適的人選對(duì)變更做出決定。?變更應(yīng)及時(shí)通知所有涉及的人員。?軟件項(xiàng)目要按一定的程序來采納需求變更。只有軟件項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在開發(fā)過程中能控制變更，他們才知道將交付什么，哪一項(xiàng)將會(huì)導(dǎo)致與目標(biāo)的差距。對(duì)項(xiàng)目越深人了解后，你就越能發(fā)現(xiàn)采納變更需求條件的苛刻。在需求文檔中一定要反映項(xiàng)目的變更，需求文檔應(yīng)精確描述要交付的產(chǎn)品，這就是你的原則。要是軟件需求文檔同產(chǎn)品不一致，那它就毫無用處，甚至就像沒有一個(gè)軟件需求文檔來指導(dǎo)開發(fā)組開發(fā)一樣。當(dāng)不得不做出變

55、更時(shí)，應(yīng)該按從高級(jí)到低級(jí)的順序?qū)Ρ挥绊懙男枨笪臋n進(jìn)行處理。舉個(gè)例子。一個(gè)已建議的變更可能影響一個(gè)使用實(shí)例和功能需求但不影響任何業(yè)務(wù)需求。改動(dòng)高層系統(tǒng)需求能夠影響多個(gè)軟件需求。如果在最低層需求上做出變更，（典型的情況是一個(gè)功能性需求），可能會(huì)導(dǎo)致需求同上層文檔不一致。變更產(chǎn)生的原因在軟件系統(tǒng)開發(fā)過程中，有很多問題都是由于在需求分析階段沒有正確地收集、編寫、協(xié)商、修改產(chǎn)品真實(shí)需求而產(chǎn)生的，造成這樣的狀況有幾方面的原因：?對(duì)需求的理解分歧當(dāng)客戶向需求分析人員提出需求的時(shí)候往往是通過自然語言來表達(dá)的，這樣的表達(dá)對(duì)于真實(shí)的需求來說是一種描述（甚至只是某個(gè)角度的描述），遠(yuǎn)遠(yuǎn)不能保證這樣的描述可以得到百分之

56、百的正確理解，也許在同客戶交流的第一時(shí)刻就埋下了理解分歧的種子，打一個(gè)比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、桿子、繩子這些我都知道，但是真的畫出來的時(shí)候客戶當(dāng)然會(huì)跳起來了!這是理解分歧的問題，一般跟分析員的知識(shí)、背景，還有客戶表述的標(biāo)準(zhǔn)程度、雙方的交流情況有關(guān)。?系統(tǒng)實(shí)施時(shí)間過長一個(gè)大中型系統(tǒng)的建設(shè)可能要延續(xù)一段時(shí)間，當(dāng)客戶提出要求之后，他當(dāng)時(shí)并不能看到系統(tǒng)的運(yùn)行情況，當(dāng)雙方認(rèn)為理解大概沒有分歧的時(shí)候（事實(shí)上還會(huì)有個(gè)Deadline） ， 開發(fā)方就開始工作了。當(dāng)客戶拿到差不多可以試用的產(chǎn)品時(shí)他可以實(shí)際操作，這時(shí)候他就會(huì)對(duì)系統(tǒng)

57、的界面、操作、功能、性能等有一些切身的體會(huì)，有可能提出需求變更要求。?客戶具體情況不一當(dāng)前客戶的情況不一，有可能客戶行業(yè)的競爭度高，需要隨時(shí)作出調(diào)整和反應(yīng)，那么他們自然會(huì)經(jīng)常提出需求變更的要求；也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時(shí)候開發(fā)方更是需要隨時(shí)準(zhǔn)備應(yīng)變。?開發(fā)本身要求有可能是來自開發(fā)方自身版本升級(jí)或性能改進(jìn)、設(shè)計(jì)修正的要求出現(xiàn)需求變更，這時(shí)更是無法繞開這個(gè)問題的了。所以說就算分析人員和客戶之間不存在理解分歧，客戶對(duì)于實(shí)際的系統(tǒng)還是會(huì)提出一些個(gè)人意見，就算沒有個(gè)人意見，他們自己的業(yè)務(wù)會(huì)變化或環(huán)境發(fā)生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當(dāng)你開始一

58、個(gè)小組項(xiàng)目的時(shí)候就應(yīng)該意識(shí)到，客戶的需求變更一定會(huì)有的，那么對(duì)于這樣的現(xiàn)狀，我們該怎么辦呢?難道我們要跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設(shè)計(jì)也會(huì)改變得支離破碎，系統(tǒng)難以維護(hù)。在軟件項(xiàng)目中如何控制變更根據(jù)公司的規(guī)章制度，在小組軟件項(xiàng)目中，控制軟件需求變更是需求經(jīng)理的職責(zé)。需求經(jīng)理要面對(duì)開發(fā)人員和客戶雙方提出的需求變更。開發(fā)人員提出需求變更，一般情況是他們在實(shí)際開發(fā)過程中發(fā)現(xiàn)了原來的設(shè)計(jì)不合理之處，需要更改設(shè)計(jì)?；蛘呤怯矛F(xiàn)有的方法不能實(shí)現(xiàn)預(yù)定的功能。對(duì)于這樣的變更，一般要做的只是及時(shí)將變更情況通知客戶，并取得客戶的諒解。但是，絕大多數(shù)的需求

59、變更是由客戶提出的。對(duì)于客戶提出的變更請(qǐng)求，要區(qū)別對(duì)待：?如果此變更是超出合同規(guī)定（或需求規(guī)格說明書中）的范圍，應(yīng)該明確予以拒絕；?綜合考慮功能、成本、進(jìn)度等方面的內(nèi)容后，認(rèn)為可以進(jìn)行變更的則答應(yīng)；?一些拿不準(zhǔn)的事情，要和項(xiàng)目組成員進(jìn)行商量，再做決定。其結(jié)果不外乎拒絕或答應(yīng)。控制變更的方法是要敢于說“不”。很多人不喜歡說“不”，開發(fā)者只好在各種壓力下接受每一項(xiàng)建議的需求。 “客戶總是對(duì)的”， “我們將使客戶完全滿意”這些話哲理上是正確的，一旦按此辦事就要付出代價(jià)。忽視代價(jià)并不能改變“變更不免費(fèi)”的事實(shí)。拒絕的方法客戶首先給我們提供的是業(yè)務(wù)需求，如果一開始就是比較完善的需求則是我們求之不得，但事

60、事并非人愿。他們總讓我們在整個(gè)項(xiàng)目周期中循環(huán)，甚至停滯。為了控制我們小組軟件項(xiàng)目的質(zhì)量、進(jìn)度我們運(yùn)用迭代，在迭代之中與客戶交流卻又出現(xiàn)新問題。用戶讓我們滿足他們一切的需求，而滿足用戶好像就我們的本能一樣，不斷的修改完善，造成不可預(yù)料的后果。有些客戶認(rèn)為自已是上帝，一句勝千金，如有不妥，就會(huì)找到你的上級(jí)，以至于毀掉合約。有時(shí)關(guān)于項(xiàng)目外也要求你去解決，這對(duì)項(xiàng)目本身，以及公司的整體利益無非是一種無利的要求。若我們?nèi)P脫出答應(yīng)于創(chuàng)1， 這會(huì)影響我們的項(xiàng)目成本與小組軟件項(xiàng)目整體的可控性。如何能回絕客戶并讓客戶充分理解你的意圖以致滿足他們一些想法與關(guān)點(diǎn)是我們應(yīng)遵循的話題，我們需在保存雙方利益友好的情況下去