《軟件需求最佳實踐》——閱讀筆記一

《軟件需求最佳實踐》——閱讀筆記一

首先對SERU模型的四個字母再作一個說明         

S:Subject Area，表示子問題域，其核心思想是要經過業務來分解系統，儘可能保證業務獨立和低耦合。    

E:Event，表示業務事件，經過業務事件可以找到流程，經過流程可以找到不一樣場景和用例。    

R:Report，表示報表，統一處理查詢，分析和統計類需求。     

U:Use Case，表示用例，需求組織的最小單位，到了需求分析階段的重要活動和產出。

這本書首先從軟件需求實踐中出現的主要問題和困難入手，指出了改進的主要方向；而後逐一說明了需求定義、需求捕獲、需求分析與建模、編寫規約、需求驗證等需求開發活動的任務、要點和手段；並提出了一個可操做性強、易上手的SERU過程框架，可以幫助讀者清楚地瞭解整個過程，理解各階段的關鍵產物和產物之間的關係。

還對包括需求基線、變動管理、需求跟蹤在內的需求管理活動的操做要點進行了闡述，給出了具備很強實踐性的具體建議。

SERU過程框架模型將需求過程分解爲三個階段，第一個階段是需求定義，重點是主題域劃分和業務事件識別。第二個階段是瀝青需求框架和脈絡，重點是經過業務流程圖轉到具體的領域類圖和用例圖。到了第三個接團重點就是填充需求細節，包括用例的詳細編寫，屆滿和交互設計等。

CHAOS Report調查結果顯示：軟件項目成功因素的前三名：用戶的參與；執行層的支持和清晰的需求描述。失敗的前三名是：不完整的需求，缺少用戶參與和資源不足。

採用數聽說話是技術人員走向成熟的一個要點。

想讓用戶表明可以更好地參與到完整性評價中來，就必須採用「業務導向」的組織結構，而是不讓用戶將一大堆技術動做翻譯到本身的業務場景中去。

需求驗證本是需求質量關，其目標是暴露更多的錯誤，也就是說咱們要的不是簽字，而是指出潛在的問題與錯誤！

需求規格說明書應該採用業務導向的屬性層次結構來組織。樹形層次結構應該面向不一樣的層面：決策者（高層），事務管理層（中層），操做層（基層）將需求分紅不一樣的部分，讓合適的人驗證適當的部分，而後再彙總。

對於需求分析員而言，真正的專業主義是基於業務利益（解決問題，創造機會，提升管控力等）的溝通。

不切實際的用戶指望的緣由在於軟件的無形和成本的不透明。

到底誰纔是知道用戶最須要什麼功能的人呢？產品經理，開發人員仍是用戶表明？其實最瞭解用戶需求的是軟件自己。看訪問量！

優先級的劃分常常是拍腦殼的產物。

解決溝通失真的方案：1 文檔；2 Re-view. (緩解溝通失真的最有效的方法是及時複述.)

項目經理的需求控制：有些需求「表面上」是控制下去了，但卻在後面以「需求變動」的形式全回來了。

需求分析的本質在於業務分析，而非技術分析。方法：多問why.

有種低效的管理叫「打地鼠」，有種低質的醫術叫「頭痛醫頭，腳痛醫腳」，有種低級的觀點是「軟件項目失敗的關鍵在於項目管理技能不足。」

以「定性」的方法來描述非功能需求，實際上就是一種無效信息傳遞。

第一部分-原理模型與誤區      

需求定義階段強調了一個重點就是高屋建瓴和從頂向下的思路。當要作一個全新的軟件產品的時候，咱們首先確定是進行需求收集和調研，因此書裏面專門談到了需求捕獲的最佳實踐，包括用戶的訪談和調查，現場的觀摩等。同時也提出了相似任務卡片等很好的現場需求捕獲工具。爲何一開始要強調第一階段對系統的宏觀把握和高屋建瓴，由於在作一個全新的軟件產品的時候咱們很容易收集到大量用戶現有的流程，表單，組織架構等信息和資料，可是這樣很容易一次的陷入到需求細節中而對企業的業務沒有一個宏觀的把握。         主題域劃分+上下文圖，是需求定義階段的重要輸出。主題域劃分主要是從業務的視角來考慮子系統應該如何劃以下降業務自己的耦合，在書中也專門提到了主題域劃分的思考應該從組織結構爲線索，從分管領導找突破以及借鑑典型的業務職能區塊等。主題域劃分清楚了下一步重點就是要肯定主題域的範圍，天然引入了上下文關係圖，其核心就是要將主題域或子系統做爲一個黑盒來分析，搞清楚邊界和其於外部用戶的交互。經過理清楚上下文關係圖後第一階段的輸出基本就很容易明確了，即業務事件+報表需求。         在這裏我以爲重點要借鑑的就是從頂向下的系統思惟和分而治之，這是解決問題很重要方法。同時剛開始必定不要跳過這個階段而落入需求細節。主題域和業務事件是兩個重要概念，而這兩個概念核心又是業務場景。