軟件項目范圍計劃——需求管理與任務分解

• 序言
• 一、軟件需求定義及層次
• • 1、定義
  • 2、層次
• 二、軟件需求管理過程
• • 1、管理過程
  • 2、需求獲取
  • 3、需求分析
  • 4、需求規格編寫
  • 5、需求驗證
  • 6、需求變更
  • • （1）需求變更管理的主要工作
    • （2）需求變更控制流程
• 三、軟件需求分析方法
• • 1、原型分析方法
  • 2、結構化分析法（基于數據流建模）
  • • （1）定義
    • （2）結構化分析方法的技術
  • 3、面向對象的用例分析法（基于UML建模）
  • • （1）定義
    • （2）UML需求視圖
  • 4、功能列表
  • • （1）圖例
    • （2）基于功能列表的實例
  • 5、敏捷分析法
• 四、任務分解
• • 1、任務分解定義
  • • （1）定義
    • （2）WBS和工作包
    • （3）WBS和工作包的區別
  • 2、任務分解形式
  • • （1）圖表形式的WBS（組織結構圖式）
    • （2）提綱式
  • 3、任務分解過程
  • • （1）五大步驟
    • （2）分解標準
    • （3）分解標準舉例闡述
    • （4）WBS字典
  • 4、任務分解方法
  • • （1）模板參照
    • （2）類比
    • （3）自頂向下
    • （4）自底向上
  • 5、任務分解結果
  • • （1）檢驗分解結果標準
    • （2）WBS任務分解建議
• 五、結束語
• 🛵專欄直通車

序言

在需求管理中，我們總會遇到各種各樣的問題。比如：①需求的隱含錯誤；②客戶不斷增加需求、變更需求；③……。往往這些需求就是導致我們項目失敗的根本原因?！?/p>

那接下來，我們先用一張圖來對項目失敗的原因進行分析。具體如下圖：

基于以上的原因分析，自然地，我們也就知道了軟件需求在軟件項目管理中不可撼動的地位。

那么在接下來的文章中，就來了解下軟件需求各方面的內容。

叮，開始學習吧~👏

一、軟件需求定義及層次

1、定義

指用戶對 軟件功能和性能 的要求。（用戶希望軟件能做什么事情，完成什么樣的功能，達到什么樣的性能）

2、層次

軟件需求的層次有以下三個方面的內容：

業務需求→用戶需求→功能需求

二、軟件需求管理過程

1、管理過程

軟件需求管理過程包含兩個方面的內容，分別是需求開發和需求管理。

需求開發的路徑是：需求獲取→需求分析→需求規格編寫→需求驗證；而需求管理指的是：需求變更。

下面我們將對以上這幾個概念進行一一解析。

2、需求獲取

首先我們要先分析用戶的要求，分析完成之后，那么我們就要去獲取這個用戶的要求，并讓軟件去實現它。隨之，軟件就得到了軟件需求。如下圖所示：

3、需求分析

需求分析是為最終用戶所看到的系統建立一個概念模型，是對需求的抽象描述。 如下圖所示：

4、需求規格編寫

需求分析工作完成的一個基本標志是形成了一份完整的、規范的需求規格說明書。

5、需求驗證

在確定了需求之后，我們需要進行以下驗證：

• 需求是正確的嗎？
• 需求是一致的嗎？
• 需求是完全的嗎？
• 需求是實際可行的嗎？
• 需求是必要的嗎？
• 需求是可檢驗的嗎？
• 需求是可跟蹤的嗎？
• 最后的簽字

6、需求變更

在軟件的某些周期，我們總會遇到需求變更的問題。那對于需求變更來說，主要需要了解以下內容。

（1）需求變更管理的主要工作

需求變更管理的主要工作有：

• 建立需求基線
• 確定需求變更控制過程
• 建立變更控制委員會 (SCCB)
• 進行需求變更影響分析
• 跟蹤所有受需求變更影響的工作產品
• 建立需求基準版本和需求控制版本文檔
• 維護需求變更的歷史記錄
• 跟蹤每項需求的狀態
• 衡量需求穩定性

（2）需求變更控制流程

需求變更的控制流程如下圖所示：

三、軟件需求分析方法

1、原型分析方法

原型分析方法需要經過三個步驟，分別是需求分析→原型方法→原型評價。如下圖所示：

2、結構化分析法（基于數據流建模）

（1）定義

• 20世紀70年發展起來的面向數據流的方法
• 是一種自頂向下逐步求精的分析方法
• 根據軟件內部數據傳遞、變換的關系進行分析的

（2）結構化分析方法的技術

• 數據流圖 (DFD)
• 數據字典 (DD)
• E-R 圖
• 系統流程圖

3、面向對象的用例分析法（基于UML建模）

（1）定義

• 基于面向對象的情景分析方法
• 從用戶角度出發考慮的功能需求
• 用例是系統向用戶提供一個有價值的結果的某項功能

（2）UML需求視圖

• 用例視圖 - Use case Diagram
• 順序圖 - Sequence Diagram
• 狀態圖 - State Diagram
• 活動圖 - Activity Diagram

4、功能列表

（1）圖例

功能列表法的圖例如下所示：

（2）基于功能列表的實例

現在，我們來看一個基于功能列表的實例。如下圖所示：

5、敏捷分析法

敏捷分析法包含以下三個部分，分別是：

• 用戶故事模板

  As a<type of user>, I want<some goal>, So that<some reason>.

  用戶故事常常寫在卡片上，然后將其部署到墻上，便于討論。

• 評價用戶故事

• 用戶故事迭代優先級

  第一組： ①must have;②should have;③could 第二組： have/want to have

四、任務分解

1、任務分解定義

（1）定義

• 任務分解指的是將一個項目分解為更多的工作細目或者子項目，使項目變得更小、更易管理、更易操作。

（2）WBS和工作包

• WBS ，即 Work Breakdown Structure ，表示任務分解結構。WBS 是任務分解的結果。
• 工作包，是 WBS 最低層次的可交付結果，是 WBS 的最小元素。

（3）WBS和工作包的區別

WBS 和工作包的區別如下：

• WBS 是對項目由粗到細的分解過程；
• WBS 是面向交互結果的；
• 同時，WBS 組織定義了整個項目范圍；
• 而工作包是 WBS 中最低層次的可交付成果（如下圖所示）；
• 且工作包應當由唯一主體負責。

2、任務分解形式

任務分解主要有兩種形式，分別為：

• 圖表形式（組織機構圖式）
• 提綱式

（1）圖表形式的WBS（組織結構圖式）

如下圖所示：

（2）提綱式

類似于下方這樣：

1 變化計數器1.1 比較兩個版本的程序1.1.11.1.21.1.31.2 找出修改后的程序中增加和刪除的代碼行1.2.11.2.21.3 統計修改后的程序中增加和刪除的代碼行數1.3.11.3.2

3、任務分解過程

（1）五大步驟

任務分解的過程要經過三個過程，輸入→分解→ WBS 。有以下步驟：

• 確認并分解項目的主要組成要素

• 確認分解標準

• 確認分解是否詳細

• 確認項目交付成果（可以編寫 WBS 字典 ）

• 驗證分解正確性

（2）分解標準

任務分解的過程有兩大標準，分別是：

• 分解標準應統一；
• 不能同時使用兩種標準進行分解。

（3）分解標準舉例闡述

第一種： 分解標準應統一

第二種： 不能同時使用兩種標準進行分解

（4）WBS字典

WBS 字典如下圖所示：

4、任務分解方法

任務分解有4種方法，分別是：

• 模板參照
• 類比
• 自頂向下
• 自底向上

（1）模板參照

如下圖所示：

（2）類比

• 有些項目在某種程度上具有相似性；
• 可以采用類似的 WBS 作為參考。

（3）自頂向下

如下圖所示：

（4）自底向上

如下圖所示：

5、任務分解結果

（1）檢驗分解結果標準

• 最底層要素是否是實現目標的充分必要條件；
• 最底層要素是否有重復的；
• 每個要素是否清晰完整定義；
• 最底層要素是否有定義清晰的責任人；
• 是否可以進行成本估算和進度安排。

（2）WBS任務分解建議

• 最低層是可控的和可管理的，但是不必要過細；
• 每個Work package 必須有一個提交物；
• 定義任務完成的標準；
• 有利于責任分配；
• 推薦任務分解到40小時以內。

五、結束語

上述文章中，我們講解了軟件項目范圍計劃中的需求管理和任務分解，從多個方面去剖析軟件需求分析。

到這里，本文的講解就結束啦！希望對大家有幫助~

🛵專欄直通車

軟件項目管理👉https://juejin.cn/column/7024826582841688077

總結

以上是生活随笔為你收集整理的「软件项目管理」软件项目范围计划——需求管理与任务分解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。