。不管是否是抛弃的原型，都需要客户看到的原型和最终实现的系统基本一致，因此原型开发需要投入一定的时间，并根据客户反馈的信息不断修正。在原型中多投入些时间，就会多减少一份后期需求变更引起的返工时间。软件原型是降低需求变更风险的有效方法。
四、需求的抽象和建模体现在哪些方面
首先要理解需求分析和设计的目的在于满足现状并适应变化。要想适应变化则业务建模和需求抽象就是必须的。当我们了解到业务的组织结构和流程经常面临变动和调整的时候，我们就需要考虑引入标准的组织结构模型，权限模型和工作流模型。这些模型的引入使业务和需求的变动变化为通过系统的灵活配置来适应。
软件系统要适应变化不是从设计阶段开始的，而是我们的软件需求本身就需要适应变化。需求的抽象包括了对业务对象模型的抽象，对业务规则的抽象，对流程的抽象。其中最重要的就是由业务对象抽象形成的概念模型，由流程抽象形成的数据交互模型。对于一些快速软件开发平台理解到的对象建模，流程建模，组织结构和权限建模，业务规则建模，BPEL业务流程编排恰好就是需求抽象的最主要内容。
要做好需求抽象必须具备两方面的知识，第一是真正的对所涉及到的业务领域及其标准模型足够理解，其二是对软件系统分析和架构设计有较多的经验积累。只有同时具备这两方面知识才能够做好需求建模工作。
五、为什么要做需求管理，需求管理包括哪些工作?
需求管理就是IT项目中的范围管理，需求管理是整个IT项目的源头，IT项目的估算，计划，后续的跟踪控制，验证和确认等各项工作都是跟需求密切相关的。因此为了保证项目的进度，质量和成本的目标的顺利实现，保证项目计划的严肃性和可执行性;为了保证软件系统最终开发的产品正是客户期望的产品，必须要做好需求管理工作。需求管理工作应该是需求全生命周期的管理，从用户原始需求的提出，到最终形成软件产品后用户对需求实现情况的验证以形成闭环流程。因此我们需要跟踪和了解到需求状态的演变过程。
大型的项目软件生命周期模型较为复杂，一个需求的实现会经过用户需求，软件需求，总体设计，详细设计，开发和单元测试，集成测试，系统测试和验收测试多个环节，在这个过程中需要建立需求追踪以确认需求和中间阶段产生的工作产品的一致性。另外变更管理是需求管理的另外一个重点，需求在经过评审确认后需要基线并受到控制，当出现需求变更的时候必须进行相应的需求影响分析以确认对需求变更的处理方式，当变更工作量影响较大的时候还需要调整并重新基线项目计划。
对于整个需求调研，分析和需求开发，评审确认的过程也需要进行管理。在这个过程中的一个重点就是对需求输出的文档需要得到用户，项目组设计开发人员的共同确认和承诺。
六、需求的验证和确认包括哪些事情
我们可以再简单理解下验证和确认的区别，对于判断最终开发出来的系统是否和用户想要的东西是一致的过程叫确认，对于你理解和描述的需求和我当初的想法是否是一致的过程叫验证。需求的验证包括了很多的内容，涉及到软件开发中上下游相关人员的参与。首先你结构和文档化后的需求需要用户来验证是否和他们的想法是一致的，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。
对于后续设计开发阶段的人员也需要对需求进行评审以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中引入了较多的易用，较好，应该等不确定和不可测试的词语。对于大