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

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