对于中小软件开发企业而言，需求管理往往是导致项目延期、资源浪费直至失控的重要原因，如何解决这个问题呢?
小张是一个软件开发公司的项目经理，目前正为一个超市的商业管理软件头疼不已。因为当初，小张与客户主管讨论项目需求时，客户主管告诉他，软件系统要包含商品的进、销、调、存，然后门店自动订货，供应商自动结算，管理人员能够随时查询门店商品的销售和库存。
小张觉得这只是项目的大体结构框架，表示需要进一步与具体业务人员交流，但客户那边人人都忙，无奈之下客户主管就代替采购部门、营运部门和财务部门解释了相关需求。由于时间紧，人员少，小张在似懂非懂的情况下，随即组织团队投入了紧张的编码开发中。
可是，在随后的日子里，一会是领导提出查询功能不完善，一会是中层表示栏目设置有漏洞，再一会是基层人员觉得软件界面过于复杂……于是，来来回回，修修补补，直到小张最后疲惫不堪。
事实上，很多中小软件开发企业都曾遭遇过类似的问题，问题的关键就在于软件开发过程中的需求管理。对于软件开发的项目经理而言，最关注的莫过于如何提高项目开发效率、减少项目开发中的重复劳动和资源浪费、提高项目的可控性。而需求管理，正是导致项目失控的最重要原因。
用例模型描述需求
需求管理的首要方面，则是需求的收集和分析。在此过程中，仅仅“倾听”用户的需求是远远不够的。而且“用户”是一个宽泛的对象，包括领导、中层和具体操作人员几个层面，不同层面在需求上往往存在明显差异。这些人并非软件设计师，通常都无法正确的、完整的描述需求。而软件开发人员由于惯有的代码思维，常常又无法和用户有效沟通。
对此，IBM Rational软件交付平台的需求管理模型可以解决这个问题，因为在IBM Rational的支撑下，软件需求是以用例模型的方式来描述。用例模型的主要元素包括用例图和用例规约，用例图以图形的方式描述用户和用例的关系，可以从不同角度建立起直观理解系统的功能需求。用例规约则以叙事的方式讲述用户使用系统的情况。
令开发人员省心的是，用例建模是站在用户的角度看问题。从目标系统的外部以一种可观测和可验证的方式描述目标系统的预期行为。与常见的需求列表方法不同，用例是按照叙事的方式讲述用户可能怎样使用系统。因此，用例易于被业务人员理解，可以清晰定义目标系统的边界。用例模型在系统功能与功能的最终用户之间建立了明确的关联，便于用户业务部门安排合适的需求评审人员对其相关需求进行评审，既可以提高需求评审的效率，又可以保证需求的正确性。如此一来，软件开发人员对于用户的需求把握无疑更加可靠。
灵活应对需求变更
不过，软件开发就像装修房子一样，永远都可以找到需要增加或改变的地方，因此，需求的收集和分析只是需求管理的其中一步，面对必要的需求变革管理，软件开发在设计系统框架时，必须设计一个有弹性的、能适应变化的、易理解的、有助于重用的软件体系架构。
这就涉及到软件开发的方法论。作为IBM Rational指导软件开发的方法论，IBM Rational Unified Process(RUP)可为开发人员提供统一的工作流程和开发方法，使开发人员相互之间能够顺利地进行沟通与协作，确保整个团队在统一的方法指导下进行协调一致的协同开发。
其中，ClearQuest作为需求变更的管理工具，能够提供灵活的流程定制能力，可根据变更的属性字段或者变更类型来执行不同的流程分支，从而定制每个环节的动作，并通过 VBScript 或者 Perl 等触发器脚本来实现用户特定需求的操作。
也就是说，通过RUP方法论建立起需求管理体系，然后采用ClearQuest实现需求及变更管理，以及使用RSA对业务和软件进行建模，从而实现以架构设计为中心的软件开发，让软件项目不再陷入进度拖延、费用超支的难堪境地。
应该说，高效的需求管理是一个软件开发项目成功的必备条件。在IBM资深软件开发顾问姚翔看来，Rational工具可以协助需求分析人员准确描述功能需求、工作流程、人际界面，并且对需求实现与变更进行有效地控制、跟踪和监控，从而显著降低开发风险，提高开发效率。
