与传统的功能分解方式相比，用例方法全都是从外部来定义系统功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。此外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。
在RUP中，以用例捕获需求方法的优势是显而易见的。首先它描述了用户是如何与系统交互的，这种描述更易于被用户所理解，是开发人员和用户之间针对系统需求进行 沟通、迅速达成共识的有效手段。其次由于它是以时间顺序描述交互过程，因此系统分析员和用户都可以轻易地识别用例中存在的缺陷。再次是它能使 团队成员在设计、实现、测试和最后编写用户手册的过程中都紧紧地以用户需求为中心，促使开发人员始终站在用户的角度考虑问题，容易验证设计和实现满足用户的需求。此外，用例还简化了记录功能需求的工作，有效提高开发工作的效率。
二、用例驱动需求管理的技巧
注重需求管理，确保满足客户的需求，既是RUP的基本原理之一，又是RUP静态结构中的一个重要核心工作流程。针对软件需求不显见、多源头、不同性、多变化等特点，RUP提供了基于用例驱动的指导来提高需求管理技能和流程的专业技术，并开发了有效进行自动化管理需求的工具。其中下列的管理技巧在有效的需求管理流程中，是以不同的顺序连续应用的。
分析业务问题。进行业务分析是为了加深了解与熟悉用户的需要和实际业务运作流程，尽力找出“隐藏在问题背后的问题”，并提出高层解决方案。在问题分析过程中，将对实际问题的说明取得一致，并确定有关的涉众。初始解决方案的界限和约束从技术和业务两个方面来定义。在适当的时候，从项目的商业理由分析中还能得到期望从系统获得的投资回报。
理解涉众需要。需求将有许多来源，客户、合作伙伴、最终用户以及领域专家都是某些需求的来源，而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。不同的用户和相关人员会关心不同的问题，其间的要求甚至是互相矛盾的；同时这些需求之间又有着千丝万缕的联系，必须在深刻理解的基础上，既综合整理归纳，又分门别类对待。
明确定义系统。定义系统是指正确解释涉众需求，并整理成对要构建的系统意义明确的说明。说明可以是书面文档、电子文件、图像或用于表达除系统本身以外的系统需求的任何表示方式。在系统定义初期，需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级、预计工作量、技术和管理 风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。
管理系统规模。项目规模由分配给它的需求集定义。管理项目规模，使之适合可用 资源（时间、人力和资金），是成功管理项目的关键。使用需求属性（如优先级、工作量和风险）作为协商项目应包含需求的基础，对管理系统规模而言是相当有用的技巧。侧重于属性，而不是需求自身，将减少通常对敏感问题的争论。同时这也有助于培养团队负责人的谈判技巧，有助于在项目中为组织培养推介人。项目推介人应既有能力代表组织拒绝那些超出可用资源的规模变更，也有相应能力扩展资源以适应扩大的规模。
改进系统定义。对高层系统定义达成一致并充分理解了系统初始规模后，投入资源改进系统定义不仅有可能，而且也是经济的。改进系统定义包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要并按说明运行。说明通常是项目团队的重要参考材料，在制定说明时一定要考虑受众，需要为不同的受众编制不同类型的说明。确定说明格式后，改进将持续贯穿整个项目生命周期。
管理变更需求。软件需求的变更总是在不断的产生之中，实际上有些变更是非常值得的，我们应当树立“变更不是敌人，而没有管理的变更才是真正敌人”的观念。对于一个团队来说，能否适应变更需求是评测团队涉众敏感度和运作灵活性的一个尺度，而敏感度和灵活性正是对项目成功有贡献的团队的特征。当然需求变更表明多少需要耗费一些时间来实施某个特定的功能，而且一个需求的变更对其他需求可能带来影响。管理需求变更包括这样一些活动：设立基线，追踪每个需求的历史，确定哪些依赖关系值得追踪，在相关项之间建立可追踪关系以及维护版本控制等。此外，建立 变更控制或批准流程也很重要，它要求由指定相关负责的团队成员来复审所有提议的变更，以在全局的高度上对变更需求的好处和可能引起的后果之间有个客观的权衡和把握。
三、管理需求中须注意的问题
Rational公司的两位RUP的开发与管理者Per Kroll和Philippe Kruchten在《实践者指南》一书中，曾提示了一些不能正确应用RUP的问题，这在管理需求工作中也有所体现。由于以用例驱动需求管理所获得的明显益处，容易使团队成员产生盲目乐观情绪，从而减弱了把握正确应用的思维判断能力，产生过犹不及或轻视麻痹的行为及不良效果，这是在管理需求实践中必须加以注意和避免的。其主要问题有：
一是创建过多的用例。一个常见的现象是根据功能把用例划分得太细，没能做到“有所为有所不为”，这样将产生下列的后果：用户对粒度太小的用例很难了解及难以判断是否满足他们的需求；设计人员对于过细的功能无法全部实现，难以通过设计满足实际用户需求；开发人员对关系太紧密的用例很可能开发重复功能并妨碍其他人工作；测试人员要花很多额外精力合成测试用例，才能创建有意义的测试。要避免发生这种情况，应注重以下列的几条标志来准确量度把握：无法衡量能否给用户产生价值的用例，代表的是不完整的交互过程，应当重建；用例A总是与用例B或用例C相关，应当把它们整合为一个用例；两个或多个用例有着几乎相同的描述，就可以把它们合并在一起；对于用例模型中用例之间的关系，不要进行多于一层的抽象。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
