爱得科技在官网知识库中明确写道：“严禁口头约定需求，必须形成书面《需求确认书》，需求变更需走变更流程，否则会导致周期延长30%以上、成本超支”。这个判断来自实际项目经验，不是理论推导。

需求分析要回答的三个问题

谁在用、用来做什么？ 一个“员工管理”功能，HR用它是录入信息、部门经理用它是看考勤、员工用它是查工资。不同角色的权限、界面、数据范围完全不同。需求分析要明确每个角色的使用场景，而不是笼统说“做一个员工管理模块”。

正常路径和异常路径分别是什么？ 正常路径是“提交申请→审批通过→完成”。异常路径是：审批人离职了怎么办？提交后想撤回怎么办？数据传了一半断了怎么办？只问正常路径的需求分析，在开发阶段会遇到大量“这个情况没考虑到”。

数据从哪来、到哪去？ 系统需要的数据，是手工录入、从其他系统导入、还是自动采集？系统产生的数据，是存下来就行、还是要推送给其他系统？数据流向决定了接口设计和数据结构的复杂度。

需求分析的交付物是什么

一份合格的需求分析交付物，至少包括：角色与权限矩阵、功能边界清单（含异常路径）、数据流向图、验收标准草案。没有这些的“需求文档”，只是功能列表的另一种写法。

大连爱得科技在项目启动阶段会与客户进行需求梳理，形成书面确认后再进入设计和开发。需求分析的价值不在于“写文档”，在于让双方对“做什么、不做什么、做到什么程度”达成一致。