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

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

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

       需求變更控制：需求變更按照嚴重程度，分為I、II、III級變更。I級變更為系統級變更：該系統、其子系統需求發生重大變更，用戶開發思路和整體工作流程發生變化，對系統各模塊接口關系，數據庫結構要做重大調整，對開發進度造成嚴重影響，需要重新定義需求工作，大量開發代碼需要重新編寫。II級變更為模塊級變更：系統的某個模塊或流程單元發生變動，變更只影響該模塊或者流程內部，對系統整體模塊接口關系，數據庫結構等未造成重大影響，僅影響工作量和開發進度。III級變更為功能性變更：變更僅僅是調整系統的小功能單元，變更不影響系統整體結構和模塊結構，也不會對開發進度和造成影響。

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

產品線支撐的原型法策略架起管理者和信息化實施團隊之間有效溝通的橋梁

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