軟件需求最佳實(shí)踐seru過程框架總結(jié)

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

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

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

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

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

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

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

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

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

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