目錄第4章需求開發與需求管理 3
4.1 什麼是需求 4
4.1.1 基本概念 4
4.1.2 需求案例 4
4.2 了解使用者 6
4.3 需求工程 7
4.3.1 基本概念 7
4.3.2 一些感悟 8
4.4 需求開發的主要困難與對策 9
4.4.1 知識技能問題 9
4.4.2 態度問題 10
4.4.3 合作關係 10
4.4.4 使用者說不清楚需求 12
4.4.5 雙方誤解需求 12
4.4.6 開發人員寫不好需求文件 13
4.4.7 使用者經常變更需求 13
4.5 如何開展需求調查 13
4.5.1 需求調查規程 13
4.5.2 準備調查 14
4.5.3 調查與記錄 14
4.5.4 撰寫使用者需求說明書 15
4.6 如何進行需求分析 17
4.6.1 問答分析法 17
4.6.2 建模分析法 17
4.6.2.1 結構化分析法 18
4.6.2.2 物件導向分析法 18
4.6.2.3 恰當地使用圖形符號 19
4.6.3 作出決策 19
4.7 什麼是好的產品需求規格說明書 20
4.7.1 正確 20
4.7.2 清楚 20
4.7.3 無二義性 20
4.7.4 一致 21
4.7.5 必要 21
4.7.6 完備 21
4.7.7 可實現 22
4.7.8 可驗證 22
4.7.9 確定優先順序 22
4.7.10 闡述「做什麼」而不是「怎麼做」 23
4.8 如何定義產品需求 23
4.8.1 規程 23
4.8.2 軟體需求規格說明書的模板 24
4.9 需求確認 26
4.9.1 規程 26
4.9.2 需求評審 26
4.9.3 需求承諾 28
4.10 需求跟蹤 29
4.11 需求變更控制 30
4.12 cmmi對應規範 32
4.12.1 需求開發過程域的目標與實踐 32
4.12.2 需求管理過程域的目標與實踐 33
4.13 需求建模工具 33
4.14 需求管理工具 34
4.15 應用示例 34
4.15.1 成功的示例 34
4.15.2 失敗的示例 34
4.16 小結 34
我們把所有與需求直接相關的活動通稱為需求工程。需求工程是國內大學軟體工程教育最薄弱的環節之一，這種教育模式下誕生的軟體工程師會有這樣的習慣：他們在開發產品時並不清楚究竟該做什麼，但卻在一直忙碌不停地開發。
這不是個別的荒唐現象，這差不多成了國內軟體業的痼疾。
把責任推給學校顯然無濟於事。不論你是學生還是職業軟體工程師，如果你不懂需求工程，你就不可能把產品做好。為了你的前途，你應該認真學習需求工程。
令人遺憾的是大多數軟體工程教科書喜歡以學術的形式論述需求，大講結構化分析或物件導向分析，並給出一堆模型和符號。然而大部分開發人員首先要學習的是如何調查需求、如何寫需求文件等基本技能。需求工程是經典軟體工程的核心內容，按理說早就研究得相當透徹了，奇怪的是人們就是學不好、用不好。
可見需求工程的研究者似乎並不清楚實踐者的真正需求，真讓人哭笑不得。
有個射擊教練教出了不少神槍手，那些神槍手的槍法雖然很準，但老是打錯人，有的甚至拿槍來自殺。你能說射擊教練教和神槍手們合格嗎？
基於我自己學習以及培訓別人的心得體會，我準備以說理的方式論述需求工程，期望能減輕軟體開發人員心頭長久的痛。
寬泛地講，需求**於使用者的一些「需要」，這些「需要」被分析、確認後形成完整的文件，該文件詳細地說明了產品「必須或應當」做什麼。
所以如果只有一些零碎的對話、資料或郵件，你就以為自己已經掌握了需求，那是自欺欺人。
人們常問：「需求、設計、程式設計、測試四者究竟哪個重要？」
這個問題不好回答。四者都是軟體開發過程中必不可少的環節，光做好其中乙個環節並不能產生好的系統，但是做壞了其中任何乙個環節，必定對系統產生壞影響。若站在風險管理角度講，我認為需求開發與管理是最重要的環節。
因為需求是產品的根源，需求工作的優劣對產品影響最大。就像一條河流，如果源頭被汙染了，那麼整條河流也就被汙染了。
frederick brooks在他2023年的經典文章「no silver bullet」中闡述了需求的重要性：
開發軟體系統最困難的部分就是準確說明開發什麼。最困難的概念性工作是編寫出詳細的需求，包括所有面向使用者、面向機器和其它軟體系統的介面。此工作一旦做錯，將會給系統帶來極大的損害，並且以後對它修改也極為困難。
沒有軟體工程書籍不強調需求的重要性，也幾乎沒有軟體開發人員不知道需求的重要性。但是讀過書並不表示就能夠熟練掌握，需求工作說起來容易做起來難啊。
根據我的觀察和切身體會，大部分軟體開發人員並不知道如何把需求工作做好。在我為本公司軟體開發人員寫需求工程培訓教材時，恰好遇到公司裡一群高智商的開發人員集體犯需求觀念錯誤的事情。我就把它寫成案例，現炒現賣。
本公司是國內一家大型的電信裝置**商，本案例涉及6個機構a,b,c,d,e和f，它們之間的關係如圖4-1所示。故事是這樣的：
a和b都是公司的研發機構，b做核心平台的研發，a做增值業務的研發（我在a工作）。c是公司的專案管理機構，負責立項、結項和研發經費管理。d是公司的乙個銷售機構。
一年前，b研製了一種資料接入伺服器的原型。b對a講：「我們的接入伺服器前途很好，請你們幫助開發網管軟體（屬於增值業務範疇），大家合作把產品做好，一起發財。」
d對b和a講：「你們把接入伺服器和網管軟體做好，我們負責賣，掙了錢大家一起分。」
a想了想覺得機會難得，於是向c申請立項。立項後，a把該專案外包給一家專業做網管軟體的公司e，期望半年內完成。由於接入伺服器是b的，於是a和e就派開發人員到b處搞需求分析。
b的接入伺服器並不成熟，老在變，三方折騰了好久，最終e用了一年時間把接入伺服器的網管軟體做出來了。
e把網管軟體交付給a，a付清了e的開發費用，再把網管軟體交付給d，d再賣給客戶f（某地電信局）。f對d講：「你們的網管軟體不是我們想要的東西，等你們把軟體改好後我們再付錢。」
d趕緊對a講：「兄弟阿，貨已經出手了，但是不對路，請趕緊把它改好，不然大家都沒錢賺。」
a很憤怒，怨天不公：「我們辛苦了一年，又花了很多錢，可是產品做完了卻沒人要，豈有此理！」
禍不單行的是，c來找a的麻煩：「你們的專案延期半年多了，經費也用光了，請盡快結束專案。」
a的那位專案經理為此每天愁眉苦臉，他的上司請來幾位參謀商量對策（包括我在內），設法把事情搞定。大家挖空心思只想出乙個餿主意：既然套子是b下的，那麼就把套子還給b。
要設法把「那麼好」的網管產品轉讓給b，只要b能給我們成本費，以後就跟b拜拜。
圖4-1 本案例6個機構的關係圖
讀者聽了這個故事肯定既迷糊又驚詫：「哇，大公司是這樣開發產品的啊？」。我也是在人家請我商量對策的時候，才知道有這樣的事情。
問題的根源在於沒有搞清楚網管軟體的需求，這都是b,a,e閉門造車惹的禍。三方開發團隊裡可是有不少的博士、碩士吶，可是他們集體犯了如此低階的錯誤。最可悲的是，相關責任人關心的是如何把事情「搞定」，而不是深刻反思。
估計類似的事情還會繼續發生，每發生一次就損失成百上千萬元。大公司再有錢也會給浪費光的。
第8章需求管理
第8章需求管理 2 8.1 介紹 2 8.2 需求確認 3 8.2.1 目的 3 8.2.2 角色與職責 3 8.2.3 啟動準則 3 8.2.4 輸入 3 8.2.5 主要步驟 4 step1 非正式需求評審 4 step2 正式需求評審 4 step3 獲取需求承諾 4 8.2.6 輸出 4 8...
第8章需求管理
第8章需求管理 2 8.1 介紹 2 8.2 需求確認 3 8.2.1 目的 3 8.2.2 角色與職責 3 8.2.3 啟動準則 3 8.2.4 輸入 3 8.2.5 主要步驟 4 step1 非正式需求評審 4 step2 正式需求評審 4 step3 獲取需求承諾 4 8.2.6 輸出 4 8...
ch04第4章物料需求計畫
幻燈片1 天津商業大學 會計系幻燈片2 教學目標 理解和掌握物料需求計畫的概念和特點 理解mrp的基本原理 理解和掌握低層碼的特點和作用 理解和掌握mrp的運算過程 幻燈片3 本章內容 4.1 概述 4.2 mrp的工作原理 4.3 低層碼的作用 4.4 mrp的計算過程 4.5 本章小結 幻燈片4...