需求附件如何定版

建站项目里，需求附件如果只有一份笼统的文档，签约后很容易出现“当时说的是这个意思”的争执。要减少这类扯皮，关键在于把需求附件分成报价稿、确认稿和执行稿三个版本，并给每条需求编号、记录版本、确认人和变更历史。下面围绕这个做法展开，适用于需要明确交付边界的定制建站项目。

一、三版附件各管什么

报价稿用于商务沟通，列出功能模块和大致范围，不追求细节完整，但每条需求应有临时编号，方便后续引用。确认稿是双方签字或邮件确认的版本，需求描述应具体到可核对的程度，比如页面数量、字段名称、交互方式。执行稿在确认稿基础上，记录开发过程中的变更和最终实现细节，作为验收和交付的依据。

三版之间不是简单替换。报价稿的编号可以延续到确认稿，确认稿新增的需求另起编号段。执行稿保留确认稿的编号，变更部分用后缀标记，例如“R2”表示第二次修订。这样任何一条需求都能追溯到它最早出现在哪一版、由谁确认、改过几次。

二、每条需求记录哪些字段

建议每条需求至少包含：需求编号、需求名称、所属模块、需求描述、优先级、确认人、确认日期、当前版本号、变更记录。变更记录里写清变更日期、变更内容、变更原因、影响范围（是否涉及报价或工期）、批准人。字段不必多，但要保证任何一次改动都能定位到人和时间。

以下为假设示例，不代表实际工时：以“产品列表页每页显示数量”为例，报价稿写“每页显示20条”，确认稿改为“每页显示20条，支持用户切换为50条”，执行稿记录“R1：增加每页条数切换，影响前端分页组件，工期增加0.5天，确认人张某，日期某月某日”。这样后续验收时，双方对“到底做没做切换”有据可查。

三、变更如何追溯与定版

变更发生时，先由提出方填写变更记录，注明涉及的需求编号和变更内容，交确认人判断是否影响报价或工期。影响报价的，同步更新报价稿对应条目；影响范围的，在执行稿中标注。每次定版时，给附件整体一个版本号，例如“需求附件V1.2”，并在版本说明里列出本次变更涉及的需求编号。

定版后，旧版本不要删除，保留在项目文件夹中，文件名带日期和版本号。交付时，附件目录应列出各版本文件及其生效日期，方便核对最终执行的是哪一版。如果合同正文引用了需求附件，务必写明版本号和日期，避免“以最新版为准”这类模糊表述。

四、交付物是附件目录

项目交付时，需求附件本身不是交付物，交付物是一份附件目录，列明需求附件的所有版本、每个版本的生效日期、对应合同条款、以及最终执行稿的编号范围。目录还应注明哪些需求在项目过程中被取消或替换，以及对应的变更记录编号。

核对方法是：拿执行稿的编号列表，逐条对照交付成果，确认每条需求的状态（已实现、已变更、已取消）。对于已变更的，检查变更记录是否有确认人签字或邮件确认。附件目录与合同正文、验收单一起归档，后续维护或二期开发时，这份目录就是范围基准。