為什麼做出來的軟體功能與客戶的實際期望相差太遠？
因為最初提出來的需求根本就不是「需求」！而僅僅是乙個想法，或者素材，或者這個功能是我們自己的想法而不是切合實際調查出來的想法。然而過於相信這種被產品經理、領導或者客戶「加工」過的需求，沒有去深入挖掘其背後隱藏的各涉眾的利益訴求，當然也就不會真正解決客戶的問題，最後導致的真實場景就是總抱怨需求頻繁變更。實際上，客戶的需求從來就沒有變過，只是我們一開始就沒有揣摩出來！
建民老師著重培養我們切合實際的思維，要求調查報告中的資料不要電子版，必須是真正採訪學院裡的學生作為虛擬客戶，使我們了解客戶的需求確實和我們想當然的不一樣，他們的需求更加貼合自身的工作需求，但是也會出現一些問題，每個人提出的需求不盡相同，很繁瑣，這時就需要我們自己去篩選出主要的功能。
「我發現團隊的開發效率不高，專案延期是常事；每個人的開發水平相差很大，有經驗的上手很快，沒有經驗的卻很難上路；bug總是改不完；自底向上的面向過程式思維設計；**的共享度不高，最有價值的**得不到沉澱，每次新人接手，很多是推倒重來……為什麼會出現這些問題？究其原因，還是開發人員的開發技能不足引起的。我遇到過很多人一接到需求，便開始做資料庫設計，往往忽略了或者不屑於做業務建模、分析和軟體本身的設計，以為做完資料庫設計就萬事大吉，特別是在網際網路公司表現較為突出。最終導致的結果就是**難以復用，互相看不懂別人寫的**，理解起來也很費勁，往往不如重寫一遍，所以出現上面這些問題也就在所難免。」
這段話充分說明了業務建模和分析的重要性，也是建民老師開設軟體需求和分析這門課的意義所在。老師經常說現在你們感覺碼**很難，但是將來你們工作時會發現碼**的時候是最幸福的也是很短暫的，你大部分時間都在寫各種文件，其中業務用例就是很重要的，如果沒有各種開發文件，那麼新人可能完全看不懂你寫的**，那麼很可能會推翻重寫，這樣**的共享度不高的同時還浪費了大量的時間。建民老師對這方面很嚴格，如果你寫的文件沒有達到要求會讓我們重新寫，並且請具有豐富專案經驗的老師為我們講解了標準文件的重要性及組成。
「中國剛改革開放時，出現了許多農民企業家，他們不用講管理，也不用講方法，只要膽子大一點，就能獲得成功。當時的市場幾乎空白，競爭非常少。農民企業家思路很簡單：人人都要吃飯，所以開飯館能夠賺錢。現在這樣的思路已經行不通了，市場競爭已經足夠激烈，十家新開張的飯館恐怕只有一家能撐下來，所以農民企業家已經很少見（連農民都越來越少了）。軟體開發行業也一樣，最開始的時候，會程式設計就了不得，思路也很簡單：每個公司都要做財務，所以開發財務軟體就能賺錢。現在呢？我們每想到乙個「點子」，可能有上千人同時在這樣想；我們要做乙個東西，可能發現市場上已經有許多類似的產品，你賣**，他就賣低價，你賣低價，他就乾脆開源。機會驅動、粗放經營的時代已經遠去，為了在激烈的競爭中獲得優勢，軟體開發組織需要從細節上提公升技能。」這時候設計和需求就顯得愈加重要。
軟體業上
利潤＝需求－設計
用例是收益面，物件是成本（高煥堂《use case入門與例項》）。在軟體開發中，需求工作致力於解決「產品好賣」的問題，設計工作致力於解決「降低成本」的問題。二者不能相互取代。你能低成本生產某種軟體產品，但不一定能保證它好賣。你的某種產品好賣，但如果生產成本太高，或者在市場需要新型號時，無法復用之前的元件，又要投入大量人力物力去重新製造，最終還是賺不了多少錢。如果需求和設計不分，利潤就會縮水。從需求直接對映設計，會導致功能分解，得到重複**。如果從設計出發來定義需求，會得到一大堆假的「需求」。
筆記 軟體方法 上冊 業務建模和需求
這本書其實買了有兩年了，還去參加了潘老師的公開課，限於能力，當時上課時領悟有限，最近因為scanning列印系統做 重構，要做 框架設計，想借助於uml，以嚴謹一些，就翻出了這本書，重新看了一遍。這本書其實並沒涉及到具體軟體架構設計要用的uml操作，誠如書名，側重於需求分析。以下是一些筆記，比較雜亂...
需求分析 軟體建模與分析閱讀筆記03
通過閱讀需求需求分析 軟體建模與分析，了解到在需求獲取中有很多困難時普遍存在的，了解這些困難對更好的了解需求分析獲取活動的複雜性有重要意義。需求獲取中常見的困難有使用者和開發人員的背景不同，立場不同。使用者和開發人員具有不同的詞匯集，所以在使用者傳遞乙個資訊時，開發人員可能連使用者表達資訊所使用的概...
《需求工程 軟體建模與分析》閱讀筆記03
一 需求工程過程概念介紹 一 概述 1.規格說明 需求工程過程是系統開發中需求開發活動的整合，它以使用者所面臨的業務問題為出發點進行分析和各種轉換，最終產生乙個能在使用者環境下解決使用者業務問題的系統方案，並將其文件化為明確的規格說明。2.生命週期 需求工程也有屬於它自己的生命週期模型，即存在針對需...