4. 需求分类与建模：功能需求、非功能需求、业务规则、数据需求、接口需求

做架构设计这么多年，我见过太多项目栽在需求分析这个环节上。说白了，很多团队拿到需求就开始画架构图，结果做到一半发现漏了关键的非功能需求，或者业务规则没搞清楚，返工成本高得吓人。

我个人习惯，拿到需求后第一件事就是分类。把需求拆成五类：功能需求、非功能需求、业务规则、数据需求、接口需求。这五类就像盖房子的五张图纸，缺一张都容易出问题。

4.1 功能需求：系统要做什么

功能需求是最直观的。用户说「我要能登录」「我要能下单」，这就是功能需求。它描述的是系统对外提供的具体行为。

举个例子，一个电商系统的功能需求可能包括：

• 用户注册与登录
• 商品浏览与搜索
• 购物车管理
• 订单提交与支付
• 订单状态查询

嗯，这里要注意。功能需求一定要写清楚输入、处理、输出三个要素。我见过不少需求文档只写了「用户能下单」，但没说明下单需要哪些前置条件、支付失败怎么处理。这种模糊的需求，开发同学只能靠猜。

4.2 非功能需求：系统要做到什么程度

非功能需求，说白了就是系统的「质量属性」。用户不会直接说「我要高可用」，但他们会抱怨「系统怎么又崩了」。这就是非功能需求没满足。

常见的非功能需求包括：

我在项目中遇到过最典型的非功能需求翻车案例：一个金融系统，功能都做完了，上线前压测才发现单机只能扛200并发，而业务预期是2000并发。结果架构师连夜改方案，从单体改成微服务，工期延误了两个月。

4.3 业务规则：系统要遵循什么约束

业务规则和功能需求不一样。功能需求说「能做什么」，业务规则说「必须怎么做」。它通常是业务领域的硬性约束，不能讨价还价。

举个例子：

• 「会员等级根据年度消费金额自动升降」—— 这是业务规则
• 「同一用户每天最多领取3张优惠券」—— 这也是业务规则
• 「订单金额超过1000元需要主管审批」—— 这还是业务规则

我个人习惯把业务规则单独列出来，用决策表或者规则引擎来表达。为什么？因为业务规则变化最频繁。你想想看，业务部门今天说满减规则要改，明天说会员权益要调整。如果这些规则硬编码在代码里，每次改都要发版，累不累？

4.4 数据需求：系统要管理什么数据

数据需求，说白了就是搞清楚系统里有哪些数据、数据长什么样、数据之间怎么关联。很多架构师容易忽略这一步，直接上手画ER图，结果画到一半发现字段定义有歧义。

数据需求分析要回答三个问题：

1. 数据实体有哪些？ 比如用户、商品、订单、支付记录
2. 每个实体有哪些属性？ 比如用户有姓名、手机号、注册时间
3. 实体之间什么关系？ 比如一个用户有多个订单，一个订单包含多个商品

我记得有一次做医疗系统，数据需求没分析透，结果开发到一半发现「患者」和「就诊人」其实是两个不同的概念。患者是注册用户，就诊人是实际看病的人，两者可以是一对多的关系。这个坑踩得，数据模型推倒重来。

实体：订单
属性：
  - 订单ID (主键，字符串，32位UUID)
  - 用户ID (外键，关联用户表)
  - 订单金额 (Decimal，精确到分)
  - 订单状态 (枚举：待支付/已支付/已取消/已完成)
  - 创建时间 (DateTime)
  - 支付时间 (DateTime，可为空)

关系：
  - 一个用户可以有多个订单 (1:N)
  - 一个订单包含多个订单项 (1:N)
  - 一个订单对应一个支付记录 (1:1)

4.5 接口需求：系统如何与外界交互

接口需求，就是系统对外提供的「门」。不管是系统之间的API调用，还是用户界面的交互方式，都属于接口需求的范畴。

接口需求要明确：

• 协议：RESTful、gRPC、WebSocket、消息队列
• 数据格式：JSON、XML、Protobuf
• 认证方式：Token、OAuth2、API Key
• 错误处理：异常码定义、重试策略、降级方案

嗯，这里有个常见的坑。很多团队只定义了正常流程的接口，没考虑异常情况。比如支付接口，正常返回支付成功，但超时了怎么办？重复回调怎么处理？这些都要在接口需求里写清楚。

4.6 五类需求的建模方法

需求分类完了，接下来就是建模。不同的需求类型，建模方法也不一样：

你想想看，如果这五类需求都分析清楚了，架构设计还会难吗？功能需求决定了系统要拆成哪些模块，非功能需求决定了技术选型和部署方案，业务规则决定了核心逻辑怎么实现，数据需求决定了存储方案，接口需求决定了系统之间的通信方式。

我个人习惯，在需求分析阶段花的时间越多，后面架构设计和开发阶段就越顺畅。别急着动手画架构图，先把这五类需求梳理清楚。磨刀不误砍柴工，这个道理在架构设计里特别适用。