1、第九章 系統(tǒng)開發(fā)中的需求分析與管理,一、需求工程概述 二、需求開發(fā) 三、需求管理 四、需求工程方法與工具,天馬行空官方博客： ；QQ:1318241189；QQ群：175569632,一、需求工程概述,一、需求工程概述,1、什么是需求 基本概念：寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)當(dāng)”做什么。 需求可能來自以下幾個(gè)方面：用戶（客戶）、接口、環(huán)境（硬件、組織文化、政策等）。 需求的重要性: 開發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說明開發(fā)什么。最困難的概念性工作是編寫出詳細(xì)的需求，包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口

2、。此工作一旦做錯(cuò)，將會(huì)給系統(tǒng)帶來極大的損害，并且以后對(duì)它修改也極為困難。（Brooks：沒有銀彈）,案例憑空想象的需求 一家大型電信設(shè)備企業(yè)有多個(gè)分支機(jī)構(gòu)，A與B是研發(fā)機(jī)構(gòu)，B是核心平臺(tái)的研發(fā)機(jī)制，A做增值業(yè)務(wù)的研發(fā)，C是整個(gè)公司的項(xiàng)目管理機(jī)構(gòu)，負(fù)責(zé)立項(xiàng)、結(jié)項(xiàng)與經(jīng)費(fèi)管理，D是銷售機(jī)構(gòu)。 B研制出一種數(shù)據(jù)接入服務(wù)器的原型，找到A，說該產(chǎn)品市場(chǎng)前景看好，請(qǐng)你們開發(fā)網(wǎng)管軟件，一起做好產(chǎn)品。 D對(duì)A，B說“你們把軟硬件都做好，我負(fù)責(zé)銷售，掙到錢大家分”。于是A決定參與合作，向C提出立項(xiàng)，立項(xiàng)后，A把該項(xiàng)目外包給一家專業(yè)的網(wǎng)管軟件開發(fā)公司E，預(yù)期半年完成。由于網(wǎng)管軟件要運(yùn)行于B的產(chǎn)品上，A與E派出開發(fā)人

3、員到B處進(jìn)行需求分析，而B的產(chǎn)品還是原型并不成熟，不斷在變化，最終用了1年時(shí)間才完成軟件開發(fā)。 開發(fā)完成后，E將軟件交付給A后，A付清開發(fā)費(fèi)用，再把軟件交付到D，D又賣給某電信局F，結(jié)果F對(duì)軟件的功能不滿意，要求按自己的要求修改后才能付錢。 D不得不要求A修改軟件，而A已經(jīng)將開發(fā)費(fèi)用付給了E，只能自己吞苦果，結(jié)果是A想辦法把軟件轉(zhuǎn)讓給B，希望拿出成本并且以后再也不與B合作。 這在很多大企業(yè)中都是普遍發(fā)生的事實(shí)。產(chǎn)品是閉門造車出來的，根本沒有弄清楚要開發(fā)的系統(tǒng)應(yīng)該是什么樣的。,一、需求工程概述,2、系統(tǒng)需求的來源 1) 客戶：購(gòu)買系統(tǒng)的人。 2）用戶：實(shí)際使用系統(tǒng)進(jìn)行日常業(yè)務(wù)活動(dòng)的人。 3）技術(shù)

4、人員：維護(hù)系統(tǒng)運(yùn)行的人。 4）其他系統(tǒng)相關(guān)者。,一、需求工程概述,3、需求工程 1)基本概念：在軟件開發(fā)的生命周期中，與需求直接相關(guān)的活動(dòng)。主要包括：需求開發(fā)和需求管理兩部分內(nèi)容。,一、需求工程概述,3、需求工程,需求開發(fā)過程：通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(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)品需

5、求規(guī)格說明書開展系統(tǒng)設(shè)計(jì)工作。,一、需求工程概述,3、需求工程,需求管理過程：在客戶與開發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。 需求確認(rèn)是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書面承諾，使需求文檔具有商業(yè)合同效果。 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。 需求變更控制是指依據(jù)“變更申請(qǐng)審批更改重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。,一、需求工程概述,3、需求工程 2）需求工程的主要內(nèi)容： 需求開發(fā)產(chǎn)生的主要文檔為用戶需

6、求說明書與軟件需求規(guī)格說明書。 需求管理產(chǎn)生的主要文檔為需求評(píng)審報(bào)告、需求跟蹤報(bào)告和需求變更控制報(bào)告,一、需求工程概述,4、需求工程中的主要問題 知識(shí)技能問題 態(tài)度問題 合作關(guān)系 用戶說不清楚需求 雙方誤解需求 開發(fā)人員寫不好需求文檔 用戶經(jīng)常變更需求,知識(shí)技能問題,應(yīng)用域的知識(shí)是無邊無際的，任何人都不可能是“萬事通”。俗話說“隔行如隔山”，需求分析員可能是某一領(lǐng)域的專家，但當(dāng)他接手陌生的業(yè)務(wù)時(shí)，他可能是個(gè)“無知”者。一個(gè)企業(yè)要謀求發(fā)展，不能總在做老的業(yè)務(wù)。人一生中會(huì)有許多充滿挫折的“第一次”，不可以逃避。 當(dāng)需求分析員缺乏應(yīng)用域知識(shí)時(shí)，他該怎么辦？ 首先要有勇氣做事，否則連實(shí)踐的機(jī)會(huì)都沒有。

7、 其次應(yīng)當(dāng)趕緊補(bǔ)習(xí)應(yīng)用域知識(shí)，不論是通過自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。如果可能的話，開發(fā)方最好請(qǐng)既懂軟件又懂應(yīng)用域知識(shí)的行家來幫忙。,態(tài)度問題,相當(dāng)多的開發(fā)人員習(xí)慣于被動(dòng)地對(duì)待需求開發(fā)。每當(dāng)遇到麻煩、挫折時(shí)，他們會(huì)發(fā)牢騷，找出一堆用戶的毛病。很多開發(fā)人員錯(cuò)誤地以為：需求是用戶的事情，不是我們的事情。我們?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)致

8、需求問題擴(kuò)散到整個(gè)軟件開發(fā)過程，產(chǎn)生太多的后患。 軟件企業(yè)的領(lǐng)導(dǎo)應(yīng)當(dāng)給具有錯(cuò)誤觀念的開發(fā)人員們洗腦：需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求，如果做不到就是失職，不要找借口。,合作關(guān)系,如果需求分析員不能與用戶建立良好的合作關(guān)系，那么他們?cè)谛枨箝_發(fā)過程中會(huì)很疲憊。 倘若用戶不能很好地配合需求分析員，那并不表示他是個(gè)壞蛋。因?yàn)橛脩粲兴约旱南敕ǎ何一卮鹆四銈兊膯栴}，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧。 對(duì)于一些競(jìng)標(biāo)項(xiàng)目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會(huì)買你的產(chǎn)品，他不會(huì)投入很多精力來協(xié)助

9、你搞需求開發(fā)。 需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡(luò)住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識(shí)，還要具備較強(qiáng)的交流、溝通能力。 開發(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在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn),合作關(guān)系,用戶在需求工程中的“權(quán)利” 1. 有權(quán)要求開發(fā)方派遣資質(zhì)合格

10、的需求分析員和相關(guān)人員。 2. 有權(quán)要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(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ī)密的前提下，盡可能地向需求分析

11、員提供與需求相關(guān)的材料。 4. 與需求分析員共同評(píng)審需求文檔，確保需求文檔準(zhǔn)確地反映用戶真實(shí)的意愿。,用戶說不清楚需求,用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛的大問題。有些用戶真的不知道需求是什么，或者對(duì)需求只有朦朧的感覺，他當(dāng)然說不清楚需求。有些用戶雖然心里明白想要什么，但卻說不清楚需求。 系統(tǒng)分析員絕不能以用戶說不清楚需求為借口而草率地對(duì)待需求開發(fā)工作，否則會(huì)連累整個(gè)開發(fā)團(tuán)隊(duì)的。 無論是什么原因?qū)е掠脩粽f不清楚需求，系統(tǒng)分析員必須設(shè)法搞清楚用戶真正的需求，這是系統(tǒng)分析員的職責(zé)，也是職業(yè)的挑戰(zhàn)。,雙方誤解需求,了解需求的過程中會(huì)發(fā)生“問非所求，答非所問”的事情。,開發(fā)人員寫不好需求文

12、檔,需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。 要想寫出好的需求文檔，前提條件是把需求調(diào)查工作做好。 企業(yè)應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。,用戶經(jīng)常變更需求,需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響。如果在項(xiàng)目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項(xiàng)目付出額外的代價(jià)。 需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂。所以需求變更控制是需求工程的重要活動(dòng)。,用戶經(jīng)常變更需求,需求變更通常會(huì)對(duì)項(xiàng)目的

13、進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響。如果在項(xiàng)目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項(xiàng)目付出額外的代價(jià)。 需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂。所以需求變更控制是需求工程的重要活動(dòng)。,一、需求工程概述,5、需求工程的層次 開發(fā)者對(duì)待需求工程的態(tài)度可分“被動(dòng)型”、“主動(dòng)型”和“領(lǐng)先型”三種，只有后兩種才有可能開發(fā)出成功的產(chǎn)品。 “被動(dòng)型”是指開發(fā)者被動(dòng)地對(duì)待需求工程中的各項(xiàng)活動(dòng)，能少干則少干，能偷懶則偷懶。他們認(rèn)為需求是用戶的事情而不是自己的事情。開發(fā)過程中經(jīng)常發(fā)

14、生需求變更，導(dǎo)致產(chǎn)品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)。 “主動(dòng)型”是指開發(fā)者積極地開展需求工程中的各項(xiàng)活動(dòng)。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會(huì)想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責(zé)任。俗話說“良好的開端是成功的一半”，“主動(dòng)型”需求工程是開發(fā)成功產(chǎn)品的必備條件。 “領(lǐng)先型”是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識(shí)到的需求，導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費(fèi)。需求工程做到這個(gè)份上，才能使產(chǎn)品立于不敗之地，長(zhǎng)盛不衰。,二、需求開發(fā),1、需求的獲取 一般地，分析員首先要通過與用戶面談、問卷調(diào)查等方式獲取需求，通過對(duì)這些需

15、求進(jìn)行記錄與定義并進(jìn)行討論與修正，將未解決的問題放在一個(gè)條目中，等下一次調(diào)查解決。通過多次迭代最終得到完整的系統(tǒng)需求。 1)需求獲取規(guī)程 現(xiàn)代軟件系統(tǒng)分析與開發(fā)一般都遵循一定的范式和規(guī)程。在需求調(diào)查階段，一般按以下規(guī)程進(jìn)行：,二、需求開發(fā),1、需求的獲取 2)調(diào)查準(zhǔn)備 (1)需求分析員應(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)以“選擇題”和“是非題”為主。 制定問題表最簡(jiǎn)便的方法就是從用戶需求說明書的模板中提取需求問題。,二、需求開發(fā),1、

16、需求的獲取 2)調(diào)查準(zhǔn)備 (2)確定調(diào)查方式，調(diào)查的方法有： 問卷調(diào)查 復(fù)查現(xiàn)有報(bào)表和業(yè)務(wù)過程的描述 與用戶面談與討論 觀察與記錄業(yè)務(wù)過程 與同行或?qū)＜医徽劊犎∫庖娕c建議 分析已經(jīng)存在的軟件系統(tǒng)，提取需求 從行業(yè)標(biāo)準(zhǔn)和規(guī)則中提取需求 到Internet上查找相關(guān)信息,二、需求開發(fā),1、需求的獲取 2)調(diào)查準(zhǔn)備 (2)確定調(diào)查方式，輔助調(diào)查的方法有： 可通過原型的方法獲取需求，這對(duì)于“說不出需求”的用戶尤其適用。 JAD（聯(lián)合應(yīng)用開發(fā)會(huì)議）是加快調(diào)查的重要方法，即將相關(guān)人員全部召集在一起參加單一會(huì)議直接解決需求分析問題。,二、需求開發(fā),1、需求的獲取 2)調(diào)查準(zhǔn)備 (3)需求分析員與被調(diào)查者建

17、立聯(lián)系，確定調(diào)查的時(shí)間、地點(diǎn)、人員等，撰寫需求調(diào)查計(jì)劃。要特別留意的是不要漏掉典型的用戶。,二、需求開發(fā),1、需求的獲取 3)調(diào)查與記錄 準(zhǔn)備工作完畢后，需求分析員按照計(jì)劃執(zhí)行調(diào)查。在調(diào)查過程中隨時(shí)記錄（或存儲(chǔ)）需求信息 。通過完成計(jì)劃的調(diào)查任務(wù)，系統(tǒng)分析員獲取用戶需求并將其正確的記錄。記錄形式一般為表格,二、需求開發(fā),1、需求的獲取 3)調(diào)查與記錄 面談中要注意的問題： 注重時(shí)間與禮節(jié)，建立與用戶的良好關(guān)系 事先了解用戶的身份、背景 從宏觀入手，然后細(xì)化，而不是象偵探那樣從蛛絲馬跡著手 輕松的氣氛，不輕意打斷用戶的談話 不為用戶添加必要的麻煩，但也不要因怕麻煩而降低調(diào)查力度,二、需求開發(fā),1

18、、需求的獲取 3)調(diào)查與記錄 調(diào)查的技術(shù)問答分析法：通過提問與回答了解系統(tǒng)需求。最主要的問題是：“是什么”和“為什么”。每個(gè)需求都用陳述句說明“是什么”，如果表達(dá)不清，則加上“不是什么”；如果“是”與“不是”不是理所當(dāng)然的，就必須加上解釋“為什么”目標(biāo)：獲得正確、清晰的需求。 其他常見問題： 需求存在二義性嗎？ 需求文檔的上下文有矛盾嗎？ 需求完備嗎？ 需求是必要的嗎？ 需求可實(shí)現(xiàn)嗎？ 需求可驗(yàn)證嗎？ 需求的優(yōu)先級(jí)確定了嗎？,二、需求開發(fā),2、需求沖突的解決 需求從獲取渠道收集到以后，可能產(chǎn)生不一致的地方。 解決原則主要有： 當(dāng)客戶需求與開發(fā)方預(yù)計(jì)需求沖突時(shí)，以客戶需求為主。 用戶間需求沖突則

19、以級(jí)別大的用戶需求為準(zhǔn)，同級(jí)則少數(shù)服從多數(shù)。 多個(gè)客戶以出錢多的客戶需求為準(zhǔn),二、需求開發(fā),3、用戶需求說明書 對(duì)收集到的用戶需求進(jìn)行分析、歸納與總結(jié)，然后根據(jù)一定的格式撰寫用戶需求說明書，調(diào)查過程中的中間資料可作為附件。用戶需求說明書完成后，應(yīng)邀請(qǐng)專家與用戶對(duì)其進(jìn)行評(píng)審，使其最大限度地符合用戶的真實(shí)意愿。之后才能進(jìn)行進(jìn)一步的需求分析與定義，產(chǎn)生軟件需求規(guī)格說明書。,（模板）,二、需求開發(fā),4、需求分析與定義 1)概述 需求分析的結(jié)果是通過建立系統(tǒng)的邏輯模型來定義需求。 邏輯模型：詳細(xì)展示系統(tǒng)要完成的功能，而不依賴具體技術(shù)的模型。 物理模型：表明系統(tǒng)是如何真正實(shí)現(xiàn)的模型。,二、需求開發(fā),4、需

20、求分析與定義 1)概述 結(jié)構(gòu)化分析方法興盛的時(shí)期，軟件系統(tǒng)的開發(fā)過程是從物理模型到邏輯模型，再?gòu)倪壿嬆Ｐ偷叫碌奈锢砟Ｐ偷倪^程。這種方法可以保證系統(tǒng)分析能按步就班的完成，但缺點(diǎn)是 a) 系統(tǒng)分析時(shí)間較長(zhǎng)，要花費(fèi)更多時(shí)間與資金去分析、了解和記錄舊系統(tǒng)的運(yùn)行，提煉出運(yùn)行邏輯。 b) 新系統(tǒng)往往是舊系統(tǒng)的簡(jiǎn)單自動(dòng)化，不論原系統(tǒng)的效率有多低，是否合理，都原樣地進(jìn)入新系統(tǒng)，并不能通過信息化改造原來的業(yè)務(wù)管理流程，提高管理水平。 不適合于全新系統(tǒng)的開發(fā)，特別是一些WEB項(xiàng)目，如電子商務(wù)方面的項(xiàng)目開發(fā)，這些項(xiàng)目沒有可參考的舊系統(tǒng)。,二、需求開發(fā),4、需求分析與定義 1)概述 現(xiàn)代的需求分析過程，往往是直接在對(duì)

21、用戶需求進(jìn)行收集地過程中直接產(chǎn)生新系統(tǒng)的邏輯模型（直接通過對(duì)比要解決的商業(yè)問題和軟件需要實(shí)現(xiàn)的功能）。系統(tǒng)分析員只有在需要理解商業(yè)業(yè)務(wù)流程時(shí)才去檢查現(xiàn)有系統(tǒng)。 系統(tǒng)分析員的焦點(diǎn)是：以新系統(tǒng)為中心。提出創(chuàng)新的問題解決之道是系統(tǒng)分析員的素質(zhì)要求之一。此外，新系統(tǒng)的引入還可能對(duì)組織原來的業(yè)務(wù)流程進(jìn)行改造BPR。 兩種思維方式： 還沒有壞，就不需要修理 總有一種更好的解決方法,案例Ford的業(yè)務(wù)流程重組,20世紀(jì)80年代，福特北美分部的帳目支付部門雇傭了500多名員工。為了提高效率，公司決定引入信息系統(tǒng)，最初的目標(biāo)是提高20%的效率。在項(xiàng)目小組進(jìn)行系統(tǒng)分析時(shí)發(fā)現(xiàn)，馬自達(dá)公司的帳目支付部門只有5名員工。

22、雖然福特比馬自達(dá)大得多，但相對(duì)于而言也達(dá)不到100倍的業(yè)務(wù)量。在借鑒了馬自達(dá)的業(yè)務(wù)過程的同時(shí)，項(xiàng)目組設(shè)計(jì)了全新的自動(dòng)化系統(tǒng)，將帳目支付功能包含在更大的購(gòu)買功能中，實(shí)現(xiàn)了從購(gòu)買到支付全程跟蹤的自動(dòng)化，項(xiàng)目結(jié)束時(shí)，只需求100人即可完成原來500多人才能完成的帳目支付功能，大大超出了預(yù)計(jì)。,二、需求開發(fā),4、需求分析與定義 2)系統(tǒng)分析規(guī)程,二、需求開發(fā),4、需求分析與定義 2)系統(tǒng)分析規(guī)程 第一步：細(xì)化并分析用戶需求 需求分析員首先對(duì)用戶需求說明書進(jìn)行細(xì)化，對(duì)比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開發(fā)人員更好地理解需求。建模分析產(chǎn)生的文檔可以作為產(chǎn)品需求規(guī)格說明書的附件。補(bǔ)充說明：建模分析的

23、技術(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ī)格說明書作書面承諾。,二、需求開發(fā),4、需求分析與定義 3)需求分析方法 文字描述（可從問答法直接獲得） 模型描述 有些時(shí)候用語言描述某個(gè)問題特別費(fèi)勁，而采用圖

24、形則使人一目了然，所謂“一圖低千言”就是這個(gè)道理。在需求開發(fā)過程中，對(duì)于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。因此在需求分析中常使用建模的方法來定義需求。,二、需求開發(fā),4、需求分析與定義 3)需求分析方法 模型描述 (1)需求建模:就是指用圖形符號(hào)來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?二、需求開發(fā),4、需求分析與定義 3)需求分析方法 模型描述 (2) 結(jié)構(gòu)化分析法 結(jié)構(gòu)化分析方法并不是明確地由涉及這個(gè)主題的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的單一方法。相反地，它是幾

25、乎發(fā)展了20多年的一個(gè)混合物。結(jié)構(gòu)化分析方法在70年代和80年代非常流行，相關(guān)論著很多。Pressmen對(duì)結(jié)構(gòu)化分析方法作了高度概括“一個(gè)中心三種圖”：,二、需求開發(fā),4、需求分析與定義 3)需求分析方法 模型描述 (3) 面向?qū)ο蠓治龇?面向?qū)ο蠓治鲈O(shè)計(jì)（OOAD）方法興起于20世紀(jì)80年代，從90年代起至今它已經(jīng)在分析設(shè)計(jì)領(lǐng)域占據(jù)了無可爭(zhēng)議的主流地位。面向?qū)ο蠓治鲈O(shè)計(jì)領(lǐng)域有一些比較著名的學(xué)派，如： lCoad和Yourdon學(xué)派。 lBooch學(xué)派。 lJocobson學(xué)派。 lRumbaugh學(xué)派。,UML,Rational Rose,二、需求開發(fā),4、需求分析與定義 3)需求分析方法

26、模型描述 (4) 建模原則恰當(dāng)?shù)厥褂脠D形符號(hào) 現(xiàn)代建模工具如Rose有非常豐富的圖形符號(hào)和文字標(biāo)注，能很好地表達(dá)模型的細(xì)節(jié)。要注意的是：在建模時(shí)使用花樣過多的圖形符號(hào)或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。 世上不存在一個(gè)包羅萬象的圖它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。,二、需求開發(fā),5、產(chǎn)品需求規(guī)格說明書 1) 用戶需求說明書與產(chǎn)品需求規(guī)格說明書的主要區(qū)別與聯(lián)系 前者主要采用自然語言（和應(yīng)用域術(shù)語）來表達(dá)用戶需求，其內(nèi)容相對(duì)于后者而言

27、比較粗略，不夠詳細(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)品。,二、需求開發(fā),5、產(chǎn)品需求規(guī)格說明書 2) 應(yīng)按一定規(guī)范書寫,（模板）,二、需求開發(fā),5、產(chǎn)品需求規(guī)格說明書 3) 書寫原則 （1）正確 （2）清楚 （3）無二義性 （4）一致 （5）必要 （6）完備 （7）可實(shí)現(xiàn) （8）可驗(yàn)證 （9）確定優(yōu)先級(jí) （10）闡述“做什么”而不是“怎么做

28、”,三、需求管理,1、需求驗(yàn)證 系統(tǒng)分析員往往認(rèn)為他們了解與掌握了用戶的需求，然而卻沒有真正把握商業(yè)過程的最精妙之處。在項(xiàng)目早期發(fā)現(xiàn)和解決這方面的問題，比到了開發(fā)與實(shí)現(xiàn)階段解決的代價(jià)要小百倍。發(fā)現(xiàn)和解決需求分析問題的手段是需求驗(yàn)證。 類似于房屋建造，需求分析相當(dāng)于設(shè)計(jì)藍(lán)圖，在進(jìn)行設(shè)計(jì)時(shí)可能會(huì)存在問題，如果在正式建造前不加以解決可能導(dǎo)致完全的失敗，在建造之前首先要驗(yàn)證圖紙的正確性。,三、需求管理,1、需求驗(yàn)證 1)需求驗(yàn)證過程 需求確認(rèn)是指開發(fā)方和客戶方共同對(duì)產(chǎn)品需求規(guī)格說明書進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出承諾。需求確認(rèn)包含兩個(gè)重要工作：“需求評(píng)審”和“需求承諾”。,三、需求管理,1、需求驗(yàn)

29、證 2)需求評(píng)審 要注意的問題： l 需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏味，也比較費(fèi)腦子。剛開始評(píng)審時(shí)，大家都比較認(rèn)真，越到后頭越馬虎。主持人應(yīng)當(dāng)控制節(jié)奏，將重要內(nèi)容放在前面。 l需求評(píng)審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開會(huì)并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進(jìn)的過程，需求評(píng)審也可以分段進(jìn)行。這樣每次評(píng)審的時(shí)間比較短，參加評(píng)審的人員也少一些，組織會(huì)議就比較容易。 l 開評(píng)審會(huì)議時(shí)經(jīng)常會(huì)“跑題”，導(dǎo)致評(píng)審效率很低。有時(shí)話匣子一打開后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評(píng)審會(huì)議變成了聊天會(huì)議。主持

30、人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西。 l開評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議。適當(dāng)?shù)臓?zhēng)議有利于澄清問題，比什么東西都一致贊成要好?？刂茽?zhēng)議不變?yōu)闋?zhēng)吵，爭(zhēng)吵不僅對(duì)評(píng)審工作沒有好處，而且會(huì)無意中傷害同事間及與客戶的關(guān)系，影響項(xiàng)目組下一步的工作。 人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是“堅(jiān)持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點(diǎn)，嘗試著讓自己站在他人的立場(chǎng)思考問題，這樣你會(huì)找到比較滿意的答案。,三、需求管理,1、需求驗(yàn)證 3)需求承諾 需求承諾是指開發(fā)方和客戶方的責(zé)任人對(duì)通過了正式技術(shù)評(píng)審的產(chǎn)品需求規(guī)格說明書作出承諾，該承諾具有商業(yè)合同的效果。 本產(chǎn)品需求