客户和其他涉众*在系统的工作内容方面达成并保持一致。
　
　　使系统开发人员能够更清楚地了解系统需求。
　
　　定义系统边界（限定）。
　
　　为计划迭代的技术内容提供基础。
　
　　为估算开发系统所需成本和时间提供基础。
　
　　义系统的用户界面，重点是用户的需要和目标。
　
　　* 涉众：涉众是所有会受到项目结果重大影响的人。如客户（或客户代表） 用户（或用户代表） 、投资者 、股东 、生产经理 、买方 、设计员 、测试员 、文档编写员等从上面的目的我们可以大致想到需求过程中要做些什么事。事实上，用简单的话来说明需求过程，就是确定系统该做些什么以及该符合什么条件。话虽然简单，实现起来可没有那么容易。所以科学的需求过程有一整套完整的理论、工具、方法来实现。就像任何企业要盈利都必须要有业务和伴随业务的管理一样，需求过程也分为需求分析过程和需求管理过程。企业的业务是盈利性的，需求分析过程在项目中也是产出型的；企业要保证业务的开展就必须要有管理，而需求分析过程也同样离不开需求管理。小企业没有成为体系的管理方法，企业规模小的时候还能够对付，可是企业一大，各种问题都接踵而来，管理上的不足直接导致了业务开展的低效性。同样，需求管理的不足可能可以应付小型的软件项目，可是对于大型的项目，管理的不足就会暴露出来，而直接的后果就是项目的失败。 插句题外话，很多人认为需求管理的目的是为了控制需求过程，这是没有错，但是在RUP的思想中，更重要的思想是迭代*.迭代的目的是为了发展，为了进化，为了完善。所以RUP中的软件生命周期是分为多个迭代周期的（软件生命周期将会在下文讨论）。
　
　　* 迭代：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。
　
　　需求分析过程主要做的事情无非就是获取涉众对系统的要求，可是需求是多变的，而你不可能告诉客户等到他们把一切都固定下来再开发软件。所以需求管理过程做的事情就是保证需求变更的可管理性。
　
　　1.6. 需求的层次

　　《软件需求》一书中有对需求层次的详细定义：软件需求包括三个不同的层次——业务需求、用户需求和功能需求——也包括非功能需求。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示：
　
　

　　对应到RUP的工作流程，业务需求其实是RUP的业务建模流程（Business Modeling），在这个流程中，参与者主要是业务流程分析员（Business-Process Analyst）。主要的目的是对企业目前的业务流程进行评估，并根据要进行的项目，确定进行何种程度的业务建模（你要做一个ERP项目就意味着你必须优化业务流程，而上一个部门级MIS项目就没有必要用牛刀了）。然后你会得到一个叫做业务前景（Business Vision）的东西，其实就是项目成功后会是个什么样子，并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，业务需求就是需求过程的宪法，任何需求不得与之相违背。
　
　　1.7. 需求的标准
　

上一页  [1] [2] [3] [4] [5] [6] 下一页

【责编:Lili】