会员登录
会员注册
通常情况下，Spec包含功能、缺陷和功能增强三个部分，他们都来源于相关的知识或需求，并与需求条目和知识库中的知识条目相关联。图2以Browser 6.0产品为例，用图形化的方式显示了Spec与知识、需求的关系。针对Browser产品的最新版本6.0，有安全和用户界面两大类需求，通过需求分析师将其分解为新的功能，如支持SSL v.3.0、Tabbed Browsing等;除新功能以外，Spec还包括对之前版本的功能增强，如保存已标记的文件;以及上一版本的缺陷，如保存时响应缓慢。这些Spec通过规划、编码、测试等工作，构成最终交付的产品。
同时，Spec也是高度结构化的，表现为其树形结构准确对应产品/版本功能树，以保证开发人员不丢失任何需求(如图3所示)。产品管理团队通过创建 Spec树，使每个功能/缺陷/功能增强都能对应分支上的树叶。同时，Spec与知识项目相关联，这些知识项目描述了形成此Spec的构思，以及其他相关的文档、标准、附件和参考项目。
需求变更的管理
理解需求变更可能产生的效应，并有效的进行控制，对于软件的最后提交都是至关重要的。无论是变更已有需求，还是增加新的需求，都对项目最终交付的日程造成不同程度的影响。例如，需求变更可能会影响到与之相关的功能、任务和测试工作;编码延期会延误与该功能相关的其他开发任务和测试工作。因此，有效的需求管理工具，必须保证项目团队能够很容易的评估这些变更可能带来的影响。
如何在变更发生之前对其进行评估呢?这就需要将需求管理与所有开发、测试行为进行集成，用户就可以通过跟踪编码、测试等行为对变更带来的潜在影响进行评估。这在SpecDD模型中得以实现。
将有效的变更转变为需求
如前文所讲，SpecDD模型表现为用Spec来表述/定义产品或版本功能，并和整个团队有效共享，从而驱动开发。因此，要保证交付的产品完全符合最终版本的Spec，需求分析部门就要和开发部门协同工作，并对变更做出严格的控制。对开发工作有潜在影响的变更都将会被慎重管理，并严格检验是否影响到需求的依赖关系。所有因需求变更而产生的影响，都必须检验变更后的完整性。因此，要实现有效的需求变更，管理工具需要实现以下几种功能：
•变更控制
对变更进行严格的流程控制，包括请求、复查、讨论、调整和批准等;
变更请求由一个独立的工作流所控制;
变更不能对需求造成不良影响，因此在变更被批准之前，需求不能被改变。