系統(tǒng)開(kāi)發(fā)中的需求分析與管理.ppt

第九章系統(tǒng)開(kāi)發(fā)中的需求分析與管理 一 需求工程概述二 需求開(kāi)發(fā)三 需求管理四 需求工程方法與工具 一 需求工程概述 一 需求工程概述 1 什么是需求基本概念 寬泛地講 需求來(lái)源于用戶(hù)的一些 需要 這些 需要 被分析 確認(rèn)后形成完整的文檔 該文檔詳細(xì)地說(shuō)明了產(chǎn)品 必須或應(yīng)當(dāng) 做什么 需求可能來(lái)自以下幾個(gè)方面 用戶(hù) 客戶(hù) 接口 環(huán)境 硬件 組織文化 政策等 需求的重要性 開(kāi)發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么 最困難的概念性工作是編寫(xiě)出詳細(xì)的需求 包括所有面向用戶(hù) 面向機(jī)器和其它軟件系統(tǒng)的接口 此工作一旦做錯(cuò) 將會(huì)給系統(tǒng)帶來(lái)極大的損害 并且以后對(duì)它修改也極為困難 Brooks 沒(méi)有銀彈 案例 憑空想象的需求一家大型電信設(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是銷(xiāo)售機(jī)構(gòu) B研制出一種數(shù)據(jù)接入服務(wù)器的原型 找到A 說(shuō)該產(chǎn)品市場(chǎng)前景看好 請(qǐng)你們開(kāi)發(fā)網(wǎng)管軟件 一起做好產(chǎn)品 D對(duì)A B說(shuō) 你們把軟硬件都做好 我負(fù)責(zé)銷(xiāo)售 掙到錢(qián)大家分 于是A決定參與合作 向C提出立項(xiàng) 立項(xiàng)后 A把該項(xiàng)目外包給一家專(zhuān)業(yè)的網(wǎng)管軟件開(kāi)發(fā)公司E 預(yù)期半年完成 由于網(wǎng)管軟件要運(yùn)行于B的產(chǎn)品上 A與E派出開(kāi)發(fā)人員到B處進(jìn)行需求分析 而B(niǎo)的產(chǎn)品還是原型并不成熟 不斷在變化 最終用了1年時(shí)間才完成軟件開(kāi)發(fā) 開(kāi)發(fā)完成后 E將軟件交付給A后 A付清開(kāi)發(fā)費(fèi)用 再把軟件交付到D D又賣(mài)給某電信局F 結(jié)果F對(duì)軟件的功能不滿(mǎn)意 要求按自己的要求修改后才能付錢(qián) D不得不要求A修改軟件 而A已經(jīng)將開(kāi)發(fā)費(fèi)用付給了E 只能自己吞苦果 結(jié)果是A想辦法把軟件轉(zhuǎn)讓給B 希望拿出成本并且以后再也不與B合作 這在很多大企業(yè)中都是普遍發(fā)生的事實(shí) 產(chǎn)品是閉門(mén)造車(chē)出來(lái)的 根本沒(méi)有弄清楚要開(kāi)發(fā)的系統(tǒng)應(yīng)該是什么樣的 一 需求工程概述 2 系統(tǒng)需求的來(lái)源1 客戶(hù) 購(gòu)買(mǎi)系統(tǒng)的人 2 用戶(hù) 實(shí)際使用系統(tǒng)進(jìn)行日常業(yè)務(wù)活動(dòng)的人 3 技術(shù)人員 維護(hù)系統(tǒng)運(yùn)行的人 4 其他系統(tǒng)相關(guān)者 一 需求工程概述 3 需求工程1 基本概念 在軟件開(kāi)發(fā)的生命周期中 與需求直接相關(guān)的活動(dòng) 主要包括 需求開(kāi)發(fā)和需求管理兩部分內(nèi)容 一 需求工程概述 3 需求工程 需求開(kāi)發(fā)過(guò)程 通過(guò)調(diào)查與分析 獲取用戶(hù)需求并定義產(chǎn)品需求 需求調(diào)查的目的是通過(guò)各種途徑獲取用戶(hù)的需求信息 原始材料 產(chǎn)生 用戶(hù)需求說(shuō)明書(shū) 需求分析的目的是對(duì)各種需求信息進(jìn)行分析 消除錯(cuò)誤 刻畫(huà)細(xì)節(jié)等 常見(jiàn)的需求分析方法有 問(wèn)答分析法 和 建模分析法 兩類(lèi) 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果 進(jìn)一步定義準(zhǔn)確無(wú)誤的產(chǎn)品需求 產(chǎn)生 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 系統(tǒng)設(shè)計(jì)人員將依據(jù) 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 開(kāi)展系統(tǒng)設(shè)計(jì)工作 一 需求工程概述 3 需求工程 需求管理過(guò)程 在客戶(hù)與開(kāi)發(fā)方之間建立對(duì)需求的共同理解 維護(hù)需求與其它工作成果的一致性 并控制需求的變更 需求確認(rèn)是指開(kāi)發(fā)方和客戶(hù)共同對(duì)需求文檔進(jìn)行評(píng)審 雙方對(duì)需求達(dá)成共識(shí)后作出書(shū)面承諾 使需求文檔具有商業(yè)合同效果 需求跟蹤是指通過(guò)比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系 建立與維護(hù) 需求跟蹤矩陣 確保產(chǎn)品依據(jù)需求文檔進(jìn)行開(kāi)發(fā) 需求變更控制是指依據(jù) 變更申請(qǐng) 審批 更改 重新確認(rèn) 的流程處理需求的變更 防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂 一 需求工程概述 3 需求工程2 需求工程的主要內(nèi)容 需求開(kāi)發(fā)產(chǎn)生的主要文檔為 用戶(hù)需求說(shuō)明書(shū) 與 軟件需求規(guī)格說(shuō)明書(shū) 需求管理產(chǎn)生的主要文檔為 需求評(píng)審報(bào)告 需求跟蹤報(bào)告 和 需求變更控制報(bào)告 一 需求工程概述 4 需求工程中的主要問(wèn)題知識(shí)技能問(wèn)題態(tài)度問(wèn)題合作關(guān)系用戶(hù)說(shuō)不清楚需求雙方誤解需求開(kāi)發(fā)人員寫(xiě)不好需求文檔用戶(hù)經(jīng)常變更需求 知識(shí)技能問(wèn)題 應(yīng)用域的知識(shí)是無(wú)邊無(wú)際的 任何人都不可能是 萬(wàn)事通 俗話(huà)說(shuō) 隔行如隔山 需求分析員可能是某一領(lǐng)域的專(zhuān)家 但當(dāng)他接手陌生的業(yè)務(wù)時(shí) 他可能是個(gè) 無(wú)知 者 一個(gè)企業(yè)要謀求發(fā)展 不能總在做老的業(yè)務(wù) 人一生中會(huì)有許多充滿(mǎn)挫折的 第一次 不可以逃避 當(dāng)需求分析員缺乏應(yīng)用域知識(shí)時(shí) 他該怎么辦 首先要有勇氣做事 否則連實(shí)踐的機(jī)會(huì)都沒(méi)有 其次應(yīng)當(dāng)趕緊補(bǔ)習(xí)應(yīng)用域知識(shí) 不論是通過(guò)自學(xué)還是培訓(xùn)的方式 否則他很難與用戶(hù)交流 如果可能的話(huà) 開(kāi)發(fā)方最好請(qǐng)既懂軟件又懂應(yīng)用域知識(shí)的行家來(lái)幫忙 態(tài)度問(wèn)題 相當(dāng)多的開(kāi)發(fā)人員習(xí)慣于被動(dòng)地對(duì)待需求開(kāi)發(fā) 每當(dāng)遇到麻煩 挫折時(shí) 他們會(huì)發(fā)牢騷 找出一堆用戶(hù)的毛病 很多開(kāi)發(fā)人員錯(cuò)誤地以為 需求是用戶(hù)的事情 不是我們的事情 我們?yōu)橛脩?hù)開(kāi)發(fā)軟件 難道用戶(hù)不該告訴我們應(yīng)當(dāng)開(kāi)發(fā)什么嗎 如果用戶(hù)說(shuō)不清楚需求 或者經(jīng)常變更需求 這類(lèi)問(wèn)題是用戶(hù)產(chǎn)生的 應(yīng)當(dāng)由他們自己負(fù)責(zé) 用戶(hù)說(shuō)不清楚需求或者需求發(fā)生變更 這些都是常見(jiàn)的問(wèn)題 并不是絕癥 是人們可以設(shè)法解決的 可悲的是開(kāi)發(fā)人員把這些問(wèn)題當(dāng)成了借口 不愿主動(dòng)攻克問(wèn)題 導(dǎo)致需求問(wèn)題擴(kuò)散到整個(gè)軟件開(kāi)發(fā)過(guò)程 產(chǎn)生太多的后患 軟件企業(yè)的領(lǐng)導(dǎo)應(yīng)當(dāng)給具有錯(cuò)誤觀(guān)念的開(kāi)發(fā)人員們洗腦 需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶(hù)需求 如果做不到就是失職 不要找借口 合作關(guān)系 如果需求分析員不能與用戶(hù)建立良好的合作關(guān)系 那么他們?cè)谛枨箝_(kāi)發(fā)過(guò)程中會(huì)很疲憊 倘若用戶(hù)不能很好地配合需求分析員 那并不表示他是個(gè)壞蛋 因?yàn)橛脩?hù)有他自己的想法 我回答了你們的問(wèn)題 講了該講的 我們付錢(qián)給你們 難道還要我伺候你們不成 我還要干自己的事情 別打擾我了 你們自己想辦法把活干好吧 對(duì)于一些競(jìng)標(biāo)項(xiàng)目 在合同未簽訂之前的需求開(kāi)發(fā)工作尤為困難 用戶(hù)未必會(huì)買(mǎi)你的產(chǎn)品 他不會(huì)投入很多精力來(lái)協(xié)助你搞需求開(kāi)發(fā) 需求分析員不是銷(xiāo)售人員 他們不可能象銷(xiāo)售人員那樣通過(guò)某些手段籠絡(luò)住用戶(hù)就能成功 出色的需求分析員不僅要有過(guò)硬的專(zhuān)業(yè)知識(shí) 還要具備較強(qiáng)的交流 溝通能力 開(kāi)發(fā)方與用戶(hù)的合作關(guān)系對(duì)需求開(kāi)發(fā)而言是至關(guān)重要的 對(duì)于重大的 復(fù)雜的項(xiàng)目 我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關(guān)系 這樣風(fēng)險(xiǎn)太大 開(kāi)發(fā)方和用戶(hù)方在開(kāi)展需求開(kāi)發(fā)之前 雙方協(xié)商并撰寫(xiě) 用戶(hù)在需求工程中的權(quán)利與義務(wù) 即以協(xié)議的方式確定合作關(guān)系 好話(huà) 和 丑話(huà) 都說(shuō)在前頭 這樣能減少今后的摩擦 如果條件允許的話(huà) 開(kāi)發(fā)方最好為用戶(hù)舉辦關(guān)于需求工程的培訓(xùn) 合作關(guān)系 用戶(hù)在需求工程中的 權(quán)利 1 有權(quán)要求開(kāi)發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員 2 有權(quán)要求開(kāi)發(fā)方采用用戶(hù)熟悉的語(yǔ)言來(lái)描述需求 即開(kāi)發(fā)方必須提供用戶(hù)看得懂得需求文檔 3 有權(quán)審查需求文檔 并對(duì)有爭(zhēng)議的需求作出決策 如果認(rèn)為需求文檔不能準(zhǔn)確地反映用戶(hù)真實(shí)的意愿 可以拒絕在需求文檔上簽字 4 如果用戶(hù)想要變更需求 有權(quán)要求開(kāi)發(fā)方對(duì)該變更將產(chǎn)生的影響作出真實(shí)可信的評(píng)估 以便用戶(hù)決定是否變更需求 用戶(hù)在需求工程中的 義務(wù) 1 以積極友善的態(tài)度與開(kāi)發(fā)方人員交流 協(xié)作 盡可能地為開(kāi)發(fā)方人員提供工作和生活上的便利 2 樂(lè)意接受需求分析員的采訪(fǎng) 在不泄漏機(jī)密的前提下盡可能地回答需求分析員的問(wèn)題 3 在不泄漏機(jī)密的前提下 盡可能地向需求分析員提供與需求相關(guān)的材料 4 與需求分析員共同評(píng)審需求文檔 確保需求文檔準(zhǔn)確地反映用戶(hù)真實(shí)的意愿 用戶(hù)說(shuō)不清楚需求 用戶(hù)說(shuō)不清楚需求是普遍現(xiàn)象 這是讓開(kāi)發(fā)人員頭痛的大問(wèn)題 有些用戶(hù)真的不知道需求是什么 或者對(duì)需求只有朦朧的感覺(jué) 他當(dāng)然說(shuō)不清楚需求 有些用戶(hù)雖然心里明白想要什么 但卻說(shuō)不清楚需求 系統(tǒng)分析員絕不能以用戶(hù)說(shuō)不清楚需求為借口而草率地對(duì)待需求開(kāi)發(fā)工作 否則會(huì)連累整個(gè)開(kāi)發(fā)團(tuán)隊(duì)的 無(wú)論是什么原因?qū)е掠脩?hù)說(shuō)不清楚需求 系統(tǒng)分析員必須設(shè)法搞清楚用戶(hù)真正的需求 這是系統(tǒng)分析員的職責(zé) 也是職業(yè)的挑戰(zhàn) 雙方誤解需求 了解需求的過(guò)程中會(huì)發(fā)生 問(wèn)非所求 答非所問(wèn) 的事情 開(kāi)發(fā)人員寫(xiě)不好需求文檔 需求調(diào)查工作不充分 獲取的需求信息太少或者太亂 以至于寫(xiě)不成需求文檔 要想寫(xiě)出好的需求文檔 前提條件是把需求調(diào)查工作做好 企業(yè)應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔 盡可能地降低寫(xiě)作難度 用戶(hù)經(jīng)常變更需求 需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度 人力資源 經(jīng)費(fèi)產(chǎn)生很大的影響 如果在項(xiàng)目開(kāi)發(fā)的初始階段 開(kāi)發(fā)人員和用戶(hù)沒(méi)有搞清楚需求或者搞錯(cuò)了需求 到了項(xiàng)目開(kāi)發(fā)后期才將需求糾正過(guò)來(lái) 導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開(kāi)發(fā) 毫無(wú)疑問(wèn) 這種需求變更將使項(xiàng)目付出額外的代價(jià) 需求變更并不可怕 可怕的是需求變更失去控制 導(dǎo)致項(xiàng)目混亂 所以需求變更控制是需求工程的重要活動(dòng) 用戶(hù)經(jīng)常變更需求 需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度 人力資源 經(jīng)費(fèi)產(chǎn)生很大的影響 如果在項(xiàng)目開(kāi)發(fā)的初始階段 開(kāi)發(fā)人員和用戶(hù)沒(méi)有搞清楚需求或者搞錯(cuò)了需求 到了項(xiàng)目開(kāi)發(fā)后期才將需求糾正過(guò)來(lái) 導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開(kāi)發(fā) 毫無(wú)疑問(wèn) 這種需求變更將使項(xiàng)目付出額外的代價(jià) 需求變更并不可怕 可怕的是需求變更失去控制 導(dǎo)致項(xiàng)目混亂 所以需求變更控制是需求工程的重要活動(dòng) 一 需求工程概述 5 需求工程的層次開(kāi)發(fā)者對(duì)待需求工程的態(tài)度可分 被動(dòng)型 主動(dòng)型 和 領(lǐng)先型 三種 只有后兩種才有可能開(kāi)發(fā)出成功的產(chǎn)品 被動(dòng)型 是指開(kāi)發(fā)者被動(dòng)地對(duì)待需求工程中的各項(xiàng)活動(dòng) 能少干則少干 能偷懶則偷懶 他們認(rèn)為需求是用戶(hù)的事情而不是自己的事情 開(kāi)發(fā)過(guò)程中經(jīng)常發(fā)生需求變更 導(dǎo)致產(chǎn)品迷失方向 不是半途而廢就是陷入半死不活的狀態(tài) 主動(dòng)型 是指開(kāi)發(fā)者積極地開(kāi)展需求工程中的各項(xiàng)活動(dòng) 他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé) 會(huì)想盡一切辦法克服需求開(kāi)發(fā)和需求管理過(guò)程中的困難 而不是找借口推卸責(zé)任 俗話(huà)說(shuō) 良好的開(kāi)端是成功的一半 主動(dòng)型 需求工程是開(kāi)發(fā)成功產(chǎn)品的必備條件 領(lǐng)先型 是需求工程的最高境界 開(kāi)發(fā)者發(fā)掘了連用戶(hù)自己都沒(méi)有意識(shí)到的需求 導(dǎo)致用戶(hù)跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶(hù)轉(zhuǎn) 這叫引導(dǎo)消費(fèi) 需求工程做到這個(gè)份上 才能使產(chǎn)品立于不敗之地 長(zhǎng)盛不衰 二 需求開(kāi)發(fā) 1 需求的獲取一般地 分析員首先要通過(guò)與用戶(hù)面談 問(wèn)卷調(diào)查等方式獲取需求 通過(guò)對(duì)這些需求進(jìn)行記錄與定義并進(jìn)行討論與修正 將未解決的問(wèn)題放在一個(gè)條目中 等下一次調(diào)查解決 通過(guò)多次迭代最終得到完整的系統(tǒng)需求 1 需求獲取規(guī)程現(xiàn)代軟件系統(tǒng)分析與開(kāi)發(fā)一般都遵循一定的范式和規(guī)程 在需求調(diào)查階段 一般按以下規(guī)程進(jìn)行 二 需求開(kāi)發(fā) 1 需求的獲取2 調(diào)查準(zhǔn)備 1 需求分析員應(yīng)當(dāng)起草需求調(diào)查問(wèn)題表 將調(diào)查重點(diǎn)鎖定在該問(wèn)題表內(nèi) 否則調(diào)查工作將變得漫無(wú)邊際 問(wèn)題表可以有多份 隨著調(diào)查的深入 問(wèn)題表將不斷地被細(xì)化 根據(jù)經(jīng)驗(yàn) 用戶(hù)通常沒(méi)有耐心回答復(fù)雜的論述題 所以問(wèn)題表應(yīng)當(dāng)以 選擇題 和 是非題 為主 制定問(wèn)題表最簡(jiǎn)便的方法就是從 用戶(hù)需求說(shuō)明書(shū) 的模板中提取需求問(wèn)題 二 需求開(kāi)發(fā) 1 需求的獲取2 調(diào)查準(zhǔn)備 2 確定調(diào)查方式 調(diào)查的方法有 問(wèn)卷調(diào)查復(fù)查現(xiàn)有報(bào)表和業(yè)務(wù)過(guò)程的描述與用戶(hù)面談與討論觀(guān)察與記錄業(yè)務(wù)過(guò)程與同行或?qū)＜医徽?聽(tīng)取意見(jiàn)與建議分析已經(jīng)存在的軟件系統(tǒng) 提取需求從行業(yè)標(biāo)準(zhǔn)和規(guī)則中提取需求到Internet上查找相關(guān)信息 二 需求開(kāi)發(fā) 1 需求的獲取2 調(diào)查準(zhǔn)備 2 確定調(diào)查方式 輔助調(diào)查的方法有 可通過(guò)原型的方法獲取需求 這對(duì)于 說(shuō)不出需求 的用戶(hù)尤其適用 JAD 聯(lián)合應(yīng)用開(kāi)發(fā)會(huì)議 是加快調(diào)查的重要方法 即將相關(guān)人員全部召集在一起參加單一會(huì)議直接解決需求分析問(wèn)題 二 需求開(kāi)發(fā) 1 需求的獲取2 調(diào)查準(zhǔn)備 3 需求分析員與被調(diào)查者建立聯(lián)系 確定調(diào)查的時(shí)間 地點(diǎn) 人員等 撰寫(xiě)需求調(diào)查計(jì)劃 要特別留意的是不要漏掉典型的用戶(hù) 二 需求開(kāi)發(fā) 1 需求的獲取3 調(diào)查與記錄準(zhǔn)備工作完畢后 需求分析員按照計(jì)劃執(zhí)行調(diào)查 在調(diào)查過(guò)程中隨時(shí)記錄 或存儲(chǔ) 需求信息 通過(guò)完成計(jì)劃的調(diào)查任務(wù) 系統(tǒng)分析員獲取用戶(hù)需求并將其正確的記錄 記錄形式一般為表格 二 需求開(kāi)發(fā) 1 需求的獲取3 調(diào)查與記錄面談中要注意的問(wèn)題 注重時(shí)間與禮節(jié) 建立與用戶(hù)的良好關(guān)系事先了解用戶(hù)的身份 背景從宏觀(guān)入手 然后細(xì)化 而不是象偵探那樣從蛛絲馬跡著手輕松的氣氛 不輕意打斷用戶(hù)的談話(huà)不為用戶(hù)添加必要的麻煩 但也不要因怕麻煩而降低調(diào)查力度 二 需求開(kāi)發(fā) 1 需求的獲取3 調(diào)查與記錄調(diào)查的技術(shù) 問(wèn)答分析法 通過(guò)提問(wèn)與回答了解系統(tǒng)需求 最主要的問(wèn)題是 是什么 和 為什么 每個(gè)需求都用陳述句說(shuō)明 是什么 如果表達(dá)不清 則加上 不是什么 如果 是 與 不是 不是理所當(dāng)然的 就必須加上解釋 為什么 目標(biāo) 獲得正確 清晰的需求 其他常見(jiàn)問(wèn)題 需求存在二義性嗎 需求文檔的上下文有矛盾嗎 需求完備嗎 需求是必要的嗎 需求可實(shí)現(xiàn)嗎 需求可驗(yàn)證嗎 需求的優(yōu)先級(jí)確定了嗎 二 需求開(kāi)發(fā) 2 需求沖突的解決需求從獲取渠道收集到以后 可能產(chǎn)生不一致的地方 解決原則主要有 當(dāng)客戶(hù)需求與開(kāi)發(fā)方預(yù)計(jì)需求沖突時(shí) 以客戶(hù)需求為主 用戶(hù)間需求沖突則以級(jí)別大的用戶(hù)需求為準(zhǔn) 同級(jí)則少數(shù)服從多數(shù) 多個(gè)客戶(hù)以出錢(qián)多的客戶(hù)需求為準(zhǔn) 二 需求開(kāi)發(fā) 3 用戶(hù)需求說(shuō)明書(shū)對(duì)收集到的用戶(hù)需求進(jìn)行分析 歸納與總結(jié) 然后根據(jù)一定的格式撰寫(xiě) 用戶(hù)需求說(shuō)明書(shū) 調(diào)查過(guò)程中的中間資料可作為附件 用戶(hù)需求說(shuō)明書(shū)完成后 應(yīng)邀請(qǐng)專(zhuān)家與用戶(hù)對(duì)其進(jìn)行評(píng)審 使其最大限度地符合用戶(hù)的真實(shí)意愿 之后才能進(jìn)行進(jìn)一步的需求分析與定義 產(chǎn)生 軟件需求規(guī)格說(shuō)明書(shū) 模板 二 需求開(kāi)發(fā) 4 需求分析與定義1 概述需求分析的結(jié)果是通過(guò)建立系統(tǒng)的邏輯模型來(lái)定義需求 邏輯模型 詳細(xì)展示系統(tǒng)要完成的功能 而不依賴(lài)具體技術(shù)的模型 物理模型 表明系統(tǒng)是如何真正實(shí)現(xiàn)的模型 二 需求開(kāi)發(fā) 4 需求分析與定義1 概述結(jié)構(gòu)化分析方法興盛的時(shí)期 軟件系統(tǒng)的開(kāi)發(fā)過(guò)程是從物理模型到邏輯模型 再?gòu)倪壿嬆Ｐ偷叫碌奈锢砟Ｐ偷倪^(guò)程 這種方法可以保證系統(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) 并不能通過(guò)信息化改造原來(lái)的業(yè)務(wù)管理流程 提高管理水平 不適合于全新系統(tǒng)的開(kāi)發(fā) 特別是一些WEB項(xiàng)目 如電子商務(wù)方面的項(xiàng)目開(kāi)發(fā) 這些項(xiàng)目沒(méi)有可參考的舊系統(tǒng) 二 需求開(kāi)發(fā) 4 需求分析與定義1 概述現(xiàn)代的需求分析過(guò)程 往往是直接在對(duì)用戶(hù)需求進(jìn)行收集地過(guò)程中直接產(chǎn)生新系統(tǒng)的邏輯模型 直接通過(guò)對(duì)比要解決的商業(yè)問(wèn)題和軟件需要實(shí)現(xiàn)的功能 系統(tǒng)分析員只有在需要理解商業(yè)業(yè)務(wù)流程時(shí)才去檢查現(xiàn)有系統(tǒng) 系統(tǒng)分析員的焦點(diǎn)是 以新系統(tǒng)為中心 提出創(chuàng)新的問(wèn)題解決之道是系統(tǒng)分析員的素質(zhì)要求之一 此外 新系統(tǒng)的引入還可能對(duì)組織原來(lái)的業(yè)務(wù)流程進(jìn)行改造 BPR 兩種思維方式 還沒(méi)有壞 就不需要修理總有一種更好的解決方法 案例 Ford的業(yè)務(wù)流程重組 20世紀(jì)80年代 福特北美分部的帳目支付部門(mén)雇傭了500多名員工 為了提高效率 公司決定引入信息系統(tǒng) 最初的目標(biāo)是提高20 的效率 在項(xiàng)目小組進(jìn)行系統(tǒng)分析時(shí)發(fā)現(xiàn) 馬自達(dá)公司的帳目支付部門(mén)只有5名員工 雖然福特比馬自達(dá)大得多 但相對(duì)于而言也達(dá)不到100倍的業(yè)務(wù)量 在借鑒了馬自達(dá)的業(yè)務(wù)過(guò)程的同時(shí) 項(xiàng)目組設(shè)計(jì)了全新的自動(dòng)化系統(tǒng) 將帳目支付功能包含在更大的購(gòu)買(mǎi)功能中 實(shí)現(xiàn)了從購(gòu)買(mǎi)到支付全程跟蹤的自動(dòng)化 項(xiàng)目結(jié)束時(shí) 只需求100人即可完成原來(lái)500多人才能完成的帳目支付功能 大大超出了預(yù)計(jì) 二 需求開(kāi)發(fā) 4 需求分析與定義2 系統(tǒng)分析規(guī)程 二 需求開(kāi)發(fā) 4 需求分析與定義2 系統(tǒng)分析規(guī)程第一步 細(xì)化并分析用戶(hù)需求 需求分析員首先對(duì) 用戶(hù)需求說(shuō)明書(shū) 進(jìn)行細(xì)化 對(duì)比較復(fù)雜的用戶(hù)需求進(jìn)行建模分析 以幫助軟件開(kāi)發(fā)人員更好地理解需求 建模分析產(chǎn)生的文檔可以作為 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 的附件 補(bǔ)充說(shuō)明 建模分析的技術(shù)難度比較高 分析員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍 第二步 撰寫(xiě)產(chǎn)品需求規(guī)格說(shuō)明書(shū) 需求分析員按照指定的文檔模板撰寫(xiě) 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 如果待開(kāi)發(fā)的產(chǎn)品分為軟件和硬件兩部分的話(huà) 則應(yīng)當(dāng)撰寫(xiě) 軟件需求規(guī)格說(shuō)明書(shū) 和 硬件需求規(guī)格說(shuō)明書(shū) 第三步 進(jìn)行需求確認(rèn) 項(xiàng)目經(jīng)理邀請(qǐng)同行專(zhuān)家和用戶(hù) 包括客戶(hù)和最終用戶(hù) 一起評(píng)審 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 盡最大努力使 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 能夠正確無(wú)誤地反映用戶(hù)的真實(shí)意愿 需求評(píng)審之后 開(kāi)發(fā)方和客戶(hù)方的責(zé)任人對(duì) 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 作書(shū)面承諾 二 需求開(kāi)發(fā) 4 需求分析與定義3 需求分析方法文字描述 可從問(wèn)答法直接獲得 模型描述有些時(shí)候用語(yǔ)言描述某個(gè)問(wèn)題特別費(fèi)勁 而采用圖形則使人一目了然 所謂 一圖低千言 就是這個(gè)道理 在需求開(kāi)發(fā)過(guò)程中 對(duì)于某些類(lèi)型的信息 用圖形表示要比文本表示更加有效 所以將圖形與文本結(jié)合起來(lái)描述需求是很自然的方法 因此在需求分析中常使用建模的方法來(lái)定義需求 二 需求開(kāi)發(fā) 4 需求分析與定義3 需求分析方法模型描述 1 需求建模 就是指用圖形符號(hào)來(lái)表示 刻畫(huà)需求 建模分析方法主要有兩大類(lèi) 結(jié)構(gòu)化分析法 和 面向?qū)ο蠓治龇?二 需求開(kāi)發(fā) 4 需求分析與定義3 需求分析方法模型描述 2 結(jié)構(gòu)化分析法結(jié)構(gòu)化分析方法并不是明確地由涉及這個(gè)主題的一篇文章或者一本著作引入的 它也不是被所有使用者一致采用的單一方法 相反地 它是幾乎發(fā)展了20多年的一個(gè)混合物 結(jié)構(gòu)化分析方法在70年代和80年代非常流行 相關(guān)論著很多 Pressmen對(duì)結(jié)構(gòu)化分析方法作了高度概括 一個(gè)中心三種圖 二 需求開(kāi)發(fā) 4 需求分析與定義3 需求分析方法模型描述 3 面向?qū)ο蠓治龇嫦驅(qū)ο蠓治鲈O(shè)計(jì) OOAD 方法興起于20世紀(jì)80年代 從90年代起至今它已經(jīng)在分析設(shè)計(jì)領(lǐng)域占據(jù)了無(wú)可爭(zhēng)議的主流地位 面向?qū)ο蠓治鲈O(shè)計(jì)領(lǐng)域有一些比較著名的學(xué)派 如 lCoad和Yourdon學(xué)派 lBooch學(xué)派 lJocobson學(xué)派 lRumbaugh學(xué)派 UML RationalRose 二 需求開(kāi)發(fā) 4 需求分析與定義3 需求分析方法模型描述 4 建模原則 恰當(dāng)?shù)厥褂脠D形符號(hào)現(xiàn)代建模工具如Rose有非常豐富的圖形符號(hào)和文字標(biāo)注 能很好地表達(dá)模型的細(xì)節(jié) 要注意的是 在建模時(shí)使用花樣過(guò)多的圖形符號(hào)或文字意味著模型表示的復(fù)雜化 將使開(kāi)發(fā)人員更難掌握 而且使圖形文檔更加雜亂 世上不存在一個(gè)包羅萬(wàn)象的圖 它能完整地描述需求 需求建模不可能取代文字描述 在需求文檔中 文字描述是第一重要的 建模主要是起分析 解釋作用 建議將模型存放在需求文檔的附錄中 便于正文引用 二 需求開(kāi)發(fā) 5 產(chǎn)品需求規(guī)格說(shuō)明書(shū)1 用戶(hù)需求說(shuō)明書(shū) 與 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 的主要區(qū)別與聯(lián)系前者主要采用自然語(yǔ)言 和應(yīng)用域術(shù)語(yǔ) 來(lái)表達(dá)用戶(hù)需求 其內(nèi)容相對(duì)于后者而言比較粗略 不夠詳細(xì) 后者是前者的細(xì)化 更多地采用計(jì)算機(jī)語(yǔ)言和圖形符號(hào)來(lái)刻畫(huà)需求 產(chǎn)品需求是軟件系統(tǒng)設(shè)計(jì)的直接依據(jù) 兩者之間可能并不存在一一影射關(guān)系 因?yàn)檐浖_(kāi)發(fā)商會(huì)根據(jù)產(chǎn)品發(fā)展戰(zhàn)略 企業(yè)當(dāng)前狀況適當(dāng)?shù)卣{(diào)整產(chǎn)品需求 例如用戶(hù)需求可能被分配到軟件的數(shù)個(gè)版本中 軟件開(kāi)發(fā)人員應(yīng)當(dāng)依據(jù) 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 來(lái)開(kāi)發(fā)當(dāng)前產(chǎn)品 二 需求開(kāi)發(fā) 5 產(chǎn)品需求規(guī)格說(shuō)明書(shū)2 應(yīng)按一定規(guī)范書(shū)寫(xiě) 模板 二 需求開(kāi)發(fā) 5 產(chǎn)品需求規(guī)格說(shuō)明書(shū)3 書(shū)寫(xiě)原則 1 正確 2 清楚 3 無(wú)二義性 4 一致 5 必要 6 完備 7 可實(shí)現(xiàn) 8 可驗(yàn)證 9 確定優(yōu)先級(jí) 10 闡述 做什么 而不是 怎么做 三 需求管理 1 需求驗(yàn)證系統(tǒng)分析員往往認(rèn)為他們了解與掌握了用戶(hù)的需求 然而卻沒(méi)有真正把握商業(yè)過(guò)程的最精妙之處 在項(xiàng)目早期發(fā)現(xiàn)和解決這方面的問(wèn)題 比到了開(kāi)發(fā)與實(shí)現(xiàn)階段解決的代價(jià)要小百倍 發(fā)現(xiàn)和解決需求分析問(wèn)題的手段是需求驗(yàn)證 類(lèi)似于房屋建造 需求分析相當(dāng)于設(shè)計(jì)藍(lán)圖 在進(jìn)行設(shè)計(jì)時(shí)可能會(huì)存在問(wèn)題 如果在正式建造前不加以解決可能導(dǎo)致完全的失敗 在建造之前首先要驗(yàn)證圖紙的正確性 三 需求管理 1 需求驗(yàn)證1 需求驗(yàn)證過(guò)程需求確認(rèn)是指開(kāi)發(fā)方和客戶(hù)方共同對(duì) 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 進(jìn)行評(píng)審 雙方對(duì)需求達(dá)成共識(shí)后作出承諾 需求確認(rèn)包含兩個(gè)重要工作 需求評(píng)審 和 需求承諾 三 需求管理 1 需求驗(yàn)證2 需求評(píng)審要注意的問(wèn)題 l需求評(píng)審的一個(gè)通病是 虎頭蛇尾 需求評(píng)審的確乏味 也比較費(fèi)腦子 剛開(kāi)始評(píng)審時(shí) 大家都比較認(rèn)真 越到后頭越馬虎 主持人應(yīng)當(dāng)控制節(jié)奏 將重要內(nèi)容放在前面 l需求評(píng)審涉及的人員可能比較多 有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開(kāi)會(huì)并不容易 例如有些人可能出差在外 有些人可能事務(wù)纏身 沒(méi)有必要把所有事情擠在一塊做 需求開(kāi)發(fā)是循序漸進(jìn)的過(guò)程 需求評(píng)審也可以分段進(jìn)行 這樣每次評(píng)審的時(shí)間比較短 參加評(píng)審的人員也少一些 組織會(huì)議就比較容易 l開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì) 跑題 導(dǎo)致評(píng)審效率很低 有時(shí)話(huà)匣子一打開(kāi)后關(guān)不上 大家越扯越遠(yuǎn) 結(jié)果評(píng)審會(huì)議變成了聊天會(huì)議 主持人應(yīng)當(dāng)控制話(huà)題 避免大家討論與主題無(wú)關(guān)的東西 l開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議 適當(dāng)?shù)臓?zhēng)議有利于澄清問(wèn)題 比什么東西都一致贊成要好 控制爭(zhēng)議不變?yōu)闋?zhēng)吵 爭(zhēng)吵不僅對(duì)評(píng)審工作沒(méi)有好處 而且會(huì)無(wú)意中傷害同事間及與客戶(hù)的關(guān)系 影響項(xiàng)目組下一步的工作 人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是 堅(jiān)持真理 還是 固執(zhí)己見(jiàn) 毫不妥協(xié)或者輕易妥協(xié)都不是好辦法 我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣 不要一棍子打死異己的觀(guān)點(diǎn) 嘗試著讓自己站在他人的立場(chǎng)思考問(wèn)題 這樣你會(huì)找到比較滿(mǎn)意的答案 三 需求管理 1 需求驗(yàn)證3 需求承諾需求承諾是指開(kāi)發(fā)方和客戶(hù)方的責(zé)任人對(duì)通過(guò)了正式技術(shù)評(píng)審的 產(chǎn)品需求規(guī)格說(shuō)明書(shū) 作出承諾 該承諾具有商業(yè)合同的效果 本 產(chǎn)品需求規(guī)格說(shuō)明