閱讀筆記：軟體需求十步走（二）

標籤：

 一個程式員最需要的就是反思，而往往反思是非常困難而且非常痛苦地一件事，因為你要打破自己以往的觀念和想法，從中找到自己的缺點進而改正。

需求問題是軟體開發過程中緊緊圍繞的一個巨大問題，乃至整本書都在圍繞著這個話題進行討論。能否獲得需求是軟體成敗的關鍵。

以往以來人們通過各種方法進行軟體的需求分析，如結構化分析方法，物件導向方法，面向問題領域分析方法等，其成果能通過case工具，uml工具來完成。其中uml工具將需求分析成

果自動化轉化成系統設計成果方面尤為突出，解決了長期困擾軟體開發中需求分析和系統設計之間失真的問題。在我們日常的學習中，uml模式圖也有為關鍵，大二上學期比較系統的

學習了uml工具，對其中的各類也有了比較簡單的瞭解，在如今王輝老師的課上，各種軟體的設計模式對應著相應的類圖，而能不能分析好畫好這些類圖，當時學習的uml起到了至關重要的作用，學習真是一環扣一環！而在用例的描述中，用例描述完整性和準確性不夠這是uml的一項缺點，還有項目的範圍和目標的定義是在用例工作開始前需要先完成的工作，uml並不支援，需要我們進行切入的探討與分析，在項目開始之前，如果不能找到一個確定的範圍，就好像有方枯地上打井，打到地也不一定能打出水來。

人們的學習就好像是在畫一格一格的圓，學習的越多，圓畫的越大，事情往往也會變得越來越難，但無論遇到什麼事情都需要有較好的心態去面對，不能被困難所打倒，也不能在困難面前過於自負，反而耽誤瞭解決問題的關鍵時期。人到不惑之年的時候當聽到有人說這件事很簡單時，第一直覺是這件事就不簡單。人們對做事的原則有個很經典胡總結：“複雜事情簡單做，簡單事情重複做，重複事情用心做。”這便是對心態的完美表述，人無禍而不立，樹無根而不生。

軟體的建設更需要軟體規格胡說明。

書中所言，往往軟體需求規格說明是軟體開發人員的寵兒，是軟體需求的核心，開發人員通過軟體需求規格說明來瞭解使用者想要什麼，想實現什麼；而實際上軟體需求規格說明並不是軟體需求的核心不是軟體需求工作的目標，真正的核心是業務需求，因為軟體分析從業務需求分析開始，在使用者需求分析的基礎上進行的功能需求分析的非功能需求分析，軟體需求分析的工作成果是軟體需求規格說明，而軟體需求規格說明主要是由功能需求分析和非功能需求構成。因此軟體需求規格說明是真正軟體需求的核心。

離開了業務，軟體什麼都不是；大部分人可能對此話嗤之以鼻，一般說的絕對的話往往是錯誤的，誠然我第一次聽到此句也是如此的心理，但仔細想來，如果一個軟體沒有業務需求，便會像無的之矢，茫茫乎不知所終，最後沉默在軟體的大潮裡。現實中大家多採用情境卡片，系統原型，使用案例圖，使用者需求文檔來擷取使用者需求，來讓使用者確定這是他想要的。從而確定自己的營運目標，不是說不可以，究其根來方法都是為目的來服務，只要找到所要追尋的目的多想些辦法，多採取些措施又未嘗不可。

形式邏輯的演繹方法可以用來解決需求的完整性問題，形式邏輯的論證方法可以用來解決需求的準確性問題。

在找尋業務根源過程中，常常會面臨各種各樣的變化，世界因為變化而精彩，而編程與軟體開發如果面臨各種各樣的變化，那程式員肯定會頭痛無比，哪怕多一點差別，程式的代碼可能就會多出幾百行。需求變化的根源往往在於客戶，客戶以為開發人員是萬能的，自己想像的程式員一定會給自己完成，正是由於單方面的不瞭解往往會產生許多分歧，耽誤開發的進程；客戶服務對象是變化的根源，明確雙方任務與能力，明確各自的初衷，往往會消除很多不便。

閱讀筆記：軟體需求十步走（二）