“扒項目”的曆程一(業務分析)

標籤：style   blog   http   使用   資料   2014   

今天新項目過來，還沒有正式立項，只是大致做好了需求分析，只有一份材料《需求規格說明書》以及一位甲方的陪伴，以供對需求不懂時隨時提問。

面對著並不詳盡的《需求規格說明書》，怎麼設計我們這個系統，我心中一片困惑。一看到這個業務需求，我還是本能的思考具體的技術實現，當然我不介意我這麼做，因為我覺得這是必須的，這對於掌控整體的技術架構是非常有好處的。但是我擔心的是，甲方以及專案經理需要一個過程，從業務需求一步步轉化為設計、代碼的過程，這個文檔是這個項目立項、拍板的支援，也有可能是中標的保證，這個過程該怎麼做。項目很多，如何“扒”一個新項目，面對一個未知的項目領域如何全面、有效分析，並得出結論是急需掌握的，我意識到這也是成長中很重要的一步，這方面的人才也是公司急切需要的。（另一主線是某些技術領域的專業性，兩手都要抓，兩手都要硬）。 關鍵詞：專案管理, 項目立項,業務分析, 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/3824964.html