什么是需求 需求是产品必须完成的事以及必须具备的品质。
功能性需求
功能性需求是产品必须完成的那些事，要求一定的功能和品质。
例子：培训机构的班主任可以给所在班级学员打考勤
非功能性需求
非功能性需求是产品必须具备的属性或品质。诸如观感、可用性、安全性和法律限制等。
例子： 平台用户数为5万人，每天登录用户数为10000左右，网络的带宽为100M带宽。在工作时间根据资料名称条件进行搜索，可以在3秒内得到搜索结果。
这类需求通常在产品的功能确定之后（但并非总是如此）。也就是说，一旦知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它的响应速度、可用性、可读性和安全性。
限制条件
限制条件是全局性的需求。它们可以是对项目本身的限制，或是对产品最终设计的限制。
例子：南京平台必须在2010年开学的第一学期上线
客户是在说，如果顾客不能在给定的时间前使用该产品，那么它就没有什么用了。其效果是，需求分析师必须对需求进行限制，只包括那些在最后期限前能够提供最大价值的需求。
需求分析的重要性
背景：冯大勇吃鱼时嗓子被鱼刺卡住了。现在正坐在椅子上候诊。
大夫：（在桌上拿起一份挂号单，大声的喊）冯大勇！
冯大勇：（病怏怏的样子，边走边咳嗽）我是。
大夫：怎么了？（低头整理手中的资料，自言自语，并打手势，示意冯大勇坐下）
冯大勇：我．．．（咳嗽）．．．我今天．．．（咳嗽）
大夫：不用说了，我知道了。（从桌子下面拿出一个大盒子，放在桌子上）我看你适合吃这种药。这是本院独家开创的哮喘新药“咽喉糖浆”，疗程短，见效快，一个疗程吃3盒，平均每天只需花费3块钱。给你先开6盒吧！（边说边开药方）
冯大勇非常惊讶地瞪大眼睛并止不住地弯腰大声咳嗽，以至于把鱼刺都咳出来了。冯大勇从口里掏出一条巨型鱼刺，递给医生。医生见到鱼刺先是吃惊，而后又非常尴尬。
医生不了解病人的需求就用药，是草菅人命；销售员不了解客户的需求就进行推销，不仅自己要徒劳无功地浪费很多口舌，更重要的是完不成销售的目标。给客户 推销软件产品，也相当于医生给病人治病，应当首先充分、全面地了解客户的需求所在、期望所在，然后才能带给他一个完美的解决方案。
需求分析没有做好的后果一般会有下列现象：
1、浪费时间和资源来满足用户并不需要的需求（过度实现一些功能）；
2、开发出来的产品技术上先进，但不满足用户需求；
3、总是需要比较长的时间来达成对产品设计的共识；
4、在产品设计，开发和测试工作中对于用户需求的解释不一致；
5、员工会厌倦因需求不断被重新解释而导致的返工；
6、未说明的或不正确的需求会导致员工与用户间的不满；
7、不稳定的产品，用户的不满意对我们未来的市场造成损失；
8、浪费时间，增加成本，使得在一些投标的项目中不能低价；
1、如果你在编码的时候发现某几行有误，那么改掉这几行就行了。而如果在编码阶段发现需求有误，那么你很可能需要改变所有代码来适应新的需求
2、在需求阶段消除问题的代价最小，而如果需求问题等到产品发布出去后才发现的话，那修复的成本就会N倍的增加。
3、稳定的需求是软件开发的关键。有了稳定的需求，软件开发工作可能从结构设计到详细设计到代码到测试都会平稳顺利的进行。
为什么要做需求分析
1、“决策性”--要不要做这个产品，通过对市场需求的分析来决策项目是否需要立项；
2、“方向性”--良好的需求分析可以对项目人员明确方向，让项目成员知道下面应该如何实施；
3、“策略性”--既然知道了为什么要做需求分析，就需要了解什么是需求分析，及如何做。需求分析并不是简单的对与错，比如说做一个产品，“做技术最先进的软件，还是做最好卖的软件”，这个需求有错吗，没有，只能说需要从不同的地方去考虑，去定位。
如何进行需求分析 “ 需求分析”不代表“用户要求什么就是什么”也不代表“我们能做什么就做什么”，做为需求人员，在进行需求分析的时候，首先应该明白用户的需求，然后再加上 自己的分析处理过程，知道哪些我们现在能做，哪些我们做不了，哪些我们咬咬牙齿能做，需求人员在做需求分析的时候不能一味的成为客户的传话筒，要有自己的 分析。
一般可以从三个方面去考虑：
1、功能需求--产品应该完成哪些功能，即向用户提供的功能，一般来说这个都是比较硬性的标准；
2、非功能性需求--用户可能不能明确告诉你的一些需求，比如说性能达到什么要求，可靠性方面，响应时间，扩展性，性能方面等，这块的内容并不 是说用户需要，而是说不知道需要做成什么样的，我们不能不做，做了只会对自己受益。要不然等到后期用户使用感觉这慢，那不爽，那倒霉的还是是自己；
3、限制条件--在需求分析中需要考虑一些条件约束，规则等，比如客户的约束，行业的约束，法律的约束以及自己的约束等，这些都需要在需求分析考虑清楚，要不然做出一款白人狂殴黑人的游戏给黑人玩，那就惨了……
测试需求分析的步骤
1 、 熟悉需求背景及商业目标：
a) 了解清楚项目发起的原因，是为了解决用户的什么问题。
b) 当前的解决方案是不是最优的，为什么会这样做？
2 、业务模型法：
a) 考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。
b) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。
3 、业务场景法：
a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注）
b) 考虑系统内部各个用例之间的交互，形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。
4 、功能分解法
a). 业务功能：与用户实际业务直接相关的功能 或细节。
b). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。
c). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。
d). 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。
e). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。
f). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。
g). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。
一个有趣的例子 某日，老师在课堂上想考考学生们的智商，就问一个男孩：“树上有十只鸟，开枪打死一只，还剩几只？”
男孩反问：“是无声枪么？”
“不是。”
“枪声有多大？”
“80~100分贝。”
“那就是说会震的耳朵疼？”
“是。”
“在这个城市里打鸟犯不犯法？”
'不犯。“
“您确定那只鸟真的被打死啦？”
“确定。”老师已经不耐烦了，“拜托，你告诉我还剩几只就行了，OK？”
“OK。鸟里有没有聋子？”
“没有。”
“有没有关在笼子里的？”
“没有。”
“边上还有没有其他的树，树上还有没有其他鸟？”
“没有。”
“方圆十里呢？”
“就这么一棵树！”
“有没有残疾或饿的飞不动的鸟？”
“没有，都身体倍棒。”
“算不算怀孕肚子里的小鸟？”
“都是公的。”
“都不可能怀孕？”
“………，决不可能。”
“打鸟的人眼里有没有花？保证是十只？”
“没有花，就十只。”
老师脑门上的汗已经流下来了，下课铃响起，但男孩仍继续问：“有没有傻的不怕死的？”
“都怕死。”
“有没有因为情侣被打中，自己留下来的？”
“笨蛋，之前不是说都是公的嘛！”
“同志可不可以啊！”
“…………，性取向都很正常！”
“会不会一枪打死两只？”
“不会。”
“一枪打死三只呢？”
“不会。”
“四只呢？”
“更不会！”
“五只呢？”
“绝对不会！！！”
“那六只总有可能吧？”
“除非你他妈的是猪生的才有可能！”
“…好吧，那么所有的鸟都可以自由活动么？”
“完全可以。”
“它们受到惊吓起飞时会不会惊慌失措而互相撞上？”
“不会，每只鸟都装有卫星导航系统，而且可以自动飞行。”
“恩，如果您的回答没有骗人，”学生满怀信心的回答，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”
老师当即倒！
举例说明如何进行测试需求分析 先看一段关于日志文件的需求描述如下：“软件要将所有的访问者都要记录下来，对每次访问要记录访问开始时间、访问结束时间、访问者的IP地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。
在这段需求描述中，我们首先要想象自己是日志模块的开发者，根据这段需求描述，是否能够开发出日志模块来呢？日志文件要记录的信息内容上面都提到了：访问开始时间、结束时间、IP地址。乍一看好像可以根据这个需求描述进行开发。
但仔细来分析一下这段需求的话，就会发现并不是想象的那样乐观。先找出需求中涉及的三个显性元素：
1、访问者
2、访问记录
3、日志文件
首先对访问者和访问记录这两个元素进行分析，先看访问者有那些属性，除了描述中提及的访问时间和IP地址外，访问者还有那些属性呢？显然访问者 的访问内容是最重要的属性，仅记录访问时间和访问者的IP地址是否足够呢，从日志能分析出什么有用的信息呢？从时间信息上最多只能看出那段时间访问的人数 较多，得到用户的时间分布规律，但很难对用户的行为有深入的分析，只有知道访问者在访问那些内容才能得到更有价值的信息。象Web服务器软件要记录下访问 的URL信息以便知道访问者访问的内容，所以访问记录中遗漏了关于访问内容的信息。
从访问记录这个元素来分析，访问记录主要属性是记录格式，每条记录是以什么格式来记录呢？没有描述出来。有经验的开发者就知道日志记录格式是一 个很重要的问题，因为日志记录的分析一般是需要使用专门的分析软件或者写专门的分析程序来分析的。如何设计合理的记录格式来利用已有的日志分析软件来进行 分析是首要考虑的问题。
再对日志文件这个元素进行分析，先看看日志文件有那些属性，首先日志文件具有文件名，还有存放位置，文件格式，文件内容、文件创建时间、文件大小、文件权限等属性。
需求描述中提到了每天要生成一个日志文件，从文件创建时间属性来看，每天有24小时，到底从什么时候开始创建文件，从0点开始还是从几点开始，没有描述出来。
---从文件名属性来看，如何命名日志文件，需求中也没有提及。从存放位置属性来看，日志文件存放在什么地方也没有说明。是不是所有的日志文件都存放在应用程序同一子目录下？
---从文件格式属性来看，首先日志文件是以文本方式存储还是以二进制格式存储？再者，文件的内容是以何种格式记录，每条访问记录间如何分隔，是以回车换行作为分隔还是以其他字符作为分隔？都没有描述。
---从文件内容属性来分析，除了存放上述描述的内容外，是否还可以保存其他内容，如果不能保存其他内容的话，需求描述中应该加上一句”日志文件中只能存储访问记录信息，不得储存其他记录信息“。
---从文件大小属性来分析，日志文件的大小有没有限制？如果某天处于访问高峰期，访问特别多，是否需要将日志文件分拆成多个是一个需要考虑的问题。
---从文件权限属性来分析，日志文件是否机器上的所有用户都可以访问还是只有特定的用户可以访问？文件是否需要设置权限是一个需要考虑的问题。
所以在对上述需求描述进行分析后，你会发现需求描述中有很多的问题没有描述清楚。也许有人会有疑问，如果将所有上面说到的问题都描述出来的话会 不会工作量太大了？仅从需求分析的角度来讲，需求规格描述得较细的话确实会增大很多工作量，但从整个开发过程来看，需求描述完整的话，后续阶段的开发产生 歧义和遗漏的可能性就很小，实际上后续阶段节约的时间会大大超过需求所多花的时间。
测试人员在需求阶段应做哪些工作
1)首先，测试用例和测试工作本身是不断完善的，在开发过程的初期，可以认为是需求阶段，或者没有规范需求工作的设计阶段。如果有一个比较明确的需求文档，可以在这个阶段检查完了需求文档以后开始设计测试用例。这里，对于需求文档的检查主要是两个方面：
---检查需求文档描述的正确性，测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟 悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的”都是用户真实的需求“，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人 员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符合，那么是否要确认--这里存在一个隐患，用户可能会在开发的后 期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
---检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性--我的意思是说保证需求是可以完全为测试工作服务的。
2)那么在检查完了需求之后，就可以开始设计测试用例了，在这个阶段因为没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发，而应该从业务角度出发，从实际业务出发来设计测试用例。
当然，这个阶段所设计的测试用例是不够完善的，只能涵盖某些内容，但是我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。 。
3)不过，当缺少需求文档时，那就要发挥测试人员自己的能动性了，要主动的工作，而不是被动的等待。要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的方法来开展工作。