第四章：规格的骨架——功能规格、非功能规格、业务规则，三者的关系与边界
好，我们进入第四章。这一章我打算聊聊规格的骨架。
你想想看，一份需求文档拿到手，最怕什么？最怕里面全是功能描述，但系统到底要跑多快、数据怎么保护、哪些业务逻辑是铁律——这些全都没提。说白了，就是只有血肉，没有骨架。
我个人习惯，把规格拆成三块：功能规格、非功能规格、业务规则。这三者就像房子的结构、水电和装修规范。缺一个，房子就住不踏实。
4.1 功能规格：系统“做什么”
功能规格是最直观的。用户点一个按钮，系统弹出一个对话框；用户提交一个表单，系统保存数据并返回成功提示。这些都是功能规格。
我在项目中遇到过一种情况：产品经理把功能规格写得特别细，连按钮颜色、字体大小都写进去了。但系统到底支持多少人同时在线、数据多久备份一次，一个字没提。结果上线第一天，并发一上来，系统直接挂了。
功能规格的核心是描述用户与系统的交互行为。它回答的是：“用户能做什么？系统如何响应？”
功能规格的典型内容：
- 用户注册、登录、注销流程
- 商品搜索、筛选、排序功能
- 订单创建、支付、取消操作
- 数据导出、报表生成功能
嗯，这里要注意：功能规格不要写成“系统应该支持用户登录”。太模糊了。要写成“用户输入正确的用户名和密码后，点击登录按钮，系统在2秒内返回登录成功状态，并跳转到首页”。
4.2 非功能规格：系统“做得怎么样”
非功能规格，说白了就是系统的质量属性。它不关心系统做什么，而是关心系统做得好不好。
我记得有一次评审一个电商系统的需求，功能规格写了50页，非功能规格只有一句话：“系统应稳定运行”。我当时就问：“稳定是什么意思？99.9%的可用性算稳定？还是99.99%？并发1000用户算稳定？还是10000？”
对方答不上来。这就是典型的非功能规格缺失。
我的经验：非功能规格一定要量化。不要写“系统响应快”，要写“95%的API请求在200ms内完成”。不要写“系统安全”，要写“用户密码使用bcrypt加密存储，传输层使用TLS 1.3”。
非功能规格通常包括以下几类：
| 类别 | 示例 |
|---|---|
| 性能 | 并发用户数、响应时间、吞吐量 |
| 可用性 | 系统可用性百分比、故障恢复时间 |
| 安全性 | 认证方式、数据加密、审计日志 |
| 可扩展性 | 支持水平扩展、数据库分片策略 |
| 可维护性 | 日志规范、监控指标、代码注释要求 |
你可能会问：“这些非功能规格谁定？”我建议是产品经理、架构师、测试一起定。产品经理提业务要求，架构师评估技术可行性，测试负责验证。三方对齐，才能落地。
4.3 业务规则：系统“必须遵守什么”
业务规则，是系统的“法律”。它不描述功能，也不描述性能，而是描述业务上的约束和逻辑。
举个例子：一个电商系统，用户下单时，如果商品库存不足，系统不能允许下单。这就是一条业务规则。再比如：用户退货必须在购买后30天内申请。这也是业务规则。
我曾经在一个金融项目中踩过坑。业务规则写在了功能规格里，散落在各个页面描述中。结果开发实现时，有的规则被遗漏了，有的规则实现得不一致。上线后，财务对账怎么都对不上。后来花了整整两周，才把所有业务规则梳理出来。
避坑指南：业务规则一定要单独成章，集中管理。不要散落在功能描述里。我曾经见过一个项目，业务规则分散在50多个页面描述中，最后测试都不知道该测哪些规则。
业务规则的典型形式：
- 条件规则：如果A成立，则执行B。例如：如果用户信用分低于600，则不能使用分期付款。
- 计算规则：运费 = 基础运费 + 超出部分 × 每公斤单价。
- 约束规则：订单状态不能从“已发货”回退到“待支付”。
- 权限规则：只有管理员才能删除用户。
4.4 三者的关系与边界
好，现在我们来聊聊这三者怎么配合。
我习惯用一个比喻：功能规格是“做什么”，非功能规格是“多好”，业务规则是“必须遵守什么”。
它们之间不是孤立的，而是相互影响的。举个例子：
- 功能规格：用户搜索商品，系统返回结果列表。
- 非功能规格：搜索结果在1秒内返回，支持1000并发用户。
- 业务规则：搜索结果按“综合排序”展示，综合排序 = 销量 × 0.4 + 评分 × 0.3 + 发布时间 × 0.3。
你看，功能规格描述了交互行为，非功能规格约束了性能指标，业务规则定义了排序逻辑。三者缺一不可。
边界怎么划？我个人的判断标准是：
- 如果描述的是用户操作和系统响应，归功能规格。
- 如果描述的是质量指标和约束，归非功能规格。
- 如果描述的是业务逻辑和约束条件，归业务规则。
当然，有些内容会跨边界。比如“用户密码必须包含大小写字母和数字，长度不少于8位”。这既是安全性的非功能规格，也是一条业务规则。我的建议是：在非功能规格中写安全要求，在业务规则中写密码策略。两边都写，但侧重点不同。
一个小技巧：写规格时，先写功能规格，再写业务规则，最后补充非功能规格。因为功能规格最容易写，业务规则需要业务方确认，非功能规格需要技术评估。按这个顺序，效率最高。
4.5 实战案例：一个订单系统的规格骨架
最后，我拿一个订单系统的例子，把三者的关系串起来。
功能规格：
- 用户选择商品后，点击“提交订单”，系统生成订单并跳转到支付页面。
- 用户支付成功后，系统更新订单状态为“已支付”，并发送通知。
非功能规格：
- 订单提交接口的响应时间不超过500ms（95%分位）。
- 系统支持同时处理1000个订单提交请求。
- 支付回调接口的可用性不低于99.99%。
业务规则：
- 订单金额必须大于0元。
- 库存不足时，不允许提交订单。
- 订单支付超时时间为30分钟，超时后自动取消订单。
- 已支付的订单不能取消，只能申请退款。
你看，这样一拆，每个部分都清晰了。开发看到功能规格知道要做什么，测试看到非功能规格知道要测什么，业务方看到业务规则知道哪些逻辑不能改。
嗯，这一章就到这里。下一章我们聊聊如何从原型中提取这些规格，把模糊的界面描述变成可执行的文档。