规范点驱动开发（Specification Driven Development，简称SpecDD）是一种全新的软件开发概念性框架，它贯穿于应用生命周期管理（Application Lifecycle Management，简称ALM）的各个阶段，支持各种成熟开发模型，旨在帮助开发团队提高项目质量，促进软件项目成功。
一、 SpecDD的概念
SpecDD概念性框架用规范点（Specification，以下简称Spec）来表述/定义产品或版本功能，并通过中央知识库与整个团队有效共享，使Spec成为贯穿ALM各阶段的要素，从需求分析到项目规划，从编码到QA测试（如图1所示），驱动整个开发流程。
Spec是SpecDD概念性框架中的最小单元。通常情况下，由来自各种渠道的客户需求和产品需求，结合以往积累的知识文档，可以提炼出多个Spec。它们可以是正规表达的新功能、功能增强或缺陷修复，并与对应的需求和知识相关联。Spec是高度结构化的，其树形结构准确地对应产品/版本功能树，以保证开发人员不丢失任何需求。
图2以Browser产品为例，要完成6.0版本，开发团队需要开发“OS Support”、“Tabbed Browsing”等几类新功能，实现“User Interface”、“AJAX”、“Application” 三类基于之前版本的功能提升，修复客户或内部发现的一些缺陷，所有这些Spec都体现为分支上的树叶。
项目管理论坛
SpecDD的关键思想有如下体现：
l 由精通业务逻辑的需求团队主导项目的规划设计，形成完整表达的“概念产品”，通过一个个基本单元Spec的组合来体现；
l 业务逻辑通过“概念产品”准确地传达给实施团队，驱动并指导开发、测试活动，并能在“实际产品”的研发中及时落实需求变更；
l 所有的设计规划、开发编码和QA测试都必须围绕Spec进行。
二、 “知识为核心”的SpecDD
“以知识为核心”是TechExcel公司ALM的宗旨，它也体现在SpecDD中。
首先，知识不仅包括项目的各种文档，也涵盖了注释、web链接和email等内容，使用户对知识的使用和积累变得更加方便快捷。通过算法对知识项目排序，也提高了知识使用的效率。
另外，知识管理细化了需求管理的颗粒度，通过插件从word格式的需求文档中直接check-in需求片断，就能在需求描述页面中查看相关的那部份内容，而不需要打开附件中的整个需求文档。
三、 定性和定量地度量软件开发质量
对项目质量的度量关乎软件企业切身发展，也是ALM解决方案长期以来所关注的。SpecDD通过对项目需求、时间和成本以及需求变更等多方面的控制，实现了对项目质量定性和定量的度量。
如前所述，SpecDD通过定义Spec集合来指导开发工作，因此，决策团队在项目设计阶段的引导将直接决定项目的质量。而管理决策本身是一个定性和定量的分析过程，需要评估需求、分配资源、预测项目的发布和里程碑日期、分析开发和QA测试过程。Spec作为需求的正规表达方式，不仅贯穿项目开发的各个阶段，还与需求、知识项目、其他Spec、开发和测试任务相关联，从而保证了任务的可追溯性。
如图3所示，对于“软件界面支持富文本格式”这个Spec，可分解为“description field” 、“results field”和“custom fields”三个开发任务；对于每个开发任务，不仅状态能够被跟踪，还能与相应的测试任务及其状态关联。这些环环相扣的关联关系使需求的实现过程处在透明化管理之下，可以随时查看和追溯。
这种可追溯性使得以下几个方面的度量成为可能：评估开发每个需求所需要的资源和时间、关联每个功能所消耗的所有费用、度量和评估需求是否成功实现、通过需求验证指标来管理开发和测试工作。SpecDD还提供了一系列度量指标，主要包括：项目规划和资源数据、日程表、任务实际花费时间、测试数据等。
对于每一个需求或Spec，产品和项目的决策人员可以参考项目成员的投票进行决策。例如，对于Browser产品的最新版本，根据公司VP或产品经理等成员的不同意见产生了两个候选方案，Option1和Option2，每个候选方案都是一些功能或Spec的组合。团队成员可以针对每个需求或Spec进行投票，选择自己认为适合于该版本的需求或Spec。最终的投票结果对决策人员都有很大的参考价值。
另外，SpecDD还实现了对需求变更成本的度量，当特定的功能或需求变更提交时，需要所有相关人员都做出反馈，度量其对成本和收益的影响，得到批准方可执行。
四、 SpecDD之于敏捷开发
虽然敏捷开发在中国还处于刚刚起步阶段，但近几年来发展迅速。调查显示，近几年来，使用极限编程（敏捷方法中最典型的一种）的程序员数量显著上升，敏捷开发已经逐渐从“软件开发”层面渗透到整个应用生命周期。
概括地说，敏捷开发具有以下基本特征：
l 客户提出需求列表并确定需求优先级；
l 开发团队按照客户的详细需求提交产品所需增加的模块；
l 客户可以在任何时间增加、删除或修改需求；
l 每次迭代/增量都可用于项目最后的评审。
正是由于开发过程上的敏捷，使得产品或服务能更好地反应客户的需求，及时沟通降低了项目失败率，避免开发一些不必要的功能，缩短产品发布周期，更快占领市场，从“开发敏捷”最终实现“业务敏捷”。
然而，敏捷开发也存在一系列问题。例如，往往只有小型的、人员集中的开发团队更愿意采用敏捷方法；项目进展常常过度依赖于频繁的面对面沟通；沟通过程缺乏必要的知识记录；开发人员不能完全准确地理解业务需求等。
SpecDD很大程度上弥补了这些不足：
l SpecDD渗透到敏捷开发的每一次迭代过程中。“概念产品”在每次迭代过程中都能得到进一步改进，每次迭代的结果对概念产品的实现又有参考价值。
l 用Spec这种正规表达形式完整地描述产品，使客户更容易理解修改后的设计。
l 以知识为核心的SpecDD概念性框架，不仅能将敏捷方法运用到日常开发中，通过日积月累总结出成熟的开发实践，还能依托于中心知识库积累的大量设计和实施数据，为不断总结和完善开发实践提供了坚实的基础。
l SpecDD真正解决了分布式团队敏捷开发的问题（如图4所示），实现了关注点的有效分离。核心团队专注于设计“概念产品”，并通过Spec对产品进行正规描述；分布式团队专注于开发、测试最终实现“实际产品”，随时比对“实际产品”和“概念产品”，做出及时修正，严格控制项目质量。
l 应用SpecDD，即使大型的分布式团队也能建立小型团队般的敏捷开发环境，提高开发效率，真正发挥分布式团队合作的规模效应。
五、 有序管理变更
敏捷开发的一个重要特点在于利用变化来为客户创造竞争优势，任何时候都欢迎客户改变需求。但是，无论是变更已有需求，还是增加新的需求，都会对项目最终交付的日程造成不同程度的影响。例如，需求变更可能会影响到与之相关的功能、开发任务和测试工作；编码延期会延误与该功能相关的其他开发任务和测试工作。因此，理解需求变更可能产生的效应，并有效控制，对于软件项目的成功至关重要。
如何在变更发生之前对其进行评估？这就需要将需求管理与所有开发、测试行为进行集成，用户可以通过跟踪编码、测试等行为对变更带来的潜在影响进行评估。
SpecDD的设计实现了对需求变更的有序管理。变更可能发生在开发或需求分析过程中的任何时间，包括对文档、设计以及图表的修改。对于每一个变更，都要跟踪其可能产生的费用、时间，以及它可能会影响到的开发和测试任务。对某些功能或需求的变更还会被慎重管理，需要通过特定工作流，进行成本和利润分析。团队成员的反馈意见需要与变更相关联。SpecDD主要通过以下几点的控制有序管理变更：
l 变更控制：变更请求需要由独立的工作流控制，通常包括请求、复查、讨论、调整和批准等；在变更被批准之前，需求不能被改变。
l 实用性：变更请求的控制应接近实际的需求管理实践，易于被客户理解，易实现对重要的变更进行跟踪。
l 各部门协同工作：需求、功能和开发等部门人员都被纳入变更管理体系，在各个阶段参与变更请求；让开发团队参与到变更请求的批准过程中，会比被动地接受或拒绝变更要更科学、更有效；在变更得到批准或拒绝之前，分析针对该变更在资源和时间上的分配。
六、 SpecDD的实现平台DevSuite
TechExcel的DevSuite是SpecDD的实现平台，它将软件开发过程中的所有文档文件视为知识，包括设计文档、客户需求、详细功能和行为图以及所有相关的支持文档等，并以知识为核心，提供了一个积累以往经验和产品需求的平台。所有知识与客户需求相关联，能帮助设计团队提炼出符合需求的、正规表达的Spec，为研发团队开发出实际功能迈出了坚实的第一步。之后，开发团队只需专注于在开发过程中随时比对“实际产品”与“概念产品”的差距，就可确保产品开发始终符合业务目标。
七、 关于TechExcel 公司
TechExcel公司是世界领先的应用生命周期管理（ALM）、IT服务管理（ITSM）和客户关系管理（CRM）解决方案提供商，倡导“以知识为核心”的管理理念，为企业实现产品开发与服务支持间的沟通，在管理软件研发全过程的同时，促进服务支持流程规范化，通过成熟的管理实践，实现企业战略目标。
