1-1 章导学：项目需求分析与架构设计
为什么需要需求分析
在正式进入 React 源码学习之前，我们需要先理解一个重要的前置能力——项目需求分析。很多开发者拿到需求就直接开干，结果后续频繁返工、需求变更不断，根本原因就是前期分析不到位。
需求分析在整个项目开发周期中的时间占比通常超过30%。听起来可能有些夸张，但想想那些"急匆匆上线、后续问题不断"的项目，往往就是前期省下的时间在后期加倍还回去了。
需求分析的核心目的有四个：
| 目的 | 说明 |
|---|---|
| 定义目标与范围 | 明确项目要做什么、不做什么 |
| 保证质量 | 通过清晰的规格定义减少歧义 |
| 提高用户满意度 | 让用户参与确认，避免最终交付与预期不符 |
| 控制成本与时间 | 避免无效开发和需求蔓延 |
用一句老话说就是"磨刀不误砍柴工"。
需求分析的四大模块
1. 业务需求分析
回答"我们要做一个什么东西"这个问题。即使领导一拍脑门说"做个打车软件"，背后也一定有一个对标系统或明确的目标。业务需求分析要把这个目标具体化、可度量。
2. 用户需求分析
聚焦最终用户的核心诉求。以打车软件为例：
- 用户叫车是否方便？
- 路线规划是否合理？
- 评价系统是否形成闭环？
- 等待时间反馈是否及时？
用户需求分析要求站在用户的视角去审视产品的每一个交互环节。
3. 功能需求分析
功能需求是最贴近开发者的部分，它详细定义了每个功能的具体行为：
- 页面上有哪些按钮、表单、交互元素
- 点击某个按钮后跳转到哪里
- 数据的增删改查流程是怎样的
- 与其他系统的接口如何交互
这一部分通常以功能列表或原型图的形式呈现。
4. 非功能需求分析
非功能需求往往被忽视，但它直接影响系统的架构设计和技术选型：
| 类别 | 示例 |
|---|---|
| 性能 | 页面首屏加载时间不超过2秒，接口响应时间不超过500ms |
| 安全性 | 用户数据加密存储，接口需要鉴权 |
| 可用性 | 系统可用性达到99.9% |
| 技术限制 | 客户要求使用指定的数据库或中间件 |
| 法律法规 | UGC内容需要接入内容审核服务 |
5. 数据需求分析（独立模块）
对于前后端都涉及的项目，数据需求分析是一个相对独立且特殊的模块。它需要明确：
- 项目需要哪些类型的数据
- 数据来源是什么（自采、第三方、用户输入）
- 数据质量要求（实时性、准确性、完整性）
- 数据的存储和处理方案
- 接口的数据格式和结构定义
- 数据与角色的绑定关系
需求分析需要明确的内容
输入与输出
输入可能包括：业务描述文档、功能列表、非功能需求描述、竞品分析报告等。
输出则包括：需求分析文档、功能列表、流程图、原型图、接口文档等。
参与角色与系统边界
明确哪些角色参与需求分析，系统与外部系统之间的边界在哪里。只有边界清晰，责任划分才明确。这一步需要梳理：
- 内部系统的职责范围
- 第三方平台和外部系统的交互方式
- 各角色的权限和数据边界
最终效果的确认
最终效果需要通过产品原型图和设计稿让用户确认。交互需求、视觉需求都需要得到明确的认可。当用户说"我需要一个XX系统"但说不清具体需求时，技术人员需要通过专业能力去引导和挖掘真实需求——这既考验沟通能力，也考验对技术领域的理解深度。
需求分析中的常见坑点
| 坑点 | 表现 | 解决方案 |
|---|---|---|
| 未对全员明确需求 | 团队成员对需求理解不一致 | 召开需求交底会议，形成需求矩阵 |
| 未考虑需求变更 | 需求一变再变，开发反复返工 | 设计需求变更流程，变更需走审批 |
| 忽视非功能需求 | 上线后性能、安全问题频发 | 需求模板中强制包含非功能需求项 |
| 过度设计 | 花大量时间做当前不需要的功能 | 明确优先级，按MVP思路分阶段交付 |
| 没有用户确认环节 | 交付后发现不是用户想要的 | 关键节点安排用户确认，签字认可 |
工作流总结
需求分析的本质是建立一套"章法"，按照这个章法把整个业务系统分析清楚，产出对应的文档和设计，最终指导开发和技术选型：
- 业务分析 → 明确做什么
- 用户分析 → 明确为谁做
- 功能分析 → 明确怎么做
- 非功能分析 → 明确做到什么程度
- 数据分析 → 明确数据怎么流转
- 文档输出 → 需求矩阵、原型图、流程图
- 用户确认 → 关键节点签字认可
这个过程和具体的技术栈无关，不论是 React 还是 Vue 项目，需求分析的方法论是通用的。掌握了这套方法论，再配合后面的 React 源码学习和架构设计实践，就能形成从需求到落地的完整闭环。
↑