一、如何理解客戶業務和客戶需求？
原則1：由粗到細，從宏觀到微觀。
必須先從宏觀上了解客戶業務的全貌，再逐步深入細節。因為對于客戶的業務而言，我們是外行，如果從業務細節著手，很容易迷失方向，失去對業務核心的把握。同時要認識到，對于一個外行而言，我們對細節的深入也必定是有限的，不要指望自己能夠無窮的徹底的了解每一個細枝末節。一是不可能有無限的時間給你了解，二是沒有這個必要。因為未來的系統也不可能完全包辦所有業務的細節，還有很多事情是要靠客戶企業中這些具有專業技能的人來做的。
原則2：從不同層次的客戶代表那里收集不同層次的需求
對于企業高層決策者，他會給你描述一個系統的大的功能藍圖，如使企業具有整體報價能力，能更好的服務于高端客戶，能支持企業的重大業務決策等；對于企業各級管理者，他會給你講述他這一層的管理需求，如能更好的進行部門員工的業績考核、生成月度報表，更好的進行業務結算等；對于各級業務操作人員，他可能給你談及很多業務細節和操作細節……
在由上到下的逐級訪談中，對未來系統的描述就從一個大黑箱變成多個小黑箱，再變成透明、明確、詳細的系統定義的過程。
客戶業務調研和需求分析注定是一個不斷細化的過程，不要指望一次訪談/調研就能窮盡，也不要指望一次開發過程就能得到完全滿足客戶夢中期待的那套系統來。因為事實上很多需求是隱性的，連用戶都不清楚自己的需求。只有經過多次循環細化才可能把更多隱性的不斷挖掘、暴露出來。
二、如何具體開展需求調研工作？
在RUP中定義需求工作流程的工作目的如下：
1. 客戶和其他涉眾*在系統的工作內容方面達成并保持一致；
2. 使系統開發人員能夠更清楚地了解系統需求；
3. 定義系統邊界（限定）；
4. 為計劃迭代的技術內容提供基礎；
5. 為估算開發系統所需成本和時間提供基礎；
6. 定義系統的用戶界面，重點是用戶的需要和目標。
[涉眾]：英文stakeholder在RUP中的翻譯，在項目管理專著中往往譯為“干系人”，指所有與項目成敗有直接間接利益關系的個人或團體。在軟件項目中，往往包括企業的投資者、各級管理者、系統使用者、公司客戶，甚至包括企業的合作伙伴和競爭對手。
首先要做好業務調研。要盡早把已經收集到的業務資料熟悉起來，并在理解的基礎上提煉出問題列表，制成調查問卷。業務調研的要求是一定要沉下去，深入細致的了解客戶的業務流程，而不是急著趕工完成自己的需求工件設計和業務模型的建立。在了解各項業務流程的同時，與客戶一同深入分析業務的實現邏輯，并記錄下有關的實現案例信息，收集好、整理好、分析好有關的參考材料。
要把迭代的思想貫穿于從業務調研、需求分析，乃至項目實施的始終。所謂迭代，就是我們老老實實承認我們沒有能力一次就把事情做到盡善盡美。所以我們就先把一大部分有把握的地方做好，再在前面成功的基礎上不斷做好剩余的部分，最終就能無限接近于成功。設計編碼過程是如此，業務調研和需求分析也是如此。
企業系統的設計開發與軟件產品的設計開發有一個最大的不同，就是企業的需求肯定會變化，過去在變、調研的時候會變，系統實施后還會變。而我們要做的就是去適應這種變化。事實上，也正是因為我們采用的是面向對象的方法，才可能做到這一點。因為面向對象的方法認為：對象的基本屬性是客觀的和不會頻繁變化的，而對象間的關系則是可能不斷變化的。所以我們在業務調研和需求分析中也要認識到這一點，把不變的沉淀下來，把可變的靈活性和變化的自主性留給客戶。
各位都是做技術的，在業務調研和需求分析中難免會不由自主的考慮一些技術實現的問題。值得強調的是：需求與技術無關。在業務調研的時候要忠實的進行記錄，不要因為你個人對實現的疑慮而對用戶需求進行（過早的）修改和裁減。
要善于爭取客戶方各級人員（均是項目干系人，RUP中稱為涉眾）的支持。只有得到未來系統用戶的充分參與，項目才有可能最終取得成功。一套缺乏用戶參與的系統，即使最后做出來也是注定沒有人去用的。
一是要利用客戶企業的組織關系，爭取到上層的支持，由上到下進行調研配合；二是要會在調研過程中為目標用戶樹立有針對性的愿景，讓他認同愿景的同時主動、積極的支持你的調研過程。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。