通過閱讀軟體需求十步走的第一章，是對軟體需求的反思。思考是人類的天性，而反思是人類對過去認為正確的思考結果的一種質疑。軟體需求分析對於軟體至關重要，但從時間，人力，物力等的投放上不那麼重要。表現在時間上是大量的軟體開發專案中需求分析所花費的時間佔整個軟體開發專案時間，表現在人力資源投入上是很多時候從事需求分析的人員是搞不了軟體開發的人員去搞需求分析，表現在整個開發組織對需求分析事不重視，事後挑問題。
學會反思需要勇氣。
痛定思痛尋根源。「軟體危機」的解決之道是軟體工程，「需求危機」的解決之道是需求工程。手握「軟體工程」和「需求工程」兩把利劍，才能確保軟體專案的成功。軟體需求分析從業務需求開始，在使用者需求分析的基礎上進行的功能需求分析和非功能需求分析，軟體需求分析的工作成果是軟體需求規格說明書，，軟體需求規格書主要是由功能需求分析和非功能需求分析構成。
使用者不是神，使用者說的也不一定完整，準確。那麼需求分析人員會想當然的認為這就是來自客戶的完整準確需求，並且順理成章的在此基礎上展開需求分析工作。從表面看合乎邏輯，但實際上結果並不和邏輯，因為從使用者那裡或得的需求只是區域性而不是整體。我們必須要明白使用者的問題是什麼，使用者的目標是什麼，使用者的服務物件是什麼，使用者的技能水平是什麼樣的，使用者所說的事項的依據是什麼等資訊。
需求會發生變化，需求變化一是需求增加和減少的變化，二是需求由原先的變成現在的。變化是比完整性和準確性還讓軟體專案相關人員無比糾結的事，變化會帶來一系列文件，**的變化，工作量也會隨之增加。找到需求變化的根源，才能更好的控制需求的變化，才能為需求變化預留充足的餘量。需求變化的根源在於錯把客戶作為變化根源，而客戶服務的物件才是變化的根源。
自然語言的語義二義性一直被認為是是使得需求分析和軟體開發人員造成認識不一致的根本原因。自然語言的二義性可以通過**，圖形等方法加以補強，減少二義性。
軟體需求是天平，業務和軟體是這個天平上的兩個砝碼，要想平衡業務和技術就要進行整體思考。
《軟體需求十步走》閱讀筆記6
需求管理活動的目標就是確保需求業務活動能夠按照進度要求 質量要求 成本要求生產出高質量的由業務需求 使用者需求和系統需求構成的軟體需求規格說明。需求管理工作具體是借助由基線 版本 狀態 變更 跟蹤構成的需求約定這一抓手將需求業務活動整合起來並加以規範化。需求管理活動的目的是在客戶與軟體開發人員之間建...
《軟體需求十步走》閱讀筆記4
這一段時間主要閱讀了本書有關需求規劃的一些內容。需求規劃工作是面向 全業務 全資訊 全系統 採用分析綜合 歸納演繹的邏輯方法整理出組織與物件的業務邏輯模型，在此業務的邏輯模型基礎上進行系統的規劃。規劃需求引入到需求工程中後，與以往的需求分析有了很大的不同。不同之處在於 跳出以往將組織作為需求獲取的單...
《軟體需求十步走》閱讀筆記2
需求工程和軟體工程之間的關係界定沒有質的變化，只是將需求工程從軟體工程中剝離出來，將需求分析的分析工作和管理工作定義為需求工程。需求工程是面向全域性的 系統頂層的 著眼未來的工程，是將客戶業務作為內部研究物件，將軟體工程全過程作為外部研究物件的工程。需求工程是圓心，軟體工程是圓點。需求工程為軟體工程...