需求實踐所面臨的問題

• 需求完整性需要諸多用戶的參與和確認(rèn)，而且用戶間需求本身也存在沖突的可能，因此需求更加強(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ī)則，流程和模式來確定。優(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背后的需求場景和背后的問題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ì)動作就是分解，抽象和消除歧義。而對于需求分析的本質(zhì)線索則是人，事(流程)，物(數(shù)據(jù))和接口。因此需求分析不能完全等同于建模型。分析是本質(zhì)，建模僅僅是手段。

需求捕獲

需求捕獲是一個不斷的探索過程。在需求捕獲中，溝通占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á)項目管理核心)

探求本源(問題背后的問題，引入了《你的燈亮著嗎》，講到了沒有荒唐需求，只有荒唐的解決方案)

需求訪談是捕獲中的一個重要內(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è)或組織還需要根據(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)容來決定我們需要什么樣的需求模板和格式。

需求驗證是一種質(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)的跟蹤。在這個過程中基線是迭代開發(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)更加容易分解和明確。

估算是在項目管理中做項目計劃的基礎(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)鍵用例來確定第一個迭代周期的長度。

需求變更是無法避免的，但是我們要盡量減少和控制變更帶來的影響。需求變更是需求管理的一個核心內(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)。而如何破解不清晰的目標(biāo)？可以從兩個方面來考慮:內(nèi)部溯源(項目的原始發(fā)起人，溝通)；外部尋因(受到外部刺激)

RUP中的問題分析五步法:

• 在問題的定義上達(dá)成共識，問題定義清楚往往問題就解決了一半。
• 要多為問題背后的問題，探求問題的本質(zhì)和根源。(如魚骨圖+帕累托圖)。
• 確定Stakeholders和用戶，高層，中層和操作層各自的價值和關(guān)注點是什么？
• 定義解決方案系統(tǒng)的范圍-》黑盒思維-》主題域劃分-》主題域內(nèi)的流程和請求
• 確定解決方案的約束

對于訪談這塊的案例和實戰(zhàn)都很好，暫時不展開了，感覺還是有很多原來在訪談中沒有注意的內(nèi)容，特別是開門點和訪談策略兩個方面。具體綜述下高層訪談主要關(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è)務(wù)活動的原子性，一是Boss測試。
• 用例的粒度可能會取決于企業(yè)內(nèi)業(yè)務(wù)的分工。
• 對于用例的CRUD原則，更加重點的標(biāo)準(zhǔn)是是否是一系列隨機(jī)操作，是否由一個Actor完成。
• 用例需要避免功能分解，而應(yīng)該是用戶業(yè)務(wù)場景驅(qū)動。

在用例中常用的關(guān)系是擴(kuò)展(Extend)，包含(Include)和泛化。對于擴(kuò)展和包含區(qū)別如下：

• 擴(kuò)展：在某種條件是會被執(zhí)行，也可能不執(zhí)行。所以它有可能是一種可以劃到下個迭代的。
• 包含：包含的是子事件流，必然會調(diào)用到，而且是調(diào)用完后還會會到基用例。

對于獲取用例的方法主要有兩種，一種是自頂向下的流程派生法，跨職能流程圖和泳道就是參與者，其中的業(yè)務(wù)活動就是用例；另外一種就是自底向上的合并法，比如可以從條目化的用戶需求進(jìn)行合并。在第一種方法中派生用例的時候需要注意：

• 去除掉非EndUser的泳道。
• 對泳道進(jìn)行角色化的抽象。
• 判斷活動與系統(tǒng)是否有關(guān)系。

對于用例分析重點是事件和業(yè)務(wù)流程，而對于數(shù)據(jù)分析則重點是在業(yè)務(wù)數(shù)據(jù)上面。用例分析代替不了數(shù)據(jù)分析。數(shù)據(jù)分析常用的就是業(yè)務(wù)實體分析，通過數(shù)據(jù)分析可以建立系統(tǒng)的領(lǐng)域模型。數(shù)據(jù)分析的目標(biāo)就是理解業(yè)務(wù)領(lǐng)域中的業(yè)務(wù)術(shù)語和實體，包括語義關(guān)系，數(shù)量關(guān)系和主要內(nèi)容。數(shù)據(jù)分析的要點就是要識別出具體的業(yè)務(wù)實體，以及這些業(yè)務(wù)實體間的關(guān)系。在FDD中的領(lǐng)域建模是基于數(shù)據(jù)和行為的綜合分析，包括Together之父PeterCoad發(fā)明的菜色建模法。他將數(shù)據(jù)類分為了行為，參與角色，人事物，通用描述四個方面的內(nèi)容。

在用例模板中有幾個關(guān)鍵點，包括前置條件應(yīng)該是系統(tǒng)必須能夠檢測和驗證的。在用例描述中應(yīng)該拒絕太多的實現(xiàn)細(xì)節(jié)；用例本身無法展示很多界面交互，因此需求建模還應(yīng)該包括界面和交互建模的內(nèi)容。而對于報表等需求往往并不太適合用例的表達(dá)方式，可以根據(jù)企業(yè)情況來確定具體的報表類需求的描述方法。

在用例模板中還有干系人利益的內(nèi)容，在這里特別說明的是分析干系人利益可以幫助我們挖掘潛在的需求。雖然關(guān)系人不是Action事件的之間操作者，但是干系人的利益往往會影響到用例本身的需求。

轉(zhuǎn)載于:https://www.cnblogs.com/jackyzhou/archive/2009/05/27/1490635.html

總結(jié)

以上是生活随笔為你收集整理的软件需求最佳实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。