一份内部系统需求表里，常常同时出现申请、审批、统计、消息提醒和数据大屏。若每一项都写“重要”，开发顺序就只能随会议声音变化。更可执行的做法，是先把功能放回具体业务，再说明先做它的理由。
下面用设备维修申请作假设示例，介绍一张一期排序表怎样形成。示例不是实际客户项目，不包含工期、费用或效果承诺。排序需要企业确认，不能靠一套分数公式代替业务决定。
先选一件要完成的事
先写一期打算支持哪类使用者完成什么任务。例如，员工提交维修申请，负责人员分派处理，维修结果得到确认。这个描述比“做一个综合管理平台”更容易用于检查需求。
接着列出开始和结束的证据。开始可能是一条可识别的申请记录；结束应有处理结果及确认记录。只做出提交页面，却没有后续分派和关闭路径，未必能形成可试用的第一版。
这一轮也要写不包含什么。设备采购、年度预算、供应商结算可能相关，但不一定都属于本次维修申请范围。暂不纳入不等于永远不做，保留提出人、理由和下次复查条件即可。
用依赖关系找出先后
把每个候选功能改成一个动作，标明使用角色、输入、输出和前置条件。“统计分析”太宽，可以改成“负责人查看尚未分派的申请”；它依赖申请状态和负责人的访问范围，通常不能先于这些规则独立验收。
有些工作看起来不像功能，却会影响许多功能。设备编号怎样统一、申请由谁接收、哪些状态允许撤回，都需要先确认。若这些问题未定，先画更多页面可能只会增加待修改内容。
依赖关系也不意味着所有前置系统都必须重做。已有设备台账可以继续使用，但要确认关联字段、授权范围和更正方式。没有稳定接口时，能否采用受控导入或人工核对，应由实际条件决定，不能默认自动对接一定可用。
把候选项分成不同去向
第一类是缺少就无法完成一期任务的事项，例如申请记录、必要身份识别、分派与结果确认。这类事项还要区分已明确和待确认，不能因为标成“必做”就跳过需求澄清。
第二类是可以通过约定方式暂时处理的事项。例如先由指定人员定时检查未分派列表，而消息推送放到后续验证。临时处理必须有接收人、检查频率与记录方式；若没有人愿意接手，它就不是真实可行的替代办法。
第三类是缺乏依据的想法。例如“以后可能需要很多维度的大屏”。可以保留为候选，但先写希望支持哪个决定、目前用什么数据、谁会使用。问题没有说清前，不把它直接排进一期。
排序表要留下能讨论的理由
一行需求可以记录：业务动作、影响对象、当前问题证据、缺少后的影响、前置依赖、可行替代、确认人和验收方式。比较时先问证据是否足够，而不是先争论哪个人给的分数更高。
例如，申请人无法查看退回原因，会阻碍补充材料；负责人想同时看到更多图表颜色，可能只影响呈现。两项都可以讨论，但影响程度需要基于具体任务解释。不要把示例判断搬成所有项目的固定结论。
成本或技术不确定性较高的事项，可以先做小范围验证。验证的目标可能是确认设备编号能否稳定关联，或旧系统是否提供需要的数据。得到证据后再决定开发范围，不把“先验证”写成已经承诺完整功能。
用验收情境检查排序有没有漏项
在确定一期清单前，按一条正常流程和几条典型异常走一遍：资料不全如何退回，接收人不在时如何处理，重复申请怎样识别，处理结果有异议时怎样记录。异常由实际业务选取，不为凑数量制造不相关情境。
再用不同角色的获准测试账号核对操作范围。申请人、处理人和负责人看到的信息可能不同。OWASP授权指南强调对请求检查权限，这提醒我们不能把“有登录入口”当成权限需求已经完成。
清单确定后仍可调整，但每次调整应说明替换了什么、依据是什么、谁确认。新增一项通常会影响现有安排，不能只不断往一期清单后面加行，却保持原验收口径不变。
Scrum指南把产品待办事项描述为有序、持续变化的工作列表；这里借用的是显式排序与持续细化的思路，不要求企业必须采用某种开发流程。一期排序的用途，是让参与者知道现在先解决哪件事，以及何时有证据改变顺序。
作者：聂亚奇。内容来源：智链魔方。方法参考：《Scrum Guide》产品待办事项章节、OWASP《Authorization Cheat Sheet》授权检查章节；维修情境与图示为独立方法示意。
声明：部分内容与示意配图由AI辅助生成，事实与示例边界已核对。
