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