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