一、從故事談起
話說在上世紀50年代的一個人民公社的領導，找到我們軟件公司的項目經理，說我們有一個項目由你來做吧。
項目經理：“yes sir,你的需求是什麼？”
公社領導：我對公社養牛的傢伙很不滿意，他養的牛滿足不了我們放衛星的要求，我想要一頭吃的草比現在的牛少一半，乾的活比現在的牛多一倍的新牛（像不像你們的BOSS）； 我的需求很明確吧？
項目經理：是的是的；我現在可以寫出需求規格說明書了，然後你鑑上字，確定下來，我們就可以開工了。
公社領導：好，就這樣定了。
在需求分析與評審會上，我聽到了這個項目的初始需求，項目經理帶回來的是讓項目組開發出一頭新牛的生物工程項目。
如果按項目經理理解的需求，我們需求玩把DNA技術了，呵呵，反正軟件公司是萬能的嘛。
可事情真的是這樣？
其實真的不是這樣的，在項目經理與用戶的交流過程中用戶已經把實際需求顯性的說了出來，其實就是想如何利用第三方產品或工具提高生產效率。
如果項目經理能在需求分析過程中把握好用戶的產業特點，並能理解用戶的需求，那麼提出的解決方案就能真正解決用戶所存在的問題。
故事講起來很輕鬆，可我發現在實際工作中我們的項目經理們經常在做生物工程。
如何在工作中正確的識別需求是項目成功的基礎，這一點沒有人會反對，可做起來非常不容易。但是，科學的思維和方法論爲我們提供了捷徑。
所以這個解決方案很簡單，賣給他們幾臺拖拉機！
二．軟件需求分析的方法論
按照哲學觀點：方法正確，結果就一定正確。軟件需求分析應該在科學的方法論下指導完成的。什麼時候需求分析的科學的發放論呢？第一，全局理解業務；第二，抽象出業務模型，剔除功能實現細節；第三，研究核心業務需求，剔除次要業務需求。
軟件開發如建房子，和你如何裝修好無關係，你可以把牆敲了，你可以東牆補西牆，但與建築框架毫無關係。
在軟件開發中，界面是依賴於市場策略的，是依賴於業務系統的。而不是市場策略或者業務系統依賴界面。通過界面去思考和發現問題，是錯誤的路線，雖然，界面很形象，讓人一目瞭然，但是這樣的路線只能看到表面現象，而看不到實質。古人都說了：“道可道，非常當，名可名，非常名”。要看到問題的實質，要剔除直觀思維，剔除次要的因素，進入抽象思維，抽象出問題的核心，加以思考。
現代軟件的開發，需求分析是融入到開發環節中的，需求分析的成果之一，就是得出系統的業務模型（不是界面），藉助UML，業務模型直接就可以用於系統開發之中，把這些業務模型，直接轉化爲程序開發的代碼。
三，需求分析的幾個層次，
1，包含哪些實體。（實體關係滲透到了業務關係，所以在分析實體的時候，是基於業務，但是這個階段主要研究一些抽象的概念）
2，包含哪些功能或者說業務。（實體之間的關係如何建立，理論上，實體不依賴於業務）
3，界面，界面是最後的環節，僅僅是如何展現的問題，和實體，業務關係都不大。
（待續）