功能分解方法的另一个缺点是它分割了各项系统功能的应用环境，从各个功能项入手，你就很难了解到这些功能项是如何相互关联来实现一个完整的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更像是一个设计文档。

　　通过软件开发的反复实践后发现，任何系统都会有很多用户（或不同类型的用户），每个用户只知道其个人如何使用系统，他们并不知道也不想了解系统的内部结构、设计及整体运行情况，他们所关心的只是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就是Rational思考问题的角度，也是创制用例方法的基本指导思想。

　　用例方法是完全站在用户的角度上（即从系统的外部）来描述系统的功能，所要回答的问题是“系统应该为每个用户做什么”。它把被定义的系统看作是一个黑箱，先不去关心系统内部是如何完成它所提供的功能，而仅描述被定义系统有哪些外部使用者（抽象成为Actor）会与其发生交互；针对每一参与者，又描述系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。在所有用例构成的用例模型中，判断系统各项功能是否重要或有价值的标准，是考虑系统为每个用户提供的价值，包括该功能辅助哪个用户进行工作？需要提供什么业务？能够为业务增加多少价值？因此，用例能够用于指导找出每个用户所需要的功能，避免提出用户根本就不需要的冗余功能，从而有效界定系统的范围和行为，使整个系统的业务为每个用户提供最大的价值。

　　与传统的功能分解方式相比，用例方法全都是从外部来定义系统功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。此外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。

　　在RUP中，以用例捕获需求方法的优势是显而易见的。首先它描述了用户是如何与系统交互的，这种描述更易于被用户所理解，是开发人员和用户之间针对系统需求进行沟通、迅速达成共识的有效手段。其次由于它是以时间顺序描述交互过程，因此系统分析员和用户都可以轻易地识别用例中存在的缺陷。再次是它能使团队成员在设计、实现、测试和最后编写用户手册的过程中都紧紧地以用户需求为中心，促使开发人员始终站在用户的角度考虑问题，容易验证设计和实现满足用户的需求。此外，用例还简化了记录功能需求的工作，有效提高开发工作的效率。

                          　　　　                   二、用例驱动需求管理的技巧

　　注重需求管理，确保满足客户的需求，既是RUP的基本原理之一，又是RUP静态结构中的一个重要核心工作流程。针对软件需求不显见、多源头、不同性、多变化等特点，RUP提供了基于用例驱动的指导来提高需求管理技能和流程的专业技术，并开发了有效进行自动化管理需求的工具。其中下列的管理技巧在有效的需求管理流程中，是以不同的顺序连续应用的。

　　分析业务问题。进行业务分析是为了加深了解与熟悉用户的需要和实际业务运作流程，尽力找出“隐藏在问题背后的问题”，并提出高层解决方案。在问题分析过程中，将对实际问题的说明取得一致，并确定有关的涉众。初始解决方案的界限和约束从技术和业务两个方面来定义。在适当的时候，从项目的商业理由分析中还能得到期望从系统获得的投资回报。

　　理解涉众需要。需求将有许多来源，客户、合作伙伴、最终用户以及领域专家都是某些需求的来源，而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。不同的用户和相关人员会关心不同的问题，其间的要求甚至是互相矛盾的；同时这些需求之间又有着千丝万缕的联系，必须在深刻理解的基础上，既综合整理归纳，又分门别类对待。

　　明确定义系统。定义系统是指正确解释涉众需求，并整理成对要构建的系统意义明确的说明。说明可以是书面文档、电子文件、图像或用于表达除系统本身以外的系统需求的任何表示方式。在系统定义初期，需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级、预计工作量、技术和管理风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。

　　管理系统规模。项目规模由分配给它的需求集定义。管理项目规模，使之适合可用资源（时间、人力和资金），是成功管理项目的关键。使用需求属性（如优先级、工作量和风险）作为协商项目应包含需求的基础，对管理系统规模而言是相当有用的技巧。侧重于属性，而不是需求自身，将减少通常对敏感问题的争论。同时这也有助于培养团队负责人的谈判技巧，有助于在项目中为组织培养推介人。项目推介人应既有能力代表组织拒绝那些超出可用资源的规模变更，也有相应能力扩展资源以适应扩大的规模。

　　改进系统定义。对高层系统定义达成一致并充分理解了系统初始规模后，投入资源改进系统定义不仅有可能，而且也是经济的。改进系统定义包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要并按说明运行。说明通常是项目团队的重要参考材料，在制定说明时一定要考虑受众，需要为不同的受众编制不同类型的说明。确定说明格式后，改进将持续贯穿整个项目生命周期。

　　管理变更需求。软件需求的变更总是在不断的产生之中，实际上有些变更是非常值得的，我们应当树立“变更不是敌人，而没有管理的变更才是真正敌人”的观念。对于一个团队来说，能否适应变更需求是评测团队涉众敏感度和运作灵活性的一个尺度，而敏感度和灵活性正是对项目成功有贡献的团队的特征。当然需求变更表明多少需要耗费一些时间来实施某个特定的功能，而且一个需求的变更对其他需求可能带来影响。管理需求变更包括这样一些活动：设立基线，追踪每个需求的历史，确定哪些依赖关系值得追踪，在相关项之间建立可追踪关系以及维护版本控制等。此外，建立变更控制或批准流程也很重要，它要求由指定相关负责的团队成员来复审所有提议的变更，以在全局的高度上对变更需求的好处和可能引起的后果之间有个客观的权衡和把握。

                         　　　　　                           三、管理需求中须注意的问题

　　Rational公司的两位RUP的开发与管理者Per Kroll和Philippe Kruchten在《实践者指南》一书中，曾提示了一些不能正确应用RUP的问题，这在管理需求工作中也有所体现。由于以用例驱动需求管理所获得的明显益处，容易使团队成员产生盲目乐观情绪，从而减弱了把握正确应用的思维判断能力，产生过犹不及或轻视麻痹的行为及不良效果，这是在管理需求实践中必须加以注意和避免的。其主要问题有：

　　一是创建过多的用例。一个常见的现象是根据功能把用例划分得太细，没能做到“有所为有所不为”，这样将产生下列的后果：用户对粒度太小的用例很难了解及难以判断是否满足他们的需求；设计人员对于过细的功能无法全部实现，难以通过设计满足实际用户需求；开发人员对关系太紧密的用例很可能开发重复功能并妨碍其他人工作；测试人员要花很多额外精力合成测试用例，才能创建有意义的测试。要避免发生这种情况，应注重以下列的几条标志来准确量度把握：无法衡量能否给用户产生价值的用例，代表的是不完整的交互过程，应当重建；用例A总是与用例B或用例C相关，应当把它们整合为一个用例；两个或多个用例有着几乎相同的描述，就可以把它们合并在一起；对于用例模型中用例之间的关系，不要进行多于一层的抽象。

　　二是忽视需求定义的准确与共识。系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成。如果忽略了不同工件之间是否存在矛盾或冲突的地方，就会在模型内部产生不一致性，这种不一致性将会直接影响到需求定义的准确性。同时用例模型最大的优点就在于它应该易于被不同涉众所理解且无二义性，因此用例的粒度、个数以及模型元素之间的关系复杂程度都应该依此原则所决定，从而使准确的需求定义成为团队成员和所有涉众达成共识的基础。

　　三是在初始阶段过于细化需求。根据RUP对生命周期的阶段、目的和里程碑的划分，初始阶段的目的是定义系统的边界并理解最重要的用户需求，这个阶段最重要的任务是尽快建立可执行的架构，以化解重大风险，因此不必在初始阶段花费太多时间细化需求。这一阶段只要得到一个合理并完整的参与者和用例的清单，广泛而扼要地描述需求，细化基本的或关键的用例，就可结束任务，尔后尽早转入到细化阶段，从而为后续的细化需求工作留出充裕的时间。