本文首先对需求工程领域相关活动及其概念进行简要阐述，由此引出需要展开的需求活动以及相应目标和目的，进一步映射到 RRC 的使用场景和相关提供的功能。希望借助本文，对围绕需求工程以及 RRC 的生态圈贡献微薄之力，也希望能够帮助读者对需求工程有基本的认识，同时对 RRC 的能力有初步的了解，便于对其进行进一步评估，甚至能够投入使用。
近两年与客户的交流过程中，我们越来越多的看到，国内客户对需求工程的意愿和认识都在逐步提升，众多的客户在努力尝试需求工程相关实践，走过许多误区，也欣喜看到许多长足的进步。成果是明显的，我们逐渐认识到需求工程能力的提升不是一朝一夕，能够一蹴而就的事情，但同时仅靠热情和时间的堆积也无法到达成功的彼岸。理论与实际的结合，实践与工具的结合，才是相辅相成，才能够确保一步一个脚印，扎实而坚定的向着需求活动的目标——质量保证而迈进。
Rational Requirements Composer（简称 RRC）是 IBM Rational 基于 Jazz 平台构建的集需求定义与需求管理于一身的需求工程平台。RRC 发展至今已有数载，版本也发展到 4.0.1，无论是从功能性、易用性、可用性上，还是从对需求工程理念的实现和遵从，都已经进入了一个良性发展的成熟期。
本文首先对需求工程领域相关活动及其概念进行简要阐述，由此引出需要展开的需求活动以及相应目标和目的，进一步映射到 RRC 的使用场景和相关提供的功能。希望借助本文，对围绕需求工程以及 RRC 的生态圈贡献微薄之力，也希望能够帮助读者对需求工程有基本的认识，同时对 RRC 的能力有初步的了解，便于对其进行进一步评估，甚至能够投入使用。
备注：RRC 是 IBM Rational 协作化的生命周期管理（CLM）整体方案中不可或缺的一部分，CLM 强调的协作不仅体现在团队、流程、人员以及资产之间，同样体现在研发生命周期的不同阶段。需求过程作为研发生命周期所有活动的起源，必然也必须要与">开发过程以及质量过程产生密不可分的关联。因此对需求工程以及 RRC 的了解不能仅局限在需求领域，而是应该投射到整个生命周期的各个阶段。有关 CLM 的相关内容，可以参阅 Developer Works 上相关文档。
需求工程领域活动基本概念简述
需求活动贯穿整个软件 / 系统开发生命周期，是研发活动的源头，同时也是衡量研发结果的唯一标准。正因为需求过程跨度长，涉及的活动多，同时与整个开发生命周期其他活动相互交织，彼此关联，与需求活动相关的概念与名词也层出不穷，有些概念甚至彼此混淆。因而有必要对需求过程中涉及的常见活动以及相关概念进行简要描述，便于统一认识。同时也能够通过一条主线对 RRC 所提供的功能进行串联，有助于提升对 RRC 使用的理解。
需求工程
对于整个需求生命周期范围的活动，我们称之为"需求工程"，需求工程包括两个阶段：需求定义和需求管理（包括变更管理）。前者更关注需求的衍生，后者更关注需求的实现，如下图所示：
图 1. 需求工程概念
需求定义阶段
简述
需求定义阶段主要关注从不同涉众获取需求，组织人员进行需求分析，定义需求规格说明书，评审并验证对需求的理解，确保对需求达成统一的理解与认识。
传统软件工程，例如瀑布式开发方法假设可以一次性得到完全正确的需求，长期实践证明过于理想化，需求定义事实上是一个不断反复的过程。现代软件开发实践表明，我们很难一次性得到完整并正确的需求，项目的开发总是伴随着需求的不断明确和演化而进行的，而这一过程的关键在于如何有效降低需求不确定性的风险。一个行之有效的方法就是不断迭代地进行需求的开发与验证。
同时需求根据涉众、角度以及阶段的不同，又划分了不同的层次：业务需求、用户需求、（软件）系统需求。如下图所示：
图 2. 需求定义的不同层次
其中业务需求是整个需求活动的源头，它阐明产品的高层次概念和将发布产品的主要业务内容。业务需求说明客户、企业以及想从该系统获利的风险承担者或从系统中取得结果的用户所要求的目标。业务需求为后继工作建立了一个指导性的框架。其它任何内容都应遵从业务需求的规定。需要注意的是业务需求并不能为开发人员提供许多开发所需的细节说明。
用户需求是从使用产品的用户处收集，用户能说清楚要使用该产品完成什么任务和一些非功能性的特性，而这些特性会对使用户很好接收和使用具有该特点的产品是重要的。
系统需求则是用户需求到软件系统层面的映射，描述了软件系统所应具有的外部行为，
分析方法
由上图可以看出，业务需求属于业务领域，更为宏观。业务需求通常来自于风险承担者，而用户需求则应来自产品的真正使用、操作者，用户需求与系统需求则属于解决方案领域。
正是由于需求有不同的层次、分属不同的领域、涉众人群有所区别，看待问题和分析问题的角度和方法也不尽相同。
在业务领域，我们通常通过业务流程来梳理描述业务需求，一张简单的示意图就可以用来描绘出用户的业务活动，输入输出数据，起始、中止以及判决条件等。编制业务流程有助于明确产品的使用实例和功能需求。
由于在业务领域有可能涉及到不同行业，不同的行业、不同的业务领域会有不同的术语。同时业务领域活动是后续分析、实现与验证的输入，需要与整个研发生命周期涉及到的不同团队形形色色不同人员进行沟通；因而定义一套统一的术语表有助于统一认识，减少误解。术语表有时也称为数据字典。
在用户需求层面，我们通常可以采用用例模型辅助进行需求分析，同时在这个阶段，除了功能性需求，我们还可以整理出非功能性需求。非功能需求包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
从系统角度我们可以通过多种方式使需求分析人员、设计人员，甚至开发人员、测试人员与需求干系人进行交流。通常我们建议开发领域人员能够尽可能的与用户进行沟通，尤其是敏捷开发更是强调用户的参与，用户如果能够在开发过程中，尤其是需求分析阶段更多的介入，能够有效提升团队对于需求的理解，避免由于信息的缺失或误解造成损失。
需求的信息，除了需求的内容以外，还包括例如优先级、必要性、来源、状态、负责人等信息，通常称为需求的属性。同时需求的层级之间，不同的需求之间会有关联关系，例如父子关系、追踪关系、依赖关系等，关联关系的维护和梳理同样有助于对需求的认识和理解。
在系统需求领域我们有例如故事板、草图、UI 设定、界面流程等多种方式对需求进行深入分析，同时通过这些手段与用户进行交流。诸如故事板、草图、UI 设定等图形化的方式更有助于双方对需求点达成一致，更加直观，能够有效的规避语言文字在理解上的二义性。