需求開發(fā)管理規(guī)范及管理流程

1、需求開發(fā)管理規(guī)范及管理流程1. 目的通過定義需求開發(fā)和管理過程，規(guī)范公司軟件開發(fā)項(xiàng)目的需求開發(fā)和管理活動(dòng)，提高需求質(zhì)量，從而提高軟件生產(chǎn)率，降低開發(fā)成本，改進(jìn)軟件質(zhì)量。應(yīng)調(diào)查用戶的需求，通過需求分析工作將用戶需求轉(zhuǎn)化為軟件需求，同時(shí)評(píng)審需求的正確性，獲得需求的承諾；應(yīng)控制需求的變更，并確保項(xiàng)目計(jì)劃、工作產(chǎn)品與需求的一致性。2. 需求開發(fā)階段的工作文件產(chǎn)品名稱說明需求開發(fā)階段計(jì)劃描述需求開發(fā)階段的人員、分工、時(shí)間、主要工作內(nèi)容及必備條件。需求開發(fā)問題表現(xiàn)場(chǎng)調(diào)研需解決的問題需求開發(fā)實(shí)施日志記錄任務(wù)執(zhí)行情況現(xiàn)場(chǎng)調(diào)研訪談表現(xiàn)場(chǎng)調(diào)研記錄（包括需求階段的會(huì)議記錄、紀(jì)要）現(xiàn)場(chǎng)資料收集清單所有現(xiàn)場(chǎng)收集的資料清

2、單需求規(guī)格說明書階段性成果、描述需求的綜合性報(bào)告需求變更申請(qǐng)單外部需求請(qǐng)求變更時(shí)申請(qǐng)，記錄變更過程需求變更表在形成階段性成果后編制的需求列表需求階段資料匯編所有需求工作產(chǎn)品總編目3. 需求開發(fā)階段工作流程2. 入口準(zhǔn)則項(xiàng)目立項(xiàng)、合同簽定3. 出口準(zhǔn)則用戶確認(rèn)需求4. 輸入用戶的需求5. 輸出1、軟件需求規(guī)格說明書2、需求變更表6. 主要步驟6.1 需求獲取1明確需求獲取的信息。需求分析師應(yīng)在需求獲取前明確需要獲取的需求信息， 以確保在實(shí)施需求獲取時(shí)有的放 矢。通常需求獲取要獲取的信息包括三大類：與問題域相關(guān)的背景信息（如業(yè)務(wù)資料，組織結(jié)構(gòu)圖，業(yè)務(wù)處理流程等） ； 與要求解決的問題直接相關(guān)的信息

3、； 用戶對(duì)系統(tǒng)的特別期望與施加的任何約束信息。2明確需求信息的來源。需求分析師在明確了所需要獲取的信息之后， 應(yīng)確定獲取需求信息的來源與渠道， 以提 高需求分析師在需求獲取階段的工作效率， 使得所收集的信息更加有價(jià)值、 更加全面。 需求 信息的來源通常包括：來自客戶的需求實(shí)施所滿足的需求 競(jìng)爭(zhēng)對(duì)手的產(chǎn)品優(yōu)勢(shì)與不足3獲取需求信息的方法。在明確須獲取什么需求、 需求的來源與獲取渠道后， 應(yīng)選擇至少一種需求獲取技術(shù)獲取 相關(guān)的需求，作為需求分析的依據(jù)。需求獲取技術(shù)包括但不限于：客戶訪談客戶調(diào)查 現(xiàn)場(chǎng)觀摩用戶的工作流程，觀察用戶的實(shí)際操作 需求討論會(huì)4需求信息的保管。根據(jù)所采用的需求獲取技術(shù)， 在需求

4、獲取過程中將產(chǎn)生不同的記錄和原始資料， 項(xiàng)目組應(yīng)將這些記錄納入開發(fā)庫進(jìn)行配置管理。需求獲取的記錄與資料包括但不限于： 用戶編寫的原始需求文檔；用戶填寫的需求調(diào)查表； 用戶訪談的訪談紀(jì)要； 需求研討會(huì)的會(huì)議紀(jì)要； 相關(guān)的政策法規(guī)文件，業(yè)務(wù)規(guī)則文件以及行業(yè)標(biāo)準(zhǔn)文件； 需求原型。5需求分析工作方法。 根據(jù)以往的工程經(jīng)驗(yàn)，需求分析工作方法，應(yīng)該定位在“三個(gè)階段” （也稱“三步法” ）。 第一階段："訪談式” （Visitation）這一階段是和具體用戶方的領(lǐng)導(dǎo)層、 業(yè)務(wù)層人員的訪談式溝通， 主要目的是從宏觀上把 握用戶的具體需求方向和趨勢(shì)，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)

5、 有的運(yùn)行系統(tǒng)等等具體情況、 客觀的信息。 建立起良好的溝通渠道和方式。 針對(duì)具體的職能 部門以及各委辦局，最好能指定本次項(xiàng)目的接口人。實(shí)現(xiàn)手段 ：訪談、調(diào)查表格輸出成果 ：調(diào)查報(bào)告、業(yè)務(wù)流程報(bào)告第二階段：“誘導(dǎo)式”（ Inducement） 這一階段是在承建方已經(jīng)了解了具體用戶方的組織架構(gòu)、 業(yè)務(wù)流程、 硬件環(huán)境、 軟件環(huán) 境、現(xiàn)有的運(yùn)行系統(tǒng)等等具體實(shí)際、客觀的信息基礎(chǔ)上，結(jié)合現(xiàn)有的硬件、軟件實(shí)現(xiàn)方案， 做出簡(jiǎn)單的用戶流程頁面， 同時(shí)結(jié)合以往的項(xiàng)目經(jīng)驗(yàn)對(duì)用戶采用誘導(dǎo)式、 啟發(fā)式的調(diào)研方法 和手段，和用戶一起探討業(yè)務(wù)流程設(shè)計(jì)的合理性、準(zhǔn)確性、便易性、習(xí)慣性。用戶可以操作 簡(jiǎn)單演示的 DEMO

6、，來感受一下整個(gè)業(yè)務(wù)流程的設(shè)計(jì)合理性、準(zhǔn)確性等等問題，及時(shí)地提 出改進(jìn)意見和方法。實(shí)現(xiàn)手段 ：拜訪（誘導(dǎo)） 、原型演示 輸出成果 ：調(diào)研分析報(bào)告、原型反饋報(bào)告、業(yè)務(wù)流程報(bào)告第三階段：“確認(rèn)式”（ Afirm ） 這一階段是在上述兩個(gè)階段成果的基礎(chǔ)上，進(jìn)行具體的流程細(xì)化、數(shù)據(jù)項(xiàng)的確認(rèn)階段， 這個(gè)階段承建方必須提供原型系統(tǒng)和明確的業(yè)務(wù)流程報(bào)告、 數(shù)據(jù)項(xiàng)表， 并能清晰地向用戶描 述系統(tǒng)的業(yè)務(wù)流設(shè)計(jì)目標(biāo)。 用戶方可以通過審查業(yè)務(wù)流程報(bào)告、 數(shù)據(jù)項(xiàng)表以及操作承建方提 供的 DEMO 系統(tǒng)，來提出反饋意見，并對(duì)已經(jīng)可接受的報(bào)告、文檔簽字確認(rèn)。實(shí)現(xiàn)手段 ：拜訪（回顧、確認(rèn)） ，提交業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表；原

7、型演示系統(tǒng) 輸出成果： 需求分析報(bào)告、數(shù)據(jù)項(xiàng)、業(yè)務(wù)流程報(bào)告、原型系統(tǒng)反饋意見（后三者可 以統(tǒng)一歸入需求分析報(bào)告中，提交用戶方、監(jiān)理方進(jìn)行確認(rèn)和存檔）需求分析的三個(gè)階段是需求調(diào)研中不可忽視一個(gè)重要的部分， 三個(gè)階段或者說三步法的 實(shí)施和采用， 對(duì)用戶和承建方都同樣提供了項(xiàng)目成功的保證。 當(dāng)然在系統(tǒng)建設(shè)的過程中， 特 別在采用迭代法的開發(fā)模式時(shí)，需求分析的工作需一直進(jìn)行下去，而在后期的需求改進(jìn)中， 工作則基本集中在后兩個(gè)階段中。6需求分析應(yīng)注意的問題。 需求說明書應(yīng)該對(duì)于那些只想了解宏觀需求的領(lǐng)導(dǎo)，和需要了解細(xì)節(jié)的技術(shù)員都合適。 在寫需求說明書時(shí)應(yīng)該注意兩個(gè)問題：1.最好為每個(gè)需求注釋“為什么”，

8、這樣可讓程序員了解需求的本質(zhì)，以便選用最合適的技術(shù)來實(shí)現(xiàn)此需求。2.需求說明不可有二義性，更不能前后相矛盾。如果有二義性或前后相矛盾，則要重新 分析此需求。7 獲取需求過程中的原則原則1永遠(yuǎn)不要顯得比客戶更聰明第一條：了解需求，而不是去批評(píng)客戶；第二條：客戶比你更熟悉業(yè)務(wù)的環(huán)境；第三條：客戶總是知道問題在哪兒，你的工作就是要讓他們自己愿意說出來； 原則2尊重用戶的現(xiàn)實(shí)選擇第一條：客戶永遠(yuǎn)是對(duì)的；第二條：提供最合適的解決方案，而非最好或最貴的方案；第三條：不要把客戶當(dāng)傻瓜；原則3轉(zhuǎn)述需求的人也是客戶第一條：轉(zhuǎn)述者一般會(huì)把自己想象成設(shè)計(jì)者；第二條：轉(zhuǎn)述者可能會(huì)遺漏或補(bǔ)充一些額外的需求；第三條：對(duì)轉(zhuǎn)

9、述者的自由發(fā)揮不應(yīng)抱怨和生氣，而是將其視為客戶； 原則4客戶和用戶要區(qū)別對(duì)待第一條：產(chǎn)品為最終用戶設(shè)計(jì)，需求的功能轉(zhuǎn)換為最終用戶的使用要求而確定; 第二條：為客戶尋找價(jià)值上的需求；第三條：用戶的利益高于一切；原則5用最簡(jiǎn)單的文字工具記錄需求第一條：所有人都能懂的東西，最不容易出錯(cuò)；第二條：不需要再學(xué)習(xí)的東西，最不容易出錯(cuò)；第三條：不要希望客戶能花更多的時(shí)間來了解需求轉(zhuǎn)換后的模型；第四條：保持溝通的通暢，是了解需求的保障； 原則6天下沒有免費(fèi)的午餐第一條：客戶從來沒有不合理的需求；第二條：客戶的要求都是可以實(shí)現(xiàn)的；第三條：我們能做這事-這是所需的費(fèi)用；6.2需求分析的內(nèi)容名稱內(nèi)容適用性功能分析實(shí)

10、現(xiàn)該需求軟件所須提供的 功能及其含義、工作內(nèi)容所有需求必須，非原子級(jí)需求 需給出下一級(jí)的功能結(jié)構(gòu)圖角色分析分析該需求涉及的角色及在 本需求內(nèi)容的行為原子級(jí)需求必須，其它可選業(yè)務(wù)流程分析分析該需求涉及的業(yè)務(wù)流程， 以流程圖或用例圖表示，并根 據(jù)需要配合一定的文字說明原子級(jí)需求必須，其它可選數(shù)據(jù)分析分析該需求涉及數(shù)據(jù)項(xiàng)的名 稱、含義、格式、規(guī)則。以表 格形式給出原子級(jí)需求必須，其它不適用權(quán)限分析定義各角色在該需求中的行 為。以表格形式給出原子級(jí)需求必須，其它不適用界面分析實(shí)現(xiàn)該需求的界面風(fēng)格、表單 樣式、報(bào)表格式及頁面布局。報(bào)表類需求或客戶明確要求 的必須，其它可在需求說明書 中統(tǒng)一分類說明性能分

11、析分析該需求的最大數(shù)據(jù)量、訪 問頻度，定義用戶響應(yīng)時(shí)間等 要求有特殊要求必須說明，其它可 在需求說明書中統(tǒng)一分類說 明偶合性分析分析該需求和其它需求間的 相互關(guān)系及影響，與其它需求 有關(guān)的應(yīng)以表格詳細(xì)說明相 互關(guān)系原子級(jí)需求必須，其它可選6.3需求分解按照功能結(jié)構(gòu)圖進(jìn)行分解，原則上以每一條完成工作的實(shí)際業(yè)務(wù)流程為一個(gè)需求最小單位（原子級(jí)需求），單個(gè)流程以下的作為該需求的功能，不向下細(xì)分。每個(gè)原子級(jí)需求必須 滿足以下條件：1）僅存在一條主要業(yè)務(wù)流程；2）操作同一業(yè)務(wù)數(shù)據(jù)；6.4需求定義1 .標(biāo)識(shí)需求為了確保需求的易跟蹤、易修改，需求分析師應(yīng)通過需求編號(hào)的方式唯一標(biāo)識(shí)每一個(gè)軟 件需求，明確需求的跟

12、蹤粒度，并體現(xiàn)于軟件需求分析文檔。編碼規(guī)則： 系統(tǒng)代碼-XQ-1級(jí)需求編號(hào) .版本號(hào)-2級(jí)需求編號(hào) .版本號(hào)例：設(shè)備系統(tǒng)（EMS ）的第一個(gè)功能“基礎(chǔ)數(shù)據(jù)管理”的第二個(gè)功能“供應(yīng)商管理的第3版需求編號(hào)為：EMS-XQ-1.1-2.3說明：需求編號(hào)按照合同方案中排列順序編排，如合同方案中未出現(xiàn)的功能需求則排在合同所列所有需求之后。2.定義需求優(yōu)先級(jí)別需求分析師應(yīng)確定每個(gè)需求的優(yōu)先級(jí)并寫入軟件需求分析文檔，需求的優(yōu)先級(jí)的評(píng)價(jià)標(biāo)準(zhǔn)如下:級(jí)別判斷標(biāo)準(zhǔn)采取的措施高滿足以下任意一條時(shí)：1）客戶明確要求的；2）滿足正常業(yè)務(wù)必須的；3）系統(tǒng)不可缺少的4）導(dǎo)致其它高優(yōu)先級(jí)需求無法實(shí)現(xiàn)的5）相關(guān)法規(guī)、標(biāo)準(zhǔn)要求的。

13、對(duì)于這些需求在項(xiàng)目實(shí)施過程中 需重點(diǎn)投入資源，優(yōu)先實(shí)現(xiàn)，只 有在這些需求上達(dá)成一致意見， 軟件才會(huì)被接受；必須完美地實(shí) 現(xiàn)。通常這類需求在當(dāng)前版本必 須實(shí)現(xiàn)。中滿足以下任意一條時(shí)：1）客戶隱含要求，對(duì)正常業(yè)務(wù)影響程度不 大2）支持必要的系統(tǒng)操作，實(shí)現(xiàn)這些需求將 增強(qiáng)產(chǎn)品的性能，是產(chǎn)品最終所要求的。這些需求必須被實(shí)現(xiàn)，但如果項(xiàng) 目實(shí)施中出現(xiàn)進(jìn)度、資源等方面 的沖突時(shí)，如果有必要，可以延 遲到下一版本；需要付出努力， 但不必做得太完美。低滿足以下任意一條時(shí)：1）功能或質(zhì)量上的附加功能；2）實(shí)現(xiàn)這些需求會(huì)使產(chǎn)品更完美，若不實(shí) 現(xiàn)也不影響產(chǎn)品的功能與性能，屬于錦 上添花。實(shí)現(xiàn)或不實(shí)現(xiàn)均可；可以在項(xiàng)目

14、組有較足夠的時(shí)間時(shí)考慮這些需 求的實(shí)現(xiàn)優(yōu)先級(jí)的定義有利于幫助項(xiàng)目組在項(xiàng)目的范圍、進(jìn)度、資源、預(yù)算等相關(guān)制約因素之間產(chǎn)生沖突時(shí)，能夠正確地對(duì)需求實(shí)現(xiàn)的范圍或?qū)崿F(xiàn)的優(yōu)先程度做出取舍。 一個(gè)實(shí)現(xiàn)這種權(quán)衡 的方法是：當(dāng)接受一個(gè)新的高優(yōu)先級(jí)的需求或者其它項(xiàng)目環(huán)境變化時(shí)， 刪除低優(yōu)先級(jí)的需求， 或者把它們推遲到下一版本中去實(shí)現(xiàn)。3 定義需求與現(xiàn)有管理的差異級(jí)別（流程差異性）需求分析師應(yīng)確定每個(gè)需求實(shí)現(xiàn)的管理流程與客戶現(xiàn)行管理流程間的差異性大小并寫 入軟件需求分析文檔，流程差異性的評(píng)價(jià)標(biāo)準(zhǔn)如下：級(jí)別判斷標(biāo)準(zhǔn)采取的措施無滿足以下全部條件時(shí)：1）現(xiàn)有流程和設(shè)計(jì)流程一致無需過多考慮，設(shè)計(jì)時(shí)實(shí)現(xiàn)原流 程既可有滿足以

15、下全部條件時(shí)：1）現(xiàn)有流程和設(shè)計(jì)流程不一致；2）客戶認(rèn)可新流程。在需求設(shè)計(jì)說明書中需要反映原 始流程和設(shè)計(jì)流程，并描述兩者 區(qū)別及調(diào)整原因，在培訓(xùn)階段應(yīng) 加強(qiáng)此部分的力度。建議滿足以下全部條件時(shí)：1）現(xiàn)有流程和設(shè)計(jì)流程不一致；2）雙方對(duì)新流程未達(dá)成共識(shí)；3）我方認(rèn)為新流程有先進(jìn)性；4）流程改變與否不會(huì)影響功能實(shí)現(xiàn)；5）流程改變與否不會(huì)影響系統(tǒng)總體目標(biāo)。改變或不改變均可；在需求設(shè)計(jì) 說明書中以原始流程為最終流 程，但在需求說明書中反映建議 的新流程，并描述原始流程實(shí)現(xiàn) 后可能帶來的問題及新流程的先 進(jìn)性。保留滿足以下全部條件時(shí)：1）現(xiàn)有流程和設(shè)計(jì)流程不一致；2）雙方對(duì)新流程未達(dá)成共識(shí)；3）客戶明

16、確要求保留的；4）我方堅(jiān)決反對(duì)的；5）流程改變與否會(huì)影響功能實(shí)現(xiàn)或者會(huì)影響 系統(tǒng)總體目標(biāo)。必須改變的流程，但客戶堅(jiān)決不 改變的。需先和客戶負(fù)責(zé)人進(jìn)行 溝通，在明確客戶負(fù)責(zé)人（必須 是客戶的主管高層）了解該問題 并堅(jiān)持的情況下，明確闡明我方 持保留意見的觀點(diǎn)。需求說明書 中應(yīng)描述原始流程和設(shè)計(jì)流程， 詳細(xì)說明原有流程存在的問題并 注明客戶主要負(fù)責(zé)人意見，應(yīng)作 為該項(xiàng)目的重要風(fēng)險(xiǎn)優(yōu)先采取措 施解決。4.編寫需求分析文檔需求分析師在需求分析過程中根據(jù)分析步驟逐步編制形成軟件需求分析文檔（其中產(chǎn)品功能列表可作為附件提交）。編寫需求分析文檔應(yīng)遵循以下規(guī)則：相關(guān)的需求都得到了識(shí)別與描述，以確保需求的完整性

17、； 各個(gè)需求之間不沖突，算法之間不相互矛盾，以確保需求的一致性； 正確描述系統(tǒng)需求，引用的資料有正規(guī)的出處，以確保需求的正確性； 定義必要的術(shù)語，適當(dāng)結(jié)合圖形、結(jié)構(gòu)圖等方式進(jìn)行描述，以確保需求無二義性； 使用較好的文檔結(jié)構(gòu)與需求標(biāo)識(shí)，使需求能夠方便地與其它工作產(chǎn)品相對(duì)應(yīng)，以確保需求易于追溯；確保所描述的需求可以通過適當(dāng)?shù)氖侄蔚玫津?yàn)證，即需求的可測(cè)試性； 考慮了各個(gè)層次的需求，確定了需求的優(yōu)先級(jí)，以確保需求的可行性。6.4 需求確認(rèn)1需求評(píng)審應(yīng)對(duì)所形成的需求文檔進(jìn)行評(píng)審， 以便作為下一階段工作的基礎(chǔ)。 需求評(píng)審的方式為 “部 門評(píng)審會(huì)議” 。部門評(píng)審成員：評(píng)審組長(zhǎng)：項(xiàng)目經(jīng)理1測(cè)試代表2開發(fā)代表3

18、項(xiàng)目經(jīng)理4客戶代表2需求承諾 項(xiàng)目經(jīng)理將評(píng)審?fù)ㄟ^的軟件需求規(guī)格說明書提交給客戶（或客戶代表） 、系統(tǒng)關(guān)聯(lián) 項(xiàng)目組進(jìn)行確認(rèn)，確認(rèn)的方式可以是以下方式之一：直接簽字：由承諾方在評(píng)審報(bào)告上直接簽字或蓋章確認(rèn)3建立基線項(xiàng)目的軟件需求分析文檔經(jīng)過評(píng)審與確認(rèn)后，應(yīng)根據(jù)要求建立需求基線。6.5 需求變更對(duì)一個(gè)軟件項(xiàng)目來說， 無論最初的需求分析有多么明確， 開發(fā)過程中的需求變化也還是 不可避免的。這主要有以下幾種原因：軟件所應(yīng)用的外部環(huán)境發(fā)生變化； 隨著用戶對(duì)軟件的熟悉和應(yīng)用，又提出新的需求； 項(xiàng)目組進(jìn)行需求分析時(shí)未能徹底分析用戶的需求，或分析錯(cuò)誤； 用戶在開始時(shí)不能很全面的知道所需軟件的功能。1、需求變更申請(qǐng) 項(xiàng)目組外的需求變更，由變更申請(qǐng)人通過填寫需求變更申請(qǐng)單向項(xiàng)目組提出進(jìn)行； 項(xiàng)目組內(nèi)部的需求變更通過軟件變更申請(qǐng)單提出。當(dāng)項(xiàng)目組接收到項(xiàng)目管理部門的 需求變更申請(qǐng)單 時(shí)，應(yīng)先根據(jù)要求進(jìn)行需求的評(píng)估， 判斷需求的類型、分析需求變更影響到的范圍、估算需求實(shí)現(xiàn)的工作量（含需求、設(shè)計(jì)、編 碼、測(cè)試、用戶文檔編寫） 、預(yù)計(jì)可以完成的時(shí)間等內(nèi)容，填寫于需求變更申請(qǐng)單內(nèi)部評(píng) 審表，并回復(fù)項(xiàng)目管理部門。若估算的開發(fā)工作量大于 10 人月時(shí)， 項(xiàng)目組可以根據(jù) 立項(xiàng) 管理過程的要求向項(xiàng)目管理部