今天新項目過來，還沒有正式立項，只是大致做好了需求分析，只有一份材料《需求規格說明書》以及一位甲方的陪伴，以供對需求不懂時隨時提問。
面對着並不詳盡的
《需求規格說明書》，怎么設計我們這個系統，我心中一片困惑。
一看到這個業務需求，我還是本能的思考具體的技術實現，當然我不介意我這么做，因為我覺得這是必須的，這對於掌控整體的技術架構是非常有好處的。
但是我擔心的是，甲方以及項目經理需要一個過程，從業務需求一步步轉化為設計、代碼的過程，這個文檔是這個項目立項、拍板的支持，也有可能是中標的保證，這個過程該怎么做。
項目很多，如何“扒”一個新項目，面對一個未知的項目領域如何全面、有效的分析，並得出結論是急需掌握的，我意識到這也是成長中很重要的一步，這方面的人才也是公司急切需要的。
（另一主線是某些技術領域的專業性，兩手都要抓，兩手都要硬）
。
關鍵詞：項目管理, 項目立項,業務分析, Enterprise Architect, EA
摘要：今天新項目過來，
面對一個未知的項目領域，如何全面、有效的分析，如何
從業務需求一步步轉化為設計、代碼，
這個能力是急需掌握的，
下面以
一個簡單的“
數據管理和查詢項目”為示例，來介紹一個項目的具體業務分析流程，其中所有的圖如有引用，請標明來源。http://www.cnblogs.com/wgp13x/p/3824964.html
第一步：總結出業務目標。
從用戶的角度來考慮這個項目，體會這個項目能為用戶做到什么、帶來什么，拋卻是什么實現的，甚至都不需要用戶知道有計算機幫助他完成這些業務。
這里要總結成書面的形式，一條一條的列在文檔中。比如，
“
數據管理和查詢項目”可以提煉出這么一條業務目標：
要
實現多種類型數據的統一管理和查詢，為用戶提供方便快捷的數據查詢界面，提高用戶對人、事、物等數據的全面掌控能力；
第二步：划分業務邊界。
根據業務目標，來划分業務邊界，可以一條對一個邊界，也可以不對應的來，后期也可以適當調整。
在這一步中，還需要進行涉眾分析，從用戶的角度來看，我要跟哪些部門打交道，記錄下來。
第三步：進行業務分析。
進行業務分析，又分成三步，a、
針對某一業務邊界的
業務主角的確定，b、針對某一業務邊界的業務用例分析，c、
針對某一業務邊界的業務用例實現
。
a、
針對某一業務邊界的 業務主角的確定，業務主角是某一業務的發起者，也是承受者，也可能是使用者，就是有哪些用戶來使用這個項目。
b、
針對某一業務邊界的業務用例分析，將上面那些步驟中划分出的涉眾、業務主角，它們在某一業務執行過程中（可以在某一業務邊界中細分業務），是如何進行交流的，分析出來，畫出泳道圖。
下面是各個細分業務。
下面是查詢A系統的業務用例的
泳道圖，它講述了具體的交互流程。
到這里還是沒有涉及到計算機這類概念，仍然完全是從用戶的角度來考慮這些問題。
c、
針對某一業務邊界的業務用例實現，這里可以涉及計算機，計算機作為我們這個系統能為用戶做什么事情，以及如何跟 涉眾 、業務主角進行交互的，在這一步需要詳細列出。
下面是查詢A系統數據業務用例實現
的
泳道圖。
以上步驟下來，就能夠把所有的需求理解清楚了，我們這個項目能做什么，怎么跟外部交互的都能夠解釋的清清楚楚。
下面還有系統分析（系統用例實現）、概要設計、詳細設計等各個階段。
具體的扒項目的過程，請關注后續總結http://www.cnblogs.com/wgp13x/p/3838078.html。