產(chǎn)品需求管理

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