軟體專案管理 4.2.傳統需求建模方法

【公眾號「專案管理研究所」將會第一時間更新文章並分享《行業分析報告》】
歸檔於軟體專案管理初級學習路線
第四章軟體需求管理
《初級學習路線合集》

前言

大家好，這節我們學習軟體專案管理---傳統需求建模方法，接下來通過例子介紹主流建模方法，我們介紹：1.原型方法 2.基於資料流建模 3.基於UML建模。

原型方法是通過不斷地評價原型來確定需求的方法。

這是某入口網站的專案，那麼在需求分析階段，通過不斷地優化這個原型介面，來最終確定專案的需求，而且與使用者很容易進行交流，實踐中可以採用原型建模工具，例如等Axure設計工具。

資料流方法是結構化分析方法的主要方法。20世紀70年發展起來的面向資料流的方法，是一種自頂向下逐步求精的分析方法，根據軟體內部資料傳遞、變換的關係進行分析的。

資料流方法的主要技術有資料流圖（DFD），資料字典（DD），系統流程圖等等...

例如這是銀行取款過程，通過資料流來描述銀行取款的需求，這裡採用的是DFD圖進行描述的資料流由存摺開始進入系統，接受檢查，如果有問題就返回，否則繼續將提款的資訊記錄在系統中，處理付款資訊，付款給儲戶，完成了取款的過程。

那麼這個例子是學生資訊管理系統，那麼他體現了自頂向下逐步求精的資料流分析過程，那麼這是最頂層的資料流，資料流再往下需要進行合法性檢查，進入了各個功能的模組。

例如學生基本資訊模組，學生健康資訊模組，學生成績資訊模組，以及查詢模組等。

如果希望對DFD圖中的資料進行描述，還可以採用資料字典等工具來描述。我們這裡將學生基本資訊，學生健康資訊，學生成績資訊等進行了詳細的描述。

基於UML建模是基於物件導向的情景分析方法，從使用者角度出發考慮的功能需求，用例是系統向用戶提供一個有價值的結果的某項功能。

建模過程可以通過幾種UML檢視來描述，例如用例檢視，順序圖，狀態圖，活動圖等等。

基於UML建模步驟如下：
1.要識別出系統的角色既Actor。2.描述需要的Use case。3.實現用例檢視。4.必要的時候可以再通過順序檢視，活動檢視，狀態檢視等來進行描述。

進出口貿易的業務環節是很多的，涉及到配額與許可申請，詢價，報價，合同洽談，備貨（出口），信用證，商檢，報關，運輸，投保，付匯/結匯，核銷退稅（出口）等多個環節。

這個案例採用UML方法進行需求建模的，首先識別角色，識別出很多角色，包括保險，出口商，儲存，海關，檢查部門，進口商，貿易管理部門，稅務，銀行，運輸等等角色。

而角色之間也存在一定的關係。

我們再看角色需要的usecase，也就是需要的用例。最高層包括出口和進口，進出口貿易按照階段可分為合同簽訂，合同執行兩部分。

我們以出口貿易的一些業務為例來進行說明，合同簽訂階段涉及的角色是出口商，進口商，貿易管理部門。出口商和貿易管理部門進行出口配額申請，出口商和進口商進行合同洽談，因此產生了出口配額申請和合同洽談兩個usecase，那麼usecase的參與者是出口商，進口商，貿易管理部門。

合同執行階段主要是合同的履行過程，主要執行過程如下圖，涉及的角色也非常多，產生的usecase也較多。

上述給出的usecase如果不夠詳細，還需要進一步描述，例如出口配額申請的usecase對很多人來講是個黑盒子，不清楚其中功能，為了進一步描述其內部功能和相關資訊，有必要將這個黑盒子開啟，那麼這個黑盒子可以進一步通過計劃分配配額，招標配額兩個usecase來描述，我們可以看這個圖：

另外呢計劃分配配額用例對很多人來講仍然是個黑盒子，有必要進一步來描述內部的相關資訊。

那麼計劃分配配額描述出出口公司向省級的地區經貿委，外貿經貿部提交計劃分配配額申請，並通過稽核領取計劃分配配額的活動，我們可以看這個圖為計劃分配配額的順序圖。

我們也可以通過活動圖來進行展示，那麼這個圖就是計劃分配配額的活動圖。

那麼其他的用例圖以此類推，可以展開來說明，直到最後需求描述清楚為止。

總之呢我們這裡介紹了原型方法，資料流建模，UML建模等傳統的需求建模方法，當然還有其他的傳統需求建模方法，這裡就不一一介紹了。

到這裡，第四章第二節傳統需求建模方法就講解完畢！下一節介紹敏捷需求建模方法~

如果您覺得這篇文章有幫助到您的的話不妨點贊支援一下喲~~