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