评价一份需求文档能否长期维护、能否作为后续验收依据，可以从三个方向入手：内容是否完整到可执行、表述是否清晰到无歧义、结构是否可追踪可更新。把这三类判断拆成可打分的检查项，为每项指定证据来源和通过标准，再按统一口径抽样评分，就能得到一份可复算的评估结果。评分用于定位薄弱环节，最终结论仍需结合评审判断。
要点总览（TL;DR）
- 评价需求文档要分开看两件事：可维护性关注文档能否被后续角色读懂、修改、追溯，可验收性关注每条需求能否对应明确的验收条件和证据。
- 把两类目标拆成完整、清晰、可追踪、可验收四个维度，每个维度下设可观察的检查项，并为每项指定证据来源和通过标准。
- 评分口径统一为得分率=通过项数÷有效检查项数，按维度分别计算；分母为零的维度标注不适用，同一轮评估内抽样单位保持一致。
- 分数用于定位薄弱条目和安排复评，不证明需求本身正确，不同团队、不同需求类型的分数不宜直接横比。
评价目标：可维护与可验收分别要回答什么
可维护性和可验收性指向两类不同的判断，混在一起评容易出现“文档写得整齐就给高分、验收条件缺失却被忽略”的情况。先分开界定，再合并成一套检查项，评分结果才有解释力。
| 判断对象 | 要回答的问题 | 典型失败表现 |
|---|---|---|
| 可维护性 | 后续的产品、开发、测试人员能否读懂这份文档，能否在需求变化时找到需要修改的位置，能否追溯某条需求的来源和变更过程 | 背景缺失导致新人反复询问；同一术语在不同章节含义不同；需求改动后旧描述未清理；找不到某条规则的提出原因 |
| 可验收性 | 每条需求能否对应明确的验收条件、判定方式和证据来源，测试或验收人员能否据此判断“做完了且做对了” | 需求只写“支持导出”，未说明导出范围、格式和异常处理；验收时靠口头确认；验收用例与需求条目对不上号 |
两类目标共享同一份文档，但判定问题不同。可维护性关注文档作为长期资产是否可读、可改、可查；可验收性关注文档作为验收依据是否可判定、可举证。一份文档可能结构清晰却缺少验收条件，也可能验收条件写得很细但背景和范围缺失，后续维护困难。评估时分别计分，才能看清短板在哪一侧。
评价维度与指标范围：完整、清晰、可追踪、可验收
把两类目标落到四个维度，每个维度下设若干检查项。检查项要写成可观察的判断句，避免“内容是否充分”这类无法打分的表述。
完整性
- 背景与目标：文档是否说明需求要解决的问题、服务哪类用户、预期达成什么结果。
- 范围边界：是否写明本次包含什么、不包含什么，与其他需求或版本的边界是否清楚。
- 角色与场景：涉及的角色、使用场景、主流程是否齐备。
- 异常分支：失败、超时、权限不足、数据为空等情况的处理是否交代。
- 非功能约束：性能、安全、兼容性、数据保留等约束是否有明确要求或明确标注“本期不涉及”。
清晰性
- 术语一致：同一概念全文使用同一名称，关键术语有定义或指向术语表。
- 指代明确：避免“该系统”“相关模块”这类无明确指向的表述。
- 条件完整：规则写清触发条件、适用范围和例外情况。
- 量化表述：涉及数量、时限、频率的要求给出具体数值和单位。
可追踪性
- 编号体系：需求条目有稳定编号，正文、评审记录、验收用例可引用同一编号。
- 版本与变更记录：文档有版本号，重要变更记录修改内容、原因和时间。
- 上下游关联：需求与来源（业务方、用户反馈、上层目标）以及下游（设计、开发任务、测试用例）的关联可查。
可验收性
- 验收条件：每条功能需求附带可判定的验收条件，说明在什么前提下、执行什么操作、观察到什么结果算通过。
- 判定方式：说明验收由谁执行、依据什么材料判定，例如测试用例、演示记录、数据核对结果。
- 验收证据留存：验收结论和支撑材料有指定存放位置，便于后续复查。
指标范围要与评估目的匹配。若本轮评估针对即将进入开发的一批需求，检查项应覆盖这批需求涉及的全部维度；若只关心验收准备度，可以只评可验收性维度，但需在报告中注明范围，避免读者把局部得分理解为整体结论。抽样范围同样要事先写清：评哪些文档、哪些需求条目、哪个时间段的版本。
数据口径与证据：每项指标拿什么材料判定
评分要经得起复核，每项检查都要指定证据来源。凭印象打分的评估在多人参与时很难对齐，也无法在复评时比较变化。
| 指标 | 证据来源 | 通过标准示例 |
|---|---|---|
| 背景与目标 | 文档正文首节 | 能用一段话说明问题、目标用户和预期结果，且与需求条目内容一致 |
| 范围边界 | 文档正文、版本说明 | 明确列出本期包含与不包含的内容，至少各一条 |
| 异常分支 | 文档正文、评审记录 | 主流程涉及的每个外部依赖或用户输入，均有对应的失败处理描述 |
| 术语一致 | 文档正文、术语表 | 抽查关键术语，全文用法一致；首次出现处有定义或指向 |
| 量化表述 | 文档正文 | 涉及数量、时限、频率的要求均带数值和单位，无“较快”“适当”等无法判定的表述 |
| 编号体系 | 文档正文、关联工作项 | 每条需求有唯一编号，验收用例可引用该编号定位到需求 |
| 变更记录 | 版本历史、评审记录 | 最近一次实质性修改有记录，包含修改内容与原因 |
| 验收条件 | 文档正文、验收用例 | 每条功能需求至少有一条可判定的验收条件，且能对应到验收用例或核对方式 |
| 验收证据留存 | 验收记录、关联工作项 | 已完成的验收有结论记录和支撑材料，位置可查 |
定性指标的通过标准要写成可观察的描述。“验收条件充分”不可观察，改成“每条功能需求至少有一条验收条件，且条件中包含前提、操作和预期结果三要素”就可以逐条核对。证据缺失时按未通过计分，并在备注中标注缺失原因，例如“文档未提供变更记录”，不要用推测补足。分母口径需在评估开始前确定：以需求条目数为单位时，每条需求逐项检查；以文档篇数为单位时，每篇文档整体判定一次。两种口径的得分不可直接比较，同一轮评估内保持一致。
计算与评估步骤：从抽样到得分
评分流程要能让另一位评审人按同样步骤复算出接近的结果。建议按以下顺序执行。
- 确定抽样范围。写明评估的文档清单、需求条目范围和版本时间点。样本量根据评估目的确定，例如抽取本轮迭代全部需求条目，或按模块分层抽取若干条；样本过少时结论只作参考。
- 逐条打分。每个检查项按“通过 / 不通过 / 不适用”三档判定，通过记1分，不通过记0分，不适用不计入分母。判定时记录证据位置，便于复核。
- 按维度汇总。维度得分率 = 该维度通过项数 ÷ 该维度有效检查项数 × 100%。整体得分率 = 全部通过项数 ÷ 全部有效检查项数 × 100%。
- 处理分母为零。某维度所有检查项均不适用时，该维度标注“不适用”，不参与整体得分率计算，并在报告中说明原因。
- 多人评分对齐。评分前由两名以上评审人各抽3至5条需求试评，比对分歧点，统一检查项定义后再全面评分；全面评分后抽检一定比例复核，分歧较大的条目由评审组讨论定案。
分值设定保持简单，避免不同检查项权重差异过大导致结果难以解释。若确需区分重要程度，可在报告中同时给出未加权得分率和按权重计算的得分率，并说明权重来源。
示例：一份需求文档的评分过程
以下为演示情景，用于说明评分口径，不代表任何真实项目。
某需求文档包含10条功能需求，评估范围为本期全部条目，采用条目级口径。检查项共12项，其中2项因文档明确标注“本期不涉及非功能约束”而判定为不适用，有效检查项10项。
| 维度 | 检查项数 | 通过 | 不通过 | 得分率 |
|---|---|---|---|---|
| 完整性 | 3 | 2 | 1 | 66.7% |
| 清晰性 | 3 | 2 | 1 | 66.7% |
| 可追踪性 | 2 | 1 | 1 | 50.0% |
| 可验收性 | 2 | 2 | 0 | 100% |
整体得分率 = 7 ÷ 10 × 100% = 70%。从维度看，可验收性满分，说明验收条件写得较完整；可追踪性得分最低，具体不通过项为“变更记录”：文档最近一次修改调整了导出范围，但版本历史中没有记录修改原因。清晰性不通过项为“量化表述”：一条需求写“导出文件不宜过大”，缺少具体上限。完整性不通过项为“异常分支”：导出失败时的重试与提示未描述。
据此提出的修改动作是：补充导出文件大小上限及单位、补写导出失败处理、在版本历史中记录本次范围调整的原因。修改完成后针对这三项复评，其余检查项沿用原判定，复评结果单独留档，与原评分并列保存以便对比。
评分依赖需求条目、变更记录和验收条件能够被稳定引用和留存。使用 ONES 时，ONES Wiki 的页面组可关联项目，需求与文档互相对应，文档实时同步并记录所有页面版本，支持随时查看与回滚，便于在复评时核对变更前后的内容；文档也可关联项目任务，使需求条目、开发任务与验收记录保持在同一工作上下文中。评估中若需要按编号定位条目和关联材料，这些关联关系可以作为证据来源的一部分。
解读与限制：分数能说明什么、不能说明什么
得分率反映的是文档在当前时点、按当前检查项口径的状态。它回答“哪些检查项没通过、薄弱环节在哪”，不回答“需求本身是否正确”。需求方向错误但文档写得完整清晰，仍可能得高分；需求正确但文档粗糙，得分会偏低。评分结果应与评审结论、验收结果结合使用。
- 分数不证明需求质量。它衡量文档的可维护与可验收程度，不衡量需求价值、优先级判断是否正确。
- 不同团队、不同需求类型的分数不宜直接横比。检查项定义、样本构成和需求复杂度不同，分数差异可能来自口径而非文档水平。跨团队比较前需统一检查项和抽样规则。
- 单指标异常不等于整体不合格。某一维度得分低，应回到具体不通过条目判断影响范围；若异常集中在少数条目，可针对性修改后复评。
- 评分与验收结果的关系是间接的。验收条件完整有助于验收执行，但验收是否顺利还取决于实现质量、测试覆盖和环境准备。
- 复评周期按需求变更节奏设定，例如每次版本发布前或需求重大变更后复评一次；评分记录、证据位置和复评结论一并留档，作为后续追溯依据。
把评分当作定位工具而非结论工具，评估结果才能真正用于改进文档，而不是变成另一份需要维护的形式材料。
常见问题
检查项里的“不适用”什么时候用，会不会被当成放水？
“不适用”只用于检查项与本次评估对象确实无关的情况，例如文档明确标注本期不涉及非功能约束，或某类需求本身没有对应的异常分支。判定时要写明理由，并让复核人能看到依据。若某维度全部检查项都不适用，该维度标注“不适用”，不参与整体得分率计算，同时在报告中说明原因。把“没写”判成“不适用”属于口径错误，复评时应纠正。
只有一名评审人，评分结果还可信吗？
单人评分可以做，但需要在流程上补两点：一是评分前把检查项定义和通过标准写成文字，判定时逐项记录证据位置；二是隔一段时间由同一人或另一人抽检部分条目复核，重点看分歧较大的检查项。单人评分的主要风险是口径漂移，同一批文档前后判定标准不一致，因此建议在评估开始前先试评几条，把边界情况定下来再全面展开。
需求条目很多，全量评分成本太高，抽样怎么抽才不失真？
可以按模块或需求类型分层抽样，每层抽取一定数量条目，保证覆盖面而不是只抽容易评的部分。样本量根据评估目的确定：若用于判断某批需求能否进入开发，应覆盖这批需求的全部条目；若用于例行体检，可按层抽取若干条，并在报告中注明样本范围和结论适用范围。样本过少时结论只作参考，不宜据此对整份文档下整体判断。
评分发现验收条件缺失，应该先补文档还是先推进开发？
取决于缺失程度和需求所处阶段。若缺失的验收条件涉及核心流程或关键判定规则，建议在进入开发前补齐，否则测试和验收阶段容易反复确认；若只是个别次要条目的表述不够具体，可以带着修改项推进，并在开发过程中同步补充。无论哪种处理，都应把缺失项记录在评估结果中，明确责任人和补充时间，复评时逐项核对。
复评时检查项要不要跟着调整？
同一轮评估周期内保持检查项不变，复评结果才能与原评分对比。若发现某些检查项定义不清或与当前需求类型不匹配，可以在下一轮评估开始前统一修订，并说明修订内容，避免新旧口径混用。复评时沿用原判定标准的条目可直接引用原证据，只对修改过的条目重新判定，结果与原评分并列留档。
