做企业后台前，必须先确认哪些需求边界？

需求边界最终要落成接口、状态和验收契约

“做一个订单系统”不是可开发的边界，“销售创建报价，客户确认后生成订单，仓库发货，财务确认回款”才开始接近工程输入。我们会把每个动作写清发起人、前置状态、输入数据、产生的记录和失败处理。这样前端、后端、测试和业务讨论的是同一条流程，而不是各自理解一组页面。

用状态表和时序图暴露歧义

流程图适合看全局，状态转换表适合约束规则，时序图适合确认多个系统之间谁先调用谁。比如付款成功后，是支付平台通知系统，还是用户页面主动查询；通知重复了怎么办；库存锁定失败是否自动退款。把这些问题画出来，往往能在编码前发现责任循环和无法恢复的中间状态。

数据契约要说明来源、含义和唯一性

“客户名称”可能来自手工输入，也可能来自工商数据；“订单号”可能是本系统编号，也可能是外部平台编号。字段字典除了类型和必填，还应写来源、单位、时区、唯一约束、敏感级别和修改规则。跨系统接口则要明确版本、超时、重试、幂等键和错误码，否则联调时最容易把业务异常当成网络异常反复重试。

非功能要求决定系统能否进入生产

并发量、响应时间、可用性、数据保留、备份恢复、浏览器范围和合规要求，常常不在页面原型里，却直接影响架构。一个内部审批系统与面向公众的秒杀活动，页面数量可能接近，容量和安全设计却完全不同。我们倾向先给关键链路设置可验证的 SLO，而不是笼统承诺“高性能”。

变更要有基线，不把讨论变成对错

确认范围后保留版本基线：本阶段包含什么、明确不包含什么、如何验收。新增需求先判断是否改变数据结构、状态机、权限或第三方接口，再决定放入当前阶段还是后续迭代。变更控制不是拒绝调整，而是让时间、成本和风险透明，避免一句“顺便加一下”掩盖一次完整的架构变化。

边界确认要落成四份可执行工件

状态迁移表决定哪些动作真正合法

每个核心对象列出当前状态、动作、操作者、前置条件、目标状态和副作用。例如退款申请通过后是否释放额度、已发货订单能否取消。接口只接受表中存在的迁移，并在数据库事务里校验当前状态。这样“按钮能不能点”不再是前端个人理解，而是后端可测试的业务规则。

接口与数据契约明确谁拥有事实

契约写清字段类型、必填条件、枚举、唯一键、时间与金额单位、错误码和分页方式，同时标注客户、商品、订单等主数据由哪个系统维护。跨系统同步要定义触发时机、最终一致性和冲突处理。没有所有权约定，两个系统都能改客户名称，迟早会出现无法判断谁是准数的情况。

异常矩阵补上主流程图没有画出的部分

针对重复提交、网络超时、第三方成功而本地失败、审批人离职、数据缺失和操作撤销逐项决定：拒绝、重试、补偿还是人工处理。每类异常指定可见提示、后台状态和责任人。复杂项目的成本往往集中在这些分支，越早确认，报价和工期越接近真实。

验收用例与非目标共同锁定第一期

每个范围项写成可执行用例，包含账号角色、初始数据、操作步骤和预期结果；同时列明第一期不做的端、报表、集成和历史迁移范围。需求变化通过变更记录评估影响，而不是在群聊里随口加入。完成标准清楚后，业务、产品、开发和测试才能对“交付了什么”达成一致。