在实际的工作中系统的性能需求通常是一个笼统的需求，而且有可能给提需求的人并不知道具体的性能需要，所以只能含糊的列出。如果测试人员不搞清楚，就会出现实际要把杀猪刀，需求标明能屠龙！！！
下面，还是举一个讲个我真实经历过的故事来做实例分析。
故事开始：
需求方是一个研究机构（甲方），它旗下本身也有一个软件技术部（但不承担开发测试任务），但是这个项目是外包方（乙方）来做的，我们公司当时是中间的监理机构（第三方），主要监理整个项目系统的性能质量以及整个工程（包括开发、测试以及系统运行）的质量，对我来讲任务只是考察系统的性能，系统讲的是一个图书检索系统，包含主要功能:图书上传，图书分类，目录索引，图书搜索，图书下载以及图书的全文检索功能。
我也参加了他们项目组组织的一次“性能需求”会议，当时的合同我们监理拿给我看了一下，实际在合同上并没有规定具体的性能指标，只有一句话：系统需要满足甲方5年内的业务需求。
系统甲方在会议上张口提出了需求：并发用户要到5000，业务响应时间要控制在3秒内；乙方开发组长是个年轻的小伙子，对这个性能完全没有概念，就问我们监理这个是否合理，监理把这个问题抛给了我，我用笔在纸上做了提纲，然后对甲方和乙方提出了问题。
(1) 请问甲方，当前的业务量或者访问量是每天多少？答：10000左右，有时候15000访问用户
--我扭头想骂人，这不是欺负人吗？
(2) 请问甲方5000的TPS从哪儿来的？答：10000的用户并发1000，估计5年内业务能上升到5倍，所以是5000
--我低头对监理说：这个5000太不合理了，是不想让上线啊。
--监理：给出合理解释，给个合理的范围。你直接说。
--好吧，每天的业务峰值才只有15000，咱们就按10倍来计算，150000，每天8个小时正常工作时间，按照只有20%的时间用户会集中，就算20%的时间所有用户都集中在这，那么TPS计算一下150000/(0.2860*60) 大约是26，还不到30的TPS，怎么会出现5000并发呢；当然30对一个系统来说可能是有点小，咱们来平衡一下。
最后在各方的努力下做出如下的改变：
当前峰值访问15000，5年内，假设业务发展增加100倍，最后定到并发访问用户和TPS在300，响应时间根据业务而定，全文检索在3分钟内，下载，上传业务不做限制，图书索引和图书索引搜索（模糊搜索）在5秒内。
故事结束。
这个例子，其实没有其他意思，只是想说，很多时候需求可能是“拍脑袋”想出来的，没有数据支撑，这个时候我们需要的是需要多次的沟通，需要达到项目组多方的一致认可（理由和数据充分，才可行）（作为监理需要既不偏袒甲方也不包庇乙方，一个项目组的共同目的就是项目保质保量、完美的上线运行）。
这个例子也是一个没有既定具体需求的案例，需要我们了解业务功能，并应用常用的规则来进行推导一些可能的需求。
这个业务里面，全文检索业务响应时间是一个比较难定义的点，需要在图书库里面（注意图书不是录入数据库的，都是PDF文件要在各个文件里面）进行检索，虽然文件进行了科目的分类检索，但是每一个科目图书还是很多的，全文检索那速度可能就更是问题了，这个问题为了给用户更好的体验，在前端进行了处理，有一个类似于进度条的展示，展示当前的所有进度，并且逐渐展示已经检索到的部分内容，提供用户的体验度。这个并没有使用任何的后台技术进行调优，因为这个代价可能非常大，只是在设计上进行了优化，而这个需求的最终确定也是测试和整个项目组一起讨论后确定下来的。
这里要说的，并不是一个具体可以拿来照搬的（需求分析）方法，只是想强调一点：分析和了解需求很重要，并且你分析得到的需求与整个项目组的沟通和确认至关重要，它关系到你后面所做的所有事情是否有效。
接下来，我们总结一下需求分析的方法：
(1) 具体有文档的和需求的，先分析文档需求，找出疑问和项目组进行确认，最好自己整理一个系统结构和业务流程图在项目组进行讲解确认，达成一致观点。
(2) 没有文档需求的，需要和整个项目组进行沟通交流，先大致了解，然后逐渐细化分析系统的各个业务流，最终形成系统结构和业务流程图在项目组进行讲解确认，达成一致观点。
(3) 一些细节的性能需求，项目组不能提供时，需要结合一些原理进行分析拿出具体数据和项目组进行确认，达成一致观点。
可以看到，最后都是落实到和项目组确认，你确认的时候，从这几个方面入手：
(1) 对给出的每一个需求点，给出需求是怎么来的？要有数据说明。
(2) 对给出的每一个需求点，给出这个值合理性？做好数据和原理说明。
(3) 最后询问一下项目组是否有遗漏？一个人的力量始终是没有一组人的力量大。整个项目组一起思考也许就能够补充一个人所想不到的一些放面。
(4) 当项目组提不出问题的时候，要主动提出一些问题，比如是否需要稳定性测试，是否需要考察可靠性，咱们是否需要做这些等等。
这个方法其实应该是所有的项目都能够采用，可能有些项目时间上比较紧张的时候，不允许我们有时间进行全面的分析，这就是测试中的最大风险所在。