定制软件验收标准怎么写
定制软件的验收标准写明可观察的结果、负责人，以及这项结果在演示或用户验收里如何被做出来。标准先于演示，演示与验收才对得上同一份清单。写不出结果与负责人的句子，先不要放进验收。
一条标准里要有的三项
每一条写三项：做完之后旁人看得到什么、谁对这条负责、用演示还是用户验收把这条做出来。三项齐了，才放进清单。
ISO/IEC/IEEE 29148:2018 的名称是系统与软件工程—生命周期过程—需求工程，第二版于 2018 年 11 月出版。ISO 该页写明此版于 2024 年复核并确认，因此现行仍然有效，同时写明预期于数月内由 ISO/IEC/IEEE DIS 29148 取代；生命周期表将 2026-02-16 标为国际标准待修订。该标准规定需求过程要产出的信息项目及其必要内容，并适用于各种项目范围、方法、规模与复杂度。IEEE 的对应页 写明该标准于 2018-11-30 出版，状态为 Active Standard，并写明它定义良好需求的构造、需求的属性与特性，以及需求过程在生命周期中反复、递归地应用。本文不抄录上述官方页面没有列出的特性形容词，也不引用售价。购买方写验收时，把每一条落成可观察的结果、负责人，以及展示方式。
跟演示走同一份清单
演示前，主持人念出条目编号与预期结果，再操作。在场的人核对的是结果有没有出现。一段没有条目编号的画面导览，不能代替这份清单。
演示当中做不到的条目留在清单上，标明未演示与原因。条目若要改，回到清单改完，下一轮演示再用新条目。当场把条目改成刚刚做出来的样子，下一轮就失去对照。
用户验收走同一份清单
用户验收的脚本就是这份清单，换由条目的负责人执行，或在场签认。负责人缺席的条目，留到负责人在场再计入通过。
边界单独成条：空白输入、重复提交、权限不足、记录已经存在。只有顺利路径的清单，可以在验收里全数通过，同时漏掉购买方在意的失败。边界没写的，补进清单，再排下一次验收。
三种常见的写法会使验收落空
「易用」「稳定」「快」没有可观察的结果，就还没有标准。速度若没有贵司自己的测量与日期，条目里不写秒数。改写成旁人看得到的结果，例如负责人在指定画面完成指定步骤，并留下记录。
没有负责人的条目，演示结束后无人签。条目若写的是类别名称、套件或算法，结果仍成立时实现一换，条目就会整条作废。实现留在设计说明。验收只留结果、负责人与展示方式。
什么时候不要写得过细
不必为每个标签、颜色与内部函数各写一条。那些句子一轮演示走不完，负责人也不会逐条签。条目数量以一轮演示或一次验收实际走得完为度。
负责人还没命名之前，先不要把清单加长。先补人，再补他会签的那几条。边界要写进验收。内部实现留在设计说明。
清单与被验收的版本放在一起
条目一改，演示脚本与验收脚本在同一笔修改里一起改。验收记录写明对上的软件版本。版本放在团队已经在用的 Git 或同等记录里，事后才看得到当时签的是哪一版。
若这套软件管的是租赁记录，条目要对上已经写明的记录种类，见 设备租赁管理系统怎么选。交付范围见 定制软件、网站与应用程序。
什么时候先不要召开验收
条目仍是「易用」、边界没写、或负责人不会到场时，先不要召开验收。先改清单，再约时间。
本文不给出缺陷数、合同期限或服务水平。那些数字要来自贵司自己的验收记录，并注明口径。没有这份记录之前，用「每条是否有结果、负责人与展示方式，演示与验收是否走同一份清单」来检查验收有没有按标准走。