軟件需求最佳實踐

純陽書評（公衆號:純陽書評／微信號:chimbusco88）信息系統項目中的坑有很多，但最要命的恐怕還是來自需求的坑，這裏的坑即使不致滿盤皆輸，也會讓項目各方傷痕累累，有驚亦有險，所以一套好的需求開發與管理方法框架對於項目成敗至關重要。本書就提供了一套叫做SERU的好方法，有理論，有實踐，作者自稱最佳實踐，似有口氣過大之嫌，但讀過之後，頗以爲然，不但在好多點上解決了我的困惑，而且讓我頗有換了一個高度看需求之感，所以我認爲此書既使不是需求工程領域最好之讀物，恐怕必是之一了。 第一看點就是SERU過程框架方法論。SERU是作者廣收RUP、面向對象分析和結構化分析等諸方法之所長，結合自己實際應用心得的匯聚之作，強調三階段完成需求開發。第一階段着眼宏觀，立足問題/機會，將系統劃分爲主題域（Subject），梳理域中事件（Event）和報表（Report）。第二階段着眼中觀，立足業務脈絡，由E、流程和R導出用例（UserCase）、類圖。第三階段着眼微觀，立足業務細節，完成用例與領域模型的細節填充。 整個SERU涵蓋了需求定義，需求捕獲，需求分析與建摸和需求驗證各個階段，囊括了需求基線，需求變更和需求追溯各個環節，結構清晰，自成體系，考慮周全，讀後令人耳目一新。 第二看點是書中案例設計精當，安排頗爲合理，置於緊要觀點處，有極好的說明效果，常有看理論時頗無感，讀罷案例，方覺觀點之妙。 第三看點是作者的語言造詣。作者具有很強的概念抽象和語言組織能力，每每在大段方法闡述後會將核心意思總結爲一句誡語，爲觀點賦上了很強的衝擊力。 個人認爲這是一本無論在甲方還是乙方從事信息化工作都必讀的好書，不管能吸收多少，相信都會帶來收穫感和愉悅感！

關於軟件需求設計和管理方面，很好的一本書。推薦

對軟件需求工程的各環節如何開展，從方法論的角度、結合例子和親身經歷進行了完整、準確且生動的闡述，讀後有撥雲見日之感；總結出的SERU框架及其所包含的一系列方法、模版、戒語等，實用性很強，對於軟件從業者有很好的指導作用。

涵蓋了軟件需求工程的各個方面，包括需求管理活動的操作要點，如需求基線、變更管理、需求跟蹤等。

對瀑布流的開發更能體現本書的價值，大環境，大企業！ 書中很多東西都可以當工具使用，無妨什麼開發流派！ 三人行必有我師，能學到知識，並應用就是最大的收穫！ 這謝謝！

1、前面幾章差點睡着了感覺內容看不懂在講什麼...中間幾章內容集中強度大...然後幾章輕鬆...最後1章總結。建議先看最後一章吧，馬上就能知道講的是什麼，更容易構建大局觀和整體觀。 2、感覺偏傳統的軟件需求分析的場景，但目前是移動互聯網和saas的時代，有些東西需要去思考。但是對於B端產品經理來講還是值得鑽研的，C端產品經理基本不需要看。 3、對於日常不怎麼使用uml圖，或者未接觸過相對複雜業務的人員讀起來比較費勁。 4、同現代sprint思想、lean精益思想實際上是有一點衝突的，傳統軟件開發週期長、任務多，而近幾年sprint的思想被越來越多公司採用。 5、如何落地實踐是值得考慮的一個問題，書中最後一章也提供了一個思路。 6、核心內容： SERU: subject area,event,report,use case; 主體域+事件+報表+用例； 3階段： 明確目標和範圍（開天闢地）=> 理清框架和脈絡（涇渭分明）=> 填充需求細節（天圓地方）； 每個階段的內容：包括主要任務、產物等 【1、明確目標和範圍】 1.1核心工作： 劃分主題域（若需要）=>用上下文圖確定主題域範圍=>列出主題域下的業務事件、報表類型列表 1.2主要產物： 構件圖（表示主題域關係，1張）=>上下文關係圖（表示主題域範圍，張數與主域個數相等）=>業務事件列表、報表類型列表 1.3主要訪談對象： 中高層用戶代表 1.4重要信息： 組織結構圖、分管領導=>有助於劃分主題域；部門職責說明=>有利於主題域間服務接口的標識 1.5其他提示： 這階段時間相對簡短，不強求標識全部業務事件和報表類型；重點在於從宏觀層面理解業務，標示出最主要的業務事件和報表 【2、理清框架和脈絡】 2.1核心工作： 針對業務事件進行流程、業務實體、使用場景分析； 針對每類報表進行業務實體、使用場景分析； 將前面標識出來的所有場景（用例）進行抽象、得到用例模型； 將前面業務實體分析獲得的領域模型片段進行合併和抽象； 對設計約束、質量屬性進行分析； 2.2主要產物： 活動圖（表示業務流程）； 領域類圖片段（表示每個業務流程、報表類型涉及的業務實體） 用例模型片段（表示每個業務流程中的業務活動、具體報表項） 領域模型（按主題域對領域類圖片段進行合併和抽象） 用例模型（按主題域對用例模型片段進行合併和抽象） 部署圖（用來描述軟硬件環境方面的設計約束） 2.3主要對象： 中層用戶代表 2.4重要信息： 業務事件、報表類型列表作爲訪談計劃的線索； 業務事件、報表類型列表作爲需求組織的二級目錄 2.5其他提示： 此階段主要是搭建框架，不要設計太深的內容；目標不在於標識所有用例、所有領域類，而是標誌出最重要的部分，此外，在本階段完成後將對需求進行基線劃分。 【3、填充需求細節階段】 3.1核心工作 針對每個用例（B類、R類、I類）進行捕獲、分析； 對流程圖上標誌的相關文檔進行分析，完成領域類的細節填充； 在架構師的支持下，完成技術類用例的描述； 3.2主要產物 業務類用例描述：包括事件流、相關需求、UI原型、規則約束； 報表類用例描述：包括報表概述、報表內容、輸入/輸出格式; 接口類用例描述：包括使用者概述、內容與格式、實現約束； 領域類描述：包括數據窗口分析、組成與格式、計算規則； 3.3主要訪談對象 操作層（及小部分中層）用戶代表 3.4重要信息： 根據上階段得出的用例模型，按基線安排調研與細化； 根據用例所關聯的領域類，安排領域類的分析和細化；

1.需求的定義～理論。 2.需求的鋪貨～訪談用戶：分類訪談，訪談事項，訪談細節，訪談總結～一定要和用戶確認是否是這樣。 需求分析～業務分析，不僅僅分析邏輯更要注意業務中是否存在問題，發現問題纔是分析的本質。 3.需求描述～需求文檔，需求建模～需求文檔要針對閱讀對象，使用對象分類業務描述，需求建模設計不要複雜，建模是爲了更好的與用戶，與開發溝通，所以實用，易懂，很重要。 4.需求評審～有效，不要形式化的評審需求，評審和分析一樣，都要重在把業務中問題找出，而不是評審通不通過。評審前注意會議安排(必要人員參加，會前一定要把需求提前發給參會人員，評審時間把握在40分鐘次，評審可以分多次但不能形式) 5.需求變更～變更分析，分析變更影響範圍。 6.需求管理～易追蹤，易維護，易查閱

我們並不缺乏軟件工程，需求工程的理論，技術，缺乏的是將這些理論和技術有效的應用到實踐。 作者的SERU過程框架正好是將軟件工程理論和具體的需求實踐工作真正的結合起來了。 最核心的不是提出了很多重要的需求誡語，重要的是可以通過SERU框架系統來梳理和回顧我們的需求開發和需求管理活動。 SERU模型 S:Subject Area，表示子問題域 其核心思想是要通過業務來分解系統，儘量保證業務獨立和低耦合。 E:Event，表示業務事件 通過業務事件能夠找到流程，通過流程能夠找到不同場景和用例。 R:Report，表示報表 統一處理查詢，分析和統計類需求。 U:Use Case表示用例 需求組織的最小單位，到了需求分析階段的重要活動和產出。 SERU過程框架模型將需求過程分解爲了三個階段， 第一個階段是需求定義，重點是主題域劃分和業務事件識別。 第二個階段是理清需求框架和脈絡，重點是通過業務流程圖轉到具體的領域類圖和用例圖。 到了第三個階段重點就是填充需求細節，包括用例的詳細編寫，界面和交互設計等。 第一階段-需求定義階段 需求定義階段強調了一個重點就是高屋建瓴和從頂向下的思路。 當要做一個全新的軟件產品的時候，我們首先肯定是進行需求收集和調研，所以書裏面專門談到了需求捕獲的最佳實踐，包括用戶的訪談和調查，現場的觀摩等。 同時也提出了類似任務卡片等很好的現場需求捕獲工具。爲什麼一開始要強調第一階段對系統的宏觀把握和高屋建瓴，因爲在做一個全新的軟件產品的時候我們很容易收集到大量用戶現有的流程，表單，組織架構等信息和資料，但是這樣很容易一次的陷入到需求細節中而對企業的業務沒有一個宏觀的把握。 主題域劃分+上下文圖，是需求定義階段的重要輸出。 主題域劃分主要是從業務的視角來考慮子系統應該如何劃以降低業務本身的耦合，在書中也專門提到了主題域劃分的思考應該從組織結構爲線索，從分管領導找突破以及借鑑典型的業務職能區塊等。 主題域劃分清楚了下一步重點就是要確定主題域的範圍，自然引入了上下文關係圖，其核心就是要將主題域或子系統作爲一個黑盒來分析，搞清楚邊界和其於外部用戶的交互。通過理清楚上下文關係圖後第一階段的輸出基本就很容易明確了，即業務事件+報表需求。 在這裏我覺得重點要借鑑的就是從頂向下的系統思維和分而治之，這是解決問題很重要方法。 同時剛開始一定不要跳過這個階段而落入需求細節。 主題域和業務事件是兩個重要概念，而這兩個概念核心又是業務場景。 第二階段-需求分析階段 在第二個階段重點就是粒度的細化，從主題域我需要細化一層到識別了關鍵業務對象的領域視圖，從業務事件進行流程分析我們需要講業務事件細化一層到具體的業務活動，而業務活動正式我們在識別用例的時候的重要參考。所以在這裏我們基本清楚了第二階段剛開始是通過業務事件進行業務流程分析，業務實體分析，業務場景分析，識別領域類和用例。 需求分析就是先分解，在提煉，然後在這個過程中消除矛盾。 不管是採用結構化的方法還是面向對象的方法，分解是人類控制複雜性，認知複雜事物的最佳實踐。 現代工程理論更建議採用業務導向的分解而非系統導向的分解。 在第一階段的分解我們可以看到以主題域爲主線索，具體的分解過程爲目標系統-》主題域-》業務事件；到了第二階段則是以業務流程爲主線索進行分解，具體爲業務事件-》業務流程和業務活動-》領域類圖和用例。 業務流程是對信息系統進行庖丁解牛的核心線索，每個業務事件都是一個業務流程的觸發，因此針對每個業務事件都應繼續做業務流程分析。 對於業務流程是企業核心業務的重要載體，業務流程本身就是結構化的，而且是分級的，通過分析業務流程就能夠識別企業核心業務活動，爲需求建模做好準備工作。 在這個階段我們看到兩個重要輸出，一個是靜態的領域類涉及到領域建模，而領域建模的重點就是標識類，明確類之間的邏輯關係和數量關係，添加重要的結構規則。另外一個就是動態的用例，在RUP核心三要素中專門強調了用例驅動，足見用例建模的重要性，但是我們要注意到第二階段的重點仍然是搭框架結構，因此並沒有要求要識別所有的領域類和用例。 第三階段-需求細化 需求細化是什麼？在第二階段我已經通過分解和細化到達了具體的用例，而第三階段的重點就是單個用例以及該用例可能涉及到的界面部分建模。 書中將用例分爲三類是有一定道理的，即業務用例，報表用例和接口用例。 對於業務用例的重點是基本流，擴展流和業務規則。 對於報表類的用例重點則是報表的輸入，輸出內容，輸出格式。 在這裏有個情況不得不提出的就是，一些報表類用例脫離了只要不是項目歷史開發人員很難看懂，原因即是關鍵的報表的數據來源在哪裏沒有說清楚，這點也是報表類用例必須關注的要點。 如果將用例分爲兩個層次，第一重點就是關注業務活動流和規則的細化，另外一個就是涉及到交互和界面的建模和細化。 這兩個層次仍然有一定的關係，重點仍然是要先考慮業務流和規則，再來考慮交互和界面。如果先陷入到了界面建模再考慮業務流和規則，則又是順序錯誤的開發人員思維，即違背了用例是業務活動驅動的初衷。 這裏多說一句即是功能點估算在什麼時候用，在第一階段用是毫無意義的，最佳的使用點就是在需求細化後，具體的業務流和規則，需要的數據輸入和輸出都基本清楚後，最適合進行功能點估算。 因此我們也建議一種方法，即第一階段先進行專家法估算，到了第三階段通過功能點估算對專家法估算內容進行驗證。

需求問題曾經是軟件開發領域最困難、影響面最廣的環節之一；而且在未來很長的一段時間裏，還將可能成爲最困難的環節之一。這或許是因爲產業環境不夠健全，或許是用戶成熟度不高，或許是產業太過年輕。 畢竟需求問題不僅僅涉及IT技術方面，還涉及業務知識、心理學、公司政治、流程管理、溝通交流等多個領域。 需求分析要有廣度，深度。

本書結構清晰，按照需求定義；需求捕獲；需求分析與建模；編寫規約；需求驗證，其中加入了大量的詳實案例，便於理解。收穫還是蠻多的。 在現代軟件工程方法論分爲重方法論和敏捷方法，重方法論強調前期設計，爲未來設計。而敏捷方法論則更加強調爲現在設計，未來重構它，就是這個最本質的區別。個人認爲先用流程武裝自己，然後在適度敏捷。不是整天滿嘴敏捷。 總體上主要講了如下內容： 1需求定義需求分層： 業務需求：建設目標，解決問題；抓住外部環境變化機會 用戶需求：用戶使用軟件完成某項任務，怎麼完成的需求。 特點零散-用戶提出不通過角度、不同層面、不同粒度的需求。 存在矛盾-用戶處於不同企業組織的不同層面，因此出現盲人摸象的現象，從而導致片面。 行爲需求/軟件需求（功能需求；非功能需求；設計約束）。 2需求獲取（需求調研）； 1）捕獲範圍不足-除了用戶想要的功能還要考慮業務知識。 2）缺乏計劃性：定向，聚焦，宏觀和微觀混在一起 3）捕獲對象不明確： 4）捕獲手段不足 3需求分析； （1）需求分析是什麼？需求分析是向下分解+向上提煉外加一些規格化 需求分析是業務分析--對問題進行研究 需求分析是一種分解活動：分解不同的主題域，分解成該主題域的業務流程和業務步驟 需求分析是一種提煉與整合活動：需要將用戶的需求合併到業務活動中去，將各個業務流程合成到全局業務流程中、 需求分析是一種規格化活動櫃：要找到衝突、矛盾、並且解決。 （2）內容與形式：分析是任務，建模是手段 （3）何時開始、何時結束 （4）需求分析人員技能：傾聽、交談、和提問的技巧，分析、協調、觀察、寫作、組織、建模、人際交往和創造能力。 概括爲：業務知識，技術知識，溝通能力。 4需求驗證 （1）需求驗證的關鍵是評審，注意分層次分內容驗證 5需求管理及跟蹤 統一明確的需求項劃分標準及優先級，明確變更管理流程 其中變更考慮三方面： 1）業務影響分析：合理性，優先級以及對原有需求的影響 2）技術影響分析：影響範圍，工作量，分析後決定是否拒絕，還是本次迭代 3）項目影響分析：對整個項目時間、進度、成本的影響程度。 最終完成以上工作還是要看需求分析員的能力水平，需求分析師在於儘早識別變更，架構師和設計員在於以彈性的架構減少變更的影響。所以一位優秀的需求分析員工對於項目產品的成敗特別重要。