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

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

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

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

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

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

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

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

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

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

10、戶的參與，我們往往是技術(shù)驅(qū)動，習(xí)慣性的跳到模塊的劃分導(dǎo)致需求本身驗證困難，也導(dǎo)致了需求間耦合很緊，很難在后期組織有效的迭代開發(fā)。因此要考慮按流程和業(yè)務(wù)梳理需求。· 需求無法實現(xiàn)也可能不是架構(gòu)問題，而是需求本身不切實際。· 用戶想要和真正需要是有區(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)近，發(fā)生的頻率兩個方面來度量)· 溝通失真，要認(rèn)識到文檔僅僅是中介而不是全部，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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