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

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

2、求規(guī)格說明書階段性成果、描述需求的綜合性報告需求變更申請單外部需求請求變更時申請，記錄變更過程需求變更表在形成階段性成果后編制的需求列表需求階段資料匯編所有需求工作產(chǎn)品總編目3需求開發(fā)階段工作流程項目啟動制定初步需求說明書形成需求調(diào)研問題表制訂現(xiàn)場調(diào)研計劃根據(jù)合同制定需求開發(fā)階段計劃現(xiàn)場調(diào)研形成需求說明書n形成正式需求說明書y確認(rèn)yn確認(rèn)ny完成需求調(diào)研問題表完成y形成新的問題表n形成原型系統(tǒng)確認(rèn)維護(hù)需求變更表總結(jié)、資料匯編2. 入口準(zhǔn)則項目立項、合同簽定3. 出口準(zhǔn)則用戶確認(rèn)需求4. 輸入用戶的需求5. 輸出1、軟件需求規(guī)格說明書2、需求變更表6. 主要步驟6.1 需求獲取1明確需求獲取的信

3、息。需求分析師應(yīng)在需求獲取前明確需要獲取的需求信息，以確保在實施需求獲取時有的放矢。通常需求獲取要獲取的信息包括三大類：與問題域相關(guān)的背景信息（如業(yè)務(wù)資料，組織結(jié)構(gòu)圖，業(yè)務(wù)處理流程等）；與要求解決的問題直接相關(guān)的信息；用戶對系統(tǒng)的特別期望與施加的任何約束信息。2明確需求信息的來源。需求分析師在明確了所需要獲取的信息之后，應(yīng)確定獲取需求信息的來源與渠道，以提高需求分析師在需求獲取階段的工作效率，使得所收集的信息更加有價值、更加全面。 需求信息的來源通常包括：來自客戶的需求實施所滿足的需求競爭對手的產(chǎn)品優(yōu)勢與不足3獲取需求信息的方法。在明確須獲取什么需求、需求的來源與獲取渠道后，應(yīng)選擇至少一種需求

4、獲取技術(shù)獲取相關(guān)的需求，作為需求分析的依據(jù)。需求獲取技術(shù)包括但不限于：客戶訪談客戶調(diào)查現(xiàn)場觀摩用戶的工作流程，觀察用戶的實際操作需求討論會4需求信息的保管。根據(jù)所采用的需求獲取技術(shù)，在需求獲取過程中將產(chǎn)生不同的記錄和原始資料，項目組應(yīng)將這些記錄納入開發(fā)庫進(jìn)行配置管理。需求獲取的記錄與資料包括但不限于：用戶編寫的原始需求文檔；用戶填寫的需求調(diào)查表；用戶訪談的訪談紀(jì)要；需求研討會的會議紀(jì)要；相關(guān)的政策法規(guī)文件，業(yè)務(wù)規(guī)則文件以及行業(yè)標(biāo)準(zhǔn)文件；需求原型。5需求分析工作方法。根據(jù)以往的工程經(jīng)驗，需求分析工作方法，應(yīng)該定位在“三個階段”（也稱“三步法” ） 。第一階段：“訪談式”（visitation ）

5、這一階段是和具體用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等等具體情況、客觀的信息。 建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。實現(xiàn)手段 ：訪談、調(diào)查表格輸出成果 ：調(diào)查報告、業(yè)務(wù)流程報告第二階段：“誘導(dǎo)式”（inducement ）這一階段是在承建方已經(jīng)了解了具體用戶方的組織架構(gòu)、業(yè)務(wù)流程、 硬件環(huán)境、 軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等等具體實際、客觀的信息基礎(chǔ)上，結(jié)合現(xiàn)有的硬件、軟件實現(xiàn)方案，做出簡單的用戶流程頁面，同時結(jié)合以往的項目經(jīng)驗對用

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

7、反饋意見，并對已經(jīng)可接受的報告、文檔簽字確認(rèn)。實現(xiàn)手段 ：拜訪（回顧、確認(rèn)） ，提交業(yè)務(wù)流程報告、數(shù)據(jù)項表；原型演示系統(tǒng)輸出成果： 需求分析報告、數(shù)據(jù)項、業(yè)務(wù)流程報告、原型系統(tǒng)反饋意見（后三者可以統(tǒng)一歸入需求分析報告中，提交用戶方、監(jiān)理方進(jìn)行確認(rèn)和存檔）需求分析的三個階段是需求調(diào)研中不可忽視一個重要的部分，三個階段或者說三步法的實施和采用， 對用戶和承建方都同樣提供了項目成功的保證。當(dāng)然在系統(tǒng)建設(shè)的過程中，特別在采用迭代法的開發(fā)模式時，需求分析的工作需一直進(jìn)行下去，而在后期的需求改進(jìn)中，工作則基本集中在后兩個階段中。6需求分析應(yīng)注意的問題。需求說明書應(yīng)該對于那些只想了解宏觀需求的領(lǐng)導(dǎo)，和需要了

8、解細(xì)節(jié)的技術(shù)員都合適。在寫需求說明書時應(yīng)該注意兩個問題：1.最好為每個需求注釋“為什么”，這樣可讓程序員了解需求的本質(zhì)，以便選用最合適的技術(shù)來實現(xiàn)此需求。2.需求說明不可有二義性，更不能前后相矛盾。如果有二義性或前后相矛盾，則要重新分析此需求。7獲取需求過程中的原則原則永遠(yuǎn)不要顯得比客戶更聰明第一條：了解需求，而不是去批評客戶；第二條：客戶比你更熟悉業(yè)務(wù)的環(huán)境；第三條：客戶總是知道問題在哪兒，你的工作就是要讓他們自己愿意說出來；原則尊重用戶的現(xiàn)實選擇第一條：客戶永遠(yuǎn)是對的；第二條：提供最合適的解決方案，而非最好或最貴的方案；第三條：不要把客戶當(dāng)傻瓜；原則轉(zhuǎn)述需求的人也是客戶第一條：轉(zhuǎn)述者一般會

9、把自己想象成設(shè)計者；第二條：轉(zhuǎn)述者可能會遺漏或補(bǔ)充一些額外的需求；第三條：對轉(zhuǎn)述者的自由發(fā)揮不應(yīng)抱怨和生氣，而是將其視為客戶；原則客戶和用戶要區(qū)別對待第一條：產(chǎn)品為最終用戶設(shè)計， 需求的功能轉(zhuǎn)換為最終用戶的使用要求而確定；第二條：為客戶尋找價值上的需求；第三條：用戶的利益高于一切；原則用最簡單的文字工具記錄需求第一條：所有人都能懂的東西，最不容易出錯；第二條：不需要再學(xué)習(xí)的東西，最不容易出錯；第三條：不要希望客戶能花更多的時間來了解需求轉(zhuǎn)換后的模型；第四條：保持溝通的通暢，是了解需求的保障；原則天下沒有免費(fèi)的午餐第一條：客戶從來沒有不合理的需求；第二條：客戶的要求都是可以實現(xiàn)的；第三條：我們能

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

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

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

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

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

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

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

17、料有正規(guī)的出處，以確保需求的正確性；定義必要的術(shù)語，適當(dāng)結(jié)合圖形、結(jié)構(gòu)圖等方式進(jìn)行描述，以確保需求無二義性；使用較好的文檔結(jié)構(gòu)與需求標(biāo)識，使需求能夠方便地與其它工作產(chǎn)品相對應(yīng)，以確保需求易于追溯；確保所描述的需求可以通過適當(dāng)?shù)氖侄蔚玫津炞C，即需求的可測試性；考慮了各個層次的需求，確定了需求的優(yōu)先級，以確保需求的可行性。6.4 需求確認(rèn)1需求評審應(yīng)對所形成的需求文檔進(jìn)行評審，以便作為下一階段工作的基礎(chǔ)。需求評審的方式為 “部門評審會議” 。部門評審成員：評審組長：項目經(jīng)理1測試代表2開發(fā)代表3項目經(jīng)理4客戶代表2需求承諾項目經(jīng)理將評審?fù)ㄟ^的軟件需求規(guī)格說明書提交給客戶（或客戶代表）、系統(tǒng)關(guān)聯(lián)項目

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