IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始，到研发以及后续的交付遵循 IBM 软件部集成产品设计(IPD)流程。
IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始，到研发以及后续的交付遵循IBM软件部集成产品设计(IPD)流程。IBM 软件产品需求管理流程是IPD的一个体现，也就是一个由市场/客户驱动的，跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。同时，此次内容我们将描述IPD和产品需求管理流程，及流程中的角色（市场、研发产品管理部门及研发工程部门），以及他们之间是如何通过协作来管理需求的。
IPD指导如何对软件产品发布版本进行投资决策和如何协调部门间工作以实现这些决策所定义目标，IBM软件产品需求管理基于IPD流程，要了解这个需求管理的流程，首先我们要了解IBM所有产品开发所遵循的IPD的流程，包括其决策点。
IPD流程分为六个步骤：
- 概念：即概念验证阶段，主要对需求包进行评审，以确定其是否有足够的商业价值；
- 计划：即资源投入计划阶段，主要对需求包进行评估，以确定是否有足够的资源且在一定的时间范围内将需求包开发出来；
- 开发：即对需求包进行开发成产品阶段；
- 验证：即对产品进行验证阶段；
- 交付：即将产品交付市场阶段；
- 生命周期：即产品在市场上销售，使用，维护和退出市场的阶段。
其中包括了几个重要的决策检查点(DCP)：
- 概念决策检查点：即经过概念阶段各方面进行的一系列评审，在此检查点确定（1）我们对需求包是否有足够的理解；（2）需求包是否有足够的商业价值。如果是，继续进入计划阶段；
- 计划决策检查点：即经过计划阶段的评估，在此检查点确定（1）我们是否有足够的资源在既定的时间范围内完成需求包的开发（2）研发部门是否能在(1)的估计上承诺进行开发。如果是，继续进入开发阶段；
- 可交付决策检查点：即经过开发和验证阶段，在此检查点确定（1）产品是否质量合格以交付给客户（2）我们产品的相应支持和销售是否已经准备好服务客户,如果是，产品交付市场；
- 生命周期结束决策检查点：即产品在市场使用一定时期后，在此检查点确定产品是否退出市场。
一个产品从市场需求开始，经过概念验证，时间、资源等计划的支持，然后进行开发，验证，直至发布到市场供客户使用，最后在某个特定的时候结束产品在市场上的销售，在IBM都遵循着IPD流程。在其中过程中，这个产品的概念是否被接受，是否能得到资源上的投入的承诺，是否通过最终验证可以在市场上发布，以及什么时候在市场上停售，这些关键的决策都通过相应的委员会在不同的决策点上进行决策。
以上描述了IBM IPD的基本概念，我们接下来看IBM软件产品的需求管理是如何基于IPD的。首先，请看下图一：产品需求管理流程。
图一：产品需求管理流程
点击查看大图
这个产品需求管理流程是如何与以上IPD的阶段相映射的呢？主要为以下几点：
- IPD的概念阶段对应的是流程中的“New->Prioritize->Prioritized”；
- IPD的计划阶段对应的是流程中的“High-Level Sizing->Sized”；
- IPD的开发和验证阶段对应的是流程中的“Plan/Develop”；
- 其中“Commit->InPlan”对应的是IPD的“Contract”点；
而产品需求管理流程与决策点的映射，主要为以下几点：
- 概念决策点-评估需求给IBM带来市场价值，决定是否接纳，如需求是不是有足够的业务潜力使得IBM产品能够成为市场的领导者；
- 计划决策点-评估需求开发的投入，决定是否将其放入开发计划，如是否有相应的资源使得我们能在既定的时间范围内实现需求；
- 可交付决策点-评估需求实现的状况，决定是否放入发布计划，如验证需求的功能及质量等是否满足要求。
产品需求管理流程中通过以下几类角色的参与并互相协作，推动需求通过评审并纳入到产品开发路线图里面。
市场部门
根据市场、竞争对手的信息，客户的反馈，技术发展方向以及IBM现在的产品组合，定义IBM在此市场领域需要提供的解决方案(O/SBP)。
研发产品管理部门
根据市场部门制订的解决方案(O/SBP)，及客户反馈的的改善和缺陷，定义产品发布版本所要提供的功能－即产品的需求。
研发工程部门
根据产品需求，评估开发需求所需要的资源、时间等，并对需求进行设计、开发和测试等，建立需求与设计开发之间的追踪关系。
技术支持
代表IBM与客户进行沟通，反馈需求所处的状态。
以上角色的互相协作关系请参考以下产品需求管理流程的三个阶段描述。
此流程是通过IBM内部系统RATLC实现，这个将在后面第7部分介绍。
研发产品管理部门根据市场部门制订的解决方案(O/SBP)，定义产品所要提供的功能－即产品的需求。研发产品管理部门将这些需求信息提交到RATLC，包括：
- 需求描述及提出理由
- 需求所涉及的产品模块
如果此需求是因为客户反馈的改善和缺陷而产生，那么研发产品管理部门将其与需求关联。改善是指客户在使用此产品的过程中提出的功能改善的要求，而缺陷是指：客户在使用此产品的过程中发现的缺陷。
当备选需求进入RRM以后，评审委员会，包括市场部门、研发产品管理部门，研发工程部门的代表会复审备选需求以决定那些需求通过概念决策点（当前的版本）。评估的条件包括其业务的重要性和对产品开发的影响（初步的需求规模评估）在评估的过程中，任何对此需求开发风险的认识，如需要的开发时间、性能要求等都被记录下来，作为此需求的风险记录，作为整个开发过程的参考。
对已经批准需求进行排序，同时需要增加以下内容：
- 将在哪个版本实现
- 负责人
- 业务的重要性
没有通过概念决策点的需求：
- 被拒绝，即现在没有任何实现的时间表；
- 被延迟，将在下次版本的概念阶段被重新考虑；
- 需要添加负责人和注释以备查。
为了了解开发的投入，并能够给每个需求制订详细的开发计划，所有需求都要进行规模评估。评估的内容包括现在或将来开发此需求所需要的人力，时间和资源。通过研发工程部门和研发产品管理部门的多次和及时的沟通，需求的规模被确定。如果需求规模被修改，研发产品管理部门将再次和市场部门和技术支持部门沟通，以确认修改。修改的记录会记录在需求变更流程里面。通过规模评估的需求，需求会关联一条或多条的规模评估记录：需求开发所需要的资源、人力及计划。
同时，开发团队根据IRUP指导对需求进行详细的描述和设计，包括用例建模，建立测试策略和项目计划等。
没有通过计划决策点的需求：
- 被拒绝，即现在没有任何实现的时间表；
- 被延迟，将在下次版本的Concept Phase重新考虑；
- 需要添加负责人和注释以备查。
在此阶段，开发团队决定是否针对需求制订开发计划, 并对需求进行开发和测试，如果制订计划，需要提供以下信息：开发的状态。在开发过程中，需求一直处于InPlan状态，直到通过Availability DCP后，需求状态转变为Delivered。
如果由于开发计划延后，或开发过程中出现技术问题而导致开发团队决定不将其放入开发计划，需求会被Decommitted。如果有变更情况，负责人需要将变更记录与需求关联。
1． 统一的版本需求管理流程：无论是外部的客户需求，IBM的市场规划需求都使用相同的流程，统一的评估，统一的规划，确保需求的开发与业务目标发展一致。
2． 需求端到端状态的可视化：需求记录包含丰富的信息包括变更的记录，使得市场部门、研发产品管理部门和研发团队能够及时了解需求所处的状态，减少多方沟通的时间，并能够及时的向客户传递相应的信息，提高客户的满意度。
3． 需求信息的集中管理：每条需求都有相应的属性，如客户优先级别，所涉及的产品模块等，需求开发时间等。有了这些信息，市场部门和研发团队可以定制各种报表对需求进行查询、过滤和排序，多角度的了解需求的状况。
4． 全球同步进行需求管理：虽然IBM市场部门及研发团队都分布在全球不同地点，但是所有相关人员可以通过WEB的方式访问需求，进行需求的沟通。
7. RATLC——通过ClearQuest实现需求管理流程
在IBM 内部是使用什么系统来支撑需求管理流程的呢？答案是RATLC。 它既是 IBM 软件部用于管理产品需求和产品缺陷的系统。 RATLC通过Rational ClearQuest工具定制实现。同时由于IBM的软件研发团队分布在全球各地，为了实现每个地区团队能快捷地访问需求，RATLC通过 ClearQuest MultiSite实现了“本地复本，全球同步”的模式。现在RATCL在全球一共有 11个复本，分别位于北美、印度、法国和中国，复本之间的一致性通过ClearQuest MultiSite的自动同步功能实现。
IBM Rational ClearQuest 是一个强大而高度灵活的需求、缺陷和变更、测试计划和用例管理平台，能在整个开发周期内捕获、跟踪并管理各种类型的记录，帮助您以更高的效率交付出更高质量的软件。无论您使用的平台是Windows、UNIX或是Web，可完全自主定制的界面和工作流程引擎都能适应任何开发流程。由于ClearQuest 支持业内标准数据库，所以它可任意扩展，以支持任何规模的项目。
RATLC的具体实现方式：
（1）通过ClearQuest Designer定制RATLC中的需求管理流程。ClearQuest本身内嵌了需求管理、缺陷管理和测试管理流程。同时，鉴于IBM需求管理流程有特殊性的需求， ClearQuest提供了灵活的手段在上述的内嵌流程中进行客户化定制。RATLC就是通过ClearQuest Designer的状态过渡矩阵定制产品需求管理流程中的需求状态和其过渡关系，如图二：
图二：ClearQuest Designer的状态过渡矩阵
图三是通过ClearQuest Designer定制好后的需求管理流程的状态图，图中的椭圆代表的是需求的状态，箭头上的文字代表用户经过何种操作后，需求的状态发生了相应的变化。如需求处在“Submitted”状态，用户经过评审，确定了此需求的优先级别并更新了界面中此需求的优先级别属性后，按下界面中“Prioritize” 按钮，需求的状态变为“Prioritized”。
图三：通过ClearQuest定制的需求在流程中的状态
点击查看大图
（2）通过ClearQuest Designer表单定制功能直观地定制RATLC用户界面。
我们可以通过ClearQuest Designer提供的可视化表单定制功能直观地定制用户界面。基本上是通过Designer提供的界面工具集如按钮、文字框等拖拽地设计用户界面。如图四：
图四：ClearQuest Designer表单定制功能
图五是通过ClearQuest Designer表单定制功能定制出来的RATLC需求录入界面。
图五：RATLC的需求录入界面
（3） 通过ClearQuest客户端定制各式报表
在RATLC中系统管理员配置了不同产品的缺省报表，当用户和登录到系统的时候可以根据报表的类型（如按产品名称分类的报表）来选择需要查看的需求记录。
或者，用户登录到系统后，可以自定义报表，如产品经理需要反复查看某个客户所提交的所有需求和缺陷记录的状态，他可以自定义这样的报表，以方便在每次登录系统后都能很迅速地查询到所需要的信息。
报表的定制也是非常简单，通过拖拽字段的方式就可以便捷地建立所需要的报表。
图六：通过ClearQuest定制各式报表
（4）多客户端界面选择-Web/Windows UI/Eclipse
RATLC 充分利用了ClearQuest多客户端的特点，为不同类型的用户提供了不同的使用界面。如市场部门及研发管理部门人员，由于他们的日常操作多为查询需求的状态和修改需求记录等，RATLC为这部分人员提供了WEB访问的方式；而对于研发工程人员，由于他们需要对需求进行开发，这就涉及到与配置管理工具的集成实现变更记录与代码的结合，RATLC为他们提供了Windows客户端或Eclipse客户端，这样研发工程人员的开发环境就能很方便地与 ClearQuest结合起来。
（4）ClearQuest与ClearCase集成
在RATLC 系统中，当某个需求经过批准后被分发到相应的开发人员，此开发人员可以通过ClearQuest与ClearCase的集成，在检出代码或文档修改的时候选择相应RATLC系统的记录。这样，变更的原因（需求）和变更的结果（代码或文档）就能紧密的集成在一起，方便随后进行双向的查询，如QA可以通过 RATCL了解此需求变更涉及到哪些代码改变，或某个文件的新版本是由于什么原因而产生的。
此次我们介绍了IBM软件产品需求管理流程， 它是IBM IPD的一个实例，也就是一个由市场/客户驱动的，跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。此流程在IBM内部的支撑系统 RATLC是通过Rational ClearQuest这一优秀生命周期管理集成器来实现（如图七）。Rational ClearQuest涵盖了需求管理、变更管理、缺陷管理和测试管理。
图七：Rational ClearQuest – 生命周期管理集成器
- developerWorks 中国网站Rational 专区
- 如果您对Rational ClearQuest感兴趣并想继续研究，您可以参考以下网页：ClearQuest 产品页面
- 如果您想试用Rational ClearQuest，您可以到以下网址下载试用版：ClearQuest 试用版
 | ||
| 刘昀，现任 IBM 中国有限公司软件部 Rational 华南大区技术主管。现主要负责 Rational 产品在华为的推广和技术支持工作。在此之前，刘昀曾任职于 Bea 中国有限公司，从事J2EE解决方案的咨询工作。在加入 Bea 之前，刘昀在美国通用电器从事电子商务系统的设计开发。在软件工程技术方面，刘昀有着多年的实践经验，对于 Rational 的软件工程技术有着深刻的理解。 | |