项目的最终目的是生产出正确的，满足客户需求的工作产品。这些工作产品可能包括最终产品，如编译后的运行文件，也包括一些必不可少的中间产品，如源代码，设计文档。CMM中的配置管理和需求管理这两个关键过程的最终目标都是为了保证工作产品的完整性和一致性，使得产品的最终输出满足初始需求。
为了保证所有工作产品的完整性和一致性，实现工作产品间的追溯跟踪，DSTP提供了工作产品管理功能，从工具层面帮助实施这些过程。

完整的工作产品管理
和一般的项目管理工具不同，DSTP统一管理SVN中的代码文件和需求测试计划等条目类信息，而不单是某一类工作产品。
各种不同类型的工作产品以统一方式显示在同一个界面中。
和SVN集成，管理代码和文档
DSTP和SVN紧密集成，SVN中文件的任何变动，都会立即反应到DSTP的系统中，从DSTP中，可以直接查看SVN中所有文件和文件目录结构。因为DSTP能够同步SVN中的所有文件信息，也就同时获得了管理SVN中所有代码和文档的能力。

为需求和测试计划等条目类信息提供支持
对于需求或者测试计划等条目信息，DSTP 把他们看作虚拟的文件信息。比如需求名称可以看作是某个虚拟的需求文件的文件名，而 需求实际内容则是该文件的一些附加属性。需求的层次则可以看成是目录。对条目类信息的操作，就像在资源管理器中对文件的增删改！
通过这种把信息文件化的概念，DSTP把需求，测试计划等条目类信息和SVN中代码和文档统一起来，共同管理！

属性定义
为了区别不同类型工作产品的特征，DSTP允许为不同类型的工作产品定义相应的属性，满足管理需要。
比如需求可能需要查看来源，分优先级和重要性，期望实现实际；而测试计划则需要写明每个测试的前置条件，测试步骤和通过准则。市场人员填写的用户需求可能只需要一些自然语言描述字段，而技术人员填写完整的设计需求规格时，可能需要填写更多的技术特征属性。这些，都可以通过区分不同的工作产品类型，为工作产品设置相应的属性来区分实现。
DSTP定义的属性支持多种类型：数字，字符，日期，用户名，枚举。系统能自动根据类型用合适形式显示，方便用户操作。比如人名字段有自动联想功能，而枚举属性则自动用下拉框显示所有枚举值。
自定义属性可以设置默认值和取值范围。

自定义显示视图
不同人需要看不同的信息。比如项目经理可能对需求是否被实现了比较关注，而测试人员可能对需求描述比较关注。而每个文档都有很多属性，包括各种各样的自定义属性，全部显示会显得内容很庞杂，干扰了查看自己的兴趣点。
DSTP允许用户创建自己的视图来显示自己感兴趣的内容。保证用户查看信息是干净的，不受干扰。

全面的关联跟踪
在DSTP中，不仅可以建立需求间的依赖关系，也可以建立需求和代码文件，需求和测试计划等的关联关系！
DSTP能在一个视图中显示文件（需求）的所有直接或间接有依赖关联关系的文件（需求），以及这些关联文件的状态。在这跟踪矩阵中，全面的显示了所有工作产品双向链接，展示它们间的相互关系。
利用该功能，不仅可以清楚看到需求对应的代码是否实现；也可以直接查看每个需求所对应的各种测试计划是否测试通过。全面了解需求实现进度！
利用该功能，进行变更决策时，决策者可以清楚看到每一个变更可能带来的冲击，为变更决策时的影响分析提供有力支持！

严格的变更控制
DSTP是一个集成的项目协作平台，它的工作产品管理和任务，变更，版本管理工具等紧密结合，为工作产品管理提供了完善的变更控制。
有目的的修改
对项目中所有工作产品的修改，都必须有目的的。也就是说，必须关联项目中的合适任务或者变更，才允许修改。任何没有合适理由的修改，都会被系统自动拒绝，从而保证了所有变更受控。
变更的追溯
每次变更都被完整记录，包括哪些文件被修改，修改差异，修改人，关联的变更任务。who,when,why,what全面记录。
查看变更任务，可以查看变更任务对应修改的所有工作产品和修改内容。做为变更任务的验收确认参考。
变更建议
查看工作产品时，能直接对工作产品提出变更建议。工作产品负责人决定是否接受建议。
被接受的变更建议，可以直接导入变更系统进行正式变更评审。系统自动记录每个建议的变更进展情况。
每个测试条目发现的问题，可以先在条目下提出问题建议再导入变更系统进行缺陷修正。方便对各测试用例测试发现的问题管理。

完善的工作产品一致性保证
在DSTP中，为工作产品一致性保证提供了有力支持，避免各工作产品间出现不一致，比如需求实现遗漏，需求变更后却没同步修改代码！
变更同步：需求更改后，系统自动触发设计、测试、用户文档同步变更，直到需求得到彻底、完全的实现。
进度跟踪：自动查看跟踪任意一个工作产品的后续进度。已经测试通过？或者才刚刚改设计？相关关联工作产品是否全部同步变更？
可疑依赖：系统自动查找可能被遗漏的实现。比如某个需求已经有设计代码并测试通过，但忽略了用户文档。
版本检查：发布版本时，系统自动检查版本中所有配置项的状态。当还有配置项处于变更中，比如改了需求还没改代码或还没测试，则给予提示，直到相关版本变更全部结束后才允许发布版本，保证版本中所有组件都具有一致性。