項(xiàng)目經(jīng)理組織舉行用戶需求的同行評審會議，同行評審會議由項(xiàng)目經(jīng)理和系統(tǒng)分析員以及項(xiàng)目經(jīng)理確定的相關(guān)涉眾人員參加。如果該需求文檔通過了評審，則由項(xiàng)目經(jīng)理與客戶代表共同對該需求文檔進(jìn)行最終確認(rèn)，并由客戶代表和項(xiàng)目經(jīng)理簽字認(rèn)可。如果該需求文檔未通過評審，則由需求開發(fā)人員繼續(xù)調(diào)研，修改《用戶需求說明書》并更新《用戶需求列表》作為附件，直到其通過評審，再由項(xiàng)目經(jīng)理與用戶簽字認(rèn)可。簽字認(rèn)可的《用戶需求說明書》即作為需求基線的組成部分，由配置管理人員遷入受控庫的基線區(qū)建立需求基線，標(biāo)明其版本，并對其進(jìn)行嚴(yán)格的配置管理。

       在完成《軟件需求規(guī)格說明書》后，同樣要舉行相應(yīng)的需求同行評審會議，最終簽字認(rèn)可的《軟件需求規(guī)格說明書》并《軟件需求列表》也作為需求基線的組成部分，由配置管理人員遷入受控庫的基線區(qū)建立需求基線，標(biāo)明其版本，并對其進(jìn)行嚴(yán)格的配置管理。

       需求跟蹤：《用戶需求說明書》和《軟件需求規(guī)格說明書》一旦經(jīng)過需求確認(rèn)后，項(xiàng)目經(jīng)理則開始按照《需求跟蹤規(guī)程》，并根據(jù)《軟件需求列表》中對應(yīng)的業(yè)務(wù)功能點(diǎn)，對該軟件需求中涉及到的每個(gè)業(yè)務(wù)功能進(jìn)行跟蹤，動態(tài)更新《需求跟蹤報(bào)告》。 《需求跟蹤報(bào)告》每周至少周期性的更新一次，當(dāng)項(xiàng)目變更或者項(xiàng)目經(jīng)理發(fā)現(xiàn)需求與項(xiàng)目實(shí)施過程存在不符合項(xiàng)時(shí)，也要及時(shí)更新《需求跟蹤報(bào)告》。在項(xiàng)目進(jìn)入每一個(gè)里程碑階段（基線階段，比如單元測試、系統(tǒng)測試、預(yù)結(jié)項(xiàng)等）時(shí)，也要更新《需求跟蹤報(bào)告》。并相應(yīng)的組織人員更改所有相關(guān)需求文檔（包括《軟件需求規(guī)格說明書》并《軟件需求列表》以及其附件），以及相應(yīng)的工作產(chǎn)品，如程序編碼和測試用例等，使得每一個(gè)軟件的需求均能夠與后續(xù)工作成果保持一致。

       需求變更控制：需求變更按照嚴(yán)重程度，分為I、II、III級變更。I級變更為系統(tǒng)級變更：該系統(tǒng)、其子系統(tǒng)需求發(fā)生重大變更，用戶開發(fā)思路和整體工作流程發(fā)生變化，對系統(tǒng)各模塊接口關(guān)系，數(shù)據(jù)庫結(jié)構(gòu)要做重大調(diào)整，對開發(fā)進(jìn)度造成嚴(yán)重影響，需要重新定義需求工作，大量開發(fā)代碼需要重新編寫。II級變更為模塊級變更：系統(tǒng)的某個(gè)模塊或流程單元發(fā)生變動，變更只影響該模塊或者流程內(nèi)部，對系統(tǒng)整體模塊接口關(guān)系，數(shù)據(jù)庫結(jié)構(gòu)等未造成重大影響，僅影響工作量和開發(fā)進(jìn)度。III級變更為功能性變更：變更僅僅是調(diào)整系統(tǒng)的小功能單元，變更不影響系統(tǒng)整體結(jié)構(gòu)和模塊結(jié)構(gòu)，也不會對開發(fā)進(jìn)度和造成影響。

       三種級別的需求的變更均可以由項(xiàng)目經(jīng)理、系統(tǒng)分析員或者相關(guān)用戶提出，需求變更提出后，交予項(xiàng)目經(jīng)理確認(rèn)，由項(xiàng)目經(jīng)理初步確定變更級別。I、II級需求的變更，項(xiàng)目經(jīng)理需首先向CCB提交《需求變更控制報(bào)告》在變更申請中，需要將變更原因及變更的影響范圍進(jìn)行詳細(xì)描述。如果CCB同意了該變更申請，則由項(xiàng)目經(jīng)理通知相關(guān)受影響組和個(gè)人，組織項(xiàng)目組成員進(jìn)行需求變更工作，即重新進(jìn)行需求開發(fā)、需求確認(rèn)，更新《用戶需求說明書》和《軟件需求規(guī)格說明書》，項(xiàng)目經(jīng)理并及時(shí)更新《需求跟蹤報(bào)告》，要對應(yīng)的填寫配置管理人員亦建立新版本的需求基線。如果變更申請被拒絕，CCB則需求在變更申請中說明理由，項(xiàng)目則繼續(xù)按原計(jì)劃進(jìn)行。配置管理人員根據(jù)配置項(xiàng)變更控制規(guī)程中基線變更的流程進(jìn)行需求基線的變更控制。在《需求跟蹤報(bào)告》中，要標(biāo)明需求變更級別，如果I，II級變更，要填寫該變更對應(yīng)的《需求跟蹤報(bào)告》的文檔編號。III級需求變更，項(xiàng)目經(jīng)理確認(rèn)后可直接更新《需求跟蹤報(bào)告》，并且更新《用戶需求說明書》和《軟件需求規(guī)格說明書》，變更后交由用戶進(jìn)行簽字確認(rèn)，不需交由CCB進(jìn)行評審。當(dāng)III級變更數(shù)量過于頻繁時(shí)，應(yīng)當(dāng)引起項(xiàng)目經(jīng)理注意，查找問題所在。

產(chǎn)品線支撐的原型法策略架起管理者和信息化實(shí)施團(tuán)隊(duì)之間有效溝通的橋梁

在“需求分析”、“原型設(shè)計(jì)”兩個(gè)階段中，開發(fā)者和用戶一起為想象中的系統(tǒng)的某些主要部分定義需求和規(guī)格說明，并由開發(fā)者在規(guī)格說明級用原型描述語言構(gòu)造一個(gè)系統(tǒng)原型，它代表了部分系統(tǒng)，包括那些為滿足用戶需求的必要屬性。該原型可用來幫助分析和設(shè)計(jì)工作，而不是一個(gè)軟件產(chǎn)