系統(tǒng)開發(fā)軟件中的需求分析

第九章系統(tǒng)開發(fā)中需求分析與管理

一、需求工程概述

二、需求開發(fā)三、需求管理

四、需求工程方法與工具系統(tǒng)開發(fā)軟件中的需求分析第1頁一、需求工程概述用戶需求產(chǎn)品需求系統(tǒng)設(shè)計(jì)系統(tǒng)實(shí)現(xiàn)單元測試集成測試系統(tǒng)測試驗(yàn)收測試系統(tǒng)開發(fā)軟件中的需求分析第2頁一、需求工程概述1、什么是需求基本概念：寬泛地講，需求起源于用戶一些“需要”，這些“需要”被分析、確認(rèn)后形成完整文檔，該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)該”做什么。需求可能來自以下幾個(gè)方面：用戶（客戶）、接口、環(huán)境（硬件、組織文化、政策等）。需求主要性:開發(fā)軟件系統(tǒng)最困難部分就是準(zhǔn)確說明開發(fā)什么。最困難概念性工作是編寫出詳細(xì)需求，包含全部面向用戶、面向機(jī)器和其它軟件系統(tǒng)接口。此工作一旦做錯(cuò)，將會(huì)給系統(tǒng)帶來極大損害，而且以后對它修改也極為困難。（Brooks：《沒有銀彈》）系統(tǒng)開發(fā)軟件中的需求分析第3頁案例——憑空想象需求

一家大型電信設(shè)備企業(yè)有多個(gè)分支機(jī)構(gòu)，A與B是研發(fā)機(jī)構(gòu)，B是關(guān)鍵平臺(tái)研發(fā)機(jī)制，A做增值業(yè)務(wù)研發(fā)，C是整個(gè)企業(yè)項(xiàng)目管理機(jī)構(gòu)，負(fù)責(zé)立項(xiàng)、結(jié)項(xiàng)與經(jīng)費(fèi)管理，D是銷售機(jī)構(gòu)。B研制出一個(gè)數(shù)據(jù)接入服務(wù)器原型，找到A，說該產(chǎn)品市場前景看好，請你們開發(fā)網(wǎng)管軟件，一起做好產(chǎn)品。D對A，B說“你們把軟硬件都做好，我負(fù)責(zé)銷售，掙到錢大家分”。于是A決定參加合作，向C提出立項(xiàng)，立項(xiàng)后，A把該項(xiàng)目外包給一家專業(yè)網(wǎng)管軟件開發(fā)企業(yè)E，預(yù)期六個(gè)月完成。因?yàn)榫W(wǎng)管軟件要運(yùn)行于B產(chǎn)品上，A與E派出開發(fā)人員到B處進(jìn)行需求分析，而B產(chǎn)品還是原型并不成熟，不停在改變，最終用了1年時(shí)間才完成軟件開發(fā)。開發(fā)完成后，E將軟件交付給A后，A付清開發(fā)費(fèi)用，再把軟件交付到D，D又賣給某電信局F，結(jié)果F對軟件功效不滿意，要求按自己要求修改后才能付錢。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)該是什么樣。

系統(tǒng)開發(fā)軟件中的需求分析第4頁一、需求工程概述2、系統(tǒng)需求起源

1)客戶：購置系統(tǒng)人。2）用戶：實(shí)際使用系統(tǒng)進(jìn)行日常業(yè)務(wù)活動(dòng)人。3）技術(shù)人員：維護(hù)系統(tǒng)運(yùn)行人。4）其它系統(tǒng)相關(guān)者。系統(tǒng)開發(fā)軟件中的需求分析第5頁一、需求工程概述3、需求工程1)基本概念：在軟件開發(fā)生命周期中，與需求直接相關(guān)活動(dòng)。主要包含：需求開發(fā)和需求管理兩部分內(nèi)容。系統(tǒng)開發(fā)軟件中的需求分析第6頁一、需求工程概述3、需求工程需求開發(fā)過程：經(jīng)過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。需求調(diào)查目標(biāo)是經(jīng)過各種路徑獲取用戶需求信息（原始材料），產(chǎn)生《用戶需求說明書》。需求分析目標(biāo)是對各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。常見需求分析方法有“問答分析法”和“建模分析法”兩類。需求定義目標(biāo)是依據(jù)需求調(diào)查和需求分析結(jié)果，深入定義準(zhǔn)確無誤產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。系統(tǒng)設(shè)計(jì)人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計(jì)工作。系統(tǒng)開發(fā)軟件中的需求分析第7頁一、需求工程概述3、需求工程需求管理過程：在客戶與開發(fā)方之間建立對需求共同了解，維護(hù)需求與其它工作結(jié)果一致性，并控制需求變更。

需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識(shí)后作出書面承諾，使需求文檔含有商業(yè)協(xié)議效果。需求跟蹤是指經(jīng)過比較需求文檔與后續(xù)工作結(jié)果之間對應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認(rèn)”流程處理需求變更，預(yù)防需求變更失去控制而造成項(xiàng)目發(fā)生混亂。系統(tǒng)開發(fā)軟件中的需求分析第8頁一、需求工程概述3、需求工程2）需求工程主要內(nèi)容：需求開發(fā)產(chǎn)生主要文檔為《用戶需求說明書》與《軟件需求規(guī)格說明書》。需求管理產(chǎn)生主要文檔為《需求評審匯報(bào)》、《需求跟蹤匯報(bào)》和《需求變更控制匯報(bào)》系統(tǒng)開發(fā)軟件中的需求分析第9頁系統(tǒng)開發(fā)軟件中的需求分析第10頁一、需求工程概述4、需求工程中主要問題知識(shí)技能問題態(tài)度問題合作關(guān)系用戶說不清楚需求雙方誤解需求開發(fā)人員寫不好需求文檔用戶經(jīng)常變更需求系統(tǒng)開發(fā)軟件中的需求分析第11頁知識(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ì)都沒有。–其次應(yīng)該趕快補(bǔ)習(xí)應(yīng)用域知識(shí)，不論是經(jīng)過自學(xué)還是培訓(xùn)方式，不然他極難與用戶交流。假如可能話，開發(fā)方最好請既懂軟件又懂應(yīng)用域知識(shí)行家來幫忙。系統(tǒng)開發(fā)軟件中的需求分析第12頁態(tài)度問題相當(dāng)多開發(fā)人員習(xí)慣于被動(dòng)地對待需求開發(fā)。每當(dāng)碰到麻煩、挫折時(shí)，他們會(huì)發(fā)怨言，找出一堆用戶毛病。很多開發(fā)人員錯(cuò)誤地認(rèn)為：需求是用戶事情，不是我們事情。我們?yōu)橛脩糸_發(fā)軟件，莫非用戶不該告訴我們應(yīng)該開發(fā)什么嗎？假如用戶說不清楚需求，或者經(jīng)常變更需求，這類問題是用戶產(chǎn)生，應(yīng)該由他們自己負(fù)責(zé)。

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

軟件企業(yè)領(lǐng)導(dǎo)應(yīng)該給含有錯(cuò)誤觀念開發(fā)人員們洗腦：需求分析員天職就是在有限時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致用戶需求，假如做不到就是瀆職，不要找借口。系統(tǒng)開發(fā)軟件中的需求分析第13頁合作關(guān)系假如需求分析員不能與用戶建立良好合作關(guān)系，那么他們在需求開發(fā)過程中會(huì)很疲憊。

倘若用戶不能很好地配合需求分析員，那并不表示他是個(gè)壞蛋。因?yàn)橛脩粲兴约合敕ǎ何一卮鹆四銈儐栴}，講了該講。我們付錢給你們，莫非還要我伺候你們不成？我還要干自己事情，別打攪我了。你們自己想方法把活干好吧

……。對于一些競標(biāo)項(xiàng)目，在協(xié)議未簽署之前需求開發(fā)工作尤為困難。用戶未必會(huì)買你產(chǎn)品，他不會(huì)投入很多精力來幫助你搞需求開發(fā)。需求分析員不是銷售人員，他們不可能象銷售人員那樣經(jīng)過一些伎倆籠絡(luò)住用戶就能成功。出眾需求分析員不但要有過硬專業(yè)知識(shí)，還要具備較強(qiáng)交流、溝通能力。開發(fā)方與用戶合作關(guān)系對需求開發(fā)而言是至關(guān)主要。對于重大、復(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)系統(tǒng)開發(fā)軟件中的需求分析第14頁合作關(guān)系用戶在需求工程中“權(quán)利”–1.有權(quán)要求開發(fā)方派遣資質(zhì)合格需求分析員和相關(guān)人員。–2.有權(quán)要求開發(fā)方采取用戶熟悉語言來描述需求，即開發(fā)方必須提供用戶看得知道需求文檔。–3.有權(quán)審查需求文檔，并對有爭議需求作出決議。假如認(rèn)為需求文檔不能準(zhǔn)確地反應(yīng)用戶真實(shí)意愿，能夠拒絕在需求文檔上簽字。

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

用戶在需求工程中“義務(wù)”–1.以主動(dòng)友善態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上便利。

–2.愿意接收需求分析員采訪，在不泄漏機(jī)密前提下盡可能地回答需求分析員問題。–3.在不泄漏機(jī)密前提下，盡可能地向需求分析員提供與需求相關(guān)材料。

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

系統(tǒng)開發(fā)軟件中的需求分析第15頁用戶說不清楚需求用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛大問題。有些用戶真不知道需求是什么，或者對需求只有朦朧感覺，他當(dāng)然說不清楚需求。有些用戶即使心里明白想要什么，但卻說不清楚需求。系統(tǒng)分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，不然會(huì)拖累整個(gè)開發(fā)團(tuán)體。不論是什么原因造成用戶說不清楚需求，系統(tǒng)分析員必須設(shè)法搞清楚用戶真正需求，這是系統(tǒng)分析員職責(zé)，也是職業(yè)挑戰(zhàn)。系統(tǒng)開發(fā)軟件中的需求分析第16頁雙方誤解需求了解需求過程中會(huì)發(fā)生“問非所求，答非所問”事情。系統(tǒng)開發(fā)軟件中的需求分析第17頁開發(fā)人員寫不好需求文檔需求調(diào)查工作不充分，獲取需求信息太少或者太亂，以至于寫不成需求文檔。要想寫出好需求文檔，前提條件是把需求調(diào)查工作做好。

企業(yè)應(yīng)該提供適當(dāng)文檔模板以及比很好示例文檔，盡可能地降低寫作難度。

系統(tǒng)開發(fā)軟件中的需求分析第18頁用戶經(jīng)常變更需求需求變更通常會(huì)對項(xiàng)目標(biāo)進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大影響。假如在項(xiàng)目開發(fā)初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，造成產(chǎn)品部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項(xiàng)目付出額外代價(jià)。需求變更并不可怕，可怕是需求變更失去控制，造成項(xiàng)目混亂。所以需求變更控制是需求工程主要活動(dòng)。

系統(tǒng)開發(fā)軟件中的需求分析第19頁用戶經(jīng)常變更需求需求變更通常會(huì)對項(xiàng)目標(biāo)進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大影響。假如在項(xiàng)目開發(fā)初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，造成產(chǎn)品部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項(xiàng)目付出額外代價(jià)。需求變更并不可怕，可怕是需求變更失去控制，造成項(xiàng)目混亂。所以需求變更控制是需求工程主要活動(dòng)。

系統(tǒng)開發(fā)軟件中的需求分析第20頁一、需求工程概述5、需求工程層次開發(fā)者對待需求工程態(tài)度可分“被動(dòng)型”、“主動(dòng)型”和“領(lǐng)先型”三種，只有后兩種才有可能開發(fā)出成功產(chǎn)品。

–“被動(dòng)型”是指開發(fā)者被動(dòng)地對待需求工程中各項(xiàng)活動(dòng)，能少干則少干，能偷懶則偷懶。他們認(rèn)為需求是用戶事情而不是自己事情。開發(fā)過程中經(jīng)常發(fā)生需求變更，造成產(chǎn)品迷失方向，不是中途而廢就是陷入半死不活狀態(tài)。–“主動(dòng)型”是指開發(fā)者主動(dòng)地開展需求工程中各項(xiàng)活動(dòng)。他們把獲取準(zhǔn)確需求看成自己職責(zé)，會(huì)想盡一切方法克服需求開發(fā)和需求管理過程中困難，而不是找借口推卸責(zé)任。俗話說“良好開端是成功二分之一”，“主動(dòng)型”需求工程是開發(fā)成功產(chǎn)品必備條件。

–“領(lǐng)先型”是需求工程最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識(shí)到需求，造成用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費(fèi)。需求工程做到這個(gè)份上，才能使產(chǎn)品立于不敗之地，長盛不衰。系統(tǒng)開發(fā)軟件中的需求分析第21頁二、需求開發(fā)1、需求獲取普通地，分析員首先要經(jīng)過與用戶面談、問卷調(diào)查等方式獲取需求，經(jīng)過對這些需求進(jìn)行統(tǒng)計(jì)與定義并進(jìn)行討論與修正，將未處理問題放在一個(gè)條目中，等下一次調(diào)查處理。經(jīng)過屢次迭代最終得到完整系統(tǒng)需求。1)需求獲取規(guī)程當(dāng)代軟件系統(tǒng)分析與開發(fā)普通都遵照一定范式和規(guī)程。在需求調(diào)查階段，普通按以下規(guī)程進(jìn)行：系統(tǒng)開發(fā)軟件中的需求分析第22頁目獲取用戶需求信息，經(jīng)過分析產(chǎn)生《用戶需求說明書》角色與職責(zé)系統(tǒng)分析員調(diào)查分析需求，用戶提供必要需求信息開啟準(zhǔn)則系統(tǒng)分析員已經(jīng)確定輸入任何與用戶需求相關(guān)材料主要步驟 1．準(zhǔn)備調(diào)查2．調(diào)查與統(tǒng)計(jì)3．分析需求信息4．撰寫《用戶需求說明書》5．需求確認(rèn)輸出《用戶需求說明書》結(jié)束準(zhǔn)則完成《用戶需求說明書》并確認(rèn)無誤度量統(tǒng)計(jì)工作量和文檔規(guī)模，上報(bào)項(xiàng)目經(jīng)理系統(tǒng)開發(fā)軟件中的需求分析第23頁二、需求開發(fā)1、需求獲取2)調(diào)查準(zhǔn)備(1)需求分析員應(yīng)該起草需求調(diào)查問題表，將調(diào)查重點(diǎn)鎖定在該問題表內(nèi)，不然調(diào)查工作將變得漫無邊際。問題表能夠有多份，伴隨調(diào)查深入，問題表將不停地被細(xì)化。依據(jù)經(jīng)驗(yàn)，用戶通常沒有耐心回回復(fù)雜敘述題，所以問題表應(yīng)該以“選擇題”和“是非題”為主。制訂問題表最簡便方法就是從《用戶需求說明書》模板中提取需求問題。系統(tǒng)開發(fā)軟件中的需求分析第24頁二、需求開發(fā)1、需求獲取2)調(diào)查準(zhǔn)備(2)確定調(diào)查方式，調(diào)查方法有：問卷調(diào)查復(fù)查現(xiàn)有報(bào)表和業(yè)務(wù)過程描述與用戶面談與討論觀察與統(tǒng)計(jì)業(yè)務(wù)過程與同行或教授交談，聽取意見與提議分析已經(jīng)存在軟件系統(tǒng)，提取需求從行業(yè)標(biāo)準(zhǔn)和規(guī)則中提取需求到Internet上查找相關(guān)信息系統(tǒng)開發(fā)軟件中的需求分析第25頁二、需求開發(fā)1、需求獲取2)調(diào)查準(zhǔn)備(2)確定調(diào)查方式，輔助調(diào)查方法有：可經(jīng)過原型方法獲取需求，這對于“說不出需求”用戶尤其適用。JAD（聯(lián)合應(yīng)用開發(fā)會(huì)議）是加緊調(diào)查主要方法，即將相關(guān)人員全部召集在一起參加單一會(huì)議直接處理需求分析問題。系統(tǒng)開發(fā)軟件中的需求分析第26頁二、需求開發(fā)1、需求獲取2)調(diào)查準(zhǔn)備(3)需求分析員與被調(diào)查者建立聯(lián)絡(luò)，確定調(diào)查時(shí)間、地點(diǎn)、人員等，撰寫需求調(diào)查計(jì)劃。要尤其留心是不要遺漏經(jīng)典用戶。系統(tǒng)開發(fā)軟件中的需求分析第27頁二、需求開發(fā)1、需求獲取3)調(diào)查與統(tǒng)計(jì)

準(zhǔn)備工作完成后，需求分析員按照計(jì)劃執(zhí)行調(diào)查。在調(diào)查過程中隨時(shí)統(tǒng)計(jì)（或存放）需求信息。經(jīng)過完成計(jì)劃調(diào)查任務(wù)，系統(tǒng)分析員獲取用戶需求并將其正確統(tǒng)計(jì)。統(tǒng)計(jì)形式普通為表格需求標(biāo)題

調(diào)查方式

調(diào)查人

調(diào)查對象

時(shí)間、地點(diǎn)

需求信息統(tǒng)計(jì)是什么？不是什么？為何？

系統(tǒng)開發(fā)軟件中的需求分析第28頁二、需求開發(fā)1、需求獲取3)調(diào)查與統(tǒng)計(jì)面談中要注意問題：重視時(shí)間與禮節(jié)，建立與用戶良好關(guān)系事先了解用戶身份、背景從宏觀入手，然后細(xì)化，而不是象偵探那樣從蛛絲馬跡著手輕松氣氛，不輕意打斷用戶談話不為用戶添加必要麻煩，但也不要因怕麻煩而降低調(diào)查力度系統(tǒng)開發(fā)軟件中的需求分析第29頁二、需求開發(fā)1、需求獲取3)調(diào)查與統(tǒng)計(jì)調(diào)查技術(shù)——問答分析法：經(jīng)過提問與回答了解系統(tǒng)需求。最主要問題是：“是什么”和“為何”。每個(gè)需求都用陳說句說明“是什么”，假如表示不清，則加上“不是什么”；假如“是”與“不是”不是理所當(dāng)然，就必須加上解釋“為何”——目標(biāo)：取得正確、清楚需求。其它常見問題：需求存在二義性嗎？需求文檔上下文有矛盾嗎？需求完備嗎？需求是必要嗎？需求可實(shí)現(xiàn)嗎？需求可驗(yàn)證嗎？需求優(yōu)先級(jí)確定了嗎？系統(tǒng)開發(fā)軟件中的需求分析第30頁二、需求開發(fā)2、需求沖突處理需求從獲取渠道搜集到以后，可能產(chǎn)生不一致地方。處理標(biāo)準(zhǔn)主要有：當(dāng)客戶需求與開發(fā)方預(yù)計(jì)需求沖突時(shí)，以客戶需求為主。用戶間需求沖突則以級(jí)別大用戶需求為準(zhǔn)，同級(jí)則少數(shù)服從多數(shù)。多個(gè)客戶以出錢多客戶需求為準(zhǔn)系統(tǒng)開發(fā)軟件中的需求分析第31頁二、需求開發(fā)3、用戶需求說明書對搜集到用戶需求進(jìn)行分析、歸納與總結(jié)，然后依據(jù)一定格式撰寫《用戶需求說明書》，調(diào)查過程中中間資料可作為附件。用戶需求說明書完成后，應(yīng)邀請教授與用戶對其進(jìn)行評審，使其最大程度地符適用戶真實(shí)意愿。之后才能進(jìn)行深入需求分析與定義，產(chǎn)生《軟件需求規(guī)格說明書?！废到y(tǒng)開發(fā)軟件中的需求分析第32頁（模板）系統(tǒng)開發(fā)軟件中的需求分析第33頁二、需求開發(fā)4、需求分析與定義1)概述需求分析結(jié)果是經(jīng)過建立系統(tǒng)邏輯模型來定義需求。邏輯模型：詳細(xì)展示系統(tǒng)要完成功效，而不依賴詳細(xì)技術(shù)模型。物理模型：表明系統(tǒng)是怎樣真正實(shí)現(xiàn)模型。

系統(tǒng)開發(fā)軟件中的需求分析第34頁二、需求開發(fā)4、需求分析與定義1)概述結(jié)構(gòu)化分析方法興盛時(shí)期，軟件系統(tǒng)開發(fā)過程是從物理模型到邏輯模型，再從邏輯模型到新物理模型過程。這種方法能夠確保系統(tǒng)分析能按步就班完成，但缺點(diǎn)是a)

系統(tǒng)分析時(shí)間較長，要花費(fèi)更多時(shí)間與資金去分析、了解和統(tǒng)計(jì)舊系統(tǒng)運(yùn)行，提煉出運(yùn)行邏輯。b)

新系統(tǒng)往往是舊系統(tǒng)簡單自動(dòng)化，不論原系統(tǒng)效率有多低，是否合理，都原樣地進(jìn)入新系統(tǒng)，并不能經(jīng)過信息化改造原來業(yè)務(wù)管理流程，提升管理水平。不適合于全新系統(tǒng)開發(fā)，尤其是一些WEB項(xiàng)目，如電子商務(wù)方面項(xiàng)目開發(fā)，這些項(xiàng)目沒有可參考舊系統(tǒng)。系統(tǒng)開發(fā)軟件中的需求分析第35頁二、需求開發(fā)4、需求分析與定義1)概述當(dāng)代需求分析過程，往往是直接在對用戶需求進(jìn)行搜集地過程中直接產(chǎn)生新系統(tǒng)邏輯模型（直接經(jīng)過對比要處理商業(yè)問題和軟件需要實(shí)現(xiàn)功效）。系統(tǒng)分析員只有在需要了解商業(yè)業(yè)務(wù)流程時(shí)才去檢驗(yàn)現(xiàn)有系統(tǒng)。系統(tǒng)分析員焦點(diǎn)是：以新系統(tǒng)為中心。提出創(chuàng)新問題處理之道是系統(tǒng)分析員素質(zhì)要求之一。另外，新系統(tǒng)引入還可能對組織原來業(yè)務(wù)流程進(jìn)行改造——BPR。兩種思維方式：還沒有壞，就不需要修理總有一個(gè)更加好處理方法系統(tǒng)開發(fā)軟件中的需求分析第36頁案例——Ford業(yè)務(wù)流程重組

20世紀(jì)80年代，福特北美分部帳目支付部門雇傭了500多名員工。為了提升效率，企業(yè)決定引入信息系統(tǒng)，最初目標(biāo)是提升20%效率。在項(xiàng)目小組進(jìn)行系統(tǒng)分析時(shí)發(fā)覺，馬自達(dá)企業(yè)帳目支付部門只有5名員工。即使福特比馬自達(dá)大得多，但相對于而言也達(dá)不到100倍業(yè)務(wù)量。在借鑒了馬自達(dá)業(yè)務(wù)過程同時(shí)，項(xiàng)目組設(shè)計(jì)了全新自動(dòng)化系統(tǒng)，將帳目支付功效包含在更大購置功效中，實(shí)現(xiàn)了從購置到支付全程跟蹤自動(dòng)化，項(xiàng)目結(jié)束時(shí)，只需求100人即可完成原來500多人才能完成帳目支付功效，大大超出了預(yù)計(jì)。

系統(tǒng)開發(fā)軟件中的需求分析第37頁二、需求開發(fā)4、需求分析與定義2)系統(tǒng)分析規(guī)程目定義準(zhǔn)確產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》角色與職責(zé)系統(tǒng)分析員定義產(chǎn)品需求，用戶確認(rèn)產(chǎn)品需求開啟準(zhǔn)則《用戶需求說明書》撰寫完成輸入《用戶需求說明書》主要步驟1．細(xì)化和分析用戶需求2．撰寫《產(chǎn)品需求規(guī)格說明書》3．需求確認(rèn)輸出《產(chǎn)品需求規(guī)格說明書》結(jié)束準(zhǔn)則《產(chǎn)品需求規(guī)格說明書》撰寫完成并經(jīng)過確認(rèn)（評審與承諾）度量系統(tǒng)分析員統(tǒng)計(jì)工作量與文檔規(guī)模，上報(bào)項(xiàng)目經(jīng)理系統(tǒng)開發(fā)軟件中的需求分析第38頁二、需求開發(fā)4、需求分析與定義2)系統(tǒng)分析規(guī)程第一步：細(xì)化并分析用戶需求

–需求分析員首先對《用戶需求說明書》進(jìn)行細(xì)化，對比較復(fù)雜用戶需求進(jìn)行建模分析，以幫助軟件開發(fā)人員更加好地了解需求。建模分析產(chǎn)生文檔能夠作為《產(chǎn)品需求規(guī)格說明書》附件。補(bǔ)充說明：建模分析技術(shù)難度比較高，分析員應(yīng)該依據(jù)本身水平進(jìn)行取舍。

第二步：撰寫產(chǎn)品需求規(guī)格說明書

–需求分析員按照指定文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》。假如待開發(fā)產(chǎn)品分為軟件和硬件兩部分話，則應(yīng)該撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。第三步：進(jìn)行需求確認(rèn)–項(xiàng)目經(jīng)理邀請同行教授和用戶（包含客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反應(yīng)用戶真實(shí)意愿。

–需求評審之后，開發(fā)方和客戶方責(zé)任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。系統(tǒng)開發(fā)軟件中的需求分析第39頁二、需求開發(fā)4、需求分析與定義3)需求分析方法文字描述（可從問答法直接取得）模型描述 有些時(shí)候用語言描述某個(gè)問題尤其費(fèi)勁，而采取圖形則使人一目了然，所謂“一圖低千言”就是這個(gè)道理。在需求開發(fā)過程中，對于一些類型信息，用圖形表示要比文本表示愈加有效。所以將圖形與文本結(jié)合起來描述需求是很自然方法。所以在需求分析中常使用建模方法來定義需求。系統(tǒng)開發(fā)軟件中的需求分析第40頁二、需求開發(fā)4、需求分析與定義3)需求分析方法模型描述(1)需求建模:就是指用圖形符號(hào)來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄Ｏ到y(tǒng)開發(fā)軟件中的需求分析第41頁二、需求開發(fā)4、需求分析與定義3)需求分析方法模型描述(2)結(jié)構(gòu)化分析法結(jié)構(gòu)化分析方法并不是明確地由包括這個(gè)主題一篇文章或者一本著作引入，它也不是被全部使用者一致采取單一方法。相反地，它是幾乎發(fā)展了20多年一個(gè)混合物。結(jié)構(gòu)化分析方法在70年代和80年代非常流行，相關(guān)論著很多。Pressmen對結(jié)構(gòu)化分析方法作了高度概括——“一個(gè)中心三種圖”：系統(tǒng)開發(fā)軟件中的需求分析第42頁數(shù)據(jù)字典實(shí)體－關(guān)系圖數(shù)據(jù)流圖狀態(tài)－變遷圖系統(tǒng)開發(fā)軟件中的需求分析第43頁二、需求開發(fā)4、需求分析與定義3)需求分析方法模型描述(3)面向?qū)ο蠓治龇嫦驅(qū)ο蠓治鲈O(shè)計(jì)（OOAD）方法興起于20世紀(jì)80年代，從90年代起至今它已經(jīng)在分析設(shè)計(jì)領(lǐng)域占據(jù)了無可爭議主流地位。面向?qū)ο蠓治鲈O(shè)計(jì)領(lǐng)域有一些比較著名學(xué)派，如：l

Coad和Yourdon學(xué)派。l

Booch學(xué)派。l

Jocobson學(xué)派。l

Rumbaugh學(xué)派。UMLRationalRose系統(tǒng)開發(fā)軟件中的需求分析第44頁二、需求開發(fā)4、需求分析與定義3)需求分析方法模型描述(4)建模標(biāo)準(zhǔn)——恰當(dāng)?shù)厥褂脠D形符號(hào)當(dāng)代建模工具如Rose有非常豐富圖形符號(hào)和文字標(biāo)注，能很好地表示模型細(xì)節(jié)。要注意是：在建模時(shí)使用花樣過多圖形符號(hào)或文字意味著模型表示復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔愈加雜亂。

–世上不存在一個(gè)包羅萬象圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一主要，建模主要是起分析、解釋作用。提議將模型存放在需求文檔附錄中，便于正文引用。系統(tǒng)開發(fā)軟件中的需求分析第45頁二、需求開發(fā)5、產(chǎn)品需求規(guī)格說明書1)《用戶需求說明書》與《產(chǎn)品需求規(guī)格說明書》主要區(qū)分與聯(lián)絡(luò)前者主要采取自然語言（和應(yīng)用域術(shù)語）來表示用戶需求，其內(nèi)容相對于后者而言比較粗略，不夠詳細(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)該依據(jù)《產(chǎn)品需求規(guī)格說明書》來開發(fā)當(dāng)前產(chǎn)品。系統(tǒng)開發(fā)軟件中的需求分析第46頁二、需求開發(fā)5、產(chǎn)品需求規(guī)格說明書2)應(yīng)按一定規(guī)范書寫

系統(tǒng)開發(fā)軟件中的需求分析第47頁（模板）

系統(tǒng)開發(fā)軟件中的需求分析第48頁二、需求開發(fā)5、產(chǎn)品需求規(guī)格說明書3)書寫標(biāo)準(zhǔn)

（1） 正確（2） 清楚（3） 無二義性（4） 一致（5） 必要（6） 完備（7） 可實(shí)現(xiàn)（8） 可驗(yàn)證（9） 確定優(yōu)先級(jí)（10）闡述“做什么”而不是“怎么做”

系統(tǒng)開發(fā)軟件中的需求分析第49頁三、需求管理1、需求驗(yàn)證系統(tǒng)分析員往往認(rèn)為他們了解與掌握了用戶需求，然而卻沒有真正把握商業(yè)過程最精妙之處。在項(xiàng)目早期發(fā)覺和處理這方面問題，比到了開發(fā)與實(shí)現(xiàn)階段處理代價(jià)要小百倍。發(fā)覺和處理需求分析問題伎倆是需求驗(yàn)證。類似于房屋建造，需求分析相當(dāng)于設(shè)計(jì)藍(lán)圖，在進(jìn)行設(shè)計(jì)時(shí)可能會(huì)存在問題，假如在正式建造前不加以處理可能造成完全失敗，在建造之前首先要驗(yàn)證圖紙正確性。

系統(tǒng)開發(fā)軟件中的需求分析第50頁三、需求管理1、需求驗(yàn)證1)需求驗(yàn)證過程

需求確認(rèn)是指開發(fā)方和客戶方共同對《產(chǎn)品需求規(guī)格說明書》進(jìn)行評審，雙方對需求達(dá)成共識(shí)后作出承諾。需求確認(rèn)包含兩個(gè)主要工作：“需求評審”和“需求承諾”。

系統(tǒng)開發(fā)軟件中的需求分析第51頁三、需求管理1、需求驗(yàn)證2)需求評審要注意問題：l

需求評審一個(gè)通病是“虎頭蛇尾”。需求評審確實(shí)乏味，也比較費(fèi)腦子。剛開始評審時(shí)，大家都比較認(rèn)真，越到后頭越馬虎。主持人應(yīng)該控制節(jié)奏，將主要內(nèi)容放在前面。

l

需求評審包括人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長時(shí)間開會(huì)并不輕易（比如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把全部事情擠在一塊做，需求開發(fā)是循序漸進(jìn)過程，需求評審也能夠分段進(jìn)行。這么每次評審時(shí)間比較短，參加評審人員也少一些，組織會(huì)議就比較輕易。

l

開評審會(huì)議時(shí)經(jīng)常會(huì)“跑題”，造成評審效率很低。有時(shí)話匣子一打開后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評審會(huì)議變成了聊天會(huì)議。主持人應(yīng)該控制話題，防止大家討論與主題無關(guān)東西。

l

開評審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭議。適當(dāng)爭議有利于澄清問題，比什么東西都一致贊成要好?？刂茽幾h不變?yōu)闋幊?，爭吵不但對評審工作沒有好處，而且會(huì)無意中傷害同事間及與客戶關(guān)系，影響項(xiàng)目組下一步工作。人們在很多時(shí)候分不清楚自己終究是“堅(jiān)持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好方法。我們應(yīng)該養(yǎng)成良好習(xí)慣：不要一棍子打死異己觀點(diǎn)，嘗試著讓自己站在他人立場思索問題，這么你會(huì)找到比較滿意答案。

系統(tǒng)開發(fā)軟件中的需求分析第52頁三、需求管理1、需求驗(yàn)證3)需求承諾 需求承諾是指開發(fā)方和客戶方責(zé)任