軟件項目如何進行需求分析

軟件項目如何進行需求分析

軟件項目如何進行需求分析?我們要圍繞兩個核心問題開展需求分

析：（1）應該了解什么？（2）通過什么方式去了解？

1 應該了解什么

那怕是天下最無能的市長或書記，都知道在作報告時要先從宏觀上講

一、二、三、四、五，再從細節上講A、B、C、D、E。需求分析不

象偵探推理那樣從蛛絲馬跡著手。應該先了解宏觀的問題，再了解細

節的問題，如圖4.1所示。

一個軟件系統（記為 S）的涉及面可能很廣，可以按不同的問題域（記

為D）分類，每個問題域對應于一個軟件子系統。

S = { D1，D2，D3，… Dn }

問題域Di 由若干個問題（記為P）組成，每個問題對應于子系統中

的一個軟構件。

Di = { P1，P2，P3，… Pm }

問題Pj有若干個行為（或功能，記為F），每個行為對應于軟構件中

的接口。

Pj = { F1，F2，F3，… Fk }

按圖4.1結構寫成的需求說明書，對于那些只想了解宏觀需求的領

導，和需要了解細節的技術員都合適。在寫需求說明書時還應該注意

兩個問題：

（1）最好為每個需求注釋“為什么”，這樣可讓程序員了解需求的本

質，以便選用最合適的技術來實現此需求。

（2）需求說明不可有二義性，更不能前后相矛盾。如果有二義性或

前后相矛盾，則要重新分析此需求。

2 通過什么方式去了解

了解需求的方式有好幾種：

（1）直接與客戶交談。如果分析人員生有足球評論員的那張“大嘴”，

就非常容易侃出需求。

（2）有些需求客戶講不清楚，分析人員又猜不透，這時就要請教行

家。有些高手真的很厲害，你還沒有開始問，他就能講出前因后果。

讓你感到“聽君一席言，勝讀十年書。”

（3）有很多需求可能客戶與分析人員想都沒有想過，或者想得太幼

稚。要經常分析優秀的和蹩腳的同類軟件，看到了優點就盡量吸取，

看到了缺點就引以為戒。前人既然付了學費，后人就不要拒絕坐享其

成。

軟件工程之需求分析過程介紹

軟件需求工程過程(SREP)，本文簡要地列舉并說明了在整個軟件需求

工程的過程中的工作職責要點。

一、 開始

1. 項目經理根據項目特點，指定對過程表格的具體要求；

2. 項目經理制訂項目的標準，包括：DTS(缺陷類型)、TRA(風險類

型)、TRS(需求類型)等，在過程表格中按標準引用.

二、 計劃

1. 計劃經理估算需求開發時間；

2. 計劃經理完成：SPT(進度計劃)、TPT(任務計劃)，將計劃數據錄

入PDS(項目計劃摘要).

三、 需求獲取

1. 軟件需求工程師搜集系統概要信息，填寫REQ(需求獲取概貌)；

2. 軟件需求工程師搜集用戶需求，分類并清晰地把需求寫入REA(需

求獲取/分析)、RES(需求獲取情節)、UIR(用戶交互需求)；

3. 檢查需求獲取過程，并填寫REC(需求獲取檢查)；

4. 如果檢查不通過，從1.重頭開始過程；

5. 軟件需求工程師填寫TRL(時間記錄日志)、PIP(過程改進建議)；

6. 計劃經理整理本階段數據，錄入SPT、TPT.

四、 需求分析

1. 軟件需求工程師進行需求分析，建立分析模型，數據字典及項目

詞匯表，完成REA（分析模型的具體要求，請分別參見結構化分析

和面向對象分析的具體作業指導書）；

2. 軟件需求工程師將發現的需求的沖突、交迭、冗余或矛盾，記入

NCR；

3. 檢查需求分析，完成RAC(需求分析檢查)；

4. 如果檢查不通過，從1重頭開始過程；

5. 軟件需求工程師填寫TRL、PIP；

6. 計劃經理整理數據，錄入TPT、SPT.

五、 協商

1. 軟件需求工程師利用NCR，與風險承擔者協商解決需求分析中發

現的問題，將決議錄入NCR；

2. 軟件需求工程師根據決議，修改REA等相關文檔；

3. 如果有新的需求引入，需要重新進行需求分析階段；

4. 軟件需求工程師填寫TRL、PIP；

5. 計劃經理整理數據，錄入TPT、SPT.

六、 需求評審

1. 評審小組負責人擬定檢查清單，為成員分派檢查任務，制訂評審

日程表；

2. 評審員各自評審分派的內容，將發現的問題錄入DRL(缺陷記錄日

志)；

3. 評審小組負責人組織評審會議，各小組成員提交DRL并討論；

4. 評審小組以IRF形式提交檢查報表；

5. 軟件需求工程師根據IRF修訂相關文檔；

6. 計劃經理整理數據，錄入TPT、SPT。

七、 需求文檔編寫

1. 軟件需求工程師綜合考慮功能需求和非功能需求，編寫《軟件需

求說明書》

《軟件需求說明書》的編寫格式與要求，請參見具體的作業指導書。

2. 利用RDC檢查《軟件需求說明書》是否全面、正確并可執行；

3. 如果檢查不通過，從1重頭開始過程；

4. 軟件需求工程師填寫TRL、PIP；

5. 計劃經理整理數據，錄入TPT、SPT。

八、 需求確認

1. 評審小組，對需求進行確認：

l 確認每一個需求及相互關系；

l 需求的總體質量達到標準。

將結果寫到RVC。

2. 軟件需求工程師根據RVC，修訂需求文檔，并最終通過；

3. 軟件工程師為每一個需求設計測試用例，并錄入TRF；

4. 相關人員填寫TRL、PIP；

5. 計劃經理整理數據，錄入TPT、SPT。

九、 配置管理

1. RD(需求文檔)成為基線后，即納入到配置管理；

2. 如果需要對基線RD(需求文檔)進行修改，填寫CCP；

3. 配置管理人員征求需求開發小組和其他相關人員(風險承擔者)關

于CCP的意見；

4. 如果所有人員通過CCP，則將需求文檔的配置管理取出，并填寫

CCF；

如果否決需求，則填寫RRF；

5. 軟件需求工程師修改RD以適應新的需求 (可能包括REA等)；

軟件需求調研中的5W+1H定律

/news/newstopic/22/

2005.06.28 來自：mypm 泓崢蕭瑟

對于軟件的需求調研活動，雖然曾經寫過三篇相關的需

求管理文章，出發角度是從整體的需求管理過程考慮；在引入

CMM（二）需求管理KPA活動的基礎上，列舉了如何進行需

求調研前的需求管理計劃活動；在失敗的項目中，找出規范和

管理軟件需求過程的關健點及需求關聯的模型架構（這些可以

參考以前寫過的《CMM 需求管理實踐經驗記錄談》、《從CMM

角度考慮需求管理計劃》、《如何用CRC模型來確定需求》）。

一直以來，感覺自己在經過幾個項目試驗的基礎上對于軟件的

需求管理應該是有一定的基礎和經驗了，然而在最近參與的一

個大型項目過程中，在新加坡項目經理的引導與幫助下，對于

軟件需求調研又有了更深一層的體會和認識；總結出需求調研

中的5W+1H定律，在此把自己的一些過程和經驗描述出來，

希望能與各同仁一起分享與討論。

項目背景：

一個中型的企業信息化項目，其中乙方的項目經理是一個擁有

PMP證書的資深項目管理人員。甲方的項目經理是一個有著豐

富項目實施和管理經驗的新加坡項目管理人員。（在這里需要

補充的時，在調研產生沖突過程中，外籍人員如何用自己的經

驗和技巧，讓乙方完全可以接收）

項目成員：

甲方：外包項目經理、外包項目管理人員

乙方：項目經理、系統分析員、界面制作人員

工作內容：

項目需求階段的活動，對于系統的需求，甲乙雙方與最終用戶

能達成一致，甲方作為外包管理者，主要是對乙方項目組的項

目進度、項目階段成果進行跟蹤與驗收，以保證項目在預期的

時間內完成預期的工作任務。

過程描述：

項目啟動后，乙方的項目經理列了一份詳細的需求調研時間表、

調研階段成果目錄清單、界面成果等的計劃內容，可以用一個

“贊” 字來形容；從計劃上看，乙方的項目經理計劃真的是完美

無缺；在與用戶進行業務需求調研的活動中，乙方不僅記錄下

目前用戶現有的業務流程，包括目前流程的局限性，流程的執

行性等方面，還為用戶進行了將來系統流程的規劃，的確是一

個不錯的開始?？墒窃谝曳教峤黄潆A段的需求分析文檔和界面

時，卻發現二者存在了種種的沖突和矛盾，我們無法將需求分

析文檔與界面結合在一起。此時，乙方的項目經理解釋是因為

文檔比界面細，所以二者存在一些理解上的差異。而我們甲方

卻總覺得有些不太對勁，但因為同樣存在著對用戶流程細節的

不熟悉，所以我們也提不出具體的問題，直到有一天，跟著乙

方一起做用戶的需求活動后，從乙方項目經理的提問方面，我

們終于明白為什么他們會做出這樣的文檔和界面。

首先，乙方項目經理對用戶的提問是沒有序列的，我們所謂的

序列就是項目經理的邏輯是否清晰，除了問及目前的流程外，

最重要的引入項目（即新的軟件系統）的目的，所需達到的效

果，可以對用戶輔助的東東，而這些乙方的項目經理一字未提

與問，只記錄用戶所說的過程、局限和要求。這樣，乙方項目

經理在分析與規劃系統的需求時，就沒有一個明確的目的性和

方向性，這里就要引入第一個W定律---WHY定律。WHY就

是為什么用戶要引入系統，引入新的信息系統對用戶有什么幫

助，在總體工作效能上如何實現一個最終的結果？WHY定律是

要求在需求開始時，項目經理就應該明確的，這個項目是為了

改進用戶工作效率；提高部門間的協作機制；加快對客戶反應

的體系服務；提升企業的競爭力等等。有了這么一個WHY引

入思想，項目經理就可以理清用戶最終要的是可以提供給他們

什么樣的系統，在系統的定位和建立上，就有一個明確地最終

目標。

其次，有了一個總體的目標性，從各業務流程的要求入手，引

入第二個W定律---WHAT定律，WHAT則是這個系統要做什

么？實現什么？就是乙方項目經理提出的各業務流程問題、流

程局限性問題、系統要解決的問題等，在這個WHAT的基礎上，

把系統劃分成各功能模塊，逐步弄清模塊流程需求、功能需求、

結構需求。引入WHAT定律可以讓我們了解到系統的初步需

求。

再次，引入第三、四、五個定律---WHO、WHEN、WHERE定

律，這個階段其實就是需求細化階段，在WHAT定律的基礎上，

細分系統的用戶需求：分析什么人，在什么時間，什么階段可

以或必須操作這個功能，結合前面的WHAT定律，理清系統的

流程階段劃分，記錄并分析系統功能實現的細節，在這個階段

就可以產生系統需求的用例圖（U Ca），作為下階段設計

的依據。

最后，就是所謂的1H定律---HOW定律，就是怎樣實現系統了，

在前面的WHY、WHAT、WHO、WHEN、WHERE基礎上，

我們已經搭建了一個非常好的系統需求基礎框架，如何在這些

用戶需求的基礎上，分析系統的需求，如何進行需求規格的分

析與下階段的設計、實現工作，就是HOW TO ACCOMPLISH

THE SYSTEM了。

在需求階段引入這5W+1H的定律，在一定程度上保證了系統

需求的準確性，也使得項目經理或需求分析人員可以非常有序

的有條理的開展需求挖掘和調研活動，這樣的安排用戶在配合

上也非常清晰，知道如何與項目人員配合。其后，在我們的建

議下，乙方改進了工作方式，理清了一些工作序列，不過在最

終文檔的提交上，乙方的項目經理為了迎合我們的需求，一直

對需求文檔的格式與內容進行修改，沒有保持需求分析中應該

有的從粗到細的階層分析，也導致其需求分析中的不確定性因

素較多，后期的設計工作展開不順，這些算后話，希望能在以

后的外包管理方面，就存在的這些問題進行其它的分析和討論。

軟件需求說明書

1． 引言

1.1 項目名稱

1.2 項目背景和內容概要

（項目的委托單位、開發單位、主管部門、與其它項目的關系，與其

他機構的關系等）

1.3 相關資料、縮略語、定義

（相關項目計劃、合同及上級機關批文，引用的文件、采用的標準等）

（縮寫詞和名詞定義）

2. 任務概述

2.1 目標

（項目的開發目標和應用目標。如果是其他系統的一部分，則說明其

關系）

2.2 范圍

（包含的業務，不包含的業務）

2.3 假定條件與約束限制

（盡量列出開展本項目的假定和約束，例如：經費限制，開發期限，

設備條件，用戶現

場環境準備等）

3．業務流程

4．數據描述

4.1 原始數據描述

a. 靜態數據

b. 動態數據

4.2 數據流向圖

4.3 數據概念模型和描述

5．功能需求

5.1 功能描述

6．界面要求

6．1報表格式

6．2圖形要求

6．3輸入輸出要求

7．接口要求

(描述與本系統相連的系統的接口的數據格式，數據交換協議，接口

功能等)

8．性能需求

8．1數據精確度

（例如，數據內部精度，外部顯示精度）

8． 2數據量

8． 3時間特性要求

（根據所開發系統的特點，規定系統對時間的特性的要求。例如：

系統響應時間、界面更新處理時間、數據轉換與傳輸時間）

9． 運行環境需求

9．1網絡和硬件設備平臺

（網絡拓撲圖及設備類型描述）

操作系統平臺

數據庫系統平臺

10.1編程工具

10.2其它支撐軟件

11． 其它專門需求

11.1安裝和操作

11.2安全保密

11.3維護服務

ITSM項目需求分析的四個關鍵步驟

CA公司技術經理 侯繼濤

ITSM（IT服務管理）由于切中如何整合信息科技投入與業務需求整

合這一頑疾，在國內正在擁有著越來越多的用戶，其理念在這些用戶

心目中越來越深入人心。但與此相對應的是，大部分用戶對于如何定

位該

類項目，如何進行恰當的項目分析工作，確保項目收益等，存在著

很多疑問：

如何建立ITIL概念與企業ITSM項目的對應？

需要推行什么樣的管理制度，與ITIL化的流程相對應？

如何建立一個自動化的ITSM工具平臺？需要外購還是自己開發？

如何選擇工具？

如何定義清楚我的業務需求和工具平臺需求？

這些疑問的存在是非常正常的，也只有在項目需求分析階段更好地解

決這些問題，才能正確的設定企業ITSM項目目標，更好地制定項目

規劃，從而確保項目的成功。

1、ITSM需求分析第一步，確定流程實施的優先順序

ITSM項目，需要重點參考ITIL所定義的十個流程和一個功能點，這

些流程整合在一起，可以幫助企業更好地管理IT服務。但是，推廣

任何一個流程都需要一定的代價和時間，這些流程也不一定符合每個

企業的文化，因此，第一個要解決的問題是，從哪個或那幾個流程開

始呢？

根據CA公司近幾年的實踐經驗，企業可從如下幾個方面來確定流程

實施的優先順序：

流程成熟度－相對企業的需求，哪個或哪幾個流程是最迫切需要改進

的？

投資回報率－根據目前的需求和企業的文化，哪個或哪幾個流程可以

取得較大的投資回報？

痛苦點－IT部門內部的最大困擾是什么？哪個或哪幾個流程可以幫

助改進它們？

組織架構－是否存在傳統的井架式組織架構？這種組織架構可以通

過哪些流程進行改善？

部門劃分－目前的IT部門劃分是否合理？需要根據哪些流程進行改

進嗎？

資源和預算－目前IT部門擁有哪些資源和預算？能支撐哪些流程的

改進？

目前國內企業在實施ITSM項目時，大多從見效快、實施較容易的事

件管理和變更管理，這也符合國際上的普遍規律。但每個企業還是要

從自身出發，更好的審視企業的需求點。

2、ITSM需求分析第二步，確定流程定義的需求

流程定義需求分析，主要從兩個方面來考慮。

一方面，是確定流程定義的六要素。

確定了實施哪些流程以后，就需要進一步關注這些流程的設計和實現

了。作為一個管理項目，流程的重組、優化是最重要的成果，所以要

更好地定義流程的描述和要求。ITIL中所定義的流程有六個要素，需

要在初步定義流程的輸入、輸出的基礎上，確定每個流程節點的六要

素。這些，都將是以后產品實施和制度定義的基礎。

另一方面，是根據管理報表的需求來進行適當的流程調整。流程的最

終目標是根據服務水平協議在合適的時間，提交符合質量要求的服

務，流程的定義首先要滿足該目標。但是，在某些情況下，要根據監

控和管理的需要，增加一些流程節點。這些流程節點的存在，主要是

為了取得某些管理數據。例如，如果我們希望得到一個故障類型統計

的報表，就需要增加一個流程節點，這個節點，就是指定特定的管理

人員，在關閉事件單時，重新定義事件類別。該節點的定義，可能不

是為了一個票單的快速解決，而主要是為了滿足管理的需要。

3、ITSM需求分析第三步，確定對工具平臺的需求

流程的優化、重組往往需要部署和實施一些ITSM工具平臺作為支撐。

這些工具平臺，應該完成什么樣的技術需求呢？這些技術需求對工具

的要求如何來分析呢？技術需求主要來自于兩個方面：一方面是需要

考慮面向流程的需求，需要分析哪些流程節點采用工具進行自動化，

哪些節點需要利用制度來保障實現；另一方面，需要考慮面向管理信

息的需求，即需要系統產生何種管理信息，采用何種展現方式等等。

一般意義來講，這些技術需求在工具平臺的實現，需要這些工具平臺

支持如下配置、定制能力：

配置－工具需提供具有友好界面的定義、配置能力

工作流－實現人與人之間的自動化

觸發器、通知、報告等－實現系統與人的自動化

數據交換－實現不同系統之間的自動化

輸入界面－實現人與系統的自動化

4、ITSM需求分析第四步，確定管理制度的制定和推廣計劃

作為典型的管理項目，工具的推廣和實施，必然伴隨著管理制度的制

定和推廣，這些管理制度將進一步細化管理流程，明確管理崗位和職

責。這些是項目成功的重要前提。一般來說，管理制度將明確如下內

容：

角色和職責－確定不同崗位的角色和職責

技能要求－對不同崗位有哪些方面的具體技能要求

培訓要求－需要提供培訓嗎？

管理方式－采用何種管理方式。

溝通方式－采用何種溝通方式。

通過如上四個步驟，企業可以初步勾勒出ITSM項目的框架，進一步

歸納出“軟”、“硬”兩方面的需求，可以說，ITSM項目已經成功了一大

半。

軟件外包流程

一個完整的軟件外包項目流程包括：需求分析、總體設計、

詳細設計、開發編程、測試分析、系統整合及現場支持。

1.需求分析：建立合作意向后，我們首先會對客戶要求有詳盡的

了解，準確知道客戶需求、客戶的商業模式和業務流程，并結合

自身的經驗，為客戶提出改進建議。

2.總體設計：在需求確定并獲得客戶認可后，由系統設計師進行

系統架構設計，并與客戶一起制定項目實施計劃。

3.詳細設計：由程序設計人員根據系統架構，真對不同模塊的功

能和規格進行詳細設計。

4.開發編程：由程序員根據詳細設計及計劃，進行軟件程序代碼

的編寫。

5.測試分析與系統整合：不同模塊的編程工作完成后，經過測試，

并進行系統的整合。

6.現場支持：軟件系統開發最終完成后，到客戶現場進行安裝、

調試、培訓。

7.系統運行支持：在系統投入運行后，我們可以為客戶進行長期

系統的維護，除了保證系統的正常運行外，還要根據客戶的業務

變化以及使用過程中發現的問題，對系統進行修改。