常用的業(yè)務(wù)功能，用戶可以在此基礎(chǔ)上，對比自己的實際需求，提出不同的需要更改的和新增的需求。這種增量迭代的思路，減少了用戶的工作量和重復(fù)工作，有助于用戶清楚地描述用戶需求。
項目研發(fā)人員有時還能夠?qū)⒃拖到y(tǒng)展示給業(yè)務(wù)人員，通過更直觀的方式給銀行業(yè)務(wù)部門的人員分析展示原型業(yè)務(wù)系統(tǒng)，從而更有效地幫助業(yè)務(wù)人員比對自己銀行的業(yè)客戶到底是需要什么樣的軟件了。
3.2 需求分析
需求分析是提煉用戶的需要，并最終完成客戶同意并簽字的需求分析報告的過程。需求分析過程分為訪談階段、誘導階段和確認階段三個過程。在需求訪談階段，項目開發(fā)人員通過與金融業(yè)務(wù)部門領(lǐng)導、主管和相關(guān)業(yè)務(wù)人員關(guān)于項目需求方向、組織架構(gòu)、業(yè)務(wù)流程和軟硬件環(huán)境的討論交流，可以從宏觀上把握項目的需求，建立起溝通渠道，確定客戶承諾的接口人，提交項目的調(diào)查報告以及業(yè)務(wù)流程報告等。在誘導階段，以調(diào)查報告及業(yè)務(wù)流程為基礎(chǔ)，結(jié)合現(xiàn)有的技術(shù)條件和軟件基礎(chǔ)將業(yè)務(wù)流程模型化，并與用戶不斷溝通，即時獲取反饋信息，從而可以對客戶的需求進行深度挖掘，將客戶的不可見的需求轉(zhuǎn)化為明確的需求。所要提交的文檔有原型反饋報告和經(jīng)過更新的業(yè)務(wù)流程報告。在確認階段，是在原型反饋報告和業(yè)務(wù)流程報告的基礎(chǔ)上，通過更進一步的細化業(yè)務(wù)流程，改進原型系統(tǒng)，撰寫需求分析報告并送交評審。
在這一需求分析的最后階段，要促使開發(fā)方和用戶之間就系統(tǒng)需求達成一致，完成客戶同意并簽字的需求分析報告及相關(guān)支持的資料。在需求分析的過程中，對需求劃分優(yōu)先級的分析也是至關(guān)重要的一個環(huán)節(jié)，在某個時刻，我們?nèi)绾沃滥男┬枨髮儆凇氨仨氉觥?，哪些屬于“?yīng)該做”，哪些又屬于“可以做”。在銀行軟件的項目中，也要對客戶需求劃分優(yōu)先級，對于已經(jīng)識別的客戶需求進行評估，分清哪些是項目關(guān)鍵路徑上的需求，必須完成的，哪些是不重要也不緊急的需求，甚至留待二期中完成用戶也可以接受的。
要理解這一點：用戶反饋非常關(guān)鍵。用戶并不關(guān)心你采用什么方式去滿足他們的需求，但當用戶看到最關(guān)鍵的功能都實現(xiàn)得很好時，如果還有幾個無關(guān)大局的需求暫時沒有滿足，也就不會引起太大的反應(yīng)了。
3.3 編寫規(guī)格說明
軟件需求是軟件產(chǎn)品開發(fā)的依據(jù)，也是整個開發(fā)過程各項活動的基礎(chǔ)。需求階段不細致的工作，軟件需求的不明確，會導致整個項目階段工作量的增加。實際上，許多軟件項目失敗的最主要原因就是需求階段對需求的描述不夠細致，導致后來超出預(yù)算或者時間進度達不到要求。
編寫規(guī)格說明是清楚、準確地編寫用戶需要和約束文檔的過程，在項目的需求分析階段，雙方必須全面地盡可能細致地討論項目的應(yīng)用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。
在此基礎(chǔ)上，要提交的成果是《軟件需求規(guī)格說明書》，它是最終用戶和開發(fā)機構(gòu)之間的技術(shù)合同書，是開發(fā)者開發(fā)軟件系統(tǒng)的依據(jù)，也是最終用戶驗收軟件系統(tǒng)的依據(jù)。
3.4 需求驗證
需求驗證是保證系統(tǒng)需求完整、正確、一致、明白的過程。在需求開發(fā)過程中，還沒有形成任何軟件，不可能進行任何測試，但是可以在軟件開發(fā)組設(shè)計編碼之前，以需求為基礎(chǔ)建立概念性的測試用例，并使用這些例子來發(fā)現(xiàn)軟件規(guī)格說明書中的錯誤、二義性，以及是否有遺漏等。
需求驗證是需求開發(fā)過程中的最后一部分，需求驗證所包括的活動是為了確定以下幾方面的內(nèi)容：
（l）軟件需求規(guī)格說明正確描述了預(yù)期的系統(tǒng)行為和特征。
（2）需求的完整性和高質(zhì)量。
（3）需求的一致性。
（4）軟件的需求分析，為接下來的功能說明書和系統(tǒng)詳細設(shè)計以及測試提供了基礎(chǔ)。
雖然對于一些大型的銀行系統(tǒng)的需求文檔進行詳細的