議時間;
4. 通過調(diào)研會議，需求調(diào)研和分析小組成員針對調(diào)研問題或新發(fā)現(xiàn)的問題進(jìn)行討論，達(dá)成一致的形成結(jié)論，由需求調(diào)研和分析小組成員簽字確認(rèn)，不能達(dá)成一致的，需求負(fù)責(zé)人整理形成備忘錄提交到項目經(jīng)理，由項目經(jīng)理組織更高層的會議處理解決;一般調(diào)研會議需要反復(fù)召開多次才能把需求基本清晰化;
5. 系統(tǒng)分析員編寫業(yè)務(wù)需求說明書。如編寫過程仍有之前因為考慮不周遺漏的問題，則通過電話、會議等形式與客戶溝通交流，之后的處理方式與第4點一致;業(yè)務(wù)需求說明書主要包括以下幾方面的內(nèi)容：
1) 業(yè)務(wù)概述。簡要說明業(yè)務(wù)意義，何時辦理，頻率多少(如一天一次、一月一次等)等;
2) 業(yè)務(wù)流程。說明該業(yè)務(wù)是如何辦理的，必要時通過流程圖、序列圖等圖形化說明;
3) 業(yè)務(wù)規(guī)則。說明辦理該業(yè)務(wù)有什么規(guī)則，需要滿足什么條件等;
4) 輸入信息。說明辦理該業(yè)務(wù)需提供何種資料，需何種信息等;
5) 輸出信息。說明辦理該業(yè)務(wù)后會打印何種資料，產(chǎn)生何種電子化信息等;
6) 管理崗位與權(quán)限。說明什么角色的人可以辦理或?qū)徍嗽摌I(yè)務(wù)。
6. 業(yè)務(wù)需求說明書編寫完畢后，系統(tǒng)分析員提交給項目經(jīng)理，然后組織內(nèi)部評審會議。評審會議的目的是控制需求質(zhì)量。評審人員包括實施部門內(nèi)的系統(tǒng)分析員、其他事業(yè)部實施部門的系統(tǒng)分析員、質(zhì)量控制部QA、測試人月等。主要從以下幾方面評審：
1) 可讀。從文檔編寫格式、語言表達(dá)是否有二義、是否使用過多的技術(shù)術(shù)語、客戶是否易于理解、是否可以直接作為系統(tǒng)設(shè)計文檔的基礎(chǔ)等方面考量;
2) 完整?？剂啃枨笫欠褚迅采w了用戶所有的業(yè)務(wù)需要;
3) 一致?？剂啃枨笫欠衽c客戶所要求的一致;
4) 可測試。從測試的角度考量需求中的業(yè)務(wù)規(guī)則是否可以明確無歧義的轉(zhuǎn)換為測試用例;
5) 實現(xiàn)可能。從技術(shù)的角度考量業(yè)務(wù)規(guī)則是否能被滿足，目前的技術(shù)是否支持等方面考量。
7. 內(nèi)部評審?fù)ㄟ^后，通過郵件方式發(fā)送給客戶需求負(fù)責(zé)人，同時抄送給信息部門相關(guān)負(fù)責(zé)人，明確反饋時間，要求客戶對需求予以確認(rèn);客戶如提出異議，則重復(fù)以上流程，直至達(dá)成一致;
8. 客戶簽字確認(rèn)，建立業(yè)務(wù)需求基線。
值得一提的是，在迭代過程中，有時候為了加快開發(fā)進(jìn)度，充分利用資源，可能獲得客戶口頭上的確認(rèn)后就開始進(jìn)入后續(xù)的功能需求和系統(tǒng)設(shè)計階段。
§1.2.4 開發(fā)功能需求
功能需求主要通過原型設(shè)計、原型展示和討論、需求會議和評審會議等方法開發(fā)。在每一迭代開發(fā)的過程，我們按照如下流程開發(fā)功能需求：
1. 系統(tǒng)分析員根據(jù)業(yè)務(wù)需求說明書設(shè)計系統(tǒng)界面原型文檔(Word格式);
2. 初級程序員根據(jù)系統(tǒng)界面原型文檔開發(fā)界面原型。由于我們的技術(shù)體系基于J2EE，因而界面原型使用Web方式展示，原型文件為HTML文件;
3. 組織內(nèi)部評審會議，主要從以下幾方面評審：
1) 完整性。原型界面是否完全表達(dá)了業(yè)務(wù)需要，功能是否完備等;通常來說，如不完備但又無法使用原型展示的，都會建議在界面原型文檔中補(bǔ)充說明;
2) 技術(shù)可行性。目前的技術(shù)是否支持，如不支持或?qū)崿F(xiàn)難度較大有什么可替換方案等;
3) 操作簡便性。界面設(shè)計是否合理，是否清晰展示了業(yè)務(wù)數(shù)據(jù)，是否便于用戶操作等;
4. 內(nèi)部評審?fù)戤吅?，由項目?jīng)理協(xié)調(diào)客戶評審，征求客戶意見，該項任務(wù)一般由系統(tǒng)分析員負(fù)責(zé)?？蛻粼u審?fù)ㄟ^原型展示的方式進(jìn)行，由系統(tǒng)分析員逐個介紹各個功能模塊，包括界面的數(shù)據(jù)展示方式、操作方式，如彈出窗口確認(rèn)、彈出查詢窗口、如何輸入數(shù)據(jù)等。通過原型展示，可以讓客戶看到未來系統(tǒng)的“樣子”，便于及時發(fā)現(xiàn)問題，減少返工;在展示過程中，客戶可隨時提出意見或建議與系統(tǒng)分析員互動交流，最終確認(rèn)界面原型。
5. 客戶確認(rèn)過程中，如對某些細(xì)節(jié)無法達(dá)成一致的，則形成問題日志，提交給項目經(jīng)理，由項目經(jīng)理組織更高層的評審會議解決，直至雙方達(dá)成一致;
6. 確認(rèn)的電子文檔和紙質(zhì)文檔分別通過配置管理系統(tǒng)和檔案系統(tǒng)進(jìn)行歸檔。
通常情況下，我們以系統(tǒng)界面原型的確認(rèn)以客戶的書面簽字為準(zhǔn)。與業(yè)務(wù)需求說明書開發(fā)類似，在實際項目過程中，為加快開發(fā)進(jìn)度，在取得客戶口頭、郵件或會議紀(jì)要的確認(rèn)后，就可以組織開發(fā)人員對部分模塊進(jìn)行開發(fā)了。