軟體需求最佳實踐(2)

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

• 思想：找到儘可能多的錯誤
• 方法：從非正式的開始，並逐漸形成文化
• 語言：從評價者轉化為建議者，強調協作者進來減少用你哪裡錯了，而多用我建議如何
• 人員：平等而且合適，減少不相關人員的參與
• 內容：不是全部而是最合適

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

迭代開發和分階段開發

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

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

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

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

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

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

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

RUP中的問題分析五步法:

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

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

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-563290/，如需轉載，請註明出處，否則將追究法律責任。