引用《走出軟體作坊》的話，在需求階段，從我們的設計模式、oo、軟體工程、虛擬介面、反射、持久化、框架中走出來。開發經理來承擔起客戶行業研究來：
1.客戶行業這個群體有多大？大中小規模各有多少家，各分布在什麼省？我們面對的最佳客戶是什麼規模什麼資訊化程度的？我們的次佳客戶是什麼規模什麼資訊化程度的？
2.我們的上層競爭對手、本層的競爭對手、下層競爭對手目前的產品怎麼樣？他們各自的優點是什麼？他們各自的缺點是什麼？我們應該突出的優點是什麼？我們的缺點是什麼？
3.客戶行業的過去5年，現在2年，未來3年的發展歷史和趨勢是什麼？他們面臨哪些挑戰和機遇？
4.我們現在所做的典型客戶，他們的組織結構，人員規模，每個崗位每日業務流程、每個崗位每日每週每月每季每年的異常處理業務流程，每個崗位每日每週每月季每年的輸入**，每個崗位每日每週每月季每年的常用資料查詢，每個崗位每日每週每月季每年的統計報表針對以上的了解，客戶面對未來挑戰和機遇，未來應該如何變更他們的崗位和職責和流程，盡量流程少，效率高，運轉快？
一、需求獲取
需求獲取是根據客戶的特點，採用某種方式盡可能多地獲取到業務的基本需求，這些需求是原生，未經過加工的，如有必要，用錄音筆進行錄音；
二、需求分析
2.1 拿到客戶的原始需求後，需要對需求進行分析，了解細節，左右推敲，整理出疑問點，並跟客戶進行諮詢，最終獲取最詳細的資料。客戶所能提供給你的只是他們想到的功能需求，很多問題並不在他們考慮的範圍之內，如果作為專案承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，自然需要更改，被看成了需求的更改。其實，都是缺乏分析所一手造成的。問題等到系統出來了才被發現，這樣的系統本身就是先天不足的了。
客戶需求只是軟體需求分析的一部分，雖然是比較重要的一部分，但也不要只是去記客戶的需求，而是要把客戶的需求進行分析；
2.2 客戶本身是不怎麼懂技術的，客戶只知道自己的業務需求，而在軟體設計時，是在把業務需求抽象到系統中實現的，把業務轉變為邏輯時，一切都應該符合邏輯的，但客戶的業務思想有時候在軟體系統實現時會有問題的，這就需要分析時分析出來的。少了分析，問題也會在後面的開發中暴露出來，到時可就更麻煩了。還有客戶的需求本身會有矛盾（這矛盾是指在邏輯角度來講），客戶本身是意識不到的，只有在分析設計時，才會分析出這裡的矛盾，而這些問題，如果在期初時，軟體負責人不分析，而是純粹的「聽從」客戶要求去做，當暴露這些問題時，你怪客戶也沒用。
2.3 專案需求分析報告，在了解客戶需求時，不要以為懂客戶了，一定要冷靜下來想一想，其實在表面的業務裡面可能包含著n多的細節，這些細節是需要你反問客戶的，只有當你提的問題越多，最終獲取的需求最具體，才能讓專案越順利。而且有很多問題，都是在你的反問中，客戶也才開始思考本來沒思考過的問題，客戶也會找到一種合理的需求給你，有人會覺得這樣了解客戶需求未免太麻煩了。至於一些在技術上會遇到問題的地方，也要告訴客戶，別以為到時候再說，客戶是不關心你的技術細節的，但你如果給他解釋的話，他也會試著理解的。客戶的需求本身是無休止，因為他們本身也在變，但當你期初的分析合理，後面的變動也將在邏輯上變動，相信代價已經不會那麼大了。這其實也體現了系統的擴充套件性。
2.4 需求分析，是乙個專案提出方和承擔方相互溝通的過程，一方是系統的使用者，一方是系統的製造者，在系統製造過程中，只有雙方相互配合，共同對系統進行設計才能最後達到使用的要求。客戶是業務上的熟悉者，對業務流程有非常清晰的了解，但是，對於軟體需求方面的描述是不了解的，他們所能提供的只是他們最終要達到的功能，但是，這其中包含的業務流程是非常複雜的。我們拿到客戶需求後，應該根據功能、流程進行初步的設計，構造出業務流程圖，再讓客戶進行評審，提出業務流程上不對的地方進行修改。這樣來回的交流，最終才能取得較全面的需求，並減少後期的修改。
2.5 從需求中，抽取業務中可能存在的變數與常量，並結合技術，對易變的因素進行設計與控制。
2.6 在分析需求過程中，從功能相關性、逆流程性來考慮會更全面。
謹記一點，需求是經常變動的，只有先做好需求的分析，了解業務以後的發展趨勢，做好具有拓展性的系統設計，才會給系統更大的擴充套件空間，從而在需求發生變化的時候可以更從容的修改。
2.7 尤其是針對於網際網路產品，後期有些需求變動是必然的，所以強制開發人員制訂規則庫，如會員買什麼產品，公升級成什麼會員，會員有哪些許可權，什麼功能可以有開關；
注：需求分析的維度可以從以下方面展開
業務角度：
1.畫業務流程圖(使用visio的水平跨職能流程圖)，來體現角色與職能的流程；
2.分析實體之間的關係，一vs多，一vs一，或 多vs多等關係，根據該特性來建立表結構。如果涉及多vs多，就要用中間表來實現；
3.在針對某事件進行分析時，用**來呈現，該事件在何狀態下，可以使某角色擁有可操作的許可權(職能)，在執行完操作後，事件的狀態又有何等變更；(rbac的角度設計業務)
4.哪些業務可能會存在變數，便於設計表結構時制訂規則表；
5.要習慣使用逆流程考慮問題；例如購買與退款，建立與取消等後相關資料項及狀態引起的變更；
6.用axure設計原型圖，把腦子裡設計的產品例項化；
7.相關性分析；
軟體角度：
1.軟體執行環境的限制；
2.設計工具的限制；
軟體需求分析
本章共分為四個部分，一軟體需求的任務和過程 二結構化分析方法 三，原型化方法四，動態分析方法。本章學習的要點是 1。了解軟體需求分析的目標和任務 2.了解軟體需求的獲得方法 3.掌握結構化的分析方法 4.了解需求規格說明和需求評審的主要內容。軟體需求分析的主要任務 深入描述軟體的功能和效能 確定軟體...
軟體需求分析
軟體需求分析所要做的工作是深入描述軟體的功能和效能，確定軟體設計的限制和軟體同其它系統元素的介面細節，定義軟體的其它有效性需求。進行需求分析時，應注意一切資訊與需求都是站在使用者的角度上。盡量避免分析員的主觀想象，並盡量將分析進度提交給使用者。在不進行直接指導的前提下，讓使用者進行檢查與評價。從而達...
軟體需求分析
軟體需求分析是把軟體計畫期間建立的 軟體可行性分析 求精和細化，分析各種可能的解法，並且分配給各個軟體元素 軟體需求分析的任務 深入描述軟體的功能和i效能 確定軟體設計的約束和軟體 同其他系統元素的介面細節 定義軟體的其他有效性需求 任務 從現有的模型中匯出目標系統的邏輯模型，解決目標系統的 做什麼...