(中國人民大學(xué)信息學(xué)院 北京 100872)
需求管理是需求工程生命周期中重要的一環(huán),它負(fù)責(zé)“建立并維護(hù)在軟件工程中同客戶達(dá)成的合同”,力圖實(shí)現(xiàn)最終鏟平同需求性的最佳結(jié)合。這種合同都包含在編寫的需求說明書與模型中。通常需求管理活動(dòng)包括:
1.定義需求基線(baseline,需求文檔的主體)。
2.評(píng)審提出的需求變更,評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。
3.以一種可控制的方式將需求融入到項(xiàng)目中。使當(dāng)前的項(xiàng)目計(jì)劃與需求一致。
4.估計(jì)變更需求所產(chǎn)生的影響并在此基礎(chǔ)上協(xié)商新的承諾。
5.讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤。
6.在整個(gè)項(xiàng)目過程中跟蹤需求的狀態(tài)及變更情況。
針對(duì)客戶的需求提出,開發(fā)方進(jìn)入需求了解環(huán)節(jié)。需求了解采用訪談、文檔、多方會(huì)議等形式采集基礎(chǔ)信息,在此基礎(chǔ)上結(jié)合系統(tǒng)原型進(jìn)行差異化分析。
在團(tuán)隊(duì)開發(fā)中,充分的溝通是非常有必要的,溝通的方式之一就是通過文檔。不論評(píng)審的效果如何,發(fā)現(xiàn)多少問題都可以讓相關(guān)人員了解需求與設(shè)計(jì)。而通過相互之間的討論,澄清一些模糊的認(rèn)識(shí),進(jìn)一步理解文檔的含義。評(píng)審不但是軟件開發(fā)活動(dòng)中一個(gè)重要的質(zhì)量控制機(jī)制,而且也是一個(gè)重要而有效的溝通方式。通過評(píng)審可以利用為軟件開發(fā)尋找最佳的解決方案。
評(píng)審的作用和目的主要是盡早發(fā)現(xiàn)潛在的問題,盡早糾正缺陷,控制糾正成本的滾雪球效應(yīng)。本階段造成的錯(cuò)誤如果能夠及時(shí)地發(fā)現(xiàn),或者在后面越早的階段發(fā)現(xiàn),就能夠及早發(fā)現(xiàn)潛在的風(fēng)險(xiǎn),及時(shí)做好防范的對(duì)策,做到未雨綢繆。
需求變更控制是指依據(jù)“變更申請(qǐng)-審批-更改-重新確認(rèn)”的流程處理需求的變更,確保需求的變更不會(huì)失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。
用戶對(duì)于系統(tǒng)、需求的理解是漸進(jìn)的過程,因此某種意義上說需求變更存在必然性。如何有效率和有效果地管理這些新增需求或變更需求是很重要的。如果需求變更控制不當(dāng),不但造成新的需求變更得不到滿足,而且對(duì)于需求進(jìn)度的管理、對(duì)于系統(tǒng)穩(wěn)定性的影響都將是負(fù)面的。變更控制,需要追溯變更的緣由,記錄變更的原因、內(nèi)容,并做好變更比例的度量。保證需求的可追溯性,對(duì)于需求變更管理至關(guān)重要;在進(jìn)行需求變更對(duì)項(xiàng)目計(jì)劃、活動(dòng)及工作產(chǎn)品的影響評(píng)估時(shí)尤其需要需求追溯表這些管理工具。
1.需求變更申請(qǐng)
需求變更申請(qǐng)人撰寫“需求變更申請(qǐng)書”,遞交給項(xiàng)目經(jīng)理或客戶方負(fù)責(zé)人?!靶枨笞兏暾?qǐng)書”必須闡述:(1)變更原因;(2)變更的內(nèi)容;(3)此變更對(duì)項(xiàng)目造成的影響。
2.審批需求變更申請(qǐng)
開發(fā)方負(fù)責(zé)人(項(xiàng)目經(jīng)理)和客戶共同審批“需求變更申請(qǐng)書”。
如果任何一方不同意變更,則退回變更請(qǐng)求,項(xiàng)目按照“原需求文檔”執(zhí)行。
3.更改需求文檔
需求分析員根據(jù)第一步和第二步更改“原需求文檔”,產(chǎn)生新的需求文檔。
4.重新進(jìn)行需求確認(rèn)
重新進(jìn)行需求評(píng)審,重新獲取書面的需求承諾。
需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系,建立與維護(hù)“需求跟蹤矩陣”,確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。
需求管理是需求分析過程中的一個(gè)步驟,是一個(gè)持續(xù)的不斷完善的過程,軟件項(xiàng)目開發(fā)過程中需求管理的問題有很多,隨時(shí)都有用戶需求變更,需求分析的錯(cuò)誤也時(shí)常發(fā)生,需求質(zhì)量難以保,針對(duì)這些問題,如何采取有效的措施盡可能減少這些問題可能給項(xiàng)目造成的影響也顯得尤其重要,因?yàn)橐坏┬枨蟮墓芾沓霈F(xiàn)問題,將會(huì)影響到不只是那部分需求所相關(guān)的功能,若是在項(xiàng)目的后期才發(fā)現(xiàn)這樣或那樣的需求偏差或者是需求理解錯(cuò)誤,將會(huì)給項(xiàng)目造成不可估量的損失,甚至是直接導(dǎo)致項(xiàng)目的失敗。而運(yùn)用良好的機(jī)制和組織來管理需求不僅可以使得需求更加的規(guī)范,也會(huì)使得整個(gè)項(xiàng)目管理起來更加方便,實(shí)施起來不會(huì)與原始的需求有太大的偏差,或者換句話說,就是最后能夠完成一個(gè)用戶想要的產(chǎn)品。
需求管理計(jì)劃往往被軟件項(xiàng)目管理人員所忽視,很多項(xiàng)目經(jīng)理在開發(fā)項(xiàng)目時(shí),一上來就是讓需求分析師跟客戶談需求去,這樣做會(huì)導(dǎo)致需求工作的盲目性甚至可能讓需求分析師無所適從。
在本項(xiàng)目啟動(dòng)時(shí),我通過如下步驟制定需求管理計(jì)劃:
1.確定需求溝通機(jī)制;
2.確定需求變更管理辦法;
3.確定需求跟蹤方法;
4.確定需求管理涉及的干系人,并明確職責(zé);
5.明確需求管理工具;
6.編寫需求管理計(jì)劃。
1.業(yè)務(wù)場景分析
業(yè)務(wù)場景場景描述使用人群一、預(yù)防接種信息系統(tǒng)1.網(wǎng)絡(luò)預(yù)約接種通過微信或APP通過網(wǎng)上進(jìn)行預(yù)約(時(shí)間、地點(diǎn))兒童家長成人2.兒童接種 1.首次接種需要建檔2.再次來的兒童直接接種接種單位工作人員3.查詢統(tǒng)計(jì)等監(jiān)管功能 給各級(jí)疾控中心提供查詢統(tǒng)計(jì)等監(jiān)管功能市、區(qū)疾控中心二、疫苗信息系統(tǒng)1.疫苗出入庫查詢和進(jìn)銷存系統(tǒng)對(duì)接各級(jí)可以查詢區(qū)級(jí)疾控中心市級(jí)疾控中心2.查詢統(tǒng)計(jì)給各級(jí)疾控中心提供查詢統(tǒng)計(jì)等監(jiān)管功能市、區(qū)疾控中心
2.系統(tǒng)邊界分析
序號(hào)系統(tǒng)邊界關(guān)系描述1與國家平臺(tái)的關(guān)系√ 預(yù)防接種(個(gè)案主索引、常規(guī)報(bào)表、個(gè)案報(bào)表等)通過國家提供的省級(jí)免疫平臺(tái)接口傳輸?shù)絿移脚_(tái)。疫苗注射器、冷鏈設(shè)備和溫度檢測、AEFI監(jiān)測等業(yè)務(wù)操作都是在北京市免疫系統(tǒng)內(nèi)進(jìn)行,產(chǎn)生的數(shù)據(jù)通過國家提供的省級(jí)免疫平臺(tái)接口傳輸?shù)絿移脚_(tái)。2與市區(qū)域衛(wèi)生平臺(tái)的關(guān)系√ 與市區(qū)域衛(wèi)生平臺(tái)數(shù)據(jù)交換,獲取產(chǎn)科醫(yī)院兒童建檔的基本信息和卡介苗、乙肝疫苗接種信息,并向市區(qū)域衛(wèi)生平臺(tái)共享人群免疫接種信息。3與市政務(wù)信息資源共享交換平臺(tái)的關(guān)系√ 對(duì)于需要使用疫苗接種信息,而未與市區(qū)域衛(wèi)生平臺(tái)建立數(shù)據(jù)交換關(guān)系的各政務(wù)系統(tǒng)(如市教委的學(xué)生管理系統(tǒng)),市免疫規(guī)劃信息系統(tǒng)將利用市政務(wù)信息資源共享平臺(tái)共享數(shù)據(jù)。
需求變更控制一般要經(jīng)過變更申請(qǐng)、變更評(píng)估、決策、回復(fù)這四大步驟。針對(duì)變更控制流程,在項(xiàng)目實(shí)際工作中總結(jié)出了軟件研發(fā)人員在需求變更管理實(shí)踐中的幾點(diǎn)對(duì)策:
相互協(xié)作。在討論需求時(shí),研發(fā)人員和用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度,對(duì)能解決的問題盡量解決。
充分交流。需求變更管理的過程非常大程度上就是用戶和研發(fā)人員的交流過程。軟件研發(fā)人員必須學(xué)會(huì)認(rèn)真聽取用戶的需求、考慮和設(shè)想,并加以分析和整理。
安排專職人員負(fù)責(zé)需求變更管理。有時(shí)研發(fā)任務(wù)較重,研發(fā)人員容易陷入研發(fā)工作中而忽略了和用戶的隨時(shí)溝通,因此需要一名專職的需求變更管理人員負(fù)責(zé)和用戶及時(shí)交流。
合同約束。需求變更給軟件研發(fā)帶來的影響有目共睹,所以在和用戶簽訂合同時(shí),能增加一些相關(guān)條款,如限定用戶提出需求變更的時(shí)間,規(guī)定何種情況的變更能接受、拒絕接受或部分接受,還能規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。
差別對(duì)待隨著研發(fā)進(jìn)展,有些用戶會(huì)不斷提出一些在項(xiàng)目組看來確實(shí)無法實(shí)現(xiàn)或工作量比較大、對(duì)項(xiàng)目進(jìn)度有重大影響的需求。遇見這種情況,研發(fā)人員能向用戶說明,項(xiàng)目的啟動(dòng)是以最初的基本需求作為研發(fā)前提的,如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求,但實(shí)際上是增加了工作量的新需求),會(huì)使項(xiàng)目不能按時(shí)完成。如果用戶堅(jiān)持實(shí)施新需求,能建議用戶將新需求按重要和緊迫程度劃分檔次,作為需求變更評(píng)估的一項(xiàng)依據(jù)。同時(shí),還要注意控制新需求提出的頻率。
選用適當(dāng)?shù)难邪l(fā)模型。采用建立原型的研發(fā)模型比較適合需求不明確的研發(fā)項(xiàng)目。研發(fā)人員先根據(jù)用戶對(duì)需求的說明建立一個(gè)系統(tǒng)原型,再和用戶溝通。一般用戶看到一些實(shí)際的東西后,對(duì)需求會(huì)有更為周詳?shù)慕忉?,研發(fā)人員可根據(jù)用戶的說明進(jìn)一步完善系統(tǒng)原型。這個(gè)過程重復(fù)幾次后,系統(tǒng)原型逐漸向最終的用戶需求靠攏,從根本上減少需求變更的出現(xiàn)。
用戶參和需求評(píng)審。作為需求的提出者,用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實(shí)際上,在需求評(píng)審過程中,用戶往往能提出許多有價(jià)值的意見。同時(shí),這也是由用戶對(duì)需求進(jìn)行最后確認(rèn)的機(jī)會(huì),能有效減少需求變更的發(fā)生。
1.建立與維護(hù)需求跟蹤矩陣
正向跟蹤。檢查需求文檔中的每個(gè)需求是否都能在后續(xù)工作成果中找到對(duì)應(yīng)點(diǎn)。
逆向跟蹤。檢查設(shè)計(jì)文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。
正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式,都要建立與維護(hù)需求跟蹤矩陣(即表格)。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對(duì)應(yīng)關(guān)系。矩陣單元之間可能存在“一對(duì)一”、“一對(duì)多”或“多對(duì)多”的關(guān)系。由于對(duì)應(yīng)關(guān)系比較復(fù)雜,最好在表格中加必要的文字解釋。
當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時(shí),要及時(shí)更新需求跟蹤矩陣。
2.查找不一致
使用需求跟蹤矩陣的優(yōu)點(diǎn)是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處,例如:
后續(xù)工作成果沒有實(shí)現(xiàn)需求文檔中的某些需求。
后續(xù)工作成果實(shí)現(xiàn)了需求文檔中不存在的需求。
后續(xù)工作成果沒有正確實(shí)現(xiàn)需求文檔中的需求。
項(xiàng)目經(jīng)理將發(fā)現(xiàn)的“不一致性”記錄在《需求跟蹤報(bào)告》之中,并通報(bào)給相關(guān)責(zé)任人。
3.消除不一致
相關(guān)責(zé)任人給出消除“不一致性”的措施和計(jì)劃,項(xiàng)目經(jīng)理將該措施和計(jì)劃記錄到《需求跟蹤報(bào)告》之中。
相關(guān)責(zé)任人消除“不一致性”之后,項(xiàng)目經(jīng)理更新“需求跟蹤矩陣”。
1.需求開發(fā)階段:需求責(zé)任人組織進(jìn)行需求調(diào)研,匯總、分析和整理需求。
2.需求評(píng)審:對(duì)項(xiàng)目需求進(jìn)行評(píng)審,如評(píng)審?fù)ㄟ^,則轉(zhuǎn)入下一步。
3.根據(jù)技術(shù)需求說明書制定開發(fā)計(jì)劃,相關(guān)人員對(duì)開發(fā)計(jì)劃進(jìn)行承諾。
4.項(xiàng)目開發(fā)過程:包括開發(fā)和測試,在開發(fā)階段建立需求跟蹤進(jìn)度表。
5.需求變更控制過程。
6.開發(fā)完畢后,提交項(xiàng)目產(chǎn)品進(jìn)行驗(yàn)收,驗(yàn)收通過后產(chǎn)品發(fā)布。
1.抓住決策者最迫切和最關(guān)心的問題,引起重視。用戶方?jīng)Q策者對(duì)項(xiàng)目的關(guān)心重視程度是項(xiàng)目能否順利開展的關(guān)鍵,決策者的真實(shí)意圖也是用戶方的最終需求,因此,在開發(fā)過程中要利用一切機(jī)會(huì)了解決策者關(guān)心的問題,同時(shí)也要讓他們了解項(xiàng)目的情況。當(dāng)決策者認(rèn)識(shí)到項(xiàng)目的重要性時(shí),需求分析工作在人力、物力、時(shí)間上就有了保障。
2.建立良好的溝通環(huán)境和氛圍。在溝通時(shí)分析人員應(yīng)注意以下幾個(gè)方面:1)態(tài)度上要尊重對(duì)方,但不謙恭。謙恭可能會(huì)讓用戶一時(shí)感到滿意,但對(duì)長期合作并沒有好處,尤其是在發(fā)生沖突的時(shí)候,用戶會(huì)習(xí)慣性地感到自己的優(yōu)勢,而忽略分析人員地意見。2)分析人員要努力適應(yīng)不同用戶的語言表達(dá)方式。每個(gè)人都有自己的表達(dá)方式,所以優(yōu)秀的分析人員應(yīng)該是一個(gè)優(yōu)秀的“傾聽者”,他們能很快的適應(yīng)用戶的語言風(fēng)格,理解他們的意思。
3.建立組織保障,明確的責(zé)任分工。項(xiàng)目開發(fā)一般都會(huì)成立相應(yīng)的項(xiàng)目組,常見的組織形式是:產(chǎn)品管理組、質(zhì)量與測試組、程序開發(fā)組、用戶代表組,各組的主要分工是:產(chǎn)品管理組負(fù)責(zé)確定和設(shè)置項(xiàng)目目標(biāo),根據(jù)需求的優(yōu)先級(jí)確定功能規(guī)范,向相關(guān)人員通報(bào)項(xiàng)目進(jìn)展。程序管理組負(fù)責(zé)系統(tǒng)分析,根據(jù)軟件開發(fā)標(biāo)準(zhǔn)協(xié)調(diào)日常開發(fā)工作確保及時(shí)交付開發(fā)任務(wù),控制項(xiàng)目進(jìn)度。程序開發(fā)組負(fù)責(zé)按照功能規(guī)范要求交付軟件系統(tǒng)。質(zhì)量與測試組負(fù)責(zé)保證系統(tǒng)符合功能規(guī)范的要求,測試工作與開發(fā)工作是獨(dú)立并行的。用戶代表組負(fù)責(zé)代表用戶方提出需求,負(fù)責(zé)軟件的用戶方測試。
本文論述圍繞于需求管理,需求管理是開發(fā)工作有效進(jìn)行的確證。很明顯需求管理是一種很高層次的系統(tǒng)行為,涉及整個(gè)開發(fā)過程和產(chǎn)品本身。需求管理首先要針對(duì)需求做出分析,隨后應(yīng)用于產(chǎn)品并提出方案。需求分析的模型正是產(chǎn)品的原型樣本,優(yōu)秀的需求管理提高了這樣的可能性:它使最終產(chǎn)品更接近于解決需求,提高了用戶對(duì)產(chǎn)品的滿意度,從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說,需求管理是產(chǎn)品質(zhì)量的基礎(chǔ)。