需求管理和需求分析.ppt_第1頁
需求管理和需求分析.ppt_第2頁
需求管理和需求分析.ppt_第3頁
需求管理和需求分析.ppt_第4頁
需求管理和需求分析.ppt_第5頁
已閱讀5頁,還剩43頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、需求管理和需求分析,需求管理和需求分析,內(nèi)容,前言 需求工程簡(jiǎn)介 需求開發(fā)的主要困難與對(duì)策 如何開展需求調(diào)查 如何進(jìn)行需求分析 什么是好的需求規(guī)格說明書 形成需求規(guī)格說明書 需求管理:確認(rèn)、跟蹤、變更控制 CMM2級(jí)KPA需求管理(RM)介紹,前言,泛泛地講,需求來源于客戶的一些“需要”,這些“需要”被分析、確認(rèn)后形成完整的文檔,該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)當(dāng)”做什么。 所以如果只有一些零碎的對(duì)話、資料或郵件,并沒有真正掌握需求 Frederick Brooks在他1987年經(jīng)典文章“No Silver Bullet”中闡述了需求的重要性:開發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說明開發(fā)什么。最困

2、難的概念性工作是編寫出詳細(xì)的需求,包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。此工作一旦做錯(cuò),將會(huì)給系統(tǒng)帶來極大的損害,并且以后對(duì)它修改也極為困難。 需求是產(chǎn)品的根源,需求工作的優(yōu)劣對(duì)產(chǎn)品影響最大。就像一條河流,如果源頭被污染了,那么整條河流也就被污染了。,前言, 定義(IEEE-STD-610) 用戶為解決某個(gè)問題、或?yàn)閷?shí)現(xiàn)某一目標(biāo), 要求軟件必須滿足的條件或能力。 軟件需求的三個(gè)層次 業(yè)務(wù)需求 用戶需求 功能需求和非功能需求,前言,前言,前言,前言,“用戶”(user)是一種泛稱,它可細(xì)分為“客戶”(customer)、“最終用戶”(the end user)和“間接用戶”(或稱為關(guān)系

3、人)。掏錢買軟件的用戶稱為客戶,而真正操作軟件的用戶叫最終用戶??蛻襞c最終用戶可能是同一個(gè)人也可能不是同一個(gè)人。 客戶是掏錢買軟件的人,所以他是“上帝” 。某飯店經(jīng)理在解釋“先有雞還是先有蛋”這個(gè)哲學(xué)問題時(shí),精辟地闡述了客戶的地位:如果顧客先點(diǎn)雞,那么就先有雞;如果顧客先點(diǎn)蛋,那么就先有蛋。 客戶的需要才是最準(zhǔn)確需求之源,需求工程簡(jiǎn)介,把所有與需求直接相關(guān)的活動(dòng)通稱為需求工程。需求工程中的活動(dòng)可分為兩大類,一類屬于需求開發(fā),另一類屬于需求管理。 需求工程的結(jié)構(gòu)圖,需求工程簡(jiǎn)介,需求工程簡(jiǎn)介,需求開發(fā)過程 需求開發(fā)的目的是通過調(diào)查與分析,獲取用戶需求并定義產(chǎn)品需求。 需求調(diào)查的目的是通過各種途徑

4、獲取用戶的需求信息(原始材料),產(chǎn)生用戶需求說明書。 需求分析的目的是對(duì)各種需求信息進(jìn)行分析,消除錯(cuò)誤,刻畫細(xì)節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果,進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求,產(chǎn)生產(chǎn)品需求規(guī)格說明書。系統(tǒng)設(shè)計(jì)人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設(shè)計(jì)工作。,需求工程簡(jiǎn)介,需求管理過程 需求管理的目的是在客戶與開發(fā)方之間建立對(duì)需求的共同理解,維護(hù)需求與其它工作成果的一致性,并控制需求的變更。 需求確認(rèn)是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審,雙方對(duì)需求達(dá)成共識(shí)后作出書面承諾,使需求文檔具有商業(yè)合同效果。 需求跟蹤是指通過比較需

5、求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系,建立與維護(hù)“需求跟蹤矩陣”,確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。 需求變更控制是指依據(jù)“變更申請(qǐng)審批更改重新確認(rèn)”的流程處理需求的變更,防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。,需求工程簡(jiǎn)介,不論是合同項(xiàng)目還是自主研發(fā)的產(chǎn)品,都必須開展需求開發(fā)和需求管理活動(dòng)。開發(fā)者對(duì)待需求工程的態(tài)度可分“被動(dòng)型”、“主動(dòng)型”和“領(lǐng)先型”三種。 “被動(dòng)型”是指開發(fā)者被動(dòng)地對(duì)待需求工程中的各項(xiàng)活動(dòng)。他們認(rèn)為需求是用戶的事情。開發(fā)過程中經(jīng)常發(fā)生需求變更,導(dǎo)致產(chǎn)品迷失方向,不是半途而廢就是陷入半死不活的狀態(tài)。 “主動(dòng)型”是指開發(fā)者積極地開展需求工程中的各項(xiàng)活動(dòng)。他們把獲取準(zhǔn)確的需求當(dāng)作自

6、己的職責(zé),會(huì)想盡一切辦法克服需求開發(fā)和需求管理過程中的困難,而不是找借口推卸責(zé)任。俗話說“良好的開端是成功的一半”。 “領(lǐng)先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識(shí)到的需求,導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn),這叫引導(dǎo)消費(fèi)。需求工程做到這個(gè)份上,才能使產(chǎn)品立于不敗之地,長(zhǎng)盛不衰。,需求工程簡(jiǎn)介,需求工程很重要羅,需求開發(fā)的主要困難與對(duì)策,1 知識(shí)技能問題 應(yīng)用域的知識(shí)是無邊無際的,任何人都不可能是“萬事通”。俗話說“隔行如隔山”,需求分析員可能是某一領(lǐng)域的專家,但當(dāng)他接手陌生的業(yè)務(wù)時(shí),他可能是個(gè)“無知”者。一個(gè)企業(yè)要謀求發(fā)展,不能總在做老的業(yè)務(wù)。人一生中會(huì)有許多充滿挫

7、折的“第一次”,不可以逃避。 我們?nèi)狈?yīng)用域知識(shí),該怎么辦? 首先要有勇氣做事,否則連實(shí)踐的機(jī)會(huì)都沒有。 其次他應(yīng)當(dāng)趕緊補(bǔ)習(xí)應(yīng)用域知識(shí),不論是通過自學(xué)還是培訓(xùn)的方式,否則他很難與用戶交流。如果可能的話,最好請(qǐng)既懂軟件又懂應(yīng)用域知識(shí)的行家來幫忙。 2 態(tài)度問題 我們習(xí)慣于被動(dòng)地對(duì)待需求開發(fā)。每當(dāng)遇到麻煩、挫折時(shí),我們會(huì)發(fā)牢騷并錯(cuò)誤地以為: 需求是用戶的事情,不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件,難道用戶不該告訴我們應(yīng)當(dāng)開發(fā)什么嗎?如果用戶說不清楚需求,或者經(jīng)常變更需求,這類問題是用戶產(chǎn)生的,應(yīng)當(dāng)由他們自己負(fù)責(zé)。 用戶說不清楚需求或者需求發(fā)生變更,這些都是常見的問題,并不是絕癥,是人們可以設(shè)法解決的

8、。我們要主動(dòng)攻克問題,導(dǎo)致需求問題擴(kuò)散到整個(gè)軟件開發(fā)過程,產(chǎn)生太多的后患。 項(xiàng)目負(fù)責(zé)人應(yīng)當(dāng)給具有錯(cuò)誤觀念的開發(fā)人員們洗腦:需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求 。,需求開發(fā)的主要困難與對(duì)策,.3 合作關(guān)系 如果我們不能與用戶建立良好的合作關(guān)系,那么我們?cè)谛枨箝_發(fā)過程中會(huì)很疲憊。 倘若用戶不能很好地配合需求分析員,那并不表示他是個(gè)壞蛋。因?yàn)橛脩粲兴约旱南敕ǎ?我回答了你們的問題,講了該講的。我們付錢給你們,難道還要我伺候你們不成?我還要干自己的事情,別打擾我了。你們自己想辦法把活干好吧。 需求分析員不是銷售人員,他們不可能象銷售人員那樣通過某些手段籠絡(luò)住用戶就能成功。出色

9、的需求分析員不僅要有過硬的專業(yè)知識(shí),還要具備較強(qiáng)的交流、溝通能力,我們可以通過幫助用戶解決一些技術(shù)上的小問題和用戶拿攏關(guān)系。 對(duì)于一些競(jìng)標(biāo)項(xiàng)目,在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會(huì)買你的產(chǎn)品,他不會(huì)投入很多精力來協(xié)助你搞需求開發(fā),我們積極主動(dòng)找用戶了解業(yè)務(wù)和需求。 開發(fā)方與用戶的合作關(guān)系對(duì)需求開發(fā)而言是至關(guān)重要的。對(duì)于重大的、復(fù)雜的項(xiàng)目,我們不能完全期望客戶能自發(fā)地和我們建立起良好地合作關(guān)系,這樣風(fēng)險(xiǎn)太大。 在開展需求開發(fā)之前,我們要“好話”和“丑話”都說在前頭,這樣能減少今后的摩擦??赡茉?,以書面形式明確雙方的在需求工程方面的權(quán)利和義務(wù)。 當(dāng)然,在進(jìn)行需求調(diào)查時(shí),我們應(yīng)該有個(gè)具

10、體的計(jì)劃供客戶確認(rèn)。,需求開發(fā)的主要困難與對(duì)策,用戶在需求工程中的“權(quán)利” 有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。 有權(quán)要求開發(fā)方采用他們熟悉的語言來描述需求,即開發(fā)方必須提供用戶看得懂得需求文檔。 有權(quán)審查需求文檔,并對(duì)有爭(zhēng)議的需求作出決策。如果認(rèn)為需求文檔不能準(zhǔn)確地反映用戶真實(shí)的意愿,可以拒絕在需求文檔上簽字。 如果用戶想要變更需求,有權(quán)要求開發(fā)方對(duì)該變更將產(chǎn)生的影響作出真實(shí)可信的評(píng)估,以便用戶決定是否變更需求。 用戶在需求工程中的“義務(wù)” 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作,盡可能地為開發(fā)方人員提供工作和生活上的便利。 樂意接受需求分析員的采訪,在不泄漏機(jī)密的前提下盡可能

11、地回答需求分析員的問題。 在不泄漏機(jī)密的前提下,盡可能地向需求分析員提供與需求相關(guān)的材料。 與需求分析員共同評(píng)審需求文檔,確保需求文檔準(zhǔn)確地反映用戶真實(shí)的意愿。,需求開發(fā)的主要困難與對(duì)策,4 用戶說不清楚需求 用戶說不清楚需求是普遍現(xiàn)象,這讓我們很頭痛。 有些用戶真的不知道需求是什么,或者對(duì)需求只有朦朧的感覺,他當(dāng)然說不清楚需求。 有些用戶雖然心里明白想要什么,但卻說不清楚需求。 好像說買鞋子。我們非常了解自已的腳,但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試,試穿時(shí)感覺到舒服才會(huì)買鞋。 我們絕不能以用戶說不清楚需求為借口而草率地對(duì)待需求開發(fā)工作,這樣會(huì)連累整個(gè)開發(fā)團(tuán)隊(duì)的。 對(duì)于不清楚需求

12、的用戶,我們可以根據(jù)客戶的業(yè)務(wù),按我們的理解提出用戶需求,然后再找用戶確認(rèn)。事實(shí)上,作為系統(tǒng)分析人員,在做系統(tǒng)分析的時(shí)候,其實(shí)也是在為國(guó)家信息化建設(shè)做普及教育工作。 對(duì)于知道需求的用戶,我們可以根據(jù)用戶大概的描敘,在按照我們的理解,再系統(tǒng)地地復(fù)述給用戶,讓用戶確認(rèn)。,需求開發(fā)的主要困難與對(duì)策,5 雙方誤解需求 人們?cè)诮涣鞯臅r(shí)候,經(jīng)常會(huì)發(fā)生“問非所求,答非所問”的事情。 有時(shí)用戶會(huì)把開發(fā)人員的建議或答復(fù)給想歪了: 而用戶表達(dá)的需求,不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求,那會(huì)導(dǎo)致后續(xù)的不少開發(fā)人員將錯(cuò)就錯(cuò)、白干活。就像作文寫跑題了,寫得再好也白搭。這類錯(cuò)誤連高智商的外星人都不能

13、避免: 不論是復(fù)雜的項(xiàng)目還是簡(jiǎn)單的項(xiàng)目,需求分析員和用戶都有可能誤解需求。所以需求確認(rèn)工作(屬于需求管理)必不可少。,需求開發(fā)的主要困難與對(duì)策,6 開發(fā)人員寫不好需求文檔 需求調(diào)查工作不充分,獲取的需求信息太少或者太亂,以至于寫不成需求文檔。 古時(shí)候,一書生在考試前補(bǔ)習(xí)“寫文章”,成天愁眉苦臉。其夫人甚為不解,問:“相公,你寫文章比我生小孩還難嗎?”書生長(zhǎng)嘆一聲:“娘子你哪里知道我的難處?。∧闵『r(shí)肚子里有東西,可我寫文章時(shí)肚子里沒東西啊?!?所以要想寫出好的需求文檔,前提條件是把需求調(diào)查工作做好。 開發(fā)人員寫作能力比較差,雖然在調(diào)查過程中已經(jīng)獲得了不少需求信息,卻寫不出好的需求文檔來。 可

14、以毫不夸張地說,國(guó)內(nèi)90以上的軟件開發(fā)人員,他們的寫作能力遠(yuǎn)不及開發(fā)能力。 提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習(xí)寫文檔,熟能生巧。 另外,公司應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔,盡可能地降低寫作難度。,需求開發(fā)的主要困難與對(duì)策,7 用戶經(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ā)。毫無疑問,這種需求變更將使項(xiàng)目付出額外的代價(jià)。這種損失是由于雙方工作失誤造成的,雙方應(yīng)當(dāng)好好反省,認(rèn)真學(xué)習(xí)需求

15、開發(fā)和管理的方法,避免再犯相似的錯(cuò)誤。 如果由于市場(chǎng)變化而導(dǎo)致產(chǎn)品需求發(fā)生變更,開發(fā)商大可不必為此煩惱,應(yīng)當(dāng)高興才對(duì)。倘若市場(chǎng)靜如死水,那么開發(fā)商吃了“上一頓”就沒有“下一頓”。正因?yàn)槭袌?chǎng)在變化,才會(huì)產(chǎn)生更多商機(jī)。 其實(shí)需求變更并不可怕,可怕的是需求變更失去控制,導(dǎo)致項(xiàng)目混亂。所以需求變更控制是需求工程的重要活動(dòng)。,如何開展需求調(diào)查,1 準(zhǔn)備調(diào)查 首先,需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表,將調(diào)查重點(diǎn)鎖定在該問題表內(nèi),否則調(diào)查工作將變得漫無邊際。 問題表可以有多份,隨著調(diào)查的深入,問題表將不斷地被細(xì)化。 根據(jù)經(jīng)驗(yàn),用戶通常沒有耐心回答復(fù)雜的論述題,所以問題表應(yīng)當(dāng)以“選擇題”和“是非題”為主。 制定

16、問題表最簡(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ì)劃。要特別留意的是不要漏掉典型的用戶。,如何開展需求調(diào)查,2 執(zhí)行調(diào)查 按照計(jì)劃執(zhí)行調(diào)查。在調(diào)查過程中隨時(shí)記錄(或存儲(chǔ))需求信息 。 與用戶面談時(shí)應(yīng)當(dāng)注意以下事項(xiàng): 如果

17、與用戶約好了時(shí)間,切勿遲到或早退。 我們應(yīng)事先了解用戶的身份、背景,以便隨機(jī)應(yīng)變。 需求調(diào)查不象偵探推理那樣從蛛絲馬跡著手,應(yīng)該先了解宏觀問題,再了解細(xì)節(jié)問題。 如果雙方氣氛融洽,可以采用靈活的訪談形式,輕易不要打斷用戶的談話。當(dāng)雙方對(duì)某些問題的交流合乎邏輯地結(jié)束后,即可繼續(xù)討論問題表中的其它問題。 在自由聊天中了解用戶需求,比正式面談效果好。 盡可能避免為用戶添麻煩,但也不能怕給用戶添麻煩而降低需求調(diào)查的力度。 避免片面地聽取某些用戶的需求而忽視其它用戶的需求。 事實(shí)上,需求調(diào)查除了面談外,還可以查閱用戶的資料,在查閱資料的過程中,有問題再向用戶詢問。讓用戶邊工作,氣氛會(huì)顯得更加輕松。,如何

18、開展需求調(diào)查,3撰寫或修改用戶需求說明書 用戶需求說明書與產(chǎn)品需求規(guī)格說明書的主要區(qū)別與聯(lián)系 前者主要采用自然語言(和應(yīng)用域術(shù)語)來表達(dá)用戶需求,其內(nèi)容相對(duì)于后者而言比較粗略,不夠詳細(xì)。 后者是前者的細(xì)化,更多地采用計(jì)算機(jī)語言和圖形符號(hào)來刻畫需求,產(chǎn)品需求是軟件系統(tǒng)設(shè)計(jì)的直接依據(jù)。 兩者之間可能并不存在一一影射關(guān)系,因?yàn)檐浖_發(fā)商會(huì)根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當(dāng)前狀況適當(dāng)?shù)卣{(diào)整產(chǎn)品需求,例如用戶需求可能被分配到軟件的數(shù)個(gè)版本中。軟件開發(fā)人員應(yīng)當(dāng)依據(jù)產(chǎn)品需求規(guī)格說明書來開發(fā)當(dāng)前產(chǎn)品。,如何進(jìn)行需求分析,1 基本概念 有時(shí)候我們不得不鼓吹:用戶就是上帝,用戶永遠(yuǎn)是正確的。 但事實(shí)上,很多時(shí)候用戶說不清楚

19、需求、會(huì)說錯(cuò)需求或者提出一些無法實(shí)現(xiàn)的需求。 需求分析是旨在需求開發(fā)過程中,對(duì)所獲取的需求信息進(jìn)行分析,及時(shí)排除錯(cuò)誤和彌補(bǔ)不足,確保需求文檔正確地反映用戶的真實(shí)意圖。 需求分析是需求開發(fā)過程中最費(fèi)腦子的工作。分析方法大體有兩類:“問答分析法”和“建模分析法”。后者技術(shù)性比較強(qiáng),寫出來有學(xué)術(shù)味,故大多數(shù)軟件工程書籍都有論述。前者就是一些常識(shí)而已,雖然寫不成文章,但是簡(jiǎn)單易用(保你一學(xué)就會(huì)),很有實(shí)用價(jià)值。 “問答分析法”比較適合于用戶需求調(diào)查階段 “建模分析法”比較適合于產(chǎn)品需求定義階段。,如何進(jìn)行需求分析,2 問答分析方法 問答分析方法很簡(jiǎn)單:刨根究底地問,如果問題都被解答了,那么需求也就分析

20、清楚了。一個(gè)人可以“自問自答”地分析需求,幾個(gè)人分析需求則稱為“研討”。 問答分析最重要的問題是:“是什么”和“為什么”。 每個(gè)需求都應(yīng)當(dāng)用陳述句說明“是什么”,如果“是什么”的內(nèi)涵不夠清晰,則應(yīng)補(bǔ)充說明“不是什么”。 如果“是什么”和“不是什么”并不是“理所當(dāng)然”的,那么應(yīng)當(dāng)解釋“為什么”,以便加深讀者的理解。 追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。 其它常見的問題有: 需求存在二義性嗎? 需求文檔的上下文有矛盾嗎? 需求完備嗎? 需求是必要的嗎? 需求可實(shí)現(xiàn)嗎? 需求可驗(yàn)證嗎? 需求的優(yōu)先級(jí)確定了嗎?,如何進(jìn)行需求分析,3 建模分析法 人們都有這樣地感受:有些時(shí)候用語言描

21、述某個(gè)問題特別費(fèi)勁,而采用圖形則使人一目了然,所謂“一圖低千言”就是這個(gè)道理。 在需求開發(fā)過程中,對(duì)于某些類型的信息,用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。 需求建模就是指用圖形符號(hào)來表示、刻畫需求。 建模分析方法主要有兩大類:“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?恰當(dāng)?shù)厥褂脠D形符號(hào): 現(xiàn)代建模工具如Rose有非常豐富的圖形符號(hào)和文字標(biāo)注,能很好地表達(dá)模型的細(xì)節(jié)。要注意的是:在建模時(shí)使用花樣過多的圖形符號(hào)或文字意味著模型表示的復(fù)雜化,將使開發(fā)人員更難掌握,而且使圖形文檔更加雜亂。 世上不存在一個(gè)包羅萬象的圖它能完整地描述需求。需求建模不可能取代文字描

22、述。在需求文檔中,文字描述是第一重要的,建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中,便于正文引用。,如何進(jìn)行需求分析,4 作出決策 當(dāng)需求從四面八方收集來后,需求的沖突在所難免。對(duì)于那些難以達(dá)成共識(shí)的需求而言,經(jīng)常會(huì)發(fā)生“公說公有理,婆說婆有理”的現(xiàn)象。那么需求分析員究竟應(yīng)該聽誰的呢? 如果一群人對(duì)需求有爭(zhēng)議,并不是誰聲音最響就聽誰的。根據(jù)生活經(jīng)驗(yàn),最保險(xiǎn)的辦法是:先聽官兒大的或者威望高的,如果大家的職位和威望都差不多,那么采用“少數(shù)服從大多數(shù)”的原則。 如果一個(gè)產(chǎn)品可以賣給幾類客戶,但是各類客戶都要求產(chǎn)品按照他們的喜好來開發(fā)。此時(shí)對(duì)需求的決策應(yīng)當(dāng)以商業(yè)利益為導(dǎo)向, 即哪一類

23、客戶出錢最多就先滿足他們的需求,以后再做那些獲利相對(duì)較少的需求。 當(dāng)開發(fā)者想象中的產(chǎn)品與客戶所提的需求有沖突時(shí),一般應(yīng)當(dāng)尊重客戶的觀點(diǎn)。但是不要陷入“客戶總是對(duì)的”陷阱里,需求分析員應(yīng)當(dāng)糾正明顯不合理的客戶需求。如果產(chǎn)品很復(fù)雜,雙方都不太明白需求,此時(shí)最好請(qǐng)開發(fā)人員快速構(gòu)造軟件的原型,雙方看著軟件原型再分析需求。,什么是好的需求規(guī)格說明書,1 正確 需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實(shí)意圖,“正確”是產(chǎn)品需求規(guī)格說明書最重要的屬性。如果“不正確”僅僅是由于錯(cuò)別字造成的,那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的,

24、開發(fā)方和用戶必須對(duì)需求規(guī)格說明書進(jìn)行確認(rèn)。 2 清楚 清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚: 文檔的結(jié)構(gòu)、段落是否亂七八糟?上下文是否不連貫? 文檔的語句是否含糊其詞、羅里羅嗦? 看了半天是否還不明白需求究竟是什么? 3 無二義性 “無二義性” 是指每個(gè)需求只有唯一的含義。如果一個(gè)人說的話,不同的人可能有不同的理解,那么這句話就有二義性。如果需求存在二義性,將會(huì)導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。,什么是好的需求規(guī)格說明書,4 一致 “一致”(Consistent)是指產(chǎn)品需求規(guī)格說明書中各個(gè)需求之間不會(huì)發(fā)生矛盾。矛盾常常潛

25、伏在需求文檔的上下文中。 5 必要 產(chǎn)品需求規(guī)格說明書中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)都是必要的。 可以把“必要”比喻為“雪中送炭”。但要把握好度,“必要”往前一步,要么是“畫蛇添足”要么是“錦上添花”。 6 完備 “完備”(Complete)是指產(chǎn)品需求規(guī)格說明書中沒有遺漏一些必要的需求。 人們往往傾向于關(guān)注系統(tǒng)的特色功能,而忽視了其它一些不起眼的但卻是必需的功能。 不完備的產(chǎn)品需求規(guī)格說明書將導(dǎo)致產(chǎn)生功能不完整的軟件,用戶在使用該軟件時(shí)可能無法完成預(yù)期的任務(wù)。,什么是好的需求規(guī)格說明書,7 可實(shí)現(xiàn) 產(chǎn)品需求規(guī)格說明書中的各項(xiàng)需求對(duì)我們而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的(Attainable)。 “可實(shí)現(xiàn)”意味

26、著在技術(shù)上是可行的,并且滿足時(shí)間、費(fèi)用、質(zhì)量等約束。 營(yíng)銷人員和用戶談生意時(shí),為了能拿到“單子”,他們往往對(duì)用戶提出的需求“來者不拒”。 所以,一般經(jīng)過雙方確認(rèn)的產(chǎn)品需求規(guī)格說明書會(huì)作為商業(yè)合同附件,所以我們要把握好產(chǎn)品需求規(guī)格說明書中的內(nèi)容,盡量在合同范圍內(nèi)滿足客戶得需求,但一定要在時(shí)間、費(fèi)用、質(zhì)量,技術(shù)內(nèi)能實(shí)現(xiàn)得,不能實(shí)現(xiàn)一定要和客戶進(jìn)行接受說明,實(shí)在不行的可以進(jìn)行業(yè)務(wù)裁決,由公司營(yíng)銷人員人員搞定。 對(duì)于合同項(xiàng)目,如果開發(fā)方不能確信某些需求是否可實(shí)現(xiàn),則應(yīng)事先與用戶協(xié)商,達(dá)成一致的處理意見,避免將來發(fā)生商業(yè)糾紛。 8 可驗(yàn)證 產(chǎn)品需求規(guī)格說明書中的各項(xiàng)需求對(duì)用戶方而言應(yīng)當(dāng)都是可驗(yàn)證的(Ve

27、rifiable)。如果需求是不可驗(yàn)證的,那么用戶就無法驗(yàn)收軟件,可能會(huì)發(fā)生商業(yè)糾紛。 例如,摩天大樓的一項(xiàng)需求是“抗十二級(jí)臺(tái)風(fēng)”,,什么是好的需求規(guī)格說明書,9 確定優(yōu)先級(jí) 為什么要確定需求的“優(yōu)先級(jí)”? 理論上講,軟件的所有需求都應(yīng)當(dāng)被實(shí)現(xiàn)。但是在現(xiàn)實(shí)之中,項(xiàng)目存在“進(jìn)度、費(fèi)用、人力資源”等限制。在項(xiàng)目剛開始的時(shí)候,開發(fā)方和客戶比較樂觀,什么都要做,可是做著做著,人們常常會(huì)面臨“進(jìn)度延誤、費(fèi)用超支、人員不足”等問題,這時(shí)就亂套了。 人們想出了“取舍”辦法:先做優(yōu)先級(jí)高的需求,后做(甚至放棄)優(yōu)先級(jí)低的需求,這樣可以將風(fēng)險(xiǎn)降到最低。 需求的優(yōu)先級(jí)其實(shí)就是需求“輕重緩急”的分級(jí)表述,例如劃分為

28、“高、中、低”三級(jí)。一般地,由用戶和開發(fā)方共同確定需求的優(yōu)先級(jí)。 10 闡述“做什么”而不是“怎么做” 產(chǎn)品需求規(guī)格說明書的重點(diǎn)是闡述“做什么”,而不是闡述“怎么做”。“怎么做”是系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段的事情。 我們經(jīng)常把系統(tǒng)設(shè)計(jì)甚至編程的變量聲明等寫到 產(chǎn)品需求規(guī)格說明書中,讓用戶看不明白,也就無法簽字確認(rèn)。,形成需求規(guī)格說明書,1 規(guī)程 第一步:細(xì)化并分析用戶需求 需求分析員首先對(duì)用戶需求說明書進(jìn)行細(xì)化,對(duì)比較復(fù)雜的用戶需求進(jìn)行建模分析,以幫助軟件開發(fā)人員更好地理解需求。例如采用Rational 的Rose工具進(jìn)行需求的建模分析,建模分析產(chǎn)生的文檔可以作為產(chǎn)品需求規(guī)格說明書的附件。補(bǔ)充說明:建

29、模分析的技術(shù)難度比較高,需求分析員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍。 第二步:撰寫產(chǎn)品需求規(guī)格說明書 需求分析員按照指定的文檔模板撰寫產(chǎn)品需求規(guī)格說明書。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話,則應(yīng)當(dāng)撰寫軟件需求規(guī)格說明書和硬件需求規(guī)格說明書。 第三步:進(jìn)行需求確認(rèn) 項(xiàng)目經(jīng)理邀請(qǐng)同行專家和用戶(包括客戶和最終用戶)一起評(píng)審產(chǎn)品需求規(guī)格說明書,盡最大努力使產(chǎn)品需求規(guī)格說明書能夠正確無誤地反映用戶的真實(shí)意愿。 需求評(píng)審之后,開發(fā)方和客戶方的責(zé)任人對(duì)產(chǎn)品需求規(guī)格說明書作書面承諾。 2 軟件需求規(guī)格說明書的參考模板,什么是好的需求規(guī)格說明書,需求管理:確認(rèn)、跟蹤、變更控制,1 需求確認(rèn)(評(píng)審和承諾) 需求確

30、認(rèn)是指開發(fā)方和客戶方共同對(duì)產(chǎn)品需求規(guī)格說明書進(jìn)行評(píng)審,雙方對(duì)需求達(dá)成共識(shí)后作出承諾。需求確認(rèn)包含兩個(gè)重要工作:“需求評(píng)審”和“需求承諾”。 2 需求評(píng)審面臨的困難 需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏味,也比較費(fèi)腦子。剛開始評(píng)審時(shí),大家都比較認(rèn)真,越到后頭越馬虎。 需求評(píng)審涉及的人員可能比較多,有些時(shí)候讓這么多人聚在一起并不容易,沒有必要把所有事情擠在一塊做,需求開發(fā)是循序漸進(jìn)的過程,需求評(píng)審也可以分段進(jìn)行。這樣每次評(píng)審的時(shí)間比較短,參加評(píng)審的人員也少一些,組織會(huì)議就比較容易。 開評(píng)審會(huì)議時(shí)經(jīng)常會(huì)“跑題”,導(dǎo)致評(píng)審效率很低。有時(shí)話匣子一打開后關(guān)不上,大家越扯越遠(yuǎn),結(jié)果評(píng)審會(huì)議變成了

31、聊天會(huì)議。主持人應(yīng)當(dāng)控制話題,避免大家討論與主題無關(guān)的東西。 開評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議。適當(dāng)?shù)臓?zhēng)議有利于澄清問題,比什么東西都一致贊成要好。然而當(dāng)爭(zhēng)議變?yōu)闋?zhēng)吵時(shí)就壞事了,爭(zhēng)吵不僅對(duì)評(píng)審工作沒有好處,而且會(huì)無意中傷害同事們的感情。 人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是“堅(jiān)持真理”還是“固執(zhí)己見”。 不要一棍子打死異己的觀點(diǎn),嘗試著讓自己站在他人的立場(chǎng)思考問題,這樣你會(huì)找到比較滿意的答案。,需求管理:確認(rèn)、跟蹤、變更控制,3 需求承諾 需求承諾是指開發(fā)方和客戶方的責(zé)任人對(duì)通過了正式技術(shù)評(píng)審的產(chǎn)品需求規(guī)格說明書作出承諾,該承諾具有商業(yè)合同的效果。 需求承諾的“八股文”如下: 本產(chǎn)品需求規(guī)格說明書建立在雙方對(duì)需求的共同理解基礎(chǔ)之上,我同意后續(xù)的開發(fā)工作根據(jù)該產(chǎn)品需求規(guī)格說明書開展。如果需求發(fā)生變化,我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論