第 2 章:需求分析

学习目标

• 把模糊的业务想法拆解成可执行的需求清单
• 区分功能需求与非功能需求
• 编写用户故事(User Story)对齐开发团队认知

一、为什么要写需求

需求分析是项目的"作战地图"。没有它,开发就是边走边挖——做到一半发现漏了功能、改完发现接口对不上。

真实项目三个角色:

角色	关注点
产品经理	业务规则、用户场景
开发	可行性、技术风险
测试	验收标准、边界条件

需求文档是三方共识的唯一依据。

⚠️ 坑 1:需求文档不要追求"完整",要追求清晰。一份让开发看完知道"做什么、不做什么"的清单,远比 50 页 PPT 有用。

二、功能需求

把 RBAC 系统拆成 8 个模块,每个模块列出具体功能点。

2.1 用户管理

// 用户管理功能清单
1. 用户登录(JWT)
2. 用户登出(撤销 Refresh Token)
3. 新增用户(用户名、密码、昵称、邮箱、手机、部门、角色)
4. 修改用户
5. 删除用户(逻辑删除)
6. 重置密码(管理员操作)
7. 分配角色(多选)
8. 用户分页(按用户名/手机/部门筛选)

2.2 角色管理

// 角色管理功能清单
1. 角色列表(分页)
2. 新增角色(名称、编码、数据权限范围)
3. 修改角色
4. 删除角色(校验是否被用户使用)
5. 分配菜单权限(树形勾选)
6. 数据权限配置(全部/本部门及下级/本部门/仅本人/自定义)

2.3 菜单管理

// 菜单管理功能清单
1. 菜单树查询
2. 新增菜单(目录/菜单/按钮)
3. 修改菜单
4. 删除菜单(校验子菜单/被角色引用)
5. 当前用户菜单(根据权限过滤)

2.4 部门与字典

// 部门管理功能清单
1. 部门树(递归)
2. 新增/修改/删除部门
3. 防环路校验(父部门不能是自己/子部门)

// 字典管理功能清单
1. 按 typeCode 查字典
2. 全部字典(缓存到 Redis)
3. 新增/修改/删除字典项

2.5 其他模块

模块	功能
操作日志	@OperationLog 注解 + AOP 自动记录
登录日志	成功/失败审计,IP 归属地查询
文件存储	通用上传接口,支持本地/MinIO/S3
代码生成	选表 → 一键生成 CRUD

⚠️ 坑 2:不要在第一版就堆所有"可能用到"的功能。先做 20% 的核心功能跑通,再 80% 渐进式增强。"MVP(最小可行产品)"思维对个人项目同样有效。

三、非功能需求

非功能需求是"软件看不见的质量",但出问题时影响巨大。

3.1 性能指标

// 性能目标
接口平均 RT (响应时间)    < 200ms
P99 响应时间             < 1s
并发支持                 1000 QPS
登录接口                 < 300ms
权限校验缓存命中         > 95%

3.2 安全指标

// 安全要求
- 密码 BCrypt 加密(不存明文)
- JWT 双 Token,Access 过期 Refresh 续签
- 接口 100% 走 Spring Security 鉴权
- 登录失败 5 次锁定 15 分钟
- SQL 注入防护(MyBatis Plus 参数绑定)
- XSS 防护(前端 Vue 自动转义 + 后端 JSON 序列化过滤)
- CSRF(前后端分离方案可以关闭,但登录接口要加 captcha)

3.3 可维护性

// 可维护性要求
- Java 代码遵循《阿里 Java 开发手册》
- 统一响应、异常、错误码
- 方法行数 ≤ 50,类行数 ≤ 800
- 单元测试覆盖率 ≥ 70%
- 关键路径(登录、权限校验)必须有测试

⚠️ 坑 3:很多同学觉得非功能需求"虚",只在最后压测才发现接口慢。性能、安全、可维护性要在需求阶段就确定,否则后面改的成本是前期的 5-10 倍。

四、用户故事

用户故事是"从用户视角描述功能",格式:作为 X,我希望 Y,以便 Z。

4.1 管理员用户故事

故事 1: 创建用户
作为 超级管理员
我希望 通过表单创建新用户,并指定他的部门和角色
以便 新员工入职后立即获得相应权限

故事 2: 权限分配
作为 超级管理员
我希望 给"运营管理员"角色只分配运营相关菜单
以便 运营无法访问财务模块

4.2 普通员工用户故事

故事 3: 修改个人信息
作为 普通员工
我希望 修改自己的昵称、头像、手机号
以便 信息变更后其他人能看到最新的我

故事 4: 查看权限
作为 普通员工
我希望 登录后只能看到自己有权限的菜单
以便 不被无关功能干扰

4.3 验收标准(AC)

每个故事要配验收标准:

# 故事 1 的验收标准(Gherkin 语法)
Given 管理员已登录
When  点击"新建用户" → 填写表单 → 提交
Then  用户列表出现新用户
And   新用户能用初始密码登录
And   新用户能看到自己角色对应的菜单

五、需求优先级

用 MoSCoW 法则排优先级:

优先级	含义	本项目内容
Must have	必须做	登录、用户、角色、菜单、权限校验
Should have	应该做	部门、字典、操作日志
Could have	可以做	数据权限、文件存储、代码生成
Won't have	不做(本期)	多租户、SSO、审计报表

六、本章小结

要点	关键
功能需求	8 大模块逐项列清楚
非功能需求	性能 / 安全 / 可维护
用户故事	"作为 X,我希望 Y"格式
验收标准	Gherkin Given/When/Then
优先级	MoSCoW 排四档

动手练习

1. 写需求清单:按本章模板,为你的一个真实业务场景(如"图书管理系统")列 8 个功能模块
2. 写用户故事:挑 3 个核心功能,写 3 个用户故事 + 验收标准
3. 排优先级:用 MoSCoW 给功能模块打分

---

下一章:第 3 章:架构设计 →