原型开发需要投入一定的时间，并根据客户反馈的信息不断修正。在原型中多投入些时间，就会多减少一份后期需求变更引起的返工时间。软件原型是降低需求变更风险的有效方法。
4.需求的抽象和建模体现在哪些方面
首先要理解需求分析和设计的目的在于满足现状并适应变化。要想适应变化则业务建模和需求抽象就是必须的。当我们了解到业务的组织结构和流程经常面临变动和调整的时候，我们就需要考虑引入标准的组织结构模型，权限模型和工作流模型。这些模型的引入使业务和需求的变动变化为通过系统的灵活配置来适应。软件系统要适应变化不是从设计阶段开始的，而是我们的软件需求本身就需要适应变化。
需求的抽象包括了对业务对象模型的抽象，对业务规则的抽象，对流程的抽象。其中最重要的就是由业务对象抽象形成的概念模型，由流程抽象形成的数据交互模型。对于一些快速软件开发平台理解到的对象建模，流程建模，组织结构和权限建模，业务规则建模，BPEL业务流程编排恰好就是需求抽象的最主要内容。
要做好需求抽象必须具备两方面的知识，第一是真正的对所涉及到的业务领域及其标准模型足够理解，其二是对软件系统分析和架构设计有较多的经验积累。只有同时具备这两方面知识才能够做好需求建模工作。
5.需求的验证和确认包括哪些事情
我们可以再简单理解下验证和确认的区别，对于判断最终开发出来的系统是否和用户想要的东西是一致的过程叫确认，对于你理解和描述的需求和我当初的想法是否是一致的过程叫验证。需求的验证包括了很多的内容，涉及到软件开发中上下游相关人员的参与。首先你结构和文档化后的需求需要用户来验证是否和他们的想法是一致的，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。对于后续设计开发阶段的人员也需要对需求进行评审以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中引入了较多的易用，较好，应该等不确定和不可测试的词语。对于大型的软件项目，如果有专门的产品化标准和UI组的话，还需要对需求的易用性和产品交互等方面进行评估，以评价整个软件系统的产品化。
确认主要是软件系统已经开发完成后交付给用户后验收的时候，用户确认系统是否实现了当初的需求。为了保证确认过程的顺利，就必须重视需求验证的过程，需求验证不仅仅是需求阶段对需求文档的评审，还需要关注设计，开发等各阶段对需求的实现情况的验证。