需求分析的過程 需求分析階段的工作,可以分爲四個方面:
- 問題識別,
- 分析與綜合,
- 制訂規格說明,
- 評審.
問題識別:就是從系統角度來理解軟件,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標準.這些需求包括：
- 功能需求(做什麼),
- 性能需求(要達到什麼指標),
- 環境需求(如機型,操作系統等),
- 可靠性需求(不發生故障的概率）,
- 安全保密需求,
- 用戶界面需求,
- 資源使用需求(軟件運行是所需的內存,CPU等),
- 軟件成本消耗與開發進度需求,
預先估計以後系統可能達到的目標. 分析與綜合:逐步細化所有的軟件功能,找出系統各元素間的聯繫,接口特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型). 制訂規格說明書:即編制文檔,描述需求的文檔稱爲軟件需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交. 評審:對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過纔可進行下一階段的工作,否則重新進行需求分析
進行估算最精確的方法通常是建立一個將工作分解開的結構。可以把功能分解爲一級，二級，甚至更多級，這就需要在一個很高的層面描述工作，然後將該工作分解成更小的部分，直到每項活動都能夠被估算在80小時以內完成。（或假如項目比較小的話，就是40個小時。），這樣的話可以方便的在一週的工作總結中進行全方面的估計。這通常也需要花費很多時間和精力。但是，假如您很好地瞭解了這項工作，而且假如您能夠確定所需要的工作都已包括進了您的工作分解結構裏，那麼您就常常取得獲得一個精確的估算。
儘管任何的項目都是唯一的，但是有些項目同其他的項目很相象。使用以前的經驗這一技巧，您能夠找一找以前完成的類似項目，然後根據那個項目實際所需要的工作量來估算您當前的工作。這是個估算工作量的好方法，因爲他允許您使用以前的經驗。但是，他需要您以前有一個類似的項目，而且您必須具備對那個項目實際工作量的準確計算
即使您以前沒有進行過這樣的項目，其他人可能經歷過。找一找內部或外部的專家，看看他們是否能夠用其以往的經驗來指導您進行估算。例如，假如您必須部署一項新技術，您能夠找一個研究分析師，請他來幫助您估算所需工作量的水平。
項目管理分九個知識領域，分別是成本管理、質量管理、時間管理、範圍管理、人力資源管理、溝通管理、風險管理、採購管理和整體管理。
一個項目經理有多少時間是用來做溝通的工作的？應該不少於75%的時間是用來溝通的，所以項目管理將項目溝通管理單獨列了出來
下面講幾個名詞，如果你掌握了，一和人講項目管理你就拋出來，一定沒有人敢小看你。他們是WBS、甘特圖、基準（BASELINE）、項目干係人和關鍵路徑
- WBS是WORK BREAKDOWN STRUCTRE ，工作分解結構 WBS的定義還是很麻煩的，PM要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，並把WBS樹分解到二層三層。然後要花上一段時間讓成員 進行頭腦風暴式（BRAINING STORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標準。比如我們要結婚了，怎麼來分解呢無非是辦酒席，拍結婚照，，等等，這個在論壇上曾有人做了詳細的分解，大家都可以找到。我們說爲什麼WBS重要，而且大部分項目管理的諮詢都是針對WBS的諮詢因爲WBS做好了，以後工作就有了參考物，你就知道在不同的階段你應該幹什麼，完成到什麼進度。其實WBS的劃分是沒有規則的，主要的考慮角度是方便你做各類的統計工作，爲管理服務。同樣的一個項目其管理的側重點不同，WBS結構的劃分也可能是完全不同的。衡量劃分好壞的標準應該是看其是否滿足你管理的需要。
- 甘特圖也叫橫道圖等，很多名稱，我們說它是甘特在第一次世界大戰時開始使用，它就是在WBS的基礎上將WBS形象化老控制進度
- 對於基準，我象舉個例子。我們在沒有結婚之前，你腳踩幾隻船？我們說法律允許但道德不允許，但你可以腳踩N只船：）但當有一天你和你的朋友進了一個小黑屋子，然後帶了兩個蓋章的本本的時候，你還可以腳踩N只船嗎？我們說此時就不允許了，因爲你過了一個基準線（BASELINE）如果你還想腳踩N只船就需要重新回小黑屋子再蓋兩個章就可以了。那我們的項目要越軌怎麼辦，也就是項目變更？我們說對這樣的項目變更會影響各要素比如時間，成本，質量等我們應該統一由項目管理辦公室來進行控制，如果你要變更基準，必須要進行嚴格的限制。在客戶提出變更請求時，要建立變更申請登記表和變更申請 表，並讓客戶簽字。有時候一些不是非常關鍵的模塊PM也不至於一點不講情面，該賣面子的時候還是要賣，尤其是當着對方領導的面，千萬要 賣面子，但是也別賣的太乾脆，不要讓他們得到的太容易。 PM在變更管理中需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。如果一個項目進行過程中，比如現在的點心的3G項目，你發現如果再多花一點時間就可以編寫出對以後非常有用處的程序，但這個程序不在本項目範圍之內，你要不要做？對，我們說不能做，你可以重新起一個項目來做，但不能在這個項目裏做，這樣會是我們的項目成本超出，風險增加，而且和其他的項目缺少比對性和參照的價值。
- 有個有名的增量開發的名聲。只用20%的功能先滿足你80%的需求，其他的功能我可以開發升級的版本
- 項目干係人是什麼東東，誰給我舉一個例子？對，包括項目人員的老婆孩子，正確我們說有的項目需要的時間很緊張，如果你的項目成功了，但項目的程序員們都成了光棍，那項目還是非常失敗，至少不是喪心病狂的PM這麼想。合理解決項目干係人的衝突是個很累的問題，其中還包括你的只能經理們，你的董事長，你的客戶，等等，等等，有的說沒用？好，如果你的項目進展不下去，你該怎麼辦？對，開會，把你的高層找一個坐到會議室，不用他說話，只讓他曖昧的看着大家，大家一定會想，這個傢伙一定和領導有關係，我們還是好好的做這個項目，下一個項目再給他使拌子吧：）所以爲了不累死好好分析一下你的項目干係人吧我們上次講了一些基礎的知識，包括什麼是項目管理，項目管理包括什麼？