需求分析大致分为三个阶段：头脑风暴，梳理需求以及校验需求。
1. 头脑风暴
实际操作是需求收集。无条件的收集客户各方面的信息，需求，反馈；
2. 梳理需求
首先就是参照着范围说明书，搞清楚此次调研的需求范围是什么。然后便是对需求进行筛选，剔除掉范围外的需求，当然这一步也可以是在头脑风暴，收集过程中进行。经过了初步的筛选之后，就开始罗列范围内的需求，并和客户确认需求的优先级别，每条需求的进行建模：输入来源（系统内，系统外，数据库，已有遗留系统…)，处理（业务的处理逻辑），输出（输出的内容，以及输出将会被那个需求作为输入，进行怎样的处理）。搞清楚了需求小项的同时，还要对于需求进行分类，分类就是划分模块，划分模块之后还要梳理清楚模块的定义（一定要对模块有一个清晰地定义，这是模块梳理的成果物，也是以后需求变更，增加进行处理的依据）以及模块间的关系，合作模式是怎样的。
在进行需求分析的过程中其实就是识别核心业务对象（对象的定义，属性，以及被那些业务使用）和对业务建模的过程，建模的过程包含两方面的意义：首先是输入，工具，输出的模型，另外一个是搞清楚业务的生命周期。关于生命周期的分析就需要有核心业务对象。比如在Challenge-POC-Proposal包括两大业务：Challenge的跟踪变化以及权限控制对应的两大业务对象，是Challenge和User。
需求还有方面需要注意就是场景的分析，这个和Use Case还不一样，Use Case是主要场景，而需求分析的场景则是全部的场景，客户可能提供的是一个需求场景，作为分析人员需要进行延伸，是否还有其他相关的场景，应该如何处理，这个时候可能就需要给客户一些经过权衡的建议处理方案。比如在Google地图中医院加载，初始化场景，拖动场景，指定区域后检索场景，以及检索后拖拽场景等各种场景都需要考虑。这也是通常讲的隐藏需求。
需求一个必须要考虑的方面就是用户群体以及权限，这是大部分企业级需求分析系统分析的共同的功能性需求，规划清楚角色，以及角色在各个模块场景下的权限是一个项目成功的关键因素之一。
3. 校验需求
在梳理之后的需求，一一对需求进行分析，比对，看看是否需求遗漏（重点分析各种场景下的需求动作的描述是否可以通过验证，），或者业务向冲突的地方，对成果物进行修改。
如果有必要，还要替用户进行业务再造。
需求分析的本质是两个，梳理清楚客户的业务逻辑，描摹系统的外在行为，当然说白了就是：输入什么，怎么处理，输出什么。也就是建模。