產(chǎn)品需求管理

產(chǎn)品需求管理版本歷史在產(chǎn)品開發(fā)之前形成明確的產(chǎn)品需求描述，并在產(chǎn)品開發(fā)過程中對產(chǎn)品需求進(jìn)行嚴(yán)格管理，是產(chǎn)品成功的關(guān)鍵所在。產(chǎn)品需求，可分為功能性需求和非功能性需求：功能性需求：是一種行為需求，指那些需要具體完成某項(xiàng)內(nèi)容的產(chǎn)品功能；非功能性需求：是指那些為滿足用戶需要而必須具有、但又不是功能性需求的產(chǎn)品特性，或者稱為質(zhì)量（Quality），包括性能、效率、安全性、易用性等多方面；產(chǎn)品的功能性需求與非功能性需求，其描述方式可以不同，但是要使用同樣的管控方法、同樣的管控質(zhì)量標(biāo)準(zhǔn)。功能性需求描述描述用戶需求的方法有很多，針對用戶的功能性需求，我們建議使用“特征（Features）+用例（UseCases）”的組合來描述。這種描述方法的主要優(yōu)點(diǎn)有：基于“特征+用例”的用戶產(chǎn)品需求描述，邏輯結(jié)構(gòu)強(qiáng)，顆粒度可控，能讓產(chǎn)品需求更明晰、定義更規(guī)范；用“特征+用例”的形式描述用戶產(chǎn)品需求，將為產(chǎn)品開發(fā)過程的跟蹤管理打好基礎(chǔ)——產(chǎn)品過程的每次迭代都可制定一個(gè)量化目標(biāo)、過程中隨時(shí)可給出完成度；增加新用戶需求是通過增加新特征/新用例或者修改已有特征／用例來實(shí)現(xiàn)的，便于變更管理，能更好地實(shí)現(xiàn)版本管控。1.1特征與用例分別是什么？所謂“特征+用例”的描述方法，是指在描述用戶需求時(shí)使用兩種對指在描述產(chǎn)品需求時(shí)使用兩種對象，一個(gè)是特征（Feature），另一個(gè)是用例（UseCase）。特征（Feature）是指系統(tǒng)圍繞某個(gè)對象發(fā)生的功能，用<動作><結(jié)果><by|for|of|to><對象>來表達(dá)。特征（Feature）描述的是產(chǎn)品的功能性需求，必須是通過某種動作、產(chǎn)生某種結(jié)果。特征功能是用戶提出的切實(shí)有效的功能，從用戶角度看，一個(gè)特征必須對應(yīng)著一個(gè)有價(jià)值的結(jié)果。用例（UseCase）是系統(tǒng)在作業(yè)時(shí)與用戶交換信息的一個(gè)個(gè)場景。用例是站在用戶角度上描述系統(tǒng)功能的，強(qiáng)調(diào)用戶的目標(biāo)。在整理清楚產(chǎn)品需求后，我們首先把產(chǎn)品的用戶需求分解為若干個(gè)特征（Feature），要求這些特征合在一起能完整地表達(dá)該產(chǎn)品的用戶需求。然后我們通過用例（UseCase）來詳細(xì)描述這些產(chǎn)品特征（Feature）。于是，特征（Feature）與用例（UseCase）的關(guān)系構(gòu)成了一個(gè)需求描述的樹狀體系。特征（Feature）是樹狀體系中的高等級對象，用例（UseCase）是這個(gè)體系中的低等級對象。在這個(gè)體系里，用例是需求描述的基本單元。在這個(gè)樹狀體系中，每個(gè)用例（UseCase）都必然隸屬于某一個(gè)特征（Feature）。特征（Feature）可以通過BreakDown的方式進(jìn)行逐級分解和細(xì)化，形成特征之間的隸屬關(guān)系；同樣的，用例（UseCase）也可以進(jìn)行BreakDown，從而形成更加詳細(xì)的描述。特征（Feature）和用例（UseCase）的粒度大小，既要取決于業(yè)務(wù)分析的精細(xì)度，也要考慮開發(fā)實(shí)現(xiàn)的周期（開發(fā)計(jì)劃將以特征和用例作為任務(wù)顆粒）。1.2“特征+用例”的描述格式在“特征+描述”的描述方法中，特征（Feature）本身并不需要細(xì)致的描述，因?yàn)殡`屬于它的用例（UseCase）可以詳細(xì)地說明該特征（Feature）的所有內(nèi)容要素。所以，針對特征（Feature）的直接描述是非常簡要的，描述的重點(diǎn)是要表達(dá)出它和用例（UseCase）之間的隸屬關(guān)系。而用例（UseCases）是需求描述的基本單元，所以用例的描述內(nèi)容中包含較多的細(xì)節(jié)。特征（Feature）和用例（UseCase）是通過兩種表格來分別描述的，如下頁中的表1、表2。如果特征和用例具有各自的BreakDown結(jié)構(gòu)，可以對表1的結(jié)構(gòu)進(jìn)行擴(kuò)展。無論是特征還是用例的描述內(nèi)容中，無法也不應(yīng)該包含太多的實(shí)現(xiàn)細(xì)節(jié)。它們本身無法展示很多界面交互的內(nèi)容，因此，要想完整表達(dá)產(chǎn)品需求，還應(yīng)該包括界面和交互建模的內(nèi)容，這就是上表中兩個(gè)“附加描述文件”列存在的意義。附加描述文件可以是任何類型的文件內(nèi)容，其作用都是用來針對特征（Feature）或用例（UseCases）的內(nèi)容進(jìn)行補(bǔ)充說明，以期更明確、更細(xì)致地描述產(chǎn)品需求。表1：特征描述表（FeaturesList）Feature名稱Feature編號附加描述文件所含用例的名稱用例編號附加描述文件特征的名稱01……(ifexist)用例的名稱01.01……(ifexist)……01.02…………01.03…………n…………n.m……表2：用例描述表（UseCasesList）用例編號：n.m優(yōu)先級：[√]必須[]應(yīng)當(dāng)[]可以[]希望狀態(tài)：[]建議[√]采納[]待定[]駁回創(chuàng)建：日期/人名修改：日期/人名目標(biāo)版本：在哪個(gè)產(chǎn)品版本中實(shí)現(xiàn)用例名稱：……操作者：用戶群中的某一種角色前提條件：前提條件應(yīng)該是系統(tǒng)能夠檢測和驗(yàn)證的業(yè)務(wù)流程：操作者和系統(tǒng)交互的業(yè)務(wù)過程，用3~9個(gè)步驟來描述，明確交互動作和觸發(fā)機(jī)制實(shí)現(xiàn)結(jié)果：業(yè)務(wù)完成后達(dá)到的結(jié)果異常處理：異常情況的處理過程補(bǔ)充說明：可能用到的業(yè)務(wù)規(guī)則等附加說明2.非功能性需求描述2.1非功能性需求的分類為了讓非功能性需求的描述更加系統(tǒng)和易于管理，把這類需求進(jìn)行分類匯總是一個(gè)可取的做法。非功能性需求的分類標(biāo)準(zhǔn)可以有很多種，但我們建議劃分為以下幾類：觀感需求：描述針對產(chǎn)品外觀/界面的期望，規(guī)定了產(chǎn)品外觀/界面想要達(dá)到的目標(biāo)。它與詳細(xì)的界面設(shè)計(jì)是有區(qū)別的，它體現(xiàn)的是用戶感覺。易用性需求：描述產(chǎn)品符合用戶習(xí)慣的能力，或者描述用戶的使用期望。它影響用戶使用產(chǎn)品時(shí)的生產(chǎn)率、錯誤率以及用戶對新產(chǎn)品的接受程度。執(zhí)行需求：執(zhí)行需求是指產(chǎn)品在給定的時(shí)間或特定的精確度來執(zhí)行某些任務(wù)，或者在一段時(shí)間內(nèi)的極端狀態(tài)值。在考慮執(zhí)行需求時(shí)，可以從完成任務(wù)的速度、結(jié)果的精確度、容量、允許值的范圍、單位時(shí)間內(nèi)完成的任務(wù)數(shù)、資源的使用效率、兩次故障間的平均無故障時(shí)間、連續(xù)不停機(jī)時(shí)間等方面入手。它還應(yīng)該包括對風(fēng)險(xiǎn)的控制內(nèi)容。環(huán)境需求：主要描述產(chǎn)品使用的環(huán)境。分為軟件環(huán)境和硬件環(huán)境方面內(nèi)容。還應(yīng)包括使用產(chǎn)品時(shí)必須要提供的合作軟件的內(nèi)容?？删S護(hù)性需求：主要描述產(chǎn)品安裝/升級的方便性、產(chǎn)品出現(xiàn)故障或者用戶錯誤操作后的可恢復(fù)性、用戶使用過程中遇到錯誤能否快速定位等方面的能力。安全性需求：指產(chǎn)品消除潛在風(fēng)險(xiǎn)的能力和對風(fēng)險(xiǎn)的承受能力，包含保密性、可靠性和完整性三個(gè)子特性。保密性指的是數(shù)據(jù)不能被授權(quán)用戶以外的任何人訪問的能力。可靠性指的是授權(quán)用戶可以不受阻止的訪問數(shù)據(jù)、與其它軟件的兼容的能力和產(chǎn)品的強(qiáng)壯度。完整性指的是安預(yù)期目標(biāo)完成任務(wù)的能力。文化和政策需求：這是一類特殊的需求，由于人的習(xí)慣、宗教、語言、禁忌或偏見，可能會導(dǎo)致產(chǎn)品不被接收。2.2非功能性需求的描述方式非功能性需求往往面臨著難以描述、難以量化的問題。但是，產(chǎn)品的所有需求都應(yīng)該是可測量、可驗(yàn)證的，否則，需求就不屬于有效需求、沒有存在的意義。所以，對于非功能性需求，還是要盡可能地設(shè)置數(shù)據(jù)標(biāo)準(zhǔn)，從而將其量化為有效需求。非功能性需求還有一個(gè)特點(diǎn)，就是不同的非功能性需求，其作用覆蓋范圍可能有差別。有的功能性需求是針對整個(gè)產(chǎn)品的，有的可能針對某一項(xiàng)或某幾項(xiàng)功能性需求（特征->用例）。我們使用兩種表格來描述非功能性需求。表3：非功能性需求索引表組別名稱組編號需求名稱需求編號類別作用到的Features界面友好度01快速從界面識別出品牌01.01觀感01/02界面加載時(shí)間盡量短01.02執(zhí)行02表4：非功能性需求描述表需求編號需求驗(yàn)收標(biāo)準(zhǔn)01.0160％的用戶在第一次看見該產(chǎn)品的5秒內(nèi)，就會識別出產(chǎn)品所屬公司01.02在95％的情況下，一般時(shí)段響應(yīng)時(shí)間不超過1.5秒，高峰時(shí)段不超過4秒…………3.產(chǎn)品需求的分析與表述3.1產(chǎn)品需求的形成通過市場調(diào)研、用戶調(diào)查、會議、觀摩同類產(chǎn)品等手段，獲取到盡可能多的與目標(biāo)產(chǎn)品相關(guān)的需求，并從這些需求材料中整理出涉眾需求（StakeholderRequests）。注意！用戶告訴你的，通常是他轉(zhuǎn)化后的解決方案，而不是原始需求；注意收集用戶群中不同角色的各自價(jià)值和關(guān)注點(diǎn)；分析需求時(shí)，應(yīng)遵循“定性->場景->定量”的路線；必要的時(shí)候，整理目標(biāo)產(chǎn)品所涉及到的專業(yè)術(shù)語和詞匯，形成需求說明的詞匯表，作為需求描述的基礎(chǔ)；分析需求的過程總是伴隨著建立領(lǐng)域模型的過程。建立領(lǐng)域模型是需求分析的方法，也是提煉和總結(jié)需求的基礎(chǔ)。使用業(yè)務(wù)流程圖（或UML活動圖）、UML類圖和UML用例圖來表達(dá)領(lǐng)域模型。還可以增加使用數(shù)據(jù)流圖（DFD）。針對領(lǐng)域模型中的業(yè)務(wù)對象，進(jìn)行對象屬性的整理歸納，形成描述文字作為UML類圖的輔助內(nèi)容。表達(dá)領(lǐng)域模型的各種圖形及輔助文字內(nèi)容，應(yīng)作為需求描述的輔助文件。分析需求的過程也會伴隨著對人機(jī)交互的分析，主要圍繞系統(tǒng)操作界面的要求和交互模式的要求。使用界面模擬圖來表達(dá)操作界面的要求，必要時(shí)輔以交互方式的演示。界面模擬圖應(yīng)作為需求描述的輔助文件。通過需求分析，確定出目標(biāo)產(chǎn)品的特性，描述產(chǎn)品的前景，整理出產(chǎn)品的特征（Feature），并標(biāo)定每個(gè)特征的優(yōu)先級。通過Features描述的產(chǎn)品需求，應(yīng)該覆蓋用戶的大部分業(yè)務(wù)；標(biāo)定優(yōu)先級時(shí)，應(yīng)從離主營業(yè)務(wù)的遠(yuǎn)近、發(fā)生頻率的高低兩個(gè)方面來度量。用戶想要和真正需要是有區(qū)別的，沒有識別好優(yōu)先級，可能導(dǎo)致需求過度；對領(lǐng)域建模過程輸出的用例和需求分析整理出的“特征”進(jìn)行功能關(guān)系分析，把各個(gè)用例指定為某個(gè)“特征”的實(shí)現(xiàn)成員，形成“特征”和用例之間的隸屬關(guān)系，從而構(gòu)建出樹型的需求體系。為每個(gè)用例編寫詳細(xì)的規(guī)約內(nèi)容，描述每個(gè)用例的過程，描述每個(gè)用例的業(yè)務(wù)規(guī)則以及對人機(jī)交互的要求。從原始的涉眾需求（StakeholderRequests）中，識別出質(zhì)量、效率、性能等方面的非功能性需求，歸納整理成產(chǎn)品的非功能性需求列表?；谝陨瞎ぷ鹘Y(jié)果，形成一系列產(chǎn)品需求描述文檔，并把產(chǎn)品需求分配到產(chǎn)品版本規(guī)劃上。3.2產(chǎn)品需求的描述載體需求分析過程會形成兩類需求描述載體：1）圖形領(lǐng)域模型的表達(dá)：業(yè)務(wù)流程圖或UML活動圖、UML類圖、UML用例圖，數(shù)據(jù)流圖人機(jī)交互要求的表達(dá)：界面模擬圖及交互演示2）文字功能需求列表：“特征”集、用例（操作流程、業(yè)務(wù)邏輯）非功能需求列表：質(zhì)量／性能／效率等方面要求的表述與驗(yàn)證方法業(yè)務(wù)對象屬性集：配合UML類圖要求把功能需求列表和質(zhì)量需求列表合并為一個(gè)doc文檔，作為產(chǎn)品需求的主描述文檔，形成產(chǎn)品需求規(guī)格說明文檔。而其它文件則以輔助描述文檔的方式，作為主文檔的內(nèi)容補(bǔ)充。任何一個(gè)需求描述文件，必須含有版本歷史記錄表，版本初創(chuàng)及以后的每次內(nèi)容修訂，均應(yīng)在記錄表中予以登記。每次登記內(nèi)容，要包含日期、操作人、內(nèi)容變化概要等3項(xiàng)內(nèi)容。4.需求描述文檔的變更管理4.1版本控制是基礎(chǔ)針對產(chǎn)品需求進(jìn)行管理的核心活動包括三個(gè)方面：定義需求基線——針對某一產(chǎn)品版本，形成意見一致的需求描述；審查需求變更請求，評估其影響，核準(zhǔn)或駁回；以可控的方式把核準(zhǔn)的變更融入開發(fā)工作，保持開發(fā)計(jì)劃與需求的同步；這些需求管理的活動又可以分為四種類型的工作：變更控制——提出申請、分析影響、做出決策、修改需求文檔、修改開發(fā)計(jì)劃、評估需求的穩(wěn)定性；版本控制——定義需求版本標(biāo)識機(jī)制、確定需求文檔的版本；需求狀態(tài)跟蹤——定義可能的需求狀態(tài)、記錄每個(gè)需求的狀態(tài)、報(bào)告所有需求的狀態(tài)分布；需求跟蹤——定義到其它需求的聯(lián)系鏈、定義到其它系統(tǒng)元素的聯(lián)系鏈；從這些工作內(nèi)容可以看出，針對需求描述的版本控制是需求管理活動的基礎(chǔ)之一。良好的需求文檔版本管理，可以避免需求過時(shí)或需求不一致而浪費(fèi)開發(fā)資源。4.2根據(jù)需求變更的類型修改文檔為了便于記錄產(chǎn)品需求的變化，我們概括地把產(chǎn)品需求變更劃分為以下幾種情況：增加／刪除業(yè)務(wù)對象（BO）：增加／刪除業(yè)務(wù)對象時(shí)領(lǐng)域模型會發(fā)生變化，通常會導(dǎo)致用例的增加、刪除或修改。修改業(yè)務(wù)對象：改變業(yè)務(wù)對象的屬性集、改變業(yè)務(wù)對象之間的關(guān)系。改變業(yè)務(wù)對象通常會引起用例的變化。新增／刪除用例修改用例：改變用例的操作流程、改變用例中的系統(tǒng)響應(yīng)、改變用例使用的業(yè)務(wù)規(guī)則等增加／刪除質(zhì)量要求修改質(zhì)量要求增加／刪除軟件界面修改軟件界面：改變軟件界面的布局與內(nèi)容、改變交互模式。針對以上不同類型的需求變更，應(yīng)分別修改相應(yīng)的需求描述載體。對于用例的變化和質(zhì)量要求的變化，要相應(yīng)地修訂產(chǎn)品需求規(guī)格說明文檔。對于涉及業(yè)務(wù)對象變化的，要相應(yīng)地修改領(lǐng)域模型的相關(guān)文件（業(yè)務(wù)流程圖、UML圖、業(yè)務(wù)對象屬性集等）。涉及界面和交互方式變化的，要相應(yīng)地修改界面與交互模擬。4.3產(chǎn)品需求文檔的版本變化標(biāo)識方法為了簡單方便地實(shí)現(xiàn)針對需求的版本管理，我們把產(chǎn)品需求的版本控制分為兩個(gè)級別：微小變更導(dǎo)致的需求文檔版本要發(fā)生變化時(shí)，我們使用文件內(nèi)標(biāo)識：我們要求需求描述文檔的主文件必須是Word文件，這樣可以使用修訂功能來標(biāo)識記錄版本變化；其它不支持修訂痕跡的輔助描述文件，則需要在文件內(nèi)容中添加修改說明。較大變更導(dǎo)致的需求文檔版本要發(fā)生變化時(shí)，我們使用文件外標(biāo)識：從原來的需求文檔復(fù)制出新文件夾或者新文件，通過文件夾或文件的重新命名來標(biāo)識版本變化（新文件夾以版本號來命名）。采用Word文件的修訂功能來標(biāo)識需求版本變化時(shí)，如果需求變更積累太多，可能會導(dǎo)致Word文件的可讀性大大降低，此種情況下，可以為Word文檔保存一個(gè)小的基線版本，然后合并所有修訂內(nèi)容形成一個(gè)新的版本控制起點(diǎn)。5.需求變更的控制方式從建立需求基線后的第一刻起，用戶需求變化就會接踵而至，比如要求新增功能、要求改變功能等。在產(chǎn)品測試、產(chǎn)品演示、用戶試用／正式使用等過程中，用戶需求變化都會隨時(shí)產(chǎn)生。用戶需求變化可能是通過某次活動（比如討論會、演示等）集中收集到的，更可能是平時(shí)零星反饋來的。無論是通過什么方式獲得，這些信息必須得到真實(shí)有效的記錄，而且能夠及時(shí)反饋給產(chǎn)品負(fù)責(zé)人或項(xiàng)目負(fù)責(zé)人。用戶需求變化的記錄格式不做具體要求（建議以禪道項(xiàng)目管理軟件的新建任務(wù)作為記錄方式），但所有記錄必須描述清晰準(zhǔn)確。收集并記錄下來的用戶需求變化，應(yīng)該周期性地進(jìn)行處理。所謂周期性，可以是每月、每周甚至每天，處理周期長短取決于產(chǎn)品處于生命周期的什么階段。某些用戶需求變化可能需要立即處理，比如：需求變化使得當(dāng)前的設(shè)計(jì)開發(fā)方案變得不合理，需求變化是用戶急需實(shí)現(xiàn)的，等等。因此，周期性處理過程中應(yīng)照顧到緊急情況。處理用戶需求變化的過程，就是評估、初審、修改需求描述文檔、評審的過程，就是需求變更控制的過程。5.1需求變更的級別需求變更的可以粗略分為大小兩個(gè)級別。大級別的需求變更通常包括以下幾種變更類型：領(lǐng)域模型發(fā)生變化，比如業(yè)務(wù)流程有所改變、業(yè)務(wù)對象增加／減少／發(fā)生屬性變化，用戶角色增加／減少等。領(lǐng)域模型的變化往往引起其它幾種的需求變更情況的發(fā)生。增加或者減少功能特征（Feature）與用例（UseCase）。增加新的質(zhì)量要求，或者刪除已有的質(zhì)量要求。增加或減少操作界面，或者人機(jī)交互方式發(fā)生重大變化。小級別的需求變更通常包括以下幾種變更類型：用例內(nèi)部發(fā)生變化（比如過程改變、系統(tǒng)響應(yīng)方式改變、業(yè)務(wù)規(guī)則改變等）。提高或降低已有的質(zhì)量要求。界面的內(nèi)容布局改變、人機(jī)交互方式有所改變。5.2需求變更的評估與初審所謂分析評估，就是對每個(gè)用戶需求變化進(jìn)行細(xì)化描述，需求分析人員評估它對產(chǎn)品的價(jià)值、可行性以及它屬于哪種變更類型，評估結(jié)果必須形成內(nèi)容清晰的描述文檔。形成評估結(jié)果后，召集“需求變更初審會議”。初審會議的輸入，是用戶需求變化評估結(jié)果的文檔。初審會議的目標(biāo)，是經(jīng)過討論，確定出哪些用戶需求變化將納入產(chǎn)品需