需求采集与场景定义：用户故事、非功能约束、边界假设

需求采集不是简单的“用户说什么就记什么”，而是架构师将混沌的业务诉求转化为可验证、可设计的边界条件的起点。本章聚焦于如何通过用户故事捕获功能意图，通过非功能约束钉死质量底线，通过边界假设划定方案的设计半径。三者共同构成原型落地前的“需求资产清单”。

2.1 用户故事：从“谁-要什么-为什么”到可验证场景

用户故事不是需求文档，而是结构化沟通卡。标准模板为：
As a [角色], I want [能力] so that [价值]

2.2 非功能约束：刻在架构里的质量门槛

非功能约束（NFR）决定了原型选型与技术栈边界。它必须可测量、可测试。以下为典型约束分类与示例：

2.3 边界假设：主动标注的设计半径

边界假设是需求阶段未明确、但设计方案必须依赖的环境条件。未被书面化假设是架构回滚的首要风险源。假设必须包含“若假设不成立，则方案失效”的应对策略。

常见边界假设分为三类：

1. 外部依赖假设：第三方接口的响应时间、限频、可用时间段；例如“支付网关的TPS不低于1000/s”。
2. 基础设施假设：中间件版本、JDK版本、操作系统参数；例如“Redis 6.x 支持 RBAC 权限控制”。
3. 业务规则假设：并发场景下不出现互斥操作；例如“同一用户不会同时从两个终端发起结算”。

2.4 从故事到结构：用户故事到系统边界的映射

下图展示了如何通过用户故事提取系统边界、模块职责和信任链路。彩色节点代表不同的参与者/系统，标色箭头代表边界数据流。

2.5 三个必须处理的专题

2.5.1 信任链路：谁信任谁，用什么协议

在用户故事中，当系统与外部Actor交互时，必须定义信任模型。配送员通过Token认证（身份信任）；第三方网关通过签名（数据完整性信任）。每个故事必须回答：“是否允许该角色直接访问？是否需要验证？验证失败时的系统行为是什么？”

2.5.2 数据流与控制流：从故事到技术落地

用户故事隐含了数据流动方向和控制权转移。以“配送员查询轨迹”为例：

• 数据流：移动端→API网关→轨迹服务→数据库（读）→返回
• 控制流：请求-响应同步模型；若轨迹未生成，则返回204 No Content

将所有故事的数据流与控制流合并后，即得到初始的系统架构分层图，包括入口层、业务层、数据层和基础设施层。

2.5.3 原型实现匹配要点

根据上述分析，原型阶段应优先实现以下关键路径：

1. 至少2个核心用户故事的全链路（从 Actor 到存储再到返回）
2. 1个非功能约束的验证场景（例如延迟边界）
3. 1个边界假设的验证测试（例如第三方接口超时后的降级行为）

验收条件1：配送员以有效Token发起轨迹查询，系统在500ms内返回完整轨迹数据（包含至少3个节点）。
验收条件2：当第三方支付网关在回调时返回签名校验失败，系统记录安全日志并返回HTTP 401。
验收条件3：假设“配送员查询时轨迹数据存在”不满足时（即数据库无记录），系统返回含错误原因的204，不崩溃。

2.6 风险清单