軟體需求最佳實踐(1)

這幾天在聽《軟體需求最佳實踐》作者徐鋒老師的軟體需求培訓，三天的課程，雖然原來對需求也關注了很多，自己也做過需求分析和開發的工作，但是這次培訓感覺收穫還是很多。三天的培訓先做個記錄，後續多個點還可以逐個展開，不斷的總結。

需求實踐所面臨的問題

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

需求分析的核心線索

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

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

需求定義輸出業務需求；需求捕獲輸出使用者需求；需求分析輸出軟體需求。需求分析的本質動作就是分解，抽象和消除歧義。而對於需求分析的本質線索則是人，事(流程)，物(資料)和介面。因此需求分析不能完全等同於建模型。分析是本質，建模僅僅是手段。

需求捕獲

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

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

探求本源(問題背後的問題，引入了《你的燈亮著嗎》，講到了沒有荒唐需求，只有荒唐的解決方案)
需求訪談是捕獲中的一個重要內容，這裡做一個概括總結：

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

需求規格說明書

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

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

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

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