这类纠纷的庭审现场往往很像：委托方拿出几十条聊天记录说"我要的不是这个"，开发方拿出需求文档说"合同里就写了这些"。双方说的都不算错，问题在于合同签订时那份需求说明书到底写了什么、变更走什么程序、验收按什么标准。这三件事在签约时含糊，后面就只能靠法官去猜。
先说一个常被忽略的前提：软件定制开发在法律上未必都按技术开发合同处理。民法典第八百五十一条把技术开发合同限定为就新技术、新产品、新工艺、新品种或者新材料及其系统的研究开发所订立的合同，并要求采用书面形式。用成熟框架做一套管理系统，如果没有任何新技术内容，有些裁判会按承揽合同或委托合同处理。定性不同，解除条件、风险分担、成果归属的规则都不一样。
浙江省内一家贸易企业（委托方，下称甲）委托一家软件公司（受托方，下称乙）开发一套进销存加线上商城系统，合同价 86 万元，分三期支付：签约付 25.8 万元，初验付 34.4 万元，终验付 25.8 万元，工期 5 个月，附件《需求说明书》列明 42 项功能，验收条款写"按附件需求逐项验收，双方签署验收确认书"。
开发过程中甲陆续提出 17 项新需求，包括对接两个电商平台、增加自定义报表、调整权限体系。乙报价增补 21 万元，甲在邮件里回复"先做起来，费用后面一起算"。第七个月乙交付系统，甲组织试用后列出 23 项问题，拒绝签署验收确认书，并停付尾款 25.8 万元；乙主张系统已交付、增补费用应付，且甲迟迟不验收构成违约。
软件纠纷的表现形式很多，落到诉请上通常是五类。先把自己放进其中一类，举证方向立刻清晰。
| 类型 | 典型事实 | 主要争点 |
|---|---|---|
| 需求争议型 | 交付物与预期不符 | 需求说明书能否涵盖，变更是否成立 |
| 验收僵持型 | 一方反复提问题，不签验收单 | 验收标准、验收期限、视为接收 |
| 付款争议型 | 阶段性成果已交付，款项未付 | 付款条件是否成就 |
| 权属争议型 | 委托方拿不到源代码或著作权 | 著作权归属、源代码交付义务 |
| 终止清算型 | 项目中途叫停 | 已完成工作量、经费与报酬分担 |
上例中那 17 项新需求，是本案的核心。民法典第四百六十九条把数据电文列入书面形式，邮件、企业微信、钉钉的往来记录都可以作为合同变更的载体。所以"先做起来，费用后面一起算"这句话，很可能被认定为甲同意变更、只是价款待定，而不是"甲没同意"。
如果变更成立而价款没谈拢，法院通常按民法典第五百一十条补充确定；仍不能确定的，按第五百一十一条第二项，价款不明时按订立合同时履行地的市场价格履行。这时乙的报价单、工时记录、同行业报价就成了关键。反过来，如果甲能证明这些需求在《需求说明书》第 42 项里已经包含，只是表述抽象，那就不构成变更，乙再要 21 万元就缺乏依据。
这也是我常提醒开发方的一句话：需求文档里"支持多平台对接""报表灵活配置"这种写法，等于给自己埋雷。写清对接哪几个平台、走什么接口、报表支持几级维度，比事后争"这算不算新需求"省力得多。
法律没有给软件验收一套统一标准，靠的是合同约定。第八百五十三条要求研究开发人制定实施研究开发计划、合理使用经费、按期完成、交付成果并提供技术资料和必要的技术指导；对应的验收依据，就是合同附件里的需求说明书和验收方案。
实践中有三种常见约定，效果差别很大。第一种，"逐项功能演示通过即视为验收"，可操作但容易在细节上扯皮；第二种，"试运行 30 日，无重大故障即视为验收通过"，把时间作为标准，最省事；第三种，"以甲方书面确认验收为准"，等于把验收权完全交给甲方，开发方极其被动。上例属于第三种，甲拖着不签，乙几乎没有办法证明交付合格。
没有明确约定时，裁判通常看两件事：系统是否实际投入使用、问题清单属于缺陷还是新增需求。上例中甲已经把部分模块用于日常开单，这一事实对乙有利；但 23 项问题里如果有 8 项属于"无法登录""数据错乱"这类阻断性缺陷，那就不是验收标准的问题，而是根本未达交付条件。
这是本类案件里最容易被忽视的一条。《计算机软件保护条例》第十一条规定，接受他人委托开发的软件，著作权归属由委托人与受托人签订书面合同约定；无书面合同或者合同未作明确约定的，著作权由受托人享有。著作权法第十九条对委托作品也是同样逻辑。
也就是说，甲付了 86 万元，如果合同里只写"系统交付甲方使用"，没写著作权归属，著作权很可能仍在乙手里。甲拿到的是使用权，不是所有权，后续想改造、想二次开发、想转让，都可能受制于人。上例合同只约定了"提供源代码"，没提著作权，这个漏洞在项目结束后会一直存在。
源代码交付则是另一条线。交付源代码属于合同义务，要看合同有没有约定、约定到什么程度（是否含编译环境、数据库结构、第三方组件清单、部署文档）。只交一堆代码文件而没有文档和依赖说明，通常很难认定为完整交付。
项目做不下去，双方都想抽身时，清算就成了主战场。技术合同司法解释（法释〔2020〕19号）第十一条第一款的态度是：合同无效或者被撤销后，已履行部分产生的经费、使用费、报酬，可以认定为对方的损失，按过错分担。合同有效但协商解除的，通常按已完成工作量折算，参照合同价款与阶段成果。
这里最怕的是没有过程记录。乙如果只有一句"我们做了五个月"，没有阶段版本、测试记录、部署环境、工时表，折算就成了各说各话。反之，甲如果没有任何书面催告就突然停付，也可能被认定违约。
解除权还有一个程序细节：技术合同司法解释第十五条规定，一方迟延履行主要债务，经催告后三十日内仍未履行的，另一方可依民法典第五百六十三条第一款第三项解除；催告期限超过三十日的，视为合理期限。付款是主要债务，先发一份写明金额、期限、后果的催告函，比直接停付稳妥得多。
如果你是委托方：第一，把 23 项问题按性质分类——阻断性缺陷、功能缺失、体验优化，分别对应拒收、要求补做、另行协商，不要混成一张清单；第二，把增补需求的来源逐条比对《需求说明书》，能证明"原就包含"的，就不必付增补费。另外，尽快核查著作权条款，必要时补签书面约定。
如果你是开发方：第一，把交付证据做实——版本号、部署记录、账号密码移交清单、培训签到、试运行日志，用来证明"已交付且可运行"；第二，把增补需求做成独立的变更单，附工时与报价依据。若对方长期不验收，发书面催告并约定验收期限，为"视为接收"或解除做准备。
A：可以作为证据。民法典第四百六十九条把数据电文纳入书面形式，关键是要能还原"谁提的、提了什么、对方是否同意做"。有报价、有工时、有交付记录，认定变更成立的把握更大。
A：先看附件需求说明书和往来确认文件；仍不明确的，按民法典第五百一十条补充协议，或按行业通常标准判断。系统是否实际投入使用、缺陷是否阻断主要功能，往往成为事实上的验收标准。
A：要看合同约定。约定"验收期限届满未提异议视为通过"的，可按约定主张；没有约定的，需要用实际使用、试运行记录、催告函来证明，单方面发一份"视为验收"的通知效力有限。
A：不一定。《计算机软件保护条例》第十一条明确，无书面约定或约定不明时著作权归受托人。要拿到著作权，必须在合同里写明归属、转让范围及是否办理登记。
A：通常不算。完整交付一般包括源代码、数据库结构、部署与编译说明、第三方组件清单、接口文档和必要的培训。缺文档会导致系统无法独立维护，容易被认定交付不合格。
我处理这类案子，第一步是把"需求—变更—交付—验收"四份材料按时间轴对齐，看每一版功能是谁提出的、有没有确认、对应哪笔款。这一步做完，谁在裸奔一目了然。第二步才看合同条款，重点三处：验收标准、变更程序、著作权归属。如果你正在推进一个软件项目，我建议现在就补三份文件：一份写明验收方式和期限的补充协议、一份变更管理流程（谁能提、谁审批、怎么计价）、一份著作权归属与源代码交付清单。这三份文件不贵，但能省掉后面大部分麻烦。
免责声明： 本文内容仅供类型化办案经验交流与法律知识普及，不构成针对具体事项的法律意见，亦不构成委托代理关系。个案处理请以正式委托及生效裁判为准。