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

1、SERU過(guò)程框架總結(jié)這是參加徐鋒的軟件需求最佳實(shí)踐課程培訓(xùn)后的再一次總結(jié)，筆者在提出SERU過(guò)程框架的時(shí)候常說(shuō)到一個(gè)觀點(diǎn)，就是我們并不缺乏軟件工程，需求工程的理論，技術(shù)，缺乏的是將這些理論和技術(shù)有效的應(yīng)用到實(shí)踐。而作者的SERU過(guò)程框架正好是將軟件工程理論和具體的需求實(shí)踐工作真正的結(jié)合起來(lái)了，個(gè)人認(rèn)為最核心的不是提出了很多重要的需求誡語(yǔ)，更重要的是可以通過(guò)SERU框架系統(tǒng)來(lái)梳理和回顧我們的需求開(kāi)發(fā)和需求管理活動(dòng)。  首先對(duì)SERU模型的四個(gè)字母再做一個(gè)說(shuō)明  S:Subject Area，表示子問(wèn)題域，其核心思想是要通過(guò)業(yè)務(wù)來(lái)分解系統(tǒng)，盡量保證業(yè)務(wù)獨(dú)立和

2、低耦合。 E:Event，表示業(yè)務(wù)事件，通過(guò)業(yè)務(wù)事件能夠找到流程，通過(guò)流程能夠找到不同場(chǎng)景和用例。 R:Report，表示報(bào)表，統(tǒng)一處理查詢，分析和統(tǒng)計(jì)類需求。 U:Use Case，表示用例，需求組織的最小單位，到了需求分析階段的重要活動(dòng)和產(chǎn)出。  SERU過(guò)程框架模型將需求過(guò)程分解為了三個(gè)階段，第一個(gè)階段是需求定義，重點(diǎn)是主題域劃分和業(yè)務(wù)事件識(shí)別。第二個(gè)階段是理清需求框架和脈絡(luò)，重點(diǎn)是通過(guò)業(yè)務(wù)流程圖轉(zhuǎn)到具體的領(lǐng)域類圖和用例圖。到了第三個(gè)階段重點(diǎn)就是填充需求細(xì)節(jié)，包括用例的詳細(xì)編寫，界面和交互設(shè)計(jì)等。  第一階段-需求定義

3、階段  需求定義階段強(qiáng)調(diào)了一個(gè)重點(diǎn)就是高屋建瓴和從頂向下的思路。當(dāng)要做一個(gè)全新的軟件產(chǎn)品的時(shí)候，我們首先肯定是進(jìn)行需求收集和調(diào)研，所以書里面專門談到了需求捕獲的最佳實(shí)踐，包括用戶的訪談和調(diào)查，現(xiàn)場(chǎng)的觀摩等。同時(shí)也提出了類似任務(wù)卡片等很好的現(xiàn)場(chǎng)需求捕獲工具。為什么一開(kāi)始要強(qiáng)調(diào)第一階段對(duì)系統(tǒng)的宏觀把握和高屋建瓴，因?yàn)樵谧鲆粋€(gè)全新的軟件產(chǎn)品的時(shí)候我們很容易收集到大量用戶現(xiàn)有的流程，表單，組織架構(gòu)等信息和資料，但是這樣很容易一次的陷入到需求細(xì)節(jié)中而對(duì)企業(yè)的業(yè)務(wù)沒(méi)有一個(gè)宏觀的把握。  主題域劃分+上下文圖，是需求定義階段的重要輸出。主題域劃分主要是從業(yè)務(wù)的視角來(lái)考

4、慮子系統(tǒng)應(yīng)該如何劃以降低業(yè)務(wù)本身的耦合，在書中也專門提到了主題域劃分的思考應(yīng)該從組織結(jié)構(gòu)為線索，從分管領(lǐng)導(dǎo)找突破以及借鑒典型的業(yè)務(wù)職能區(qū)塊等。主題域劃分清楚了下一步重點(diǎn)就是要確定主題域的范圍，自然引入了上下文關(guān)系圖，其核心就是要將主題域或子系統(tǒng)作為一個(gè)黑盒來(lái)分析，搞清楚邊界和其于外部用戶的交互。通過(guò)理清楚上下文關(guān)系圖后第一階段的輸出基本就很容易明確了，即業(yè)務(wù)事件+報(bào)表需求。  在這里我覺(jué)得重點(diǎn)要借鑒的就是從頂向下的系統(tǒng)思維和分而治之，這是解決問(wèn)題很重要方法。同時(shí)剛開(kāi)始一定不要跳過(guò)這個(gè)階段而落入需求細(xì)節(jié)。主題域和業(yè)務(wù)事件是兩個(gè)重要概念，而這兩個(gè)概念核心又是業(yè)務(wù)場(chǎng)景。 

5、; 第二階段-需求分析階段  在第二個(gè)階段重點(diǎn)就是粒度的細(xì)化，從主題域我需要細(xì)化一層到識(shí)別了關(guān)鍵業(yè)務(wù)對(duì)象的領(lǐng)域視圖，從業(yè)務(wù)事件進(jìn)行流程分析我們需要講業(yè)務(wù)事件細(xì)化一層到具體的業(yè)務(wù)活動(dòng)，而業(yè)務(wù)活動(dòng)正式我們?cè)谧R(shí)別用例的時(shí)候的重要參考。所以在這里我們基本清楚了第二階段剛開(kāi)始是通過(guò)業(yè)務(wù)事件進(jìn)行業(yè)務(wù)流程分析，業(yè)務(wù)實(shí)體分析，業(yè)務(wù)場(chǎng)景分析，識(shí)別領(lǐng)域類和用例。  需求分析就是先分解，在提煉，然后在這個(gè)過(guò)程中消除矛盾。不管是采用結(jié)構(gòu)化的方法還是面向?qū)ο蟮姆椒ǎ纸馐侨祟惪刂茝?fù)雜性，認(rèn)知復(fù)雜事物的最佳實(shí)踐。現(xiàn)代工程理論更建議采用業(yè)務(wù)導(dǎo)向的分解而非系統(tǒng)導(dǎo)向的分解。在第

6、一階段的分解我們可以看到以主題域?yàn)橹骶€索，具體的分解過(guò)程為目標(biāo)系統(tǒng)-主題域-業(yè)務(wù)事件；到了第二階段則是以業(yè)務(wù)流程為主線索進(jìn)行分解，具體為業(yè)務(wù)事件-業(yè)務(wù)流程和業(yè)務(wù)活動(dòng)-領(lǐng)域類圖和用例。  業(yè)務(wù)流程是對(duì)信息系統(tǒng)進(jìn)行庖丁解牛的核心線索，每個(gè)業(yè)務(wù)事件都是一個(gè)業(yè)務(wù)流程的觸發(fā)，因此針對(duì)每個(gè)業(yè)務(wù)事件都應(yīng)繼續(xù)做業(yè)務(wù)流程分析。對(duì)于業(yè)務(wù)流程是企業(yè)核心業(yè)務(wù)的重要載體，業(yè)務(wù)流程本身就是結(jié)構(gòu)化的，而且是分級(jí)的，通過(guò)分析業(yè)務(wù)流程就能夠識(shí)別企業(yè)核心業(yè)務(wù)活動(dòng)，為需求建模做好準(zhǔn)備工作。  在這個(gè)階段我們看到兩個(gè)重要輸出，一個(gè)是靜態(tài)的領(lǐng)域類涉及到領(lǐng)域建模，而領(lǐng)域建模的重點(diǎn)就是標(biāo)識(shí)類，明確類

7、之間的邏輯關(guān)系和數(shù)量關(guān)系，添加重要的結(jié)構(gòu)規(guī)則。另外一個(gè)就是動(dòng)態(tài)的用例，在RUP核心三要素中專門強(qiáng)調(diào)了用例驅(qū)動(dòng)，足見(jiàn)用例建模的重要性，但是我們要注意到第二階段的重點(diǎn)仍然是搭框架結(jié)構(gòu)，因此并沒(méi)有要求要識(shí)別所有的領(lǐng)域類和用例。  第三階段-需求細(xì)化  需求細(xì)化是什么？在第二階段我已經(jīng)通過(guò)分解和細(xì)化到達(dá)了具體的用例，而第三階段的重點(diǎn)就是單個(gè)用例以及該用例可能涉及到的界面部分建模。書中將用例分為三類是有一定道理的，即業(yè)務(wù)用例，報(bào)表用例和接口用例。對(duì)于業(yè)務(wù)用例的重點(diǎn)是基本流，擴(kuò)展流和業(yè)務(wù)規(guī)則。對(duì)于報(bào)表類的用例重點(diǎn)則是報(bào)表的輸入，輸出內(nèi)容，輸出格式。在這里有個(gè)情況不得

8、不提出的就是，一些報(bào)表類用例脫離了只要不是項(xiàng)目歷史開(kāi)發(fā)人員很難看懂，原因即是關(guān)鍵的報(bào)表的數(shù)據(jù)來(lái)源在哪里沒(méi)有說(shuō)清楚，這點(diǎn)也是報(bào)表類用例必須關(guān)注的要點(diǎn)。  如果將用例分為兩個(gè)層次，第一重點(diǎn)就是關(guān)注業(yè)務(wù)活動(dòng)流和規(guī)則的細(xì)化，另外一個(gè)就是涉及到交互和界面的建模和細(xì)化。這兩個(gè)層次仍然有一定的關(guān)系，重點(diǎn)仍然是要先考慮業(yè)務(wù)流和規(guī)則，再來(lái)考慮交互和界面。如果先陷入到了界面建模再考慮業(yè)務(wù)流和規(guī)則，則又是順序錯(cuò)誤的開(kāi)發(fā)人員思維，即違背了用例是業(yè)務(wù)活動(dòng)驅(qū)動(dòng)的初衷。  這里多說(shuō)一句即是功能點(diǎn)估算在什么時(shí)候用，在第一階段用是毫無(wú)意義的，最佳的使用點(diǎn)就是在需求細(xì)化后，具體的業(yè)務(wù)流和規(guī)

9、則，需要的數(shù)據(jù)輸入和輸出都基本清楚后，最適合進(jìn)行功能點(diǎn)估算。因此我們也建議一種方法，即第一階段先進(jìn)行專家法估算，到了第三階段通過(guò)功能點(diǎn)估算對(duì)專家法估算內(nèi)容進(jìn)行驗(yàn)證。這幾天在聽(tīng)軟件需求最佳實(shí)踐作者徐鋒老師的軟件需求培訓(xùn)，三天的課程，雖然原來(lái)對(duì)需求也關(guān)注了很多，自己也做過(guò)需求分析和開(kāi)發(fā)的工作，但是這次培訓(xùn)感覺(jué)收獲還是很多。三天的培訓(xùn)先做個(gè)記錄，后續(xù)多個(gè)點(diǎn)還可以逐個(gè)展開(kāi)，不斷的總結(jié)。需求實(shí)踐所面臨的問(wèn)題· 需求完整性需要諸多用戶的參與和確認(rèn)，而且用戶間需求本身也存在沖突的可能，因此需求更加強(qiáng)調(diào)角色和場(chǎng)景和劃分，一個(gè)所有用戶需要都能夠滿足的需求往往不是一個(gè)好需求。· 需求過(guò)程缺乏用

10、戶的參與，我們往往是技術(shù)驅(qū)動(dòng)，習(xí)慣性的跳到模塊的劃分導(dǎo)致需求本身驗(yàn)證困難，也導(dǎo)致了需求間耦合很緊，很難在后期組織有效的迭代開(kāi)發(fā)。因此要考慮按流程和業(yè)務(wù)梳理需求。· 需求無(wú)法實(shí)現(xiàn)也可能不是架構(gòu)問(wèn)題，而是需求本身不切實(shí)際。· 用戶想要和真正需要是有區(qū)別的，沒(méi)有真正的識(shí)別需求優(yōu)先級(jí)可能導(dǎo)致需求過(guò)量開(kāi)發(fā)和需求鍍金。· 需求優(yōu)先級(jí)識(shí)別往往并不能完全依靠用戶，用戶往往只會(huì)把自己關(guān)注功能講優(yōu)先級(jí)識(shí)別的很高，因此需求優(yōu)先級(jí)識(shí)別應(yīng)該是通過(guò)業(yè)務(wù)規(guī)則，流程和模式來(lái)確定。優(yōu)先級(jí)識(shí)別方法(離主營(yíng)業(yè)務(wù)的遠(yuǎn)近，發(fā)生的頻率兩個(gè)方面來(lái)度量)· 溝通失真，要認(rèn)識(shí)到文檔僅僅是中介而不是全部，

11、要通過(guò)即時(shí)的驗(yàn)證來(lái)減少溝通失真。· 需求捕獲和調(diào)研常見(jiàn)問(wèn)題-用戶告訴你的是他轉(zhuǎn)化后的解決方案，而不是最原始的需求。· 變更頻繁，但是要響應(yīng)變化，比如通過(guò)對(duì)變更分類來(lái)識(shí)別哪些變更是可以通過(guò)復(fù)用和可配置解決的。· 非功能性需求為有效的識(shí)別，僅僅是定性，而沒(méi)有通過(guò)定性->場(chǎng)景->定量的路線。需求分析的核心線索在原有的需求分析方法中，我們往往過(guò)多的關(guān)注How，而沒(méi)有關(guān)注What，或者關(guān)注了What而沒(méi)有關(guān)注What背后的需求場(chǎng)景和背后的問(wèn)題Why。這都導(dǎo)致我們沒(méi)有進(jìn)行很好的需求挖掘。需求分為業(yè)務(wù)需求，用戶需求和軟件需求三個(gè)層面。而我們?cè)谄綍r(shí)的需求分析中往往很容

12、易直接跳到了軟件需求階段，而忽視了業(yè)務(wù)需求和業(yè)務(wù)建模。· 業(yè)務(wù)需求 = 目標(biāo) + 范圍· 目標(biāo)的表達(dá)必須包括目標(biāo)+優(yōu)勢(shì)+度量+合理+可行，或者說(shuō)SMART原則。同時(shí)在目標(biāo)表達(dá)上可以考慮場(chǎng)景法，即問(wèn)題是什么-影響誰(shuí)-后果是什么-解決方案優(yōu)點(diǎn)是什么？· 范圍表達(dá)的兩個(gè)重要方面是人和物，人包括干系人和最終用戶；物包括業(yè)務(wù)事件和管理控制點(diǎn)。需求定義輸出業(yè)務(wù)需求；需求捕獲輸出用戶需求；需求分析輸出軟件需求。需求分析的本質(zhì)動(dòng)作就是分解，抽象和消除歧義。而對(duì)于需求分析的本質(zhì)線索則是人，事(流程)，物(數(shù)據(jù))和接口。因此需求分析不能完全等同于建模型。分析是本質(zhì)，建模僅僅是手段。需

13、求捕獲需求捕獲是一個(gè)不斷的探索過(guò)程。在需求捕獲中，溝通占40%，業(yè)務(wù)占30%，技術(shù)占30%。而對(duì)于溝通往往講究的并不是單純的技巧，而更多的是一種思維模式和順序的問(wèn)題。在這里老師引入了思維模式的話題，也通過(guò)一個(gè)案例講解了溝通中順序的重要性，如先將解決方案再講具體場(chǎng)景和問(wèn)題(類似于我上個(gè)ppt里面強(qiáng)調(diào)的結(jié)構(gòu)化思維的一個(gè)重要原則即開(kāi)門見(jiàn)山的逐層展開(kāi))。在溝通中講了三個(gè)可以借鑒的方法。· 未知問(wèn)題->已知問(wèn)題· 相對(duì)重要->相當(dāng)次要(創(chuàng)造一種比較的環(huán)境給用戶)· 關(guān)注點(diǎn)的轉(zhuǎn)換->(溝通也要洞察心理學(xué))· 隱喻(將了一個(gè)用漢字的贏字來(lái)表達(dá)項(xiàng)目管理

14、核心)探求本源(問(wèn)題背后的問(wèn)題，引入了你的燈亮著嗎，講到了沒(méi)有荒唐需求，只有荒唐的解決方案)需求訪談是捕獲中的一個(gè)重要內(nèi)容，這里做一個(gè)概括總結(jié)：· 首先要搞清楚你訪問(wèn)的用戶本身的角色和特點(diǎn)，前期要收集足夠的資料，然后制定針對(duì)性問(wèn)題。· 應(yīng)該是先訪談?dòng)辛顺醪降木劢购?，再進(jìn)行調(diào)查。· 訪談的用戶分類包括(用戶特點(diǎn)，功能/流程，數(shù)據(jù)，非功能性和接口)· 調(diào)查問(wèn)卷設(shè)計(jì)諸多講究，如避免簡(jiǎn)單的排序題，調(diào)查問(wèn)卷中的C現(xiàn)象和D現(xiàn)象等，不展開(kāi)。需求規(guī)格說(shuō)明書業(yè)界關(guān)注需求有很多標(biāo)準(zhǔn)，如GB2006等，但是關(guān)于功能性需求方面都不能再細(xì)化展開(kāi)，因此標(biāo)準(zhǔn)僅僅是一個(gè)展開(kāi)。各個(gè)行業(yè)或

15、組織還需要根據(jù)自身軟件項(xiàng)目特點(diǎn)對(duì)模板進(jìn)行補(bǔ)充和完善。需求分析過(guò)程應(yīng)該是一個(gè)業(yè)務(wù)流程驅(qū)動(dòng)的至上而下的過(guò)程。開(kāi)始不應(yīng)該一下轉(zhuǎn)入到一個(gè)具體的功能細(xì)節(jié)，而是應(yīng)該先規(guī)劃目錄和打提綱，然后以流程為主線逐層分解和展開(kāi)。在需求描述上可以是文字，也可以是圖形化的，也可以是一種形式化規(guī)格表達(dá)。需求規(guī)格說(shuō)明書模板的內(nèi)容也可以逆向思維，如設(shè)計(jì)需求我們提供什么樣的需求對(duì)他們才是最有參考意義的。我們的需求調(diào)研不應(yīng)該是通過(guò)模板格式來(lái)決定內(nèi)容，再?zèng)Q定溝通。而是應(yīng)該根據(jù)需要的溝通來(lái)決定內(nèi)容，根據(jù)內(nèi)容來(lái)決定我們需要什么樣的需求模板和格式。需求實(shí)踐所面臨的問(wèn)題· 需求完整性需要諸多用戶的參與和確認(rèn)，而且用戶間需求本身也存

16、在沖突的可能，因此需求更加強(qiáng)調(diào)角色和場(chǎng)景和劃分，一個(gè)所有用戶需要都能夠滿足的需求往往不是一個(gè)好需求。· 需求過(guò)程缺乏用戶的參與，我們往往是技術(shù)驅(qū)動(dòng)，習(xí)慣性的跳到模塊的劃分導(dǎo)致需求本身驗(yàn)證困難，也導(dǎo)致了需求間耦合很緊，很難在后期組織有效的迭代開(kāi)發(fā)。因此要考慮按流程和業(yè)務(wù)梳理需求。· 需求無(wú)法實(shí)現(xiàn)也可能不是架構(gòu)問(wèn)題，而是需求本身不切實(shí)際。· 用戶想要和真正需要是有區(qū)別的，沒(méi)有真正的識(shí)別需求優(yōu)先級(jí)可能導(dǎo)致需求過(guò)量開(kāi)發(fā)和需求鍍金。· 需求優(yōu)先級(jí)識(shí)別往往并不能完全依靠用戶，用戶往往只會(huì)把自己關(guān)注功能講優(yōu)先級(jí)識(shí)別的很高，因此需求優(yōu)先級(jí)識(shí)別應(yīng)該是通過(guò)業(yè)務(wù)規(guī)則，流程和模

17、式來(lái)確定。優(yōu)先級(jí)識(shí)別方法(離主營(yíng)業(yè)務(wù)的遠(yuǎn)近，發(fā)生的頻率兩個(gè)方面來(lái)度量)· 溝通失真，要認(rèn)識(shí)到文檔僅僅是中介而不是全部，要通過(guò)即時(shí)的驗(yàn)證來(lái)減少溝通失真。· 需求捕獲和調(diào)研常見(jiàn)問(wèn)題-用戶告訴你的是他轉(zhuǎn)化后的解決方案，而不是最原始的需求。· 變更頻繁，但是要響應(yīng)變化，比如通過(guò)對(duì)變更分類來(lái)識(shí)別哪些變更是可以通過(guò)復(fù)用和可配置解決的。· 非功能性需求為有效的識(shí)別，僅僅是定性，而沒(méi)有通過(guò)定性->場(chǎng)景->定量的路線。需求分析的核心線索在原有的需求分析方法中，我們往往過(guò)多的關(guān)注How，而沒(méi)有關(guān)注What，或者關(guān)注了What而沒(méi)有關(guān)注What背后的需求場(chǎng)景和背后

18、的問(wèn)題Why。這都導(dǎo)致我們沒(méi)有進(jìn)行很好的需求挖掘。需求分為業(yè)務(wù)需求，用戶需求和軟件需求三個(gè)層面。而我們?cè)谄綍r(shí)的需求分析中往往很容易直接跳到了軟件需求階段，而忽視了業(yè)務(wù)需求和業(yè)務(wù)建模。· 業(yè)務(wù)需求 = 目標(biāo) + 范圍· 目標(biāo)的表達(dá)必須包括目標(biāo)+優(yōu)勢(shì)+度量+合理+可行，或者說(shuō)SMART原則。同時(shí)在目標(biāo)表達(dá)上可以考慮場(chǎng)景法，即問(wèn)題是什么-影響誰(shuí)-后果是什么-解決方案優(yōu)點(diǎn)是什么？· 范圍表達(dá)的兩個(gè)重要方面是人和物，人包括干系人和最終用戶；物包括業(yè)務(wù)事件和管理控制點(diǎn)。需求定義輸出業(yè)務(wù)需求；需求捕獲輸出用戶需求；需求分析輸出軟件需求。需求分析的本質(zhì)動(dòng)作就是分解，抽象和消除歧義

19、。而對(duì)于需求分析的本質(zhì)線索則是人，事(流程)，物(數(shù)據(jù))和接口。因此需求分析不能完全等同于建模型。分析是本質(zhì)，建模僅僅是手段。需求捕獲需求捕獲是一個(gè)不斷的探索過(guò)程。在需求捕獲中，溝通占40%，業(yè)務(wù)占30%，技術(shù)占30%。而對(duì)于溝通往往講究的并不是單純的技巧，而更多的是一種思維模式和順序的問(wèn)題。在這里老師引入了思維模式的話題，也通過(guò)一個(gè)案例講解了溝通中順序的重要性，如先將解決方案再講具體場(chǎng)景和問(wèn)題(類似于我上個(gè)ppt里面強(qiáng)調(diào)的結(jié)構(gòu)化思維的一個(gè)重要原則即開(kāi)門見(jiàn)山的逐層展開(kāi))。在溝通中講了三個(gè)可以借鑒的方法。· 未知問(wèn)題->已知問(wèn)題· 相對(duì)重要->相當(dāng)次要(創(chuàng)造一種比

20、較的環(huán)境給用戶)· 關(guān)注點(diǎn)的轉(zhuǎn)換->(溝通也要洞察心理學(xué))· 隱喻(將了一個(gè)用漢字的贏字來(lái)表達(dá)項(xiàng)目管理核心)探求本源(問(wèn)題背后的問(wèn)題，引入了你的燈亮著嗎，講到了沒(méi)有荒唐需求，只有荒唐的解決方案)需求訪談是捕獲中的一個(gè)重要內(nèi)容，這里做一個(gè)概括總結(jié)：· 首先要搞清楚你訪問(wèn)的用戶本身的角色和特點(diǎn)，前期要收集足夠的資料，然后制定針對(duì)性問(wèn)題。· 應(yīng)該是先訪談?dòng)辛顺醪降木劢购?，再進(jìn)行調(diào)查。· 訪談的用戶分類包括(用戶特點(diǎn)，功能/流程，數(shù)據(jù)，非功能性和接口)· 調(diào)查問(wèn)卷設(shè)計(jì)諸多講究，如避免簡(jiǎn)單的排序題，調(diào)查問(wèn)卷中的C現(xiàn)象和D現(xiàn)象等，不展開(kāi)。需

21、求規(guī)格說(shuō)明書業(yè)界關(guān)注需求有很多標(biāo)準(zhǔn)，如GB2006等，但是關(guān)于功能性需求方面都不能再細(xì)化展開(kāi)，因此標(biāo)準(zhǔn)僅僅是一個(gè)展開(kāi)。各個(gè)行業(yè)或組織還需要根據(jù)自身軟件項(xiàng)目特點(diǎn)對(duì)模板進(jìn)行補(bǔ)充和完善。需求分析過(guò)程應(yīng)該是一個(gè)業(yè)務(wù)流程驅(qū)動(dòng)的至上而下的過(guò)程。開(kāi)始不應(yīng)該一下轉(zhuǎn)入到一個(gè)具體的功能細(xì)節(jié)，而是應(yīng)該先規(guī)劃目錄和打提綱，然后以流程為主線逐層分解和展開(kāi)。在需求描述上可以是文字，也可以是圖形化的，也可以是一種形式化規(guī)格表達(dá)。需求規(guī)格說(shuō)明書模板的內(nèi)容也可以逆向思維，如設(shè)計(jì)需求我們提供什么樣的需求對(duì)他們才是最有參考意義的。我們的需求調(diào)研不應(yīng)該是通過(guò)模板格式來(lái)決定內(nèi)容，再?zèng)Q定溝通。而是應(yīng)該根據(jù)需要的溝通來(lái)決定內(nèi)容，根據(jù)內(nèi)容來(lái)

22、決定我們需要什么樣的需求模板和格式。需求驗(yàn)證是一種質(zhì)量活動(dòng)，在這里要注意驗(yàn)證和確認(rèn)的區(qū)別，一般驗(yàn)證活動(dòng)主要方式就是Reivew，而Reivew根據(jù)正式程度又包括了審查，多人復(fù)審，單人復(fù)審等多種方式。需求驗(yàn)證的五大要素包括：思想：找到盡可能多的錯(cuò)誤方法：從非正式的開(kāi)始，并逐漸形成文化語(yǔ)言：從評(píng)價(jià)者轉(zhuǎn)化為建議者，強(qiáng)調(diào)協(xié)作者進(jìn)來(lái)減少用你哪里錯(cuò)了，而多用我建議如何人員：平等而且合適，減少不相關(guān)人員的參與內(nèi)容：不是全部而是最合適需求管理的三大內(nèi)容是基線，變更和狀態(tài)跟蹤。其實(shí)基線和變更都屬于配置管理的需求跟蹤。需求跟蹤又包括了對(duì)需求-設(shè)計(jì)-測(cè)試整個(gè)需求鏈的跟蹤，同時(shí)也包括了對(duì)需求實(shí)現(xiàn)狀態(tài)的跟蹤。在這個(gè)過(guò)程

23、中基線是迭代開(kāi)發(fā)的基礎(chǔ)，但是迭代開(kāi)發(fā)往往又是最難去規(guī)劃和打基線的。在這里的原因是我們是以整個(gè)文檔作為基線的對(duì)象，而不是以文檔中的條目化需求作為基線的對(duì)象。另外對(duì)于變更管理其核心作用是通過(guò)變更管理減少變更對(duì)目標(biāo)的影響。迭代開(kāi)發(fā)和分階段開(kāi)發(fā)· 迭代開(kāi)發(fā)是以時(shí)間(迭代周期)來(lái)劃分，而分階段開(kāi)發(fā)是以任務(wù)完成來(lái)劃分。· 迭代周期一般比較短而分階段開(kāi)發(fā)的每個(gè)階段會(huì)比較長(zhǎng)。· 迭代不響應(yīng)變更，需要變更會(huì)轉(zhuǎn)入下次迭代；分階段開(kāi)發(fā)響應(yīng)變更導(dǎo)致混亂和計(jì)劃失效。在RUP的三要素中最后一個(gè)就是增量迭代，但是要注意到迭代是手段，增量是目標(biāo)。而且每一個(gè)迭代其本身就是一個(gè)微型的瀑布。迭代使目標(biāo)

24、更加容易分解和明確。估算是在項(xiàng)目管理中做項(xiàng)目計(jì)劃的基礎(chǔ)，不能因?yàn)楣浪悴粶?zhǔn)確而不去做估算和計(jì)劃，堅(jiān)持估算和檢查估算歷史數(shù)據(jù)的收集就不斷的糾正估算的經(jīng)驗(yàn)數(shù)據(jù)，而使估算準(zhǔn)確性得到提高。同時(shí)，估算的本質(zhì)是計(jì)算單元和復(fù)雜因子，首先要選擇好相應(yīng)的估算方法，如在需求早期往往并不適合用功能點(diǎn)法進(jìn)行估算；其次就是要識(shí)別計(jì)算單元，然后再確定具體的復(fù)雜度。· 估算是手段，估算需要在執(zhí)行過(guò)程中多次調(diào)整。· 估算應(yīng)該是基于權(quán)重的，比如我們用的根據(jù)規(guī)模到工作量的方法，比如要考慮人員效率的影響。· 在估算后可以根據(jù)關(guān)鍵用例來(lái)確定第一個(gè)迭代周期的長(zhǎng)度。需求變更是無(wú)法避免的，但是我們要盡量減少和控

25、制變更帶來(lái)的影響。需求變更是需求管理的一個(gè)核心內(nèi)容，有了需求變更自然會(huì)涉及到需求基線和配置管理的內(nèi)容。例如我們可以講對(duì)于已經(jīng)基線的配置項(xiàng)要修改都必須要走變更流程等。對(duì)于需求變更主要有以下重點(diǎn)：· 是控制變更而不是避免變更。· 控制變更的目的是減少變更的影響，客戶要意識(shí)到變更是有成本的。· 需求團(tuán)隊(duì)的貢獻(xiàn)在于盡早標(biāo)識(shí)變更。· 需要建立統(tǒng)一的平臺(tái)來(lái)捕獲，管理和控制變更。目標(biāo)的尋找方法可以用GPOA方法：GOAL-Problem-Option-Answer。在確定項(xiàng)目目標(biāo)和范圍的時(shí)候，我們往往容易提出類似要建立一個(gè)先進(jìn)的信息系統(tǒng)一類的不清晰的目標(biāo)。而如何破解不

26、清晰的目標(biāo)？可以從兩個(gè)方面來(lái)考慮:內(nèi)部溯源(項(xiàng)目的原始發(fā)起人，溝通)；外部尋因(受到外部刺激)RUP中的問(wèn)題分析五步法:· 在問(wèn)題的定義上達(dá)成共識(shí)，問(wèn)題定義清楚往往問(wèn)題就解決了一半。· 要多為問(wèn)題背后的問(wèn)題，探求問(wèn)題的本質(zhì)和根源。(如魚(yú)骨圖+帕累托圖)。· 確定Stakeholders和用戶，高層，中層和操作層各自的價(jià)值和關(guān)注點(diǎn)是什么？· 定義解決方案系統(tǒng)的范圍-黑盒思維-主題域劃分-主題域內(nèi)的流程和請(qǐng)求· 確定解決方案的約束對(duì)于訪談這塊的案例和實(shí)戰(zhàn)都很好，暫時(shí)不展開(kāi)了，感覺(jué)還是有很多原來(lái)在訪談中沒(méi)有注意的內(nèi)容，特別是開(kāi)門點(diǎn)和訪談策略兩個(gè)方面。

27、具體綜述下高層訪談主要關(guān)注點(diǎn):開(kāi)門點(diǎn)：易于回答而且激發(fā)其興趣· 訪談策略：Review驗(yàn)證最后結(jié)果，問(wèn)題不要太大，連續(xù)，挖掘不夠有時(shí)候只聽(tīng)到一個(gè)問(wèn)題· 問(wèn)題類型和挖掘：上下文，問(wèn)題暴露后的分解，發(fā)展機(jī)會(huì)，約束· 其它策略：還應(yīng)該找哪些人做進(jìn)一步的交流用例是一種紀(jì)錄新系統(tǒng)或軟件更換時(shí)的需求的技術(shù)。每個(gè)用例包含一個(gè)系統(tǒng)在作業(yè)時(shí)與用戶或與其它系統(tǒng)之間交換信息的場(chǎng)景。一般用例避免使用術(shù)語(yǔ)，而盡量使用顧客、用戶或他們的專家的語(yǔ)言。一般用例由軟件開(kāi)發(fā)者和顧客一起寫成。用例之道：· 不是系統(tǒng)完成的動(dòng)作行為，而應(yīng)該是有價(jià)值的業(yè)務(wù)活動(dòng)的分解。· 用例是需求分析的新視角-業(yè)務(wù)視角。用例也可以是需求管理的基本單元。· 用例價(jià)值的測(cè)試包括兩方面，一是業(yè)