项目需求分析是从用户原始诉求到技术方案的关键转化过程，核心是“分解+抽象”——先将复杂问题拆解为可管理的模块，再提炼共性规则形成系统框架。一份专业的需求分析应包含需求挖掘、建模、规格化三个阶段，既要覆盖业务目标，又要为开发提供清晰指导。

一、需求挖掘：穿透表面诉求

用户提出的往往是“解决方案”而非真实需求。比如客户说“需要一个手机端报表”，可能实际是“希望销售人员在外随时查看库存数据”。需通过三重验证确保需求真实性：

角色分析：区分外部客户（触发核心业务）与内部角色（流程执行者），优先捕捉外部触发事件。例如电商系统中，“用户下单”是外部事件，“库存扣减”是内部响应。

场景还原：用上下文关系图描述业务环境，标注“谁在什么条件下做什么”。某体检系统通过该方法发现，体检报告查询虽未出现在主流程中，却是用户高频需求。

动机挖掘：用“5Why分析法”追问根本目的。如用户要求“增加审批按钮”，背后可能是“需留痕避免责任纠纷”，此时电子签名或许是更优解。

二、需求建模：构建业务蓝图

SERU框架是系统化建模的实用工具，通过四步将零散需求转化为结构化模型：

主题域划分（S）：按职责将系统拆分为子问题域。例如体检系统可分为“客户管理”“体检业务”“物资管理”三大主题域，每个域对应独立业务板块。

事件驱动流程（E）：通过业务事件串联流程。如“客户预约”事件触发“创建订单→分配资源→发送提醒”的流程链，可用活动图或跨职能流程图可视化。

报表需求梳理（R）：单独处理查询、统计类需求。管理类报表（如“月度销售分析”）和操作类报表（如“库存实时查询”）需分别标注，避免遗漏。

用例细化（U）：用例是需求的最小单位，需包含：

基本事件流：正常操作路径，如“用户登录→浏览商品→下单支付”

扩展事件流：异常场景，如“支付失败→重试/取消订单”

规则约束：如“订单金额超过1000元需二次验证”

三、需求规格化：输出可执行文档

需求文档需兼顾业务可读性与技术指导性，推荐结构如下：

引言：说明文档目的、读者范围及术语定义。例如明确“VIP用户”指“年消费超10万元的客户”，避免歧义。

需求概述：用KANO模型分类需求优先级：

基本型（必须实现）：如电商系统的“商品搜索”功能

期望型（提升满意度）：如“个性化推荐”

兴奋型（超出预期）：如“下单后自动生成礼品包装选项”

功能详述：每个功能需包含验收准则。例如“用户注册”功能：