需求實踐所面臨的問題

• 需求完整性需要諸多用戶的參與和確認，而且用戶間需求本身也存在沖突的可能，因此需求更加強調角色和場景和劃分，一個所有用戶需要都能夠滿足的需求往往不是一個好需求。
• 需求過程缺乏用戶的參與，我們往往是技術驅動，習慣性的跳到模塊的劃分導致需求本身驗證困難，也導致了需求間耦合很緊，很難在后期組織有效的迭代開發。因此要考慮按流程和業務梳理需求。
• 需求無法實現也可能不是架構問題，而是需求本身不切實際。
• 用戶想要和真正需要是有區別的，沒有真正的識別需求優先級可能導致需求過量開發和需求鍍金。
• 需求優先級識別往往并不能完全依靠用戶，用戶往往只會把自己關注功能講優先級識別的很高，因此需求優先級識別應該是通過業務規則，流程和模式來確定。優先級識別方法(離主營業務的遠近，發生的頻率兩個方面來度量)
• 溝通失真，要認識到文檔僅僅是中介而不是全部，要通過即時的驗證來減少溝通失真。
• 需求捕獲和調研常見問題-用戶告訴你的是他轉化后的解決方案，而不是最原始的需求。
• 變更頻繁，但是要響應變化，比如通過對變更分類來識別哪些變更是可以通過復用和可配置解決的。
• 非功能性需求為有效的識別，僅僅是定性，而沒有通過定性->場景->定量的路線。

需求分析的核心線索

在原有的需求分析方法中，我們往往過多的關注How，而沒有關注What，或者關注了What而沒有關注What背后的需求場景和背后的問題Why。這都導致我們沒有進行很好的需求挖掘。需求分為業務需求，用戶需求和軟件需求三個層面。而我們在平時的需求分析中往往很容易直接跳到了軟件需求階段，而忽視了業務需求和業務建模。

• 業務需求 = 目標 + 范圍
• 目標的表達必須包括目標+優勢+度量+合理+可行，或者說SMART原則。同時在目標表達上可以考慮場景法，即問題是什么-》影響誰-》后果是什么-》解決方案優點是什么？
• 范圍表達的兩個重要方面是人和物，人包括干系人和最終用戶；物包括業務事件和管理控制點。

需求定義輸出業務需求；需求捕獲輸出用戶需求；需求分析輸出軟件需求。需求分析的本質動作就是分解，抽象和消除歧義。而對于需求分析的本質線索則是人，事(流程)，物(數據)和接口。因此需求分析不能完全等同于建模型。分析是本質，建模僅僅是手段。

需求捕獲

需求捕獲是一個不斷的探索過程。在需求捕獲中，溝通占40%，業務占30%，技術占30%。而對于溝通往往講究的并不是單純的技巧，而更多的是一種思維模式和順序的問題。在這里老師引入了思維模式的話題，也通過一個案例講解了溝通中順序的重要性，如先將解決方案再講具體場景和問題(類似于我上個ppt里面強調的結構化思維的一個重要原則即開門見山的逐層展開)。在溝通中講了三個可以借鑒的方法。

• 未知問題->已知問題
• 相對重要->相當次要(創造一種比較的環境給用戶)
• 關注點的轉換->(溝通也要洞察心理學)
• 隱喻(將了一個用漢字的贏字來表達項目管理核心)

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

需求訪談是捕獲中的一個重要內容，這里做一個概括總結：

• 首先要搞清楚你訪問的用戶本身的角色和特點，前期要收集足夠的資料，然后制定針對性問題。
• 應該是先訪談有了初步的聚焦后，再進行調查。
• 訪談的用戶分類包括(用戶特點，功能/流程，數據，非功能性和接口)
• 調查問卷設計諸多講究，如避免簡單的排序題，調查問卷中的C現象和D現象等，不展開。

需求規格說明書

業界關注需求有很多標準，如GB2006等，但是關于功能性需求方面都不能再細化展開，因此標準僅僅是一個展開。各個行業或組織還需要根據自身軟件項目特點對模板進行補充和完善。

需求分析過程應該是一個業務流程驅動的至上而下的過程。開始不應該一下轉入到一個具體的功能細節，而是應該先規劃目錄和打提綱，然后以流程為主線逐層分解和展開。在需求描述上可以是文字，也可以是圖形化的，也可以是一種形式化規格表達。

需求規格說明書模板的內容也可以逆向思維，如設計需求我們提供什么樣的需求對他們才是最有參考意義的。我們的需求調研不應該是通過模板格式來決定內容，再決定溝通。而是應該根據需要的溝通來決定內容，根據內容來決定我們需要什么樣的需求模板和格式。

需求驗證是一種質量活動，在這里要注意驗證和確認的區別，一般驗證活動主要方式就是Reivew，而Reivew根據正式程度又包括了審查，多人復審，單人復審等多種方式。需求驗證的五大要素包括：

思想：找到盡可能多的錯誤

方法：從非正式的開始，并逐漸形成文化

語言：從評價者轉化為建議者，強調協作者進來減少用你哪里錯了，而多用我建議如何

人員：平等而且合適，減少不相關人員的參與

內容：不是全部而是最合適

需求管理的三大內容是基線，變更和狀態跟蹤。其實基線和變更都屬于配置管理的需求跟蹤。需求跟蹤又包括了對需求-》設計-》測試整個需求鏈的跟蹤，同時也包括了對需求實現狀態的跟蹤。在這個過程中基線是迭代開發的基礎，但是迭代開發往往又是最難去規劃和打基線的。在這里的原因是我們是以整個文檔作為基線的對象，而不是以文檔中的條目化需求作為基線的對象。另外對于變更管理其核心作用是通過變更管理減少變更對目標的影響。

迭代開發和分階段開發

• 迭代開發是以時間(迭代周期)來劃分，而分階段開發是以任務完成來劃分。
• 迭代周期一般比較短而分階段開發的每個階段會比較長。
• 迭代不響應變更，需要變更會轉入下次迭代；分階段開發響應變更導致混亂和計劃失效。

在RUP的三要素中最后一個就是增量迭代，但是要注意到迭代是手段，增量是目標。而且每一個迭代其本身就是一個微型的瀑布。迭代使目標更加容易分解和明確。

估算是在項目管理中做項目計劃的基礎，不能因為估算不準確而不去做估算和計劃，堅持估算和檢查估算歷史數據的收集就不斷的糾正估算的經驗數據，而使估算準確性得到提高。同時，估算的本質是計算單元和復雜因子，首先要選擇好相應的估算方法，如在需求早期往往并不適合用功能點法進行估算；其次就是要識別計算單元，然后再確定具體的復雜度。

• 估算是手段，估算需要在執行過程中多次調整。
• 估算應該是基于權重的，比如我們用的根據規模到工作量的方法，比如要考慮人員效率的影響。
• 在估算后可以根據關鍵用例來確定第一個迭代周期的長度。

需求變更是無法避免的，但是我們要盡量減少和控制變更帶來的影響。需求變更是需求管理的一個核心內容，有了需求變更自然會涉及到需求基線和配置管理的內容。例如我們可以講對于已經基線的配置項要修改都必須要走變更流程等。對于需求變更主要有以下重點：

• 是控制變更而不是避免變更。
• 控制變更的目的是減少變更的影響，客戶要意識到變更是有成本的。
• 需求團隊的貢獻在于盡早標識變更。
• 需要建立統一的平臺來捕獲，管理和控制變更。

目標的尋找方法可以用GPOA方法：GOAL-Problem-Option-Answer。在確定項目目標和范圍的時候，我們往往容易提出類似要建立一個先進的信息系統一類的不清晰的目標。而如何破解不清晰的目標？可以從兩個方面來考慮:內部溯源(項目的原始發起人，溝通)；外部尋因(受到外部刺激)

RUP中的問題分析五步法:

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

對于訪談這塊的案例和實戰都很好，暫時不展開了，感覺還是有很多原來在訪談中沒有注意的內容，特別是開門點和訪談策略兩個方面。具體綜述下高層訪談主要關注點:

開門點：易于回答而且激發其興趣

• 訪談策略：Review驗證最后結果，問題不要太大，連續，挖掘不夠有時候只聽到一個問題
• 問題類型和挖掘：上下文，問題暴露后的分解，發展機會，約束
• 其它策略：還應該找哪些人做進一步的交流

用例是一種紀錄新系統或軟件更換時的需求的技術。每個用例包含一個系統在作業時與用戶或與其它系統之間交換信息的場景。一般用例避免使用術語，而盡量使用顧客、用戶或他們的專家的語言。一般用例由軟件開發者和顧客一起寫成。用例之道：

• 不是系統完成的動作行為，而應該是有價值的業務活動的分解。
• 用例是需求分析的新視角-》業務視角。用例也可以是需求管理的基本單元。
• 用例價值的測試包括兩方面，一是業務活動的原子性，一是Boss測試。
• 用例的粒度可能會取決于企業內業務的分工。
• 對于用例的CRUD原則，更加重點的標準是是否是一系列隨機操作，是否由一個Actor完成。
• 用例需要避免功能分解，而應該是用戶業務場景驅動。

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

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

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

• 去除掉非EndUser的泳道。
• 對泳道進行角色化的抽象。
• 判斷活動與系統是否有關系。

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

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

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

轉載于:https://www.cnblogs.com/jackyzhou/archive/2009/05/27/1490635.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。