科技券系统开发类项目验收标准与文档
科技券（Technology Voucher Programme，简称 TVP）是香港生产力促进局推出的资助计划，每家企业可获累计最高港币 60 万元资助（以官方最新公布为准），用于采购现成或订制的科技解决方案。在所有项目类别中，「系统订制开发」是申请量最大、但也是验收阶段最容易因细节缺失被退回的一类。系统开发不同于购买现成 SaaS 软件，它涉及代码交付、设计文档、测试报告、安装部署等大量客观凭证——任一环节缺失，审批主任都可能要求补件甚至削减资助金额。
本文聚焦系统开发类项目，从交付物、文档规范、测试要求三个维度，梳理一份完整的验收清单。
一、系统开发类项目的特殊验收逻辑
科技券采用 「先批后用，再核验」 的三段式流程：
- 申请阶段：提交报价单、项目计划书、开支预算；
- 批准阶段：获批后与企业签订资助协议，须在约定期限（一般 12 个月内，可申请延期一次）内完成项目；
- 验收阶段：项目完成后，提交最终报告 + 全部交付物 + 付款凭证，由生产力局审核主任核查后才发放资助。
核心原则：所有交付物必须可追溯、可验证、可呈现。审批主任不会单凭企业口头描述判断项目是否完成，而是以「书面文件 + 系统截图 + 测试记录 + 付款凭证」四类证据交叉验证。
| 项目类型 | 验收难度 | 关键证据 |
|---|---|---|
| 现成软件采购 | 低 | 软件许可证书、付款收据 |
| 云端订阅服务（SaaS） | 中 | 订阅合同、付款记录、后台使用截图 |
| 系统订制开发 | 高 | 需求文档、设计文档、源代码、测试报告、用户手册 |
| 流程改善咨询 | 中 | 顾问报告、培训记录、付款凭证 |
二、必备交付物清单
系统开发项目验收时，至少需备齐以下九类文件：
1. 项目计划书（已批版本）
必须与申请时提交、获生产力局核准的版本完全一致。若项目过程中出现重大变更（更换供应商、调整功能模块、变更交付时间），须事先提交修订申请并获同意，否则验收时会被视为「未按批准计划执行」。
2. 需求规格说明书（Requirement Specification）
描述系统功能需求、性能需求、用户角色、操作流程。建议包含：
- 功能列表（Function List）
- 用例图或用户故事（User Story / Use Case）
- 非功能需求（如并发量、响应时间、安全等级）
- 验收准则（Acceptance Criteria）
验收关注点：是否明确写出”什么算完成”。
3. 系统设计文档（System Design Document）
涵盖：
- 架构图（系统整体技术架构、模块划分）
- 数据库设计（ER 图、表结构说明）
- 接口设计（API 文档、内部模块接口）
- 安全设计（权限分级、数据加密、备份策略）
4. 源代码及版本记录
- 完整的源代码包（一般以压缩包形式提交）
- Git 提交记录或版本控制日志（证明开发过程真实发生）
- 第三方组件清单与开源协议声明
注意：源代码无须公开提交完整工程，但需保留可被审计抽查的版本记录。
5. 测试报告（Test Report）
这是验收的核心文件，须包含：
- 测试计划（Test Plan）
- 测试用例（Test Case，至少覆盖主要功能）
- 测试结果（Pass / Fail 记录、截图）
- 缺陷清单（Bug List）及修复记录
6. 用户验收测试记录（UAT Record）
由企业方签字确认的 UAT 记录，证明系统已通过最终用户测试。建议包含测试人员姓名、测试日期、测试场景、签字栏。
7. 用户手册与培训记录
- 用户操作手册（PDF 或网页版）
- 培训出席记录、签到表、培训照片（如适用）
8. 系统截图与运行环境说明
- 系统主界面截图
- 后台管理界面截图
- 服务器部署信息（云端平台、配置规格）
- 系统上线证明（上线日期、网址、登录演示截图）
9. 付款凭证
- 每笔支出的发票 / 收据
- 银行转账记录
- 付款方与收款方名称须与合同一致
三、文档规范的五个常见扣分点
审批主任对系统开发类项目的文档有明确的形式要求，以下五类问题最容易导致补件：
扣分点 1：文件没有日期与版本号
所有文档须标注「文档版本号」「最后更新日期」「编写人」。缺失日期会让审批主任怀疑文件是临时补造。
扣分点 2：测试报告只有结果没有截图
「所有测试用例全部通过」这类结论性描述不构成证据。每个测试用例都应附执行截图，至少覆盖核心业务流程的端到端测试。
扣分点 3：源代码包无法解压或缺失
压缩包须采用通用格式（zip / rar），内部结构清晰可读。若提供的是代码托管平台链接（如 GitHub 私有仓库），须确保审批主任在合理时间内可访问。
扣分点 4：发票信息与合同不匹配
发票抬头须与企业名称完全一致；付款金额、币种须与报价单一致；分期付款的，每期发票须对应合同条款。
扣分点 5：缺失用户验收测试签字
UAT 记录若无企业方代表签字，系统等于「未交付」。建议由项目负责人亲自签字，并加盖公司印章（如有）。
四、测试报告怎么写才算合格？
测试报告是系统开发验收的「命脉文件」。一份合格的测试报告应满足以下结构：
| 模块 | 内容要求 |
|---|---|
| 测试概述 | 项目名称、测试范围、测试周期、测试环境 |
| 测试策略 | 黑盒 / 白盒、功能 / 性能 / 安全测试的覆盖说明 |
| 测试用例 | 用例编号、输入数据、操作步骤、预期结果、实际结果、Pass/Fail |
| 缺陷管理 | Bug ID、严重等级、修复状态、回归测试结果 |
| 测试结论 | 通过率统计、未解决缺陷说明、综合结论 |
| 附件 | 关键测试截图、性能测试曲线图 |
实战建议：
- 至少准备 30-50 个测试用例，覆盖正常流程与异常流程；
- 性能测试可使用 JMeter、LoadRunner 等工具生成并发测试报告；
- 若系统涉及支付、登录、权限等敏感模块，须额外补充安全测试记录。
五、验收前的自查清单
在提交最终报告前，建议企业用以下清单逐项核对：
- 项目计划书与实际执行一致，无未报备的重大变更
- 所有交付物均已上传至生产力局指定系统
- 需求文档、设计文档、用户手册齐全且带版本日期
- 测试报告含截图、用例编号、Pass/Fail 记录
- UAT 记录有企业方签字
- 源代码包可正常解压，目录结构清晰
- 系统截图包含主界面、后台、关键功能流程
- 发票抬头、金额、付款方与合同一致
- 培训记录 / 用户手册已发放至最终用户
- 项目实际支出与核准预算偏差在合理范围内
六、常见被退回的原因与对策
根据过往项目案例，系统开发类被退回补件的高频原因集中在：
- 开发未完成：部分功能仅做了 Demo，未真正上线运行；
- 文档与系统脱节：截图是后期补拍，与实际功能不符；
- 测试走过场：测试用例数量过少，未覆盖主流程；
- 付款超前：发票日期早于交付物完成日期；
- 超期未申请延期：项目超过核准完成日期仍未提交验收。
对策：
- 立项时与企业约定清晰的「验收标准」并写入合同；
- 开发过程中同步整理文档，避免「最后一周补文档」；
- 收到供应商发票前，先确认系统已上线、文档已就绪；
- 临近截止日期前 60 天，主动评估进度，必要时申请延期。
七、写在最后
系统开发类项目验收的核心逻辑是「证据链完整」：从需求到设计、从代码到测试、从交付到付款，每一个环节都需要可被第三方独立验证的书面记录。比起技术实现难度，文档的规范性与完整性往往更能决定项目能否一次性通过审批。
科技券的资助金额虽然有限（以官方最新公布为准），但其严谨的核验机制也训练了中小企业一套标准化的项目管理流程——这些经验本身，往往比资助款更值钱。
更多香港政府资助、签证、税务与营商指南，欢迎浏览 香港大全。
常见问答
系统开发类科技券项目验收时，必须准备哪些核心文档？
依据文章内容，系统开发类项目至少需备齐九类文件：项目计划书（已批版本）、需求规格说明书、系统设计文档、源代码及版本记录、测试报告、用户验收测试记录（UAT）、用户手册与培训记录、系统截图与运行环境说明，以及付款凭证。九类文件齐备且互相一致，构成验收的「证据链」。
测试报告里只写「全部通过」可以吗？为什么会被退回？
不可以。文章明确指出，「所有测试用例全部通过」这类结论性描述不构成证据。每个测试用例都应附执行截图，至少覆盖核心业务流程的端到端测试，否则会被视为「测试走过场」而要求补件。
源代码包是否一定要公开提交完整工程？
不一定。文章提到，源代码无须公开提交完整工程，但需保留可被审计抽查的版本记录，例如 Git 提交记录或版本控制日志。同时，压缩包须采用通用格式（zip / rar），内部结构清晰可读，若提供代码托管平台链接，须确保审批主任在合理时间内可访问。
项目中途更换供应商或调整功能模块，应该怎么处理？
须事先提交修订申请并获生产力局同意。文章强调，验收时会核对项目计划书与申请时提交、获核准的版本是否完全一致；任何更换供应商、调整功能模块、变更交付时间等重大变更，若未事先报备，会被视为「未按批准计划执行」。
临近项目截止日期才发现做不完，能否补救？
可以申请延期。文章指出，科技券项目获批后须在约定期限（一般 12 个月内）完成，但可申请延期一次。建议企业在临近截止日期前 60 天主动评估进度，必要时尽早申请延期，避免出现「超期未申请延期」而被退回的情况。