2、需求分析：用户角色识别、功能需求收集、非功能性需求定义

好，咱们进入第二章。需求分析，这词儿听着挺虚的，对吧？

但说实话，我做了十几年企业级应用，见过太多项目栽在需求分析上。有的OA系统上线后没人用，有的跑着跑着就崩了。为什么？说白了，就是需求没摸透。

这一章，我带你走一遍我的分析框架。你跟着做，至少能避开80%的坑。

2.1 用户角色识别：别把所有人都当成「用户」

很多新手做需求，上来就问「用户想要什么」。这其实是个误区。企业级OA系统里，不同角色的诉求天差地别。

我习惯先画一张角色地图。你想想看，一个典型的OA系统，至少会涉及这几类人：

• 普通员工：最关心请假、报销、审批流程顺不顺，界面好不好看。
• 部门经理：要能快速审批，能看到团队的工作进度。
• HR/行政：需要考勤统计、人员信息管理、资产登记。
• IT管理员：权限配置、流程定制、系统监控，这些是他们的命根子。
• 高层管理者：他们不看细节，只看仪表盘、报表、关键指标。

识别角色时，我建议你用这个简单方法：

1. 列出所有可能使用系统的人。
2. 按「职责」和「权限」分组。
3. 给每个组起个名字，比如「审批者」「填报人」「系统管理员」。
4. 最后，画一张角色-用例矩阵，看看有没有遗漏。

2.2 功能需求收集：别让用户「画饼」

角色定好了，接下来就是功能需求。嗯，这里要注意，用户说的需求，往往不是真正的需求。

比如，销售总监跟你说：「我要一个能自动生成周报的功能。」你信吗？别急着点头。他真正的需求可能是「每周花太多时间整理数据，想省事」。自动生成周报只是他想到的一个解决方案。

我一般用「5W1H」法来深挖：

• Who：谁要用这个功能？
• What：他想达成什么目标？
• When：什么时候用？每天？每周？
• Where：在什么场景下用？办公室？手机上？
• Why：为什么需要这个功能？
• How：他期望怎么操作？

举个例子，收集「请假审批」功能的需求时，我通常会这样记录：

角色	功能描述	优先级	备注
普通员工	在线提交请假申请，选择类型（年假、病假、事假），上传附件	P0	需要支持手机端
部门经理	在待办列表中查看并审批，支持批量操作	P0	审批时能看到员工剩余假期
HR	查看全公司请假统计，导出月度报表	P1	需要与考勤系统对接

2.3 非功能性需求：决定系统「生死」的关键

功能需求决定了系统「能不能用」，非功能性需求决定了系统「好不好用」。很多项目死在非功能性需求上，我见过太多了。

2.3.1 性能需求

你想想看，一个OA系统，如果每次打开审批列表都要等5秒，员工会怎么想？直接骂娘。

我一般会跟客户明确这几个指标：

• 响应时间：页面加载不超过2秒，查询操作不超过3秒。
• 并发用户数：比如，同时在线500人，高峰期1000人。
• 吞吐量：每天处理多少条审批流程？多少条消息？

2.3.2 安全需求

企业数据是命根子。OA系统里跑着员工信息、薪资数据、合同文件，安全做不好，等着吃官司吧。

我建议至少覆盖这些点：

• 身份认证：支持密码、短信验证码、甚至生物识别。
• 权限控制：细粒度到按钮级别。比如，普通员工看不到别人的薪资。
• 数据加密：传输用HTTPS，存储时敏感字段加密。
• 审计日志：谁在什么时候做了什么操作，都要记录下来。

2.3.3 可用性需求

说白了，就是系统不能老宕机。我一般会跟运维团队约定：

• 可用性指标：99.9% 可用，意味着一年宕机不超过8.76小时。
• 备份策略：每天全量备份，每小时增量备份。
• 灾难恢复：RTO（恢复时间目标）不超过4小时，RPO（恢复点目标）不超过1小时。

2.4 需求优先级排序：别什么都想做

需求收集完了，你会发现，什么都想做。但资源是有限的。我习惯用「MoSCoW法」来排序：

• Must have：没有这个功能，系统没法用。比如，登录、审批流程。
• Should have：很重要，但暂时没有也能凑合。比如，消息通知。
• Could have：有了更好，没有也无所谓。比如，个性化皮肤。
• Won't have：这次不做，以后再说。

嗯，这里要注意，客户往往会把所有需求都标成「Must have」。这时候，你需要用数据说话。比如：「如果所有功能都做，工期要6个月。如果只做Must have，3个月就能上线。你选哪个？」

好了，需求分析这块，核心就是这些。你记住一句话：需求分析不是记录，而是挖掘和取舍。下一章，咱们聊聊怎么把这些需求变成可落地的系统架构。