文章有點(diǎn)長(zhǎng)，字字是干貨，建議收藏，需要文檔可評(píng)論“需求開(kāi)發(fā)標(biāo)準(zhǔn)化文檔”，覺(jué)得還不錯(cuò)的可以用發(fā)財(cái)?shù)男∈贮c(diǎn)個(gè)免費(fèi)的關(guān)注，小編更加有動(dòng)力整理分享。

目錄

1 目的

定義需求開(kāi)發(fā)與管理過(guò)程，為需求開(kāi)發(fā)及跟蹤提供有效的流程和方法。

2 適用范圍

2.1 機(jī)構(gòu)

研發(fā)中心技術(shù)部門及PMO、技術(shù)拓展部。

2.2 業(yè)務(wù)

提供需求工程的過(guò)程標(biāo)準(zhǔn)。

3 名詞術(shù)語(yǔ)

3.1 RDM（Request Development and Management）：需求開(kāi)發(fā)與管理。

3.2 SRS(Software Requirement Specification)：軟件需求規(guī)格說(shuō)明書(shū)。

3.3 客戶(Customer)：開(kāi)發(fā)產(chǎn)品訂單的付費(fèi)方

3.4 最終用戶(End User)：最終真正操作軟件的用戶

3.5 用戶需求：指直接來(lái)自于客戶或者用戶的原始需求

3.6 產(chǎn)品需求：指對(duì)用戶需求進(jìn)行需求分析和開(kāi)發(fā)之后生成的對(duì)于軟件產(chǎn)品開(kāi)發(fā)的需求

3.7 CCB(Change Control Board)：變更控制委員會(huì)。CCB的組長(zhǎng)一般為適用機(jī)構(gòu)的領(lǐng)導(dǎo)，成員一般為PMO及適用機(jī)構(gòu)領(lǐng)導(dǎo)制定的某些特定人員，對(duì)于子部門級(jí)別的項(xiàng)目，CCB可直接由子部門的經(jīng)理?yè)?dān)任組長(zhǎng)，由PMO擔(dān)任組員。

4 概述

項(xiàng)目在工程活動(dòng)的開(kāi)始，首先要進(jìn)行需求開(kāi)發(fā)。后續(xù)所有的工程活動(dòng)，包括設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試均是根據(jù)需求展開(kāi)的，所以需求開(kāi)發(fā)的重要程度是最高的，而由于需求的抽象性，需求開(kāi)發(fā)人員（系統(tǒng)分析員）既需要有過(guò)硬的專業(yè)知識(shí)，還要具備較強(qiáng)的交流、溝通能力，所以需求開(kāi)發(fā)也是最難的。任何項(xiàng)目，需求在整個(gè)工程開(kāi)發(fā)過(guò)程中必定會(huì)發(fā)生變化，因此對(duì)需求變更的控制，即需求管理必不可少。

5 過(guò)程定義

5.1 需求開(kāi)發(fā)與管理

需求開(kāi)發(fā)與管理流程圖

5.1.1 角色與職責(zé)

5.1.2 入口準(zhǔn)則

◆ 項(xiàng)目已經(jīng)啟動(dòng)；

◆ 對(duì)于合同項(xiàng)目，合同已經(jīng)簽訂。

5.1.3 輸入

◆ 項(xiàng)目計(jì)劃

5.1.4 過(guò)程活動(dòng)

1)、需求調(diào)查

獲取用戶（客戶和最終用戶）的需求信息。調(diào)查需求的方式包括：

◆ 與用戶交談，向用戶提問(wèn)題

◆ 參觀用戶的工作流程，觀察用戶的操作

◆ 向用戶群體發(fā)調(diào)查問(wèn)卷

◆ 與同行。專家交談，聽(tīng)取他們的意見(jiàn)

◆ 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求

◆ 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求

◆ 從internet上搜查相關(guān)資料

在需求調(diào)查完成之后，需要生成需求搜集的文檔，文檔形式可以自定義，但搜集的需求形成的文檔需要由項(xiàng)目經(jīng)理組織進(jìn)行非正式的評(píng)審，要盡最大努力使搜集到的需求正確無(wú)誤的反映用戶的真實(shí)意愿。

《用戶需求說(shuō)明書(shū)》需要得到用戶的確認(rèn)和承諾。

2）、需求分析及需求定義

需求分析員對(duì)搜集到的用戶需求進(jìn)行分析細(xì)化，以便產(chǎn)生詳細(xì)的產(chǎn)品需求。需求分析的主要方法有：

問(wèn)答分析法。常見(jiàn)的問(wèn)題包括：

◆ 需求是否存在二義性

◆ 需求文檔上下文是否有矛盾

◆ 需求是否完備

◆ 需求是必要的嗎

◆ 需求可實(shí)現(xiàn)嗎

◆ 需求可驗(yàn)證嗎

◆ 需求的優(yōu)先級(jí)確定了嗎

建模分析法。這種分析法需要需求分析員有較高的水平，因?yàn)榻７治龅募夹g(shù)難度比較高。針對(duì)目前情況，不推薦使用。

同時(shí)撰寫(xiě)產(chǎn)品需求規(guī)格說(shuō)明書(shū)。其內(nèi)容主要包括：

◆ 產(chǎn)品介紹

◆ 描述用戶群體的特征

◆ 定義產(chǎn)品的范圍

◆ 闡述產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)和規(guī)范

◆ 定義產(chǎn)品中的角色

◆ 定義產(chǎn)品的功能性需求

◆ 定義產(chǎn)品的非功能性需求，如用戶需求、軟硬件環(huán)境、質(zhì)量等需求

3）、評(píng)審及確認(rèn)需求

項(xiàng)目經(jīng)理組織對(duì)《產(chǎn)品需求規(guī)格說(shuō)明書(shū)》進(jìn)行正式評(píng)審，同時(shí)要取得開(kāi)發(fā)方和客戶方的書(shū)面承諾。

4）、需求跟蹤

將系統(tǒng)設(shè)計(jì)、編程、測(cè)試等階段的工作成果與需求文檔進(jìn)行比較，建立與維護(hù)“需求文檔－設(shè)計(jì)文檔－代碼－測(cè)試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開(kāi)發(fā)。

5）、需求變更申請(qǐng)

項(xiàng)目經(jīng)理撰寫(xiě)需求變更申請(qǐng)單。需求變更說(shuō)明書(shū)包括：變更原因；變更的內(nèi)容；此變更對(duì)項(xiàng)目造成的影響。

6）、審批需求變更申請(qǐng)

高層經(jīng)理和客戶共同進(jìn)行需求變更申請(qǐng)的審批。

7）、變更需求文檔

需求分析員根據(jù)變更申請(qǐng)對(duì)用戶需求說(shuō)明書(shū)和產(chǎn)品需求規(guī)格說(shuō)明書(shū)進(jìn)行變更處理，模板參見(jiàn)“變更控制與管理”過(guò)程域的變更單模板。

5.1.5輸出

◆ 用戶需求調(diào)查報(bào)告

◆ 用戶需求說(shuō)明書(shū)；

◆ 產(chǎn)品需求規(guī)格說(shuō)明書(shū)；

◆ 需求跟蹤矩陣；

◆ 需求變更申請(qǐng)單；

5.1.6 出口準(zhǔn)則

◆ 產(chǎn)品需求規(guī)格說(shuō)明書(shū)通過(guò)審批；

◆ 需求管理貫穿整個(gè)項(xiàng)目生命周期，直到項(xiàng)目結(jié)項(xiàng)；

5.1.7 過(guò)程度量

1）度量人員對(duì)以下數(shù)據(jù)進(jìn)行度量

工作量。

◆ 進(jìn)度。

◆ 需求變更的次數(shù)。

◆ 產(chǎn)品需求規(guī)格說(shuō)明書(shū)的規(guī)模。

◆ 評(píng)審需求發(fā)現(xiàn)的缺陷。

5.1.8 確認(rèn)與驗(yàn)證

◆ QA對(duì)需求開(kāi)發(fā)與管理過(guò)程及其產(chǎn)生的產(chǎn)品的規(guī)范性進(jìn)行檢查；

◆ 項(xiàng)目經(jīng)理對(duì)需求開(kāi)發(fā)與管理過(guò)程進(jìn)行監(jiān)督，對(duì)產(chǎn)生的產(chǎn)品進(jìn)行審查；

◆ 用戶確認(rèn)用戶需求說(shuō)明書(shū)及其變更。

◆ 高層經(jīng)理及客戶對(duì)產(chǎn)品需求規(guī)格說(shuō)明書(shū)進(jìn)行確認(rèn)；

◆ 高層經(jīng)理及客戶對(duì)需求變更申請(qǐng)單進(jìn)行審批；

6 規(guī)程

無(wú)

7 標(biāo)準(zhǔn)與規(guī)范

7.1 《需求開(kāi)發(fā)與管理檢查單》

8 裁剪指南

1）、用戶以規(guī)范形式提供了需求的情況下可裁剪《用戶需求調(diào)查報(bào)告》；

9 模板與表格

9.1 《用戶需求調(diào)查報(bào)告模板》

9.2 《用戶需求說(shuō)明書(shū)模板》

9.3 《產(chǎn)品需求規(guī)格說(shuō)明書(shū)模板》

9.4 《軟件需求跟蹤矩陣表單模板》

10 實(shí)施指導(dǎo)

“需求開(kāi)發(fā)與管理”是CMMI中的工程類過(guò)程。以下是對(duì)“需求開(kāi)發(fā)與管理”過(guò)程實(shí)施時(shí)的進(jìn)一步指導(dǎo)說(shuō)明：

1）、管理配置項(xiàng)

對(duì)“需求開(kāi)發(fā)與管理”過(guò)程產(chǎn)生的所有有價(jià)值的文檔應(yīng)納入配置管理的適當(dāng)層次。主要文檔示例如下：

◆ 用戶需求說(shuō)明書(shū)

◆ 產(chǎn)品需求規(guī)格說(shuō)明書(shū)

◆ 需求跟蹤矩陣

◆ 需求變更申請(qǐng)單

2）、培訓(xùn)人員

組織應(yīng)該對(duì)所有或部分參與“需求開(kāi)發(fā)與管理”過(guò)程的相關(guān)人員進(jìn)行培訓(xùn)。主要培訓(xùn)專題示例如下：

◆ 需求分析方法

3）、使項(xiàng)目干系人適時(shí)介入

◆對(duì)于需求調(diào)查的用戶需求要得到所有項(xiàng)目干系人的共同理解和承諾。

4）、QA根據(jù)計(jì)劃和控制“需求開(kāi)發(fā)與管理”過(guò)程，并且采取適當(dāng)?shù)募m正措施。

5）、項(xiàng)目經(jīng)理在執(zhí)行“需求開(kāi)發(fā)與管理”過(guò)程中，應(yīng)注意收集對(duì)過(guò)程的改進(jìn)建議，并提交給組織EPG。

6)、評(píng)審及確認(rèn)需求時(shí)，如客戶及最終用戶納入存在困難，可以在征求高層經(jīng)理的同意下，由高層經(jīng)理代表客戶需求，其他指定人員代表最終用戶需求進(jìn)行評(píng)審。

附錄一：需求開(kāi)發(fā)與管理檢查單

需求開(kāi)發(fā)與管理檢查單

附錄二：需求跟蹤矩陣表單模板

需求跟蹤矩陣表單模板

附錄三：需求調(diào)查報(bào)告模板

【項(xiàng)目(產(chǎn)品)名稱】

常見(jiàn)需求調(diào)查方式有：

1. 與用戶交談，向用戶提問(wèn)題。

2.參觀用戶的工作流程，觀察用戶的操作。

3. 向用戶群體發(fā)調(diào)查問(wèn)卷。

4.與同行、專家交談，聽(tīng)取他們的意見(jiàn)。

5.分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。

6.從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。

7.從Internet上搜查相關(guān)資料。

1 需求標(biāo)題1

2 需求標(biāo)題N

附錄四：用戶需求說(shuō)明書(shū)

目錄二

1引言

1.1 編寫(xiě)目的

1.2 范圍

1.3 術(shù)語(yǔ)與縮寫(xiě)解釋

1.4 參考資料

2 產(chǎn)品介紹

【提示：

（1）說(shuō)明產(chǎn)品是什么，什么用途。

（2）介紹產(chǎn)品的開(kāi)發(fā)背景?！?/span>

3 產(chǎn)品面向的用戶群體

提示：

（1）描述本產(chǎn)品面向的用戶（客戶、最終用戶）的特征，

（2）說(shuō)明本產(chǎn)品將給他們帶來(lái)什么好處？他們選擇本產(chǎn)品的可能性有多大？

4 產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范

提示：闡述本產(chǎn)品應(yīng)當(dāng)遵循什么標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則（Business Rules），違反標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則的產(chǎn)品通常不太可能被接受。

5 產(chǎn)品的功能性需求

5.1 功能性需求分類

提示：將功能性需求先粗分再細(xì)分，下表中的 Feature A, Function A.1等符號(hào)應(yīng)當(dāng)被替換成有含義的名稱。

按照上面劃分的功能下面具體填加標(biāo)題描述

5.2 Feature A

提示：此處寫(xiě)一些承上啟下的文字。

5.2.1 Function A.1

功能描述：

6 產(chǎn)品的非功能性需求

6.1 用戶界面需求

6.2 軟硬件環(huán)境需求

6.3 產(chǎn)品質(zhì)量需求

6.4 其它需求