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