|
| 目錄： 勇于直面需求變更 從程序員到系統(tǒng)分析員 需求的問(wèn)題 互連網(wǎng)軟件工程淺談 淺談網(wǎng)站工程的管理與規(guī)范 系統(tǒng)規(guī)格說(shuō)明 典型系統(tǒng)分析 邊 際 需 求 遞 減 規(guī) 律 如何寫系統(tǒng)分析書(shū)
|
|
|
| 探究需求管理的本質(zhì)
任務(wù)劃分：
這里有一個(gè)需求、產(chǎn)品和測(cè)試系統(tǒng)之間的關(guān)系問(wèn)題，確定需要進(jìn)行的測(cè)試屬于總體開(kāi)發(fā)主管的工作范疇，雖然具體工作并非都要由開(kāi)發(fā)主管來(lái)親自完成。
試想以下三種情況：
☆總結(jié)：需求管理
|
|
|
| ||
|
|
| |
| |
|
|
|
|
勇于直面需求變更
Windy. J
關(guān)鍵詞：需求、需求變更、需求分析、代價(jià)估算、面向?qū)ο蠹夹g(shù)、封裝、繼承、多態(tài)、UML 、軟件設(shè)計(jì)、軟件可維護(hù)性、可擴(kuò)展性、軟件可重用性、接口
摘要：作者針對(duì)當(dāng)前軟件系統(tǒng)建設(shè)中普遍存在的需求變更問(wèn)題提出了自己的見(jiàn)解，并提出除了從客觀上采取加強(qiáng)培訓(xùn)和代價(jià)分析等方法外，更重要的是通過(guò)采用合理的分析設(shè)計(jì)方法，進(jìn)行可擴(kuò)展性設(shè)計(jì)可以有效地降低需求變更引起的風(fēng)險(xiǎn)和維護(hù)代價(jià)，并給出了可擴(kuò)展性設(shè)計(jì)的一個(gè)具體例子。
軟件系統(tǒng)開(kāi)發(fā)過(guò)程中的需求變更問(wèn)題
作為軟件開(kāi)發(fā)人員或者軟件系統(tǒng)客戶，相信我們都遭遇過(guò)因?yàn)樾枨笞兏枰薷南到y(tǒng)的情況，一般說(shuō)來(lái)客戶會(huì)要求改變界面，改變操作方式，甚至改變業(yè)務(wù)，說(shuō)，當(dāng)時(shí)我是那樣要求的，不過(guò)現(xiàn)在我們的業(yè)務(wù)調(diào)整了…這時(shí)需要中斷正在進(jìn)行的工作，需要查證以往的資料，需要修正計(jì)劃，需要… 需求包括業(yè)務(wù)需求、用戶需求和功能需求。業(yè)務(wù)需求（Business Requirement ）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，用戶需求（User Requirement ）描述了用戶使用產(chǎn)品必須完成的任務(wù)，功能需求（Functional Requirement ）定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能。在軟件系統(tǒng)開(kāi)發(fā)過(guò)程中，有很多問(wèn)題都是由于在需求分析階段沒(méi)有正確地收集、編寫、協(xié)商、修改產(chǎn)品真實(shí)需求而產(chǎn)生的，造成這樣的狀況有幾方面的原因:
對(duì)需求的理解分歧
當(dāng)客戶向需求分析人員提出需求的時(shí)候往往是通過(guò)自然語(yǔ)言來(lái)表達(dá)的，這樣的表達(dá)對(duì)于真實(shí)的需求來(lái)說(shuō)是一種描述（甚至只是某個(gè)角度的描述），遠(yuǎn)遠(yuǎn)不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時(shí)刻就埋下了理解分歧的種子，打一個(gè)比方說(shuō)客戶說(shuō)我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來(lái)的時(shí)候客戶當(dāng)然會(huì)跳起來(lái)了！這是理解分歧的問(wèn)題，一般跟分析員的知識(shí)、背景，還有客戶表述的標(biāo)準(zhǔn)程度、雙方的交流情況有關(guān)；
系統(tǒng)實(shí)施時(shí)間過(guò)長(zhǎng)
一個(gè)大中型系統(tǒng)的建設(shè)可能要延續(xù)一段時(shí)間，當(dāng)客戶提出要求之后，他當(dāng)時(shí)并不能看到系統(tǒng)的運(yùn)行情況，當(dāng)雙方認(rèn)為理解大概沒(méi)有分歧的時(shí)候（事實(shí)上還會(huì)有個(gè)Deadline ），開(kāi)發(fā)方就開(kāi)始工作了。當(dāng)客戶拿到差不多可以試用的產(chǎn)品時(shí)他可以實(shí)際操作，這時(shí)候他就會(huì)對(duì)系統(tǒng)的界面、操作、功能、性能等有一些切身的體會(huì)，有可能提出需求變更要求；
客戶具體情況不一
當(dāng)前客戶的情況不一，有可能客戶行業(yè)的競(jìng)爭(zhēng)度高，需要隨時(shí)作出調(diào)整和反應(yīng)，那么他們自然會(huì)經(jīng)常提出需求變更的要求；也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時(shí)候開(kāi)發(fā)方更是需要隨時(shí)準(zhǔn)備應(yīng)變；
開(kāi)發(fā)本身要求
有可能是來(lái)自開(kāi)發(fā)方自身版本升級(jí)或性能改進(jìn)、設(shè)計(jì)修正的要求出現(xiàn)需求變更，這時(shí)更是無(wú)法繞開(kāi)這個(gè)問(wèn)題的了！ 所以說(shuō)就算分析人員和客戶之間不存在理解分歧，客戶對(duì)于實(shí)際的系統(tǒng)還是會(huì)提出一些個(gè)人意見(jiàn)，就算沒(méi)有個(gè)人意見(jiàn)，他們自己的業(yè)務(wù)會(huì)變化或環(huán)境發(fā)生變化，這些都是無(wú)法避免的，所以不要夢(mèng)想那么理想的需求分析，當(dāng)你開(kāi)始一個(gè)項(xiàng)目的時(shí)候就應(yīng)該意識(shí)到，客戶需求變更一定會(huì)有的，那么對(duì)于這樣的現(xiàn)狀，我們?cè)撛趺崔k呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長(zhǎng)，員工疲憊，成本成倍增長(zhǎng)，客戶滿意度降低，原來(lái)的設(shè)計(jì)也會(huì)改變得支離破碎，系統(tǒng)難以維護(hù)？
客觀面對(duì)需求變更
如果需求一定會(huì)變化，如果我們不得不面對(duì)，如果我們已經(jīng)痛定思痛，想要變革，那么還有什么辦法可以改善我們的現(xiàn)狀 答案是有的。
加強(qiáng)人員培訓(xùn)
從客觀方面可以采取的措施來(lái)說(shuō)，首先，我想不容置疑的是加強(qiáng)對(duì)需求分析人員的培訓(xùn)，盡可能增強(qiáng)軟件系統(tǒng)、行業(yè)的背景知識(shí)，提高與客戶的溝通能力，增強(qiáng)服務(wù)意識(shí)和責(zé)任感，因?yàn)閷⒁_(kāi)發(fā)的系統(tǒng)直接建立在需求分析的基礎(chǔ)上；同時(shí)規(guī)范需求分析人員和客戶溝通的方式，以及規(guī)范需求說(shuō)明的格式，如果可能的話，盡量采取象XP 的UserStory ，或者用戶可以理解的用例圖來(lái)對(duì)需求進(jìn)行標(biāo)準(zhǔn)、規(guī)范的描述，保證雙方在工具的協(xié)助下對(duì)需求達(dá)到共同的認(rèn)識(shí)，這一點(diǎn)是老生常談，就不多說(shuō)。
確定文檔的有效性（Validity ）
順便要提的一句是關(guān)于文檔，需求文檔是相當(dāng)重要的，可是目前存在一種奇怪的現(xiàn)象，本來(lái)說(shuō)必須要有文檔，而且是按照某種特定的格式，當(dāng)然這沒(méi)有錯(cuò)，但接下來(lái)，卻沒(méi)有人關(guān)心文檔的真正內(nèi)容是否正確，格式是否真的合理，是否實(shí)用（而且很多情況下是在幾天時(shí)間里趕出來(lái)或補(bǔ)上去的），例如我遇到一個(gè)例子，需要在原來(lái)的需求基礎(chǔ)上進(jìn)行后續(xù)開(kāi)發(fā)，文檔找到了，完全符合格式的要求，但是我在里面找到的線索是有限的，結(jié)果是自己花幾天的時(shí)間查找數(shù)據(jù)表結(jié)構(gòu)、甚至查看數(shù)據(jù)表的內(nèi)容，詢問(wèn)當(dāng)時(shí)的開(kāi)發(fā)人員，才分析到所要的關(guān)系，這種情況在設(shè)計(jì)文檔里也存在，所以同時(shí)提一提，希望我們的開(kāi)發(fā)人員、PM 以及各級(jí)領(lǐng)導(dǎo)可以注意文檔的有效性和有用性問(wèn)題，甚至對(duì)文檔的格式進(jìn)行一下合理性檢查。 建立代價(jià)估算（Cost Estimate ）概念 |
聯(lián)系客服
