管理系统需求梳理：先看角色、流程和数据

不要从菜单和页面开始

需求讨论常从“需要哪些模块”开始，很快形成一份菜单树。但相同的模块名称，在不同企业里可能对应完全不同的职责、规则和数据。仅按页面估算，容易在开发后期才发现关键流程没有被覆盖。

梳理管理系统时，应先描述工作怎样发生：谁发起、谁处理、依据什么规则、产生什么记录，以及异常时如何回到可控状态。页面是这些关系的呈现结果，而不是需求的起点。

先把角色与责任分开

角色不应只等同于部门名称。同一部门可能包含录入、审核和查看等不同责任，同一人员也可能在不同业务范围内拥有不同权限。

角色梳理需要同时回答可见范围和可执行动作。谁能创建、修改、审核、导出或配置，哪些数据只能查看，权限是否跟随组织、项目或区域变化，都应在设计前形成基本规则。

• 角色负责完成什么业务任务。
• 角色可以看到哪些范围的数据。
• 哪些动作需要审批、复核或留痕。
• 人员变动后，权限和待办如何交接。

用主流程连接状态和异常

主流程需要标出每个节点的输入、处理动作、状态变化和输出。除了顺利完成的正常路径，还要讨论退回、撤销、重复提交、超时和数据缺失等常见异常。

状态名称应对业务人员有清晰含义，并且能够对应允许的操作。若一个状态下不同人员理解不一致，后续统计、提醒和权限判断都会出现歧义。

尽早统一数据口径

系统能否形成可靠报表，取决于源头字段和业务口径是否一致。需求阶段应确认关键数据由谁产生、是否必填、何时允许修改，以及不同系统之间由哪一方作为准确信息来源。

同名字段也可能有不同定义。例如“完成时间”可能指业务提交、审核通过或实际交付。把口径写入字段说明与验收场景，可以减少上线后的反复校正。

把验收写成真实任务

仅检查按钮是否可点击，无法证明系统能够支持工作。验收场景应由具体角色在明确前提下完成一项业务任务，并检查状态、权限、通知和数据结果是否符合规则。

• 准备接近真实情况的角色与基础数据。
• 覆盖主流程以及高风险异常流程。
• 检查操作留痕、权限边界和数据导出。
• 记录验收结论、遗留项与后续处理方式。