概述
1.获取干系人信息
2.调查与记录
3.整理需求信息
4.撰写需求说明书
5.确认需求
需求
设计
编码
单元测试
验收测试
维护
需求的三个层次
1）业务需求
2）用户需求
3）功能需求（软件必须实现的软件功能）和非功能需求（操作界面）
如何开展需求调研？
了解需求调研方法
座谈法：与用户交谈，向用户提出事先准备好的相关问题。
调查表法：将相关问题制成调查表，向用户群体发调查问卷。
观察法：参观用户的工作流程，观察用户的操作。
收集法：收集用户使用的表格，工作责任，工作规范。
收集同类相关产品的资料、技术资料、演示程序或软件程序。
情景分析：利用情景分析（描述当前一项业务怎么做，描述设想的系统中此项业务怎么做。）
可视化：结合情景分析，结合业务流程图、功能结构图、时序图等图形与客户进行讨论。
业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。
首先，明确你要梳理的业务流程的范围——用大的粗略的关键节点，讲清楚这个业务流程范围中的故事，就是顶层业务流程 图。你的顶层业务流程图是业务全局故事的简单表达，但是请注意这里的业务全局不见得是公司整体的业务全局，而是你界定好的业务范围。比如，下图是餐厅的日 常运作流程图，若你界定的业务范围是面向顾客的点餐和结帐流程，那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程，那这显然还是一个子 集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。
1. 界定范围内的业务全局故事。2. 包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单，会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。3. 顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。
流程图的常用图示
流程图常用结构
金字塔方法
首先搞清楚对象（调研对象）与对象之间的关系，
理清对象的目标及和其它对象发生关系的目标。
其次理清对象内部的活动以及对象与对象之间的活动。
对活动进行整理，确定活动边界。
根据活动进行详细的需求调研。
五种提高
1.了解被调研对象的组织机构，了解每一个子对象中的关键人物，提高自己的观察能力。
2.了解用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户的需求，提高自己的行业知识面。
3.需求调研中，学会尽量不使用IT行业术语，而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语，以便用户能够很好的理解，提高自己的沟通交流能力。
4.提高自己的速记能力，文字表达能力以及归纳，能迅速的记录需求调研核心的问题，总结归纳之。
5.提高自己的总结能力，书写一份完整的、前后一致的、可追踪的需求报告。
步骤
1.倾听客户的心声
找一个安静的地方，以客户为主，面对面的沟通和交流，倾听客户的心声，
记录客户所说的一切，调研完后对所有的记录进行整理，形成文档，在下一次的调研开始对上次的总结进行确认。
2.整理客户的需求
调研主题
调研对象
调研人
调研时间
调研描述
3.引导客户的需求
许多客户有时候并不知道自己想要什么？有时候并不清楚自己缺少什么？所以就需要我们去引导客户的需求。
常用引导方法：
1）向客户讲述基本的计算机操作。
2）提示客户在全局中的地位以及作用。
3）向客户演示将要实施的系统的原型。
4）从软件开发中需求考虑的几个方面入手。
争取能够提出用户的兴奋需求，这样做出的软件才有生命力，
才能真正体现软件的价值。
4.编写用户需求说明书
需求分析员对收集到的所有需求信息进行分类整理，消除错误，归纳与总结共性的用户需求，然后形成文档，编写《用户需求说明书》。
《用户需求说明书》要和客户以及相关的行业专家进行共同评审。以前整理的需求记录可以作为附件整理在《用户需求说明书》之后。
用自然语言来表达用户需求，相对较粗略。
《产品需求说明书》则更多采用计算机语言和图形符号来刻画需求。
用户需求说明书模板
1）产品介绍
2）产品面向的用户群（用户特征，使用的好处）
3）功能需求（功能1，子功能1、2、3）
4）非功能需求（界面要求，软硬件要求，质量要求）
交谈注意事项
1.约好时间，切勿迟到或早退。注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。
2.事先了解用户的身份、背景，以便随机应变。
3.先了解宏观问题，再了解细节问题。
4.尽可能避免给用户添麻烦，但也不能怕给用户添麻烦而降低需求调研的力度。
5.尽可能听取多方的综合意见。
调研后整理
角色：部门、岗位或人
活动：做了什么事情
次序：做这些事情的次序如何
规则：什么情况下到什么事情