常用的业务功能，用户可以在此基础上，对比自己的实际需求，提出不同的需要更改的和新增的需求。这种增量迭代的思路，减少了用户的工作量和重复工作，有助于用户清楚地描述用户需求。
项目研发人员有时还能够将原型系统展示给业务人员，通过更直观的方式给银行业务部门的人员分析展示原型业务系统，从而更有效地帮助业务人员比对自己银行的业客户到底是需要什么样的软件了。
3.2 需求分析
需求分析是提炼用户的需要，并最终完成客户同意并签字的需求分析报告的过程。需求分析过程分为访谈阶段、诱导阶段和确认阶段三个过程。在需求访谈阶段，项目开发人员通过与金融业务部门领导、主管和相关业务人员关于项目需求方向、组织架构、业务流程和软硬件环境的讨论交流，可以从宏观上把握项目的需求，建立起沟通渠道，确定客户承诺的接口人，提交项目的调查报告以及业务流程报告等。在诱导阶段，以调查报告及业务流程为基础，结合现有的技术条件和软件基础将业务流程模型化，并与用户不断沟通，即时获取反馈信息，从而可以对客户的需求进行深度挖掘，将客户的不可见的需求转化为明确的需求。所要提交的文档有原型反馈报告和经过更新的业务流程报告。在确认阶段，是在原型反馈报告和业务流程报告的基础上，通过更进一步的细化业务流程，改进原型系统，撰写需求分析报告并送交评审。
在这一需求分析的最后阶段，要促使开发方和用户之间就系统需求达成一致，完成客户同意并签字的需求分析报告及相关支持的资料。在需求分析的过程中，对需求划分优先级的分析也是至关重要的一个环节，在某个时刻，我们如何知道哪些需求属于“必须做”，哪些属于“应该做”，哪些又属于“可以做”。在银行软件的项目中，也要对客户需求划分优先级，对于已经识别的客户需求进行评估，分清哪些是项目关键路径上的需求，必须完成的，哪些是不重要也不紧急的需求，甚至留待二期中完成用户也可以接受的。
要理解这一点：用户反馈非常关键。用户并不关心你采用什么方式去满足他们的需求，但当用户看到最关键的功能都实现得很好时，如果还有几个无关大局的需求暂时没有满足，也就不会引起太大的反应了。
3.3 编写规格说明
软件需求是软件产品开发的依据，也是整个开发过程各项活动的基础。需求阶段不细致的工作，软件需求的不明确，会导致整个项目阶段工作量的增加。实际上，许多软件项目失败的最主要原因就是需求阶段对需求的描述不够细致，导致后来超出预算或者时间进度达不到要求。
编写规格说明是清楚、准确地编写用户需要和约束文档的过程，在项目的需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。
在此基础上，要提交的成果是《软件需求规格说明书》，它是最终用户和开发机构之间的技术合同书，是开发者开发软件系统的依据，也是最终用户验收软件系统的依据。
3.4 需求验证
需求验证是保证系统需求完整、正确、一致、明白的过程。在需求开发过程中，还没有形成任何软件，不可能进行任何测试，但是可以在软件开发组设计编码之前，以需求为基础建立概念性的测试用例，并使用这些例子来发现软件规格说明书中的错误、二义性，以及是否有遗漏等。
需求验证是需求开发过程中的最后一部分，需求验证所包括的活动是为了确定以下几方面的内容：
（l）软件需求规格说明正确描述了预期的系统行为和特征。
（2）需求的完整性和高质量。
（3）需求的一致性。
（4）软件的需求分析，为接下来的功能说明书和系统详细设计以及测试提供了基础。
虽然对于一些大型的银行系统的需求文档进行详细的