最近改行專做需求分析了，所以決定在需求領域再下一番功夫。由於問題域的不同，通常我們無法找到類似於設計模式的概念和方法來解決需求，但是有一些專家已經做了這方面的嘗試，如《分析模式》和《軟體需求模式》。前者對需求模式的啟發及後者對需求模式的總結都給sa帶來的巨大的幫助。按照需求的問題域，我們可以把需求分為以下幾個領域(from )：
fundamental:所採用的技術，標準，內部子系統的邊界及介面
information:資料的結構，型別及生命週期
data entity:資料儲存策略，包括事務、配置、資料實體
user function:使用者介面，報表，資料的獲取和更改，可訪問性
performance:響應時間，吞吐量，動態容量，靜態容量
flexibility:可擴充套件性，可測量性，便攜性，多元性
access control:認證與授權
commercial:計費及稅，可能涉及到多部門，多組織或者多貨幣
這是從另乙個角度來對需求歸類—概念角度。這種分類方式的好處是你可以從技術的角度來考慮如何來滿足需求，迅速決定解決方案。它提供了很好的思考方式，將問題域的需求迅速分解，形成不同層次的幾個小問題，大家都知道，10個小問題要比乙個大問題容易解決得多。仔細想想，你所涉及的需求，很難逃出上面幾個提到的領域。
實際上，各種方**、技術、工具正在試圖填平需求和設計之間的鴻溝，現實的情況是，最終還是要靠人來解決這些問題。關鍵問題又來了——尋找合適的人比什麼都重要。回到技術本身，需求的獲取與分析同樣重要，如果你無法得到真實的、本質的需求，再高超的分析技巧也解決不了使用者的根本問題，即便你真的可以解決使用者提出的一些問題。另乙個旁證就是一本書上提到的，不了解問題的本質就開始解決問題，也許會解決一時的問題，但最終還是會回到起點。這樣的例子太多了，尤其是在需求獲取階段，沒能真正理解使用者的需求，只是按使用者的理解去實現系統功能，最終的結果常常無法令人滿意，但沒人願意為此承擔責任。我們都知道需求引起的變更所花費的成本會在後續階段逐步放大，而且是呈數量級增長。所以需求的質量往往決定了產品/專案的成敗。
因此，我希望跟大家多交流交流關於需求的獲取和分析的心得。當然，我們的話題不僅限於此，可以涉及到軟體開發的各個領域。
探索需求6
接著第五章，此時已經有了乙個切入點的工作標題，在專案過程中，下乙個步驟是要問一些自由問題。第六章提出了乙個新概念 自由問題。自由提問讓你在設計過程中找到那些有關全域性的問題,這樣你就能夠進人正確的方向,而遠勝於孤立無援。由於他們對所有設計專案都是適用的,所以他們可以提前準備好並且在乙個接乙個的專案中...
探索需求21
第二十一章講了衡量滿意度。雖然我還沒有接觸過真正的使用者，但是這個也是未來一定會遇到的，保證使用者會對最終的設計感到滿意的最簡單和最可靠的方法就是始設計時測量他們的滿意度。沒有週期性的度量,很容易就造成一種後果,就如同美國人去到巴黎,並在三星級的餐館裡點乙份大餐。當他看到在 子裡小牛的圓滾滾的眼睛瞪...
探索需求20
第二十章講了技術複審。需要需求複審是因為沒有人能夠在穩定的基礎上製作沒有錯誤的求,同時也因為製作者是最不容易看到他們自己產品的錯誤的人。通過閱讀我了解到，無論何時你需要判斷需求文件是否的確做了它被期望做的工作，都應該使用需求複審。如何複審？1.有許多可以挑選的複審規則。都試一下,然後讓它們滿足你特別...