规范点驱动开发（Specification Driven Development, 简称SpecDD）是一种全新的软件开发概念性框架，它贯穿于应用生命周期管理（Application Lifecycle Management，简称ALM）的各个阶段，支持各种成熟开发模型，旨在帮助开发团队提高项目质量，促进软件项目成功。

SpecDD概念

SpecDD概念性框架用规范点（Specification，以下简称Spec）来表述/定义产品或版本功能，并通过中央知识库与整个团队有效共享，使 Spec成为贯穿ALM各阶段的要素，从需求分析到项目规划，从编码到QA测试（如图1所示），驱动整个开发流程。

图1 SpecDD概念性框

Spec是SpecDD概念性框架中的最小单元。通常情况下，由来自各种渠道的客户和产品需求，结合以往积累的知识文档，提炼出多个 Spec。它们可以是正规表达的新功能、功能增强或缺陷修复，并与对应的需求和知识相关联。Spec是高度结构化的，其树形结构准确地对应产品/版本功能 树，以保证开发人员不丢失任何需求。图2以Browser产品为例，要完成6.0版本，开发团队需要开发“OS Support”、“Tabbed Browsing”等几类新功能，实现“User Interface”、“AJAX”、“Application” 三类基于之前版本的功能提升，修复客户或内部发现的一些缺陷，所有这些Spec都体现为分支上的树叶。

图2 用Spec完整表达软件产品

SpecDD的关键思想有如下体现：将来自于客户或产品经理的需求文档分解为结构化的“需求树”，需求的进一步添加和修改，可以直接 体现在需求树上；依照需求树，由经验丰富的技术人员将需求转变为可量化的Spec单元，通过“Spec树”直观正规地表达需求和设计；在做项目规划时，依 据Spec树、团队安排和开发阶段，进行宏观层面的子项目分解，并将Spec树中的Spec直接分配到相应子项目下，具体落实每个Spec的开发计划。有 了这棵“项目树”，Spec就能驱动产品的开发和测试了。

“以知识为核心”的SpecDD

“以知识为核心”是TechExcel ALM的宗旨，它也体现在SpecDD中。首先，知识不仅包括项目的各种文档，也涵盖了注释、web链接和email等内容，使用户对知识的使用和积累变 得更加方便快捷。通过算法对知识项目排序，也提高了知识使用的效率。另外，知识管理细化了需求管理的颗粒度，通过插件从MS Office格式的需求文档中直接check-in需求片断，就能在需求描述页面中查看相关的那部份内容，而不需要打开附件中的整个需求文档。

定性和定量地度量软件开发质量

对项目质量的度量关乎软件企业切身发展，也是ALM解决方案长期以来所关注的。决策团队在项目设计阶段的引导将直接决定项目的质 量。而管理决策本身是一个定性和定量的分析过程，需要评估需求、分配资源、预测项目的发布和里程碑日期、分析开发和QA测试过程。如前所述，SpecDD 通过定义Spec集合来指导开发工作，Spec本身是可以量化的，它不仅贯穿项目开发的各个阶段，还与需求、知识项目、其他Spec、开发和测试任务相关 联，从而保证了任务的可追溯性。如图3所示，对于“软件界面支持富文本格式”这个Spec，可分解为“description field” 、“results field”和“custom fields”三个开发任务；对于每个开发任务，不仅状态能够被跟踪，还能与相应的测试任务及其状态关联。这些环环相扣的关联关系使需求的实现过程处在透 明化管理之下，可以随时查看和追溯。

图3 跟踪矩阵示例

这种可追溯性使得以下几个方面的度量成为可能：评估开发每个需求所需要的资源和时间，关联每个功能消耗的费用，评估需求是否成功实 现，通过需求验证指标来管理开发和测试工作。SpecDD还提供了一系列度量指标，主要包括：项目规划和资源数据、日程表、任务实际花费时间、测试数据 等。

对于每一个需求或Spec，产品和项目的决策人员可以参考项目成员的投票进行决策。例如，对于Browser产品的最新版本，根据 公司VP或产品经理等成员的不同意见产生了两套候选方案，Option1和Option2，每个候选方案都是一些功能或Spec的组合。团队成员可以针对 每个需求或Spec进行投票，选择自己认为适合于该版本的需求或Spec。投票结果对最终决策有很大的参考价值。

另外，SpecDD还实现了对需求变更成本的度量，当特定的功能或需求变更提交时，需要所有相关人员都做出反馈，度量其对成本和收 益的影响，得到批准方可执行。

SpecDD之于敏捷开发

虽然敏捷开发在中国还处于刚刚起步阶段，但近几年来发展迅速，敏捷已经逐渐从“软件开发”层面渗透到整个应用生命周期。概括地说， 敏捷开发具有以下基本特征：客户提出需求列表并确定需求优先级；开发团队按照客户的详细需求提交产品所需增加的模块；客户可以在任何时间增加、删除或修改 需求。正是由于开发过程上的敏捷，使得产品或服务能更好更快地反应客户的需求，从“开发敏捷”最终实现“业务敏捷”。

然而，敏捷开发也存在一系列问题。例如，往往只有小型的、人员集中的团队更愿意采用敏捷方法；项目进展常常过度依赖于频繁的面对面 沟通；沟通过程缺乏必要的知识记录等。SpecDD很大程度上弥补了这些不足：

• SpecDD渗透到敏捷开发的每一次迭代过程中。“概念产品”在每次迭代过程中都能得到进一步改进，每次迭代的结果对概 念产品的实现又有参考价值。
• 用Spec正规、量化、完整地描述产品，使客户更容易理解修改后的设计。
• 以知识为核心的SpecDD，不仅能将敏捷运用到日常开发中，通过日积月累总结出成熟的开发实践，还能依托于中心知识库积累 的大量设计和实施数据，不断完善开发实践。
• SpecDD真正解决了分布式团队敏捷开发的问题，实现了关注点的有效分离。核心团队专注于设计“概念产品”；分布式团队专 注于开发、测试最终实现“实际产品”，随时比对“实际产品”和“概念产品”，做出及时修正，严格控制项目质量。
• 应用SpecDD，即使大型的分布式团队也能建立小型团队般的敏捷开发环境，提高开发效率，真正发挥分布式团队合作的规模效 应。

有序管理变更

敏捷开发的一个重要特点在于利用变化来为客户创造竞争优势，任何时候都欢迎客户改变需求。但是，无论是变更已有需求，还是增加新的需 求，都会对项目最终交付的日程造成不同程度的影响。如何在变更发生之前对其进行评估？这就需要将需求管理与所有开发、测试行为进行集成，用户可以通过跟踪 编码、测试等行为对变更带来的潜在影响进行评估。

SpecDD的设计实现了对需求变更的有序管理。变更请求需要由独立的工作流控制，通常包括请求、复查、讨论、调整和批准等。对于 每一个变更，都要跟踪其可能产生的费用、时间，以及它可能会影响到的开发和测试任务。对某些功能或需求的变更，需要通过特定工作流慎重管理，进行成本和利 润分析。各部门相应人员都被纳入变更管理体系，在各个阶段参与变更请求。

SpecDD实现平台 – DevSuite

TechExcel DevSuite是SpecDD的实现平台，它将软件开发过程中的所有文档文件视为知识，包括设计文档、需求、详细功能和所有相关的支持文档等，并以知识 为核心，提供了一个积累以往经验和产品需求的平台。所有知识与客户需求相关联，能帮助设计团队提炼出符合需求的、可量化的、正规表达的Spec，为研发团 队开发出实际功能迈出了坚实的第一步。之后，开发团队只需专注于在开发过程中随时比对“实际产品”与“概念产品”的差距，就可确保产品开发始终符合业务目标。