需求分析师一般由具有业务背景经验的技术人员担任，在不同的企业，这个角色的名称不一样，有的企业叫做
BA（业务分析师），有的企业叫做SA（系统分析师）。前者更侧重业务分析、后者更侧重系统分析。需求人员目前存在的主要问题是不清楚需求有哪些内容和层次，需求工作太被动，主要是等待用户提出需求，对需求缺乏系统的分析和长远的规划。造成需求变更出现的时候疲于奔命。
需求分析师首先收到用户的原始请求，然后进行需求调研，基于需求调研的结果进行业务分析，沥青业务模型，然后进行系统分析，确定系统需求。如果有必要，还可以为用户设计方案、和产品原型，以便让用户确认未来系统的什么样。开发应该根据系统需求和产品原型实现系统。在此过程中的需求变更将被管控，以便能够按时交付。开发完成后，由需求分析师对系统进行需求验证，合格的产品才交付给用户。
| 目标 |
登记来自客户的原始请求，识别核心需求。 |
| 环境 |
需求是客户发起的，但是客户一般不会一下告诉清晰而全部的需求，客户一般从他们的角度，说出愿望性的需求，这就称为原始请求，这些需求一般是目标性的，也会涉及一些关键特性要求。需求虽然可能有些凌乱，但是一般都是涉及商业契约的核心需求。所以一定要登记清楚，而且还要把这些需求整理出来层次关系，帮助客户理清愿景，让客户确认。 |
| 输入 |
原始请求 |
| 输出 |
客户的愿景 |
| 规则 |
原始请求一般是对于整个项目的初始需求，比一般是目标性的，是项目发起的原因，也是需求的核心，所以要登记好。一般分为2种情况：
客户的原始需求不明确，这是因为客户有的时候也不知道能得到什么，此时要跟客户进行沟通，挖掘、确认核心需求。
客户的原始请求目标明确、内容完整、描述清晰，则后面的需求工作就会更加高效。 |
| 工具 |
需求管理工具iSpace，excel
|
| 目标 |
面向用户调查工作背景、当前的现状、存在的问题，以及对未来的期望。 |
| 输入 |
《原始请求》 |
| 输出 |
《需求调研报告》 |
| 规则 |
1.如果用户很清楚自己的需求，则需求调研的结果很多可以直接当作需求。
如果用户也提不出需求，则需求调研更多的是了解用户的现状，为今后的需求分析提供素材 |
| 工具 |
录音设备，拍照设备，office，电子邮件，即时通信，界面截图工具 |
| 目标 |
对用户方的业务情况进行调查、分析，形成业务理解，在此基础上定义需要系统支持的业务需求。 |
| 输入 |
《需求调研报告》 |
| 输出 |
《业务模型》《业务需求说明书》 |
| 规则 |
业务需求分析的目标不是简单的了解业务，而是对业务深刻理解，然后提出具有商业价值的业务需求，所以应该尽可能建立业务模型，这是深入业务分析的基础。分为2种情况：
简单的业务可以采用业务流程图简要描述。
复杂的业务要全面建立业务模型：业务目标、业务场景、业务流程、业务对象 |
| 工具 |
专业建模工具
EA，需求管理工具iSpace，word，excel |
| 目标 |
分析系统需要什么功能以及非功能需求 |
| 输入 |
《业务模型》《业务需求说明书》 |
| 输出 |
《系统需求模型》《系统需求说明书》 |
| 规则 |
系统需求分析的重点是定义能够有效支持业务的系统需求，而用户一般没有能力主动提出清晰、完整的系统需求。所以需求分析师有责任对系统需求进行完善的分析、合理的定义。
也分2种情况：
如果客户能够提出清晰完整的系统需求，需求分析师要根据《业务模型》判断系统需求是否合理。
如果客户不能提出清晰完整功能的需求，需求分析师要把系统需求按照《业务模型》的需要向客户讲解，让客户从业务角度理解系统需求，这样才符合客户的价值观。 |
| 工具 |
建模工具
EA，需求管理工具iSpace，word，excel |
| 目标 |
为客户设计解决方案，以便让客户从整体上对提供什么样的系统、系统如何支持业务、系统如何实施和维护有一个整体的了解。 |
| 输入 |
《业务模型》《业务需求说明书》
《系统需求模型》《系统需求说明书》 |
| 输出 |
《XXX 解决方案》 |
| 规则 |
解决方案一般要在项目签约前就要提供，会作为项目可行性评估和签约的主要依据。此时业务需求和系统需求有可能还没有时间进行充分分析，在此种情况下如何做好解决方案：
参考同类的解决方案；
通过解决方案的多次迭代，逐步制定一个客户认可的解决方案，这个过程需要在客户认可的状态下进行，这就需要认真对待客户的反馈，并及时给出解决方法。
|
| 工具 |
建模工具
EA，需求管理工具iSpace，PPT |
| 目标 |
基于系统需求分析的结果，面向最终交付的系统，制作一个用户易于理解的原型，以便让用户知道将来的系统的样子，确认需求。 |
| 输入 |
《系统需求模型》《系统需求说明书》 |
| 输出 |
草稿原型，静态原型，仿真原型 |
| 规则 |
原型是用户能够接受的确认需求的主要形式之一，所以原型是必要的。
制作什么样的原型，可以根据项目特点进行：
为了确认需求，至少应该做出静态原型；
如果是全新的系统，应该制作完整的仿真原型，因为需求更容易出现偏差。
如果是已有的系统增加部分功能，则可以只制作新增部分的静态原型，因为如果全部制作过于费时，而且也无必要。
如果是具有相似参照系统的，则可以基于参照系统描述原型的差异部分，这样也更真实和节省成本。 |
| 工具 |
用户建模与交互建模工具
EA，仿真原型工具EA，界面原型工具 Axure |
| 目标 |
跟用户方和开发团队确认需求。 |
| 输入 |
《原始请求》
《业务模型》《业务需求说明书》
《系统模型》《系统需求说明书》
系统原型，需求清单 |
| 输出 |
确认的需求基线 |
| 规则 |
需求确认一定经过双方（用户方和开发团队）确认;
需求确认也是互相建立信任的过程，应该公开而且透明，这样有利于培育诚信的工程环境。
没有确认的需求不应该算作正式需求。
如果用户方不愿意确认需求，应该让用户方理解，未经确认的需求，如果投入开发，会浪费双方的成本，而且可能会因为不必要的变更影响交付时间。
开发团队对需求是否可实现的反馈，是需求确认的重要反馈，不能实现或者实现成本超出预期的需求，应该及时反馈给用户调整。 |
| 工具 |
需求管理工具iSpace，建模工具EA，文档工具office |
| 目标 |
对确认后的需求，如果发生了变更，则要经过评审，才能够接受变更。 |
| 输入 |
《变更请求》《需求基线》 |
| 输出 |
《变更处理单》，《系统版本》
《被变更的组件》 |
| 规则 |
变更的影响范围应该考虑到对已有的需求的影响，以及开发、测试的成本。
变更应该划分优先级，这样就可以有序处理。
变更可以设置一个缓冲期，这样有助于让变更稳定，避免反复变更。 |
| 工具 |
需求管理工具iSpace，建模工具EA，文档工具office |
| 目标 |
对需求的实现进行验证，是否满足了先前确认的需求。 |
| 输入 |
待验证的《实现的系统》
，
《原始请求》《业务模型》 《系统模型》
系统原型，需求清单 |
| 输出 |
已验证的《实现的系统》 ，
《需求验收记录》 |
| 规则 |
需求验证会依赖与系统测试，但不局限于系统测试；
需求验证不止验证系统的功能、性能、可靠性、安全性，还验证是否提升了业务效率，实现和核心目标、用户体验是否好；
需求验证应该由原来定义需求的需求分析师主导，这样有始有终，客户更认可。
系统上线后的使用情况，是验证系统应用的效果重要环节，应用效果统计是最真实的验证方法。 |
| 工具 |
需求管理工具iSpace，建模工具EA，开发工具，测试工具 |
| 类型 |
工件名称 |
用途 |
| 模型 |
用户模型 |
对用户进行角色划分，描述用户的目标、特征和行为习惯。用户模型是需求人员对用户的画像，是了解用户的重要依据。 |
| 业务模型 |
建模业务流程、业务对象，描述业务现状和业务需求。对于如下情况尤其需要业务建模：复杂的业务或者虽然短期不复杂、但是不断积累的业务。因为业务是系统的价值目标，所以强烈建议建立业务模型，以便全面的了解业务 |
| 系统模型 |
对系统的功能、接口和非功能需求（性能需求、可靠性需求、可支持需求、设计约束、实施需求）进行建模。因为系统需求各种类型多、细节更多，所以强烈建议通过系统模型对系统形成一个多维度的清晰描述，避免需求疏漏和误解。减少后期不必要的返工。 |
| 方案模型 |
建模业务方案、系统方案、技术方案以及制定实施计划。因为方案涉及的内容多，而且要给客户领导确认，所以方案应该多采用清晰简洁的图示，让客户一目了然，也在客户眼里建立专业的工作风格。 |
| 文档 |
需求调研文档 |
包括需求调研的记录、规章制度、工作图表的整理以及参考资料。需求调研文档各种素材比较多，应该有一个统一的目录，对于各种参考资料作为附录管理起来。并采用需求条目登记对应。 |
| 业务需求文档 |
建模业务流程、业务对象，描述业务现状和业务需求。 |
| 系统需求文档 |
包括系统的功能需求、接口需求、数据需求、性能需求、可靠性需求、可支持需求、设计约束、实施需求等的全面描述。 |
| 解决方案文档 |
包括现状和问题分析、业务方案、系统方案、技术方案以及制定实施计划。 |
| 需求验证报告 |
包括业务需求验证、系统需求验证、用户体验验证。 |
| 条目 |
原始请求 |
记录用户提出的原始的请求，并对原始请求划分优先级，标识核心需求。可以跟踪到需求调研文档。 |
| 需求清单 |
对各种需求的列表，可以跟踪到各种需求模型和文档，建立关系和版本，方便跟踪管理。 |
| 变更记录 |
记录提出的各种变更，并标记变更的来源、影响范围，进而确定变更的优先级，通过变更状态进行跟踪管理。 |
| 原型 |
草稿原型，
|
对系统的形态的概念性描述，对于软件来讲一般是指界面草图，表达出界面的基本结构和功能，以便对功能需求进行细化。 |
| 静态原型 |
体现系统的结构和关系的原型，一般用来确认功能结构和系统形态，以便让用户对系统的功能、交互和视觉有全面的了解。 |
| 仿真原型 |
无论是结构、外观还是交互都和真实及系统基本一致，具有可操作性，可以对用户的交互给出和系统一致的反应，一般用于确认人机交互动态效果、系统和系统之间的实时交互反应。 |
| 工具类型 |
用途 |
推荐工具 |
| 建模工具 |
建立用户需求模型、业务模型、系统模型 |
EA
|
| 需求管理工具 |
登记需求条目，包括：原始请求、产品特性、变更记录。 |
iSpace
iWork |
| 文档工具 |
编辑需求类文档，包括：业务需求文档、系统需求文档、解决方案、需求调研报告、需求验证报告等 |
Word，
Excel |
| 静态原型工具 |
描述静态界面为主的原型，能画出基本的界面轮廓，标识功能区，和数据表格。 |
EA
powerPoint |
| 界面仿真原型工具 |
能比较真实的描述界面结构、关系、界面的各种控件，并修饰以视觉效果。也能遍历执行各种界面的交互过程。 |
Axure
JustinMind
MockPlus
powerPoint |
| 逻辑仿真工具 |
能够对系统的动态运行过程、状态进行模拟，并执行各种算法，以便验证各种事件下系统的状态反应和输出。 |
EA，
Matlab |
