RUP是Rational统一过程（Rational Unified Process）的简称，它是Rational公司（现归属 IBM公司）推出的一种软件过程产品。从软件过程模式角度看，RUP又是一种典型的软件过程模式，它以迭代增量式、架构为中心、用例驱动的软件开发方法为主要特征，其中以用例驱动乃是贯穿软件开发始终的方法，而将其应用于需求管理自然是首当其冲的课题。
软件需求是一个软件系统必须完成或达到的目标总和，需求管理是指了解、记录、追踪不断变化的需求的一个系统化方法。至今许多软件开发的实践都表明，有无良好的需求管理是整个软件项目成败的至关重要的一步，是与项目得失关系最大的首要因素。RUP把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”，并描述了如何提取、组织需要的功能和限制；跟踪和文档化适中方案和决策；捕获和进行商业需求交流。在此过程中的用例和场景（用例的实例）的使用，已被证明是捕获功能性需求的卓越方法，并确保由它们来驱动软件的设计、实现和测试，使最终系统更能满足最终用户的需要。下面对此稍作具体的分析。
一、用例驱动较之功能分解的优势
在不同行业中，都有很多机会足以去发明产品，或改善制造和管理的过程，而把握机会的一个重要方法就是从问题中找机会。Rational正是一家善于思考问题的企业。
长期以来，在 软件工程实践中普遍存在这样一种认识——用户知道需求是什么，开发人员要做的就是从他们那里得到需求，并由此做出系统功能的说明。基于这样的认识和思想指导，传统的软件需求规约采用的基本上都是以功能分解的方式来描述系统功能。在这种表述方式中，系统功能被分解到各个系统功能模块中，通过描述细分的系统模块功能来达到描述整个系统功能的目的。但采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，其表述中实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？极端的情况就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。以往在有些公司的开发流程中，对于需求就有"内部需求"（实为内部设计）和"外部需求"之区分与称谓。
功能分解方法的另一个缺点是它分割了各项系统功能的应用环境，从各个功能项入手，你就很难了解到这些功能项是如何相互关联来实现一个完整的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更像是一个设计文档。
通过软件开发的反复实践后发现，任何系统都会有很多用户（或不同类型的用户），每个用户只知道其个人如何使用系统，他们并不知道也不想了解系统的内部结构、设计及整体运行情况，他们所关心的只是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就是Rational思考问题的角度，也是创制用例方法的基本指导思想。
用例方法是完全站在用户的角度上（即从系统的外部）来描述系统的功能，所要回答的问题是“系统应该为每个用户做什么”。它把被定义的系统看作是一个黑箱，先不去关心系统内部是如何完成它所提供的功能，而仅描述被定义系统有哪些外部使用者（抽象成为Actor）会与其发生交互；针对每一参与者，又描述系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。在所有用例构成的用例模型中，判断系统各项功能是否重要或有价值的 标准，是考虑系统为每个用户提供的价值，包括该功能辅助哪个用户进行工作？需要提供什么业务？能够为业务增加多少价值？因此，用例能够用于指导找出每个用户所需要的功能，避免提出用户根本就不需要的冗余功能，从而有效界定系统的范围和行为，使整个系统的业务为每个用户提供最大的价值。
文章来源于领测软件测试网 https://www.ltesting.net/
