定制软件需求规格怎么写
定制软件的需求规格写明要达成的结果、每一条的负责人、明确留在范围外的事项，以及谁可以改这份规格。规格先写好，验收标准才有对得上的依据。写不出结果与负责人的句子，先留在讨论。
规格写在验收之前
每一条先写四项：做完之后什么算达成、谁对这一条负责、这一版明确不做什么、谁可以收下对这一条的修改。四项缺任何一项，这一句还留在讨论，不放进规格。
验收标准写的是同一条结果在演示或用户验收里如何被做出来，见 定制软件验收标准怎么写。本文停在开工前的规格。交付范围见 定制软件、网站与应用程序。
标准要求的是信息项目
ISO/IEC/IEEE 29148:2018 的名称是系统与软件工程—生命周期过程—需求工程，第二版于 2018 年 11 月出版。ISO 该页写明此版于 2024 年复核并确认，因此现行仍然有效，同时写明预期于数月内由 ISO/IEC/IEEE DIS 29148 取代；生命周期表将 2026-02-16 标为国际标准待修订。摘要写明这份标准规定需求过程要产出的信息项目、这些项目的必要内容，以及必要与相关信息项目的格式指引，并适用于各种项目范围、方法、规模与复杂度。
IEEE 的对应页 写明该标准于 2018-11-30 出版，状态为 Active Standard。同一页写明它定义良好需求的构造、需求的属性与特性，讨论需求过程在生命周期中反复、递归地应用，并写明需求工程适用的信息项目及其内容已有定义。这些内容可以加进 ISO/IEC/IEEE 12207 或 15288 已有的需求相关过程，也可以独立使用。公开页面没有逐条列出信息项目的名称。本文不抄录上述官方页面没有列出的特性形容词，也不引用售价。下面四段是购买方在开工前用来对齐的写法。
每一条写结果与负责人
结果写成旁人以后对得上的状态：哪一个角色在哪一个画面完成哪一件事，系统留下哪一笔记录。负责人是会确认「这一条就是我们要的」的那个人，名字写在条目上。
「易用」「稳定」「快」还没有结果。速度若没有贵司自己的测量与日期，条目里不写秒数。类别名称、软件包与算法留在设计说明。规格只留结果与会确认这一条的人。
范围外单独成段
规格里用单独一段列出这一版不做的事。每一项写明暂时不做的内容，以及若要纳入，要改哪一条结果、由谁收下。没有这一段，讨论过的愿望会在建造途中被当成已经答应。
一项从范围外移进范围内，要在同一笔修改里补上结果与负责人，并改规格版本。只把句子从范围外删掉、却没有新的结果条目，范围会在无记录的情况下变大。
变更留下版本与收件人
每一版规格都是一份可以指认的信息项目。改动写在同一笔记录：谁提出、谁收下、哪一条结果改了、范围外有没有跟着改。收下的人与条目负责人可以是同一人，两种角色都要在记录上分得开。
版本放在团队已经在用的 Git 或同等记录里，并写上阅读或修改的日期。事后要能指出当时开工对上的是哪一版。本文不另设一套与现行记录平行的编号规则。
规格交到验收清单
验收清单从规格里的结果条目产生，一条结果对一条或一组验收。验收补上的是展示方式：演示还是用户验收。展示方式的写法沿用验收那一篇，本文不重写。
规格改了，验收清单在同一笔修改里一起改，两份都指向新版本。验收当天才把规格改成刚刚做出来的样子，下一轮就失去对照。范围外的事项不进验收清单。
什么时候先不要加长
不必为每个标签、颜色与内部函数各写一条。那些句子没有单独的结果，负责人也不会逐条确认。条目数量以负责人实际读得完、确认得了为度。
负责人还没命名、范围外还是空白时，先不要把清单加长。先补人，再补他会确认的那几条，并把这一版不做的事写进范围外。
什么时候先不要开工
结果仍是「易用」、条目没有负责人、范围外空白，或没有人被指定收下变更时，先不要开工。先改规格，再排建造。
本文不给出页数、工期或服务水平。那些数字要来自贵司自己的规格与变更记录，并注明口径。没有这份记录之前，用「每条是否有结果与负责人、范围外是否单独成段、变更是否写明谁收下并指向同一版本」来检查规格能不能作为开工依据。