3. 功能需求与非功能需求：拆解方法、性能、安全与可用性
说实话，很多新手产品经理或开发同学，拿到需求文档后第一反应就是「赶紧画原型、写代码」。但我在实际项目中踩过无数次坑之后，才真正理解一个道理：需求拆解得不够细，后面全是雷。
这一章，我们就来聊聊功能需求怎么拆、非功能需求怎么定。尤其是性能、安全、可用性这三座大山，你想想看，哪个线上故障不是跟它们有关？
3.1 功能需求拆解：从一句话到一张表
功能需求，说白了就是「系统要做什么」。但「用户能登录」这句话，能直接扔给开发吗？当然不行。我个人的习惯是，把每个功能需求拆成三层：
- 用户层：用户能感知到的操作和反馈
- 业务层：背后触发的业务流程和数据变化
- 系统层：接口、状态机、异常处理
举个例子，「用户注册」这个功能，拆出来是这样的：
| 层级 | 需求描述 |
|---|---|
| 用户层 | 用户输入手机号、验证码、密码，点击注册按钮 |
| 业务层 | 校验手机号格式、验证码有效期、密码强度；创建用户账户；发送欢迎短信 |
| 系统层 | POST /api/register 接口；60秒验证码过期；密码加密存储；手机号唯一索引 |
为什么要拆这么细？因为每一层都可能出问题。我曾经遇到过一个项目，产品经理只写了「用户注册」，结果开发直接调了短信验证码接口，没做频率限制，上线当天短信费就烧了五千块……嗯，从那以后，我再也不敢跳过系统层的细节了。
3.2 性能需求：别等上线了才喊慢
性能需求是最容易被忽略的非功能需求。很多团队都是上线后用户反馈「好卡啊」，才想起来做压测。我个人的经验是，性能需求必须在需求阶段就量化。
常见的性能指标包括：
- 响应时间：API 接口 95% 的请求在 200ms 内返回
- 吞吐量：系统每秒能处理 1000 笔订单
- 并发用户数：支持 5000 用户同时在线
- 资源利用率：CPU 使用率不超过 70%，内存不超过 80%
你可能会问：「这些数字怎么定？」其实很简单，看业务场景。比如一个内部管理系统，并发 100 就够用了；但如果是双十一的电商系统，那得按峰值流量的 3 倍来设计。
3.3 安全需求：从源头堵住漏洞
安全需求不是等被攻击了才补的。我见过太多项目，上线第一天就被 SQL 注入打穿了。安全需求应该从需求阶段就开始考虑，常见的包括：
| 安全维度 | 需求示例 |
|---|---|
| 认证与授权 | 密码必须加密存储（bcrypt）；JWT 令牌有效期 2 小时；接口鉴权 |
| 数据保护 | 用户手机号、身份证等敏感字段必须加密存储；传输使用 HTTPS |
| 防攻击 | 登录接口限制频率（每分钟最多 10 次）；输入过滤防 XSS/SQL 注入 |
| 日志与审计 | 所有敏感操作（删除、修改权限）必须记录操作人、时间、IP |
这里我想特别强调一点：安全需求一定要写进验收条件。比如「用户注册」这个功能，验收条件里必须有一条：密码不能明文存储。否则开发可能图省事，直接存明文了。
3.4 可用性需求：让用户用得爽
可用性需求，说白了就是「用户用得顺不顺」。很多产品功能很强大，但用户就是不想用，为什么？因为不好用。可用性需求包括：
- 易学性：新用户第一次使用，不需要看说明书就能完成核心任务
- 效率：熟练用户完成一个操作，点击次数不超过 3 次
- 容错性：用户误操作时，系统能给出清晰的提示，而不是直接报错
- 一致性：同一个操作在不同页面，交互方式保持一致
举个例子，一个表单提交功能，可用性需求可以这样写：
- 用户填写完表单，点击「提交」按钮后，按钮变为「提交中…」并禁用，防止重复提交
- 如果提交失败，保留用户已填写的内容，并提示具体错误原因
- 如果提交成功，跳转到成功页面，并显示「操作成功」的提示
你看，这些细节看起来简单，但很多产品就是没做到。用户填了 10 分钟的表，一提交报了个 500 错误，所有内容都没了——这种体验，用户不骂你才怪。
3.5 知识结构图：功能与非功能需求全景
下面这张图，是我自己总结的需求拆解全景图。你可以把它当作一个检查清单，每次写需求文档时对照一下，看看有没有遗漏。
3.6 需求拆解实战：一个完整的例子
光说不练假把式。我们拿「用户修改密码」这个功能，完整走一遍需求拆解流程。
功能需求拆解：
| 层级 | 需求描述 |
|---|---|
| 用户层 | 用户输入旧密码、新密码、确认新密码，点击「修改密码」按钮 |
| 业务层 | 校验旧密码是否正确；校验新密码强度（8位以上，含大小写字母和数字）；校验新密码与确认密码一致；更新密码；踢出用户重新登录 |
| 系统层 | PUT /api/user/password 接口；旧密码校验失败返回 401；新密码强度不够返回 422；更新成功后清除所有活跃会话 |
非功能需求拆解：
- 性能：修改密码接口响应时间不超过 500ms（95% 分位）
- 安全：旧密码错误超过 5 次，锁定账号 30 分钟；密码传输必须使用 HTTPS；新密码不能与最近 3 次历史密码相同
- 可用性：修改成功后，页面提示「密码修改成功，请重新登录」，并自动跳转到登录页；如果修改失败，保留用户已填写的内容，并高亮显示错误字段
嗯，这一章的内容就到这里。记住一句话：需求拆解得越细，后面的坑就越少。下次写需求文档的时候，不妨拿出这张全景图，一个一个对照着检查一遍。