淺析免疫規(guī)劃信息管理系統(tǒng)的需求管理

(中國人民大學(xué)信息學(xué)院　北京　100872)

一、項(xiàng)目需求管理主要活動

需求管理是需求工程生命周期中重要的一環(huán)，它負(fù)責(zé)“建立并維護(hù)在軟件工程中同客戶達(dá)成的合同”，力圖實(shí)現(xiàn)最終鏟平同需求性的最佳結(jié)合。這種合同都包含在編寫的需求說明書與模型中。通常需求管理活動包括：

1.定義需求基線(baseline，需求文檔的主體)。

2.評審提出的需求變更，評估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。

3.以一種可控制的方式將需求融入到項(xiàng)目中。使當(dāng)前的項(xiàng)目計劃與需求一致。

4.估計變更需求所產(chǎn)生的影響并在此基礎(chǔ)上協(xié)商新的承諾。

5.讓每項(xiàng)需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤。

6.在整個項(xiàng)目過程中跟蹤需求的狀態(tài)及變更情況。

(一)項(xiàng)目需求提出

針對客戶的需求提出，開發(fā)方進(jìn)入需求了解環(huán)節(jié)。需求了解采用訪談、文檔、多方會議等形式采集基礎(chǔ)信息，在此基礎(chǔ)上結(jié)合系統(tǒng)原型進(jìn)行差異化分析。

(二)項(xiàng)目需求分析及評審

在團(tuán)隊(duì)開發(fā)中，充分的溝通是非常有必要的，溝通的方式之一就是通過文檔。不論評審的效果如何，發(fā)現(xiàn)多少問題都可以讓相關(guān)人員了解需求與設(shè)計。而通過相互之間的討論，澄清一些模糊的認(rèn)識，進(jìn)一步理解文檔的含義。評審不但是軟件開發(fā)活動中一個重要的質(zhì)量控制機(jī)制，而且也是一個重要而有效的溝通方式。通過評審可以利用為軟件開發(fā)尋找最佳的解決方案。

評審的作用和目的主要是盡早發(fā)現(xiàn)潛在的問題，盡早糾正缺陷，控制糾正成本的滾雪球效應(yīng)。本階段造成的錯誤如果能夠及時地發(fā)現(xiàn)，或者在后面越早的階段發(fā)現(xiàn)，就能夠及早發(fā)現(xiàn)潛在的風(fēng)險，及時做好防范的對策，做到未雨綢繆。

(三)需求變更控制

需求變更控制是指依據(jù)“變更申請-審批-更改-重新確認(rèn)”的流程處理需求的變更，確保需求的變更不會失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。

用戶對于系統(tǒng)、需求的理解是漸進(jìn)的過程，因此某種意義上說需求變更存在必然性。如何有效率和有效果地管理這些新增需求或變更需求是很重要的。如果需求變更控制不當(dāng)，不但造成新的需求變更得不到滿足，而且對于需求進(jìn)度的管理、對于系統(tǒng)穩(wěn)定性的影響都將是負(fù)面的。變更控制，需要追溯變更的緣由，記錄變更的原因、內(nèi)容，并做好變更比例的度量。保證需求的可追溯性，對于需求變更管理至關(guān)重要；在進(jìn)行需求變更對項(xiàng)目計劃、活動及工作產(chǎn)品的影響評估時尤其需要需求追溯表這些管理工具。

1.需求變更申請

需求變更申請人撰寫“需求變更申請書”，遞交給項(xiàng)目經(jīng)理或客戶方負(fù)責(zé)人。“需求變更申請書”必須闡述：(1)變更原因；(2)變更的內(nèi)容；(3)此變更對項(xiàng)目造成的影響。

2.審批需求變更申請

開發(fā)方負(fù)責(zé)人(項(xiàng)目經(jīng)理)和客戶共同審批“需求變更申請書”。

如果任何一方不同意變更，則退回變更請求，項(xiàng)目按照“原需求文檔”執(zhí)行。

3.更改需求文檔

需求分析員根據(jù)第一步和第二步更改“原需求文檔”，產(chǎn)生新的需求文檔。

4.重新進(jìn)行需求確認(rèn)

重新進(jìn)行需求評審，重新獲取書面的需求承諾。

(四)項(xiàng)目需求跟蹤

需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。

二、免疫規(guī)劃項(xiàng)目需求管理措施

需求管理是需求分析過程中的一個步驟，是一個持續(xù)的不斷完善的過程，軟件項(xiàng)目開發(fā)過程中需求管理的問題有很多，隨時都有用戶需求變更，需求分析的錯誤也時常發(fā)生，需求質(zhì)量難以保，針對這些問題，如何采取有效的措施盡可能減少這些問題可能給項(xiàng)目造成的影響也顯得尤其重要，因?yàn)橐坏┬枨蟮墓芾沓霈F(xiàn)問題，將會影響到不只是那部分需求所相關(guān)的功能，若是在項(xiàng)目的后期才發(fā)現(xiàn)這樣或那樣的需求偏差或者是需求理解錯誤，將會給項(xiàng)目造成不可估量的損失，甚至是直接導(dǎo)致項(xiàng)目的失敗。而運(yùn)用良好的機(jī)制和組織來管理需求不僅可以使得需求更加的規(guī)范，也會使得整個項(xiàng)目管理起來更加方便，實(shí)施起來不會與原始的需求有太大的偏差，或者換句話說，就是最后能夠完成一個用戶想要的產(chǎn)品。

(一)制定需求管理計劃

需求管理計劃往往被軟件項(xiàng)目管理人員所忽視，很多項(xiàng)目經(jīng)理在開發(fā)項(xiàng)目時，一上來就是讓需求分析師跟客戶談需求去，這樣做會導(dǎo)致需求工作的盲目性甚至可能讓需求分析師無所適從。

在本項(xiàng)目啟動時，我通過如下步驟制定需求管理計劃：

1.確定需求溝通機(jī)制；

2.確定需求變更管理辦法；

3.確定需求跟蹤方法；

4.確定需求管理涉及的干系人，并明確職責(zé)；

5.明確需求管理工具；

6.編寫需求管理計劃。

(二)需求調(diào)研與定義

1.業(yè)務(wù)場景分析

業(yè)務(wù)場景場景描述使用人群一、預(yù)防接種信息系統(tǒng)1.網(wǎng)絡(luò)預(yù)約接種通過微信或APP通過網(wǎng)上進(jìn)行預(yù)約(時間、地點(diǎn))兒童家長成人2.兒童接種　　1.首次接種需要建檔2.再次來的兒童直接接種接種單位工作人員3.查詢統(tǒng)計等監(jiān)管功能　　給各級疾控中心提供查詢統(tǒng)計等監(jiān)管功能市、區(qū)疾控中心二、疫苗信息系統(tǒng)1.疫苗出入庫查詢和進(jìn)銷存系統(tǒng)對接各級可以查詢區(qū)級疾控中心市級疾控中心2.查詢統(tǒng)計給各級疾控中心提供查詢統(tǒng)計等監(jiān)管功能市、區(qū)疾控中心

2.系統(tǒng)邊界分析

序號系統(tǒng)邊界關(guān)系描述1與國家平臺的關(guān)系√　預(yù)防接種(個案主索引、常規(guī)報表、個案報表等)通過國家提供的省級免疫平臺接口傳輸?shù)絿移脚_。疫苗注射器、冷鏈設(shè)備和溫度檢測、AEFI監(jiān)測等業(yè)務(wù)操作都是在北京市免疫系統(tǒng)內(nèi)進(jìn)行,產(chǎn)生的數(shù)據(jù)通過國家提供的省級免疫平臺接口傳輸?shù)絿移脚_。2與市區(qū)域衛(wèi)生平臺的關(guān)系√　與市區(qū)域衛(wèi)生平臺數(shù)據(jù)交換,獲取產(chǎn)科醫(yī)院兒童建檔的基本信息和卡介苗、乙肝疫苗接種信息,并向市區(qū)域衛(wèi)生平臺共享人群免疫接種信息。3與市政務(wù)信息資源共享交換平臺的關(guān)系√　對于需要使用疫苗接種信息,而未與市區(qū)域衛(wèi)生平臺建立數(shù)據(jù)交換關(guān)系的各政務(wù)系統(tǒng)(如市教委的學(xué)生管理系統(tǒng)),市免疫規(guī)劃信息系統(tǒng)將利用市政務(wù)信息資源共享平臺共享數(shù)據(jù)。

(三)變更控制的應(yīng)對措施

需求變更控制一般要經(jīng)過變更申請、變更評估、決策、回復(fù)這四大步驟。針對變更控制流程，在項(xiàng)目實(shí)際工作中總結(jié)出了軟件研發(fā)人員在需求變更管理實(shí)踐中的幾點(diǎn)對策：

相互協(xié)作。在討論需求時，研發(fā)人員和用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。

充分交流。需求變更管理的過程非常大程度上就是用戶和研發(fā)人員的交流過程。軟件研發(fā)人員必須學(xué)會認(rèn)真聽取用戶的需求、考慮和設(shè)想，并加以分析和整理。

安排專職人員負(fù)責(zé)需求變更管理。有時研發(fā)任務(wù)較重，研發(fā)人員容易陷入研發(fā)工作中而忽略了和用戶的隨時溝通，因此需要一名專職的需求變更管理人員負(fù)責(zé)和用戶及時交流。

合同約束。需求變更給軟件研發(fā)帶來的影響有目共睹，所以在和用戶簽訂合同時，能增加一些相關(guān)條款，如限定用戶提出需求變更的時間，規(guī)定何種情況的變更能接受、拒絕接受或部分接受，還能規(guī)定發(fā)生需求變更時必須執(zhí)行變更控制流程。

差別對待隨著研發(fā)進(jìn)展，有些用戶會不斷提出一些在項(xiàng)目組看來確實(shí)無法實(shí)現(xiàn)或工作量比較大、對項(xiàng)目進(jìn)度有重大影響的需求。遇見這種情況，研發(fā)人員能向用戶說明，項(xiàng)目的啟動是以最初的基本需求作為研發(fā)前提的，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求)，會使項(xiàng)目不能按時完成。如果用戶堅持實(shí)施新需求，能建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項(xiàng)依據(jù)。同時，還要注意控制新需求提出的頻率。

選用適當(dāng)?shù)难邪l(fā)模型。采用建立原型的研發(fā)模型比較適合需求不明確的研發(fā)項(xiàng)目。研發(fā)人員先根據(jù)用戶對需求的說明建立一個系統(tǒng)原型，再和用戶溝通。一般用戶看到一些實(shí)際的東西后，對需求會有更為周詳?shù)慕忉專邪l(fā)人員可根據(jù)用戶的說明進(jìn)一步完善系統(tǒng)原型。這個過程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現(xiàn)。

用戶參和需求評審。作為需求的提出者，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一。實(shí)際上，在需求評審過程中，用戶往往能提出許多有價值的意見。同時，這也是由用戶對需求進(jìn)行最后確認(rèn)的機(jī)會，能有效減少需求變更的發(fā)生。

(四)需求跟蹤方法

1.建立與維護(hù)需求跟蹤矩陣

正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點(diǎn)。

逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣(即表格)。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單元之間可能存在“一對一”、“一對多”或“多對多”的關(guān)系。由于對應(yīng)關(guān)系比較復(fù)雜，最好在表格中加必要的文字解釋。

當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。

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)的“不一致性”記錄在《需求跟蹤報告》之中，并通報給相關(guān)責(zé)任人。

3.消除不一致

相關(guān)責(zé)任人給出消除“不一致性”的措施和計劃，項(xiàng)目經(jīng)理將該措施和計劃記錄到《需求跟蹤報告》之中。

相關(guān)責(zé)任人消除“不一致性”之后，項(xiàng)目經(jīng)理更新“需求跟蹤矩陣”。

三、項(xiàng)目需求管理流程與實(shí)踐

(一)需求管理流程

1.需求開發(fā)階段：需求責(zé)任人組織進(jìn)行需求調(diào)研，匯總、分析和整理需求。

2.需求評審：對項(xiàng)目需求進(jìn)行評審，如評審?fù)ㄟ^，則轉(zhuǎn)入下一步。

3.根據(jù)技術(shù)需求說明書制定開發(fā)計劃，相關(guān)人員對開發(fā)計劃進(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ā)布。

(二)需求管理實(shí)踐

1.抓住決策者最迫切和最關(guān)心的問題，引起重視。用戶方?jīng)Q策者對項(xiàng)目的關(guān)心重視程度是項(xiàng)目能否順利開展的關(guān)鍵，決策者的真實(shí)意圖也是用戶方的最終需求，因此，在開發(fā)過程中要利用一切機(jī)會了解決策者關(guān)心的問題，同時也要讓他們了解項(xiàng)目的情況。當(dāng)決策者認(rèn)識到項(xiàng)目的重要性時，需求分析工作在人力、物力、時間上就有了保障。

2.建立良好的溝通環(huán)境和氛圍。在溝通時分析人員應(yīng)注意以下幾個方面：1)態(tài)度上要尊重對方，但不謙恭。謙恭可能會讓用戶一時感到滿意，但對長期合作并沒有好處，尤其是在發(fā)生沖突的時候，用戶會習(xí)慣性地感到自己的優(yōu)勢，而忽略分析人員地意見。2)分析人員要努力適應(yīng)不同用戶的語言表達(dá)方式。每個人都有自己的表達(dá)方式，所以優(yōu)秀的分析人員應(yīng)該是一個優(yōu)秀的“傾聽者”，他們能很快的適應(yīng)用戶的語言風(fēng)格，理解他們的意思。

3.建立組織保障，明確的責(zé)任分工。項(xiàng)目開發(fā)一般都會成立相應(yīng)的項(xiàng)目組，常見的組織形式是：產(chǎn)品管理組、質(zhì)量與測試組、程序開發(fā)組、用戶代表組，各組的主要分工是：產(chǎn)品管理組負(fù)責(zé)確定和設(shè)置項(xiàng)目目標(biāo)，根據(jù)需求的優(yōu)先級確定功能規(guī)范，向相關(guān)人員通報項(xiàng)目進(jìn)展。程序管理組負(fù)責(zé)系統(tǒng)分析，根據(jù)軟件開發(fā)標(biāo)準(zhǔn)協(xié)調(diào)日常開發(fā)工作確保及時交付開發(fā)任務(wù)，控制項(xiàng)目進(jìn)度。程序開發(fā)組負(fù)責(zé)按照功能規(guī)范要求交付軟件系統(tǒng)。質(zhì)量與測試組負(fù)責(zé)保證系統(tǒng)符合功能規(guī)范的要求，測試工作與開發(fā)工作是獨(dú)立并行的。用戶代表組負(fù)責(zé)代表用戶方提出需求，負(fù)責(zé)軟件的用戶方測試。

四、結(jié)語

本文論述圍繞于需求管理,需求管理是開發(fā)工作有效進(jìn)行的確證。很明顯需求管理是一種很高層次的系統(tǒng)行為，涉及整個開發(fā)過程和產(chǎn)品本身。需求管理首先要針對需求做出分析，隨后應(yīng)用于產(chǎn)品并提出方案。需求分析的模型正是產(chǎn)品的原型樣本，優(yōu)秀的需求管理提高了這樣的可能性：它使最終產(chǎn)品更接近于解決需求，提高了用戶對產(chǎn)品的滿意度，從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說，需求管理是產(chǎn)品質(zhì)量的基礎(chǔ)。