軟件需求最佳實踐seru過程框架總結

1、SERU過程框架總結過程框架總結這是參加徐鋒的《軟件需求最佳實踐》課程培訓后的再一次總結，筆者在提出SERU過程框架的時候常說到一個觀點，就是我們并不缺乏軟件工程，需求工程的理論，技術，缺乏的是將這些理論和技術有效的應用到實踐。而作者的SERU過程框架正好是將軟件工程理論和具體的需求實踐工作真正的結合起來了，個人認為最核心的不是提出了很多重要的需求誡語，更重要的是可以通過SERU框架系統(tǒng)來梳理和回顧我們的需求開發(fā)和需求管理活動。首先對S

2、ERU模型的四個字母再做一個說明S:SubjectArea，表示子問題域，其核心思想是要通過業(yè)務來分解系統(tǒng)，盡量保證業(yè)務獨立和低耦合。E:Event，表示業(yè)務事件，通過業(yè)務事件能夠找到流程，通過流程能夠找到不同場景和用例。R:Rept，表示報表，統(tǒng)一處理查詢，分析和統(tǒng)計類需求。U:UseCase，表示用例，需求組織的最小單位，到了需求分析階段的重要活動和產(chǎn)出。SERU過程框架模型將需求過程分解為了三個階段，第一個階段是需求定義，重點是主

3、題域劃分和業(yè)務事件識別。第二個階段是理清需求框架和脈絡，重點是通過業(yè)務流程圖轉到具體的領域類圖和用例圖。到了第三個階段重點就是填充需求細節(jié)，包括用例的詳細編寫，界面和交互設計等。第一階段需求定義階段需求定義階段強調了一個重點就是高屋建瓴和從頂向下的思路。當要做一個全新的軟件產(chǎn)品的時候，我們首先肯定是進行需求收集和調研，所以書里面專門談到了需求捕獲的最佳實踐，包括用戶的訪談和調查，現(xiàn)場的觀摩等。同時也提出了類似任務卡片等很好的現(xiàn)場需求捕獲

4、工具。為什么一開始要強調第一階段對系統(tǒng)的宏觀把握和高屋建瓴，因為在做一個全新的軟件產(chǎn)品的時候我們很容易收集到大量用戶現(xiàn)有的流程，表單，組織架構等信息和資料，但是這樣很容易一次的陷入到需求細節(jié)中而對企業(yè)的業(yè)務沒有一個宏觀的把握。主題域劃分上下文圖，是需求定義階段的重要輸出。主題域劃分主要是從業(yè)務的視角來考慮子系統(tǒng)應該如何劃以降低業(yè)務本身的耦合，在書中也專門提到了主題域劃分的思考應該從組織結構為線索，從分管領導找突破以及借鑒典型的業(yè)務職能區(qū)

5、塊等。主題域劃分清楚了下一步重點就是要確定主題域的范圍，自然引入了上下文關系圖，其核心就是要將主題域或子系統(tǒng)作為一個黑盒來分析，搞清楚邊界和其于外部用戶的交互。通過理清楚上下文關系圖后第一階段的輸出基本就很容易明確了，即業(yè)務事件報表需求。在這里我覺得重點要借鑒的就是從頂向下的系統(tǒng)思維和分而治之，這是解決問題很重要方法。同時剛開始一定不要跳過這個階段而落入需求細節(jié)。主題域和業(yè)務事件是兩個重要概念，而這兩個概念核心又是業(yè)務場景。第二階段需求

6、分析階段在第二個階段重點就是粒度的細化，從主題域我需要細化一層到識別了關鍵業(yè)務對象的領域視圖，從業(yè)務事件進行流程分析我們需要講業(yè)務事件細化一層到具體的業(yè)務活動，而業(yè)務活動正式我們在識別用例需求實踐所面臨的問題需求實踐所面臨的問題?需求完整性需要諸多用戶的參與和確認，而且用戶間需求本身也存在沖突的可能，因此需求更加強調角色和場景和劃分，一個所有用戶需要都能夠滿足的需求往往不是一個好需求。?需求過程缺乏用戶的參與，我們往往是技術驅動，習慣性

7、的跳到模塊的劃分導致需求本身驗證困難，也導致了需求間耦合很緊，很難在后期組織有效的迭代開發(fā)。因此要考慮按流程和業(yè)務梳理需求。?需求無法實現(xiàn)也可能不是架構問題，而是需求本身不切實際。?用戶想要和真正需要是有區(qū)別的，沒有真正的識別需求優(yōu)先級可能導致需求過量開發(fā)和需求鍍金。?需求優(yōu)先級識別往往并不能完全依靠用戶，用戶往往只會把自己關注功能講優(yōu)先級識別的很高，因此需求優(yōu)先級識別應該是通過業(yè)務規(guī)則，流程和模式來確定。優(yōu)先級識別方法(離主營業(yè)務的遠

8、近，發(fā)生的頻率兩個方面來度量)?溝通失真，要認識到文檔僅僅是中介而不是全部，要通過即時的驗證來減少溝通失真。?需求捕獲和調研常見問題用戶告訴你的是他轉化后的解決方案，而不是最原始的需求。?變更頻繁，但是要響應變化，比如通過對變更分類來識別哪些變更是可以通過復用和可配置解決的。?非功能性需求為有效的識別，僅僅是定性，而沒有通過定性場景定量的路線。需求分析的核心線索需求分析的核心線索在原有的需求分析方法中，我們往往過多的關注How，而沒有關

9、注What，或者關注了What而沒有關注What背后的需求場景和背后的問題Why。這都導致我們沒有進行很好的需求挖掘。需求分為業(yè)務需求，用戶需求和軟件需求三個層面。而我們在平時的需求分析中往往很容易直接跳到了軟件需求階段，而忽視了業(yè)務需求和業(yè)務建模。?業(yè)務需求=目標范圍?目標的表達必須包括目標優(yōu)勢度量合理可行，或者說SMART原則。同時在目標表達上可以考慮場景法，即問題是什么》影響誰》后果是什么》解決方案優(yōu)點是什么？?范圍表達的兩個重要

10、方面是人和物，人包括干系人和最終用戶；物包括業(yè)務事件和管理控制點。需求定義輸出業(yè)務需求；需求捕獲輸出用戶需求；需求分析輸出軟件需求。需求分析的本質動作就是分解，抽象和消除歧義。而對于需求分析的本質線索則是人，事(流程)，物(數(shù)據(jù))和接口。因此需求分析不能完全等同于建模型。分析是本質，建模僅僅是手段。需求捕獲需求捕獲需求捕獲是一個不斷的探索過程。在需求捕獲中，溝通占40%，業(yè)務占30%，技術占30%。而對于溝通往往講究的并不是單純的技巧，