DevSuite提供了变更标识功能，通过变更标识子任务，我们可以选择受影响的开发、测试任务，建立变更标识子任务，该子任务将以旗帜形式反映到开发、测试任务中。变更标识子任务不但能够标识变更，还能够帮助团队进行变更反馈，通过文字记录和状态改变，任务负责人员可以将需求变更对于任务的影响及时回馈给需求管理人员。另外，对于需求实际改变的内容，需求负责人员可以创建变更推送子任务，通过邮件系统，可以将变更信息发送给该需求的干系人。

　　方法五：需求指导项目规划与执行

　　纵使项目最初都有比较全面的计划，延期仍然会时常发生，即便是在管理机制比较成熟的大型研发企业中，跳票也不可避免。通常情况下，导致跳票主要有以下几点原因：功能设计规划过多，很多又无法删除，如不增加开发时间，产品几乎不能完成；缺乏有经验的管理或开发人员，不能准确估计工作量；任务执行缺乏规范，开发人员随意更改功能设计，影响整体进度；过高的人员流动率，导致知识的流失，任务不能及时跟进。

　　针对以上问题，只要从量化需求入手， 有序管理需求变更，用正规表达、可量化的Spec来指导项目规划、编程和测试，就能把风险降到最低。

　　基于结构化的Spec集合，可以将项目分解为多个子项目，将Spec直接分配到各自对应的子项目中，以此来规划和估算子项目的工作量。项目管理人员为每个子项目分配资源，安排优先顺序，确定项目里程碑。

　　在项目执行时，可以为每一个Spec产生出一系列开发任务。自定义的工作流机制确保每一个任务从提交到最终解决的生命周期都严格符合业务流程，保证任何时刻都有唯一的负责人、状态和截止日期。这样，不仅能规范产品研发过程，还能降低人员流动带来的风险。任务的流转及相关知识文档，如源代码、设计资源等，都得到系统完整的记录，还能与任务关联，便于追溯。一旦有人离开项目，接替的人员能够查看任务和文档信息，迅速弥补人员空缺。

　　DevSuite需求管理视图提供产品版本树管理，产品经理可以创建新产品和版本，每个需求和功能点可以在多个产品和版本实现。通常一个产品的各个功能可能会分布在不同的项目中实现，项目经理如何在产品发布的时候知道每次发布实现了那些功能，各个功能点的负责人是谁，通过DevSpec视图提供的产品版本树功能，项目经理可以轻松的过滤出每个发布版本实现了那些客户需求。

　　支持产品的版本规划，当收集到的需求经过评审等规定流程决策后，将需求与规划好的产品版本关联起来，通过产品版本视图可以直接追踪到需求与产品版本的关系，未决定开发的需求可以不设定版本，等决定后再关联相应产品版本。

　　以上所述的需求管理经验和系统工具的支持，希望与大家共同分享与探讨，探索出一条以有效的需求管理推动项目执行、产品研发整个生命周期的最佳途径！