如何进行需求分析

　　“ 需求分析”不代表“用户要求什么是什么”也不代表“我们能做什么做什么”，做为需求人员，在进行需求分析的时候，首先应该明白用户的需求，然后再加上自己的分析处理过程，知道哪些我们现在能做，哪些我们做不了，哪些我们咬咬牙齿能做，需求人员在做需求分析的时候不能一味的成为客户的传话筒，要有自己的分析。

　　一般可以从三个方面去考虑：

　　1、功能需求--产品应该完成哪些功能，即向用户提供的功能，一般来说这个都是比较硬性的标准；

　　2、非功能性需求--用户可能不能明确告诉你的一些需求，比如说性能达到什么要求，可靠性方面，响应时间，扩展性，性能方面等，这块的内容并不是说用户需要，而是说不知道需要做成什么样的，我们不能不做，做了只会对自己受益。要不然等到后期用户使用感觉这慢，那不爽，那倒霉的还是是自己；

　　3、限制条件--在需求分析中需要考虑一些条件约束，规则等，比如客户的约束，行业的约束，法律的约束以及自己的约束等，这些都需要在需求分析考虑清楚，要不然做出一款白人狂殴黑人的游戏给黑人玩，那惨了……

　　测试需求分析的步骤

　　1 、 熟悉需求背景及商业目标：

　　a) 了解清楚项目发起的原因，是为了解决用户的什么问题。

　　b) 当前的解决方案是不是优的，为什么会这样做？

　　2 、业务模型法：

　　a) 考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互是系统的边界），可以参考系统分析说明书。

　　b) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

　　3 、业务场景法：

　　a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注）

　　b) 考虑系统内部各个用例之间的交互，形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。

　　4 、功能分解法

　　a). 业务功能：与用户实际业务直接相关的功能 或细节。

　　b). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。

　　c). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

　　d). 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷键是典型的易用性需求。

　　e). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

　　f). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。

　　g). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。