1.項目前期輸入

2.***步---了解項目背景

3.第二步---需求細化

4.第三步---根據需求做初步總體架構及技術架構

5.第四步---WBS分解

6.第五步---人員組織架構分析

7.項目前期輸出

1.項目前期輸入

該文章以一個簡單的辦公系統為例，由于辦公系統的業務各不相同，我隨便在網上找了一個做為示例(共3個模塊)

原始需求(原文檔，一點沒修改過)如下：

1)個人工具箱

站內信、消息提醒、個人文件、短信系統

2)考勤系統

上班簽到，值班簽到：排值班表，按值班表在值班中每個時段簽到(17:00-18:00、18:00-19:00、19:00-20:00 三個時段分別簽訂一次，滿三次 給予積分，少于兩次扣分)；簽到結果 領導查詢統計， 員工查詢個人記錄；評年度全勤；

3)工作日志

每人每天 逐項填寫當天工作記錄 和 明日工作計劃 ；填寫后提交所屬領導，所屬領導根據 計劃 和 完成情況 予以打分；

2.***步---了解項目背景

估計有不少朋友在接到需求都會直接細化需求吧？不過我在這里提醒，請不要忽略這一步，客戶才是最終給你錢的人。

幾年前博主曾經接到過兩個項目，一個是國企下面的下屬企業公司的企業型網站。另一個是一家小公司的含有業務的運營系統。企業網站大家都知道，是最基礎文章發布系統，幾張數據表、十來個欄目、十幾個頁面搞定。而含有業務的網站系統就不同了，如：活動啦，流程啦什么的。含有業務的系統工作量必然會比企業網站大很多。但***兩個網站的報價幾乎差不多。雖然都是賺點小錢，但兩個項目的利潤相差很大。為什么？項目的背景不同而以。如果當時還是按程序員的標準思維去老實的評估工作量，那么那個企業型的網站利潤會大打折扣。所以這一步對于下面的多個步驟都是一個重要的前置分析條件。對于不同的背景的公司會做出不同的需求分析含水量是不同的。

3.第二步---需求細化

客戶給出的需求是多么的凌亂和無理頭？我們需要把需求細化一下，并把思路搞清些

1)個人工具箱

站內信：員工間可以相互發送的，可以即時查看的文字或圖片的信息。

消息提醒：是發送消息的時候瀏覽器右下角彈出提示嗎？彈出時像msn一樣彈出幾秒就消失？還是一直持續？這里因為和客戶具體的業務需求不一樣，所以在此我們只假設和msn的一樣，收到消息的時候彈出對話框并在3秒后消失。
個人文件：個人文件是什么意思？這里也無法確定，此時我們假設他是站內信的一個部分，即：站內信發送的同時可以帶有附件。

短信系統：短信的業務也是根據需求而定，這里只是假設：根據站內信的重要級別，在收到站內信的時候，重要級別非常高的站內信向收到信息的用戶發送短信給予手機短信的提醒功能。

2)考勤系統

上班簽到，值班簽到：簽到？公司一般都會有考勤機或是指紋機，但對于我們的即將要開發的辦公系統來說，他只是一個對外開放的接口，工作量基本是一致的。

簽到時段 (17:00-18:00、18:00-19:00、19:00-20:00 三個時段分別簽訂一次)：簽到的要有時段的限制，上面開放了三個時段。

滿三次 給予積分，少于兩次扣分：（這里又引入了積分子系統和積分子系統的業務規則）只有每天都滿三次的簽到才給積分，否則不給積分或扣分。

簽到結果 領導查詢統計， 員工查詢個人記錄：領導可以根據每員工的個人考勤情況查看公司整體的考勤報表（這里又引入了報表子系統）員工可以查看個人的考勤詳細記錄。

評年度全勤：系統要支持可以查看到年度全勤的員工。

3)工作日志

每人每天 逐項填寫當天工作記錄 和 明日工作計劃：系統需要支持員工在每天下班前要填寫當天的工作記錄和對第二天的工作計劃。

填寫后提交所屬領導，所屬領導根據 計劃 和 完成情況 予以打分；這里又引出了審批流程子系統和組織機構子系統，領導可以查看他所管理的員工的工作情況和計劃，而且還可以給該員工打分。

4.第三步---根據需求做初步總體架構及技術架構

把需求轉換成子系統或模塊、必要的技術拆分

1)總體架構：把需求描述成業務子系統

網站訪問系統

我一般習慣把公眾訪問子系統獨立出來，因為在當前的技術發展程度下，一般的系統都會要求有“手機訪問子系統(安桌、Iphone、WinPhone)”、“網站訪問子系統(基于瀏覽器)”、“其他硬件機器訪問子系統(如：銀行的取款機，查詢機等)”。該系統主要負責與接收用戶數據，一般不處理業務(手機App除外)。

辦公管理子系統

辦公管理：主要處理業務數據，如：日志填寫、考勤記錄的查詢、工作日志的填寫與查看、審批工作等

運維管理：描述積分的查看和報表的形成等

系統管理：每個系統都會有這么一個模塊，用戶、權限、角色、流程定義等

外部系統針對有關聯的系統做數據或業務交互

2）技術架構：把需求描述到技術層面，把技術分析清楚，不管業務多么復雜一般這里只分析到3層就可以了。致于詳細的架構和設計可能是項確定合作意向以后要做的事。

5.第四步---WBS分解

把業務模塊和技術分析轉換成具體的工作量

Wbs分解一般會借助于外部應用軟件，個人比較喜歡Micorsoft的Project，當然在項目管理的集合中大部份人都會使用Project，功能強大模型多。此處只列出了必要的幾列。

由于只是舉例，這里做的有些粗糙，但意圖已表述明確。系統調研視企業背景而定，一般政府的項目都要有大量的人力物力投入在調研階段。

大的項目在其中每個階段都會再次細分，這里不在冗述。

6.第五步---人員組織架構分析

按工作量確定人力資源信息

根據技術架構和WBS容易得出我們需要什么的樣團隊去實施該項目，一般會用抽象程度很高的組織架構圖來表示

[[68928]]

人員組成：

領導組：項目經理1名

需求組：需求分析師人員1名

開發組：開發工程師2名。人員要求，2名.net 2年以上的開發人員開發基礎信息、至少其中一名會使用mvc和wcf

測試組：測試工程師1名

7.項目前期輸出

是時候匯總了，人力資源、成本即是我們在項目前期需要內容

該項目的成本，粗略估算為：2.35萬人民幣。人力成本是有地域性的，人月單價不同成本合算差異比較大。在實際過程中不同的單位會有不同的成本合算表格里面含有各種公式，這里就不列舉了。

三、后繼說明

這個例子只是寫項目初期的成本合算，隨著需求的細化各方面變動會非常大，但很多工作都是確定合作意見后的工作。具體情況具體確定吧，總之，但完成了這些步驟后，哪些地方可以壓縮，哪些地方可以細化，哪些工作水深，心里應該有底了。

原文鏈接：http://www.cnblogs.com/iamlilinfeng/archive/2013/04/01/2993918.html

【編輯推薦】