A. 需求分类
是对需求按照可以管理的方式分组。可分为以下：
(一) 原始需求(客户需求)：原始需求可视为客户的需求，而客户是不了解软件开发技术的，提出的需求是没有办法直接用于开发的，输出文档：市场需求文档(Market Requirement Document，MRD)
(二) 产品需求：产品设计人员或者需求分析人员根据原始需求、结合软件可以实现的功能形成的需求，我个人理解应该就是所说的业务需求，这点待讨论.输出文档：产品需求文档(Product Requirement Document，PRD)
(三) 软件需求：软件开发人员根据软件实现原理进一步将产品需求详细化，输出文档：软件需求规格说明书（Software Requirements Specification），简称SRS
(四) 测试需求：开发人员不了解如何对软件进行测试，无法将需求详细到可直接用于测试，所以测试人员还需要将软件需求转化为测试需求
客户需求->产品需求(业务需求)->软件需求->测试需求，可看成需求由简单到详细的过程，对于每个需求类型都要界定需求实现的优先级、工作量和风险
一个经典的例子：
小明说，他要吃猪骨头火锅(客户需求)，80块吧，但没想到又碰到了授客。
授客：“真的想吃？”
小明：“想吃！”
授客：“为什么？”
小明：“我饿了……”（找到了本质）
授客：“哦，这里是两个馒头（产品需求），请你吃，才1块钱”
……
小知识：客户和用户的区别
客户是为产品或服务买单的人。
用户是使用产品或服务的人，和产品或服务产生直接的交互过程。
客户是对产品或服务形成服务请求和达成买卖关系的人或实体。也可以说是对产品或服务购买有决策权的相关人，这里包含技术决策者和业务决策者等系列人。
客户一般关注的是价格和效果，效果包括了产品使用后的工作效率提升，也隐含了领导的业绩提升。有的时候客户既不关心价格也不关心效果，他关心自己的个人利益。所以找到客户的真实意图是拿单的关键所在。
用户对产品的关注点是好用，简单，提高效率，带来便利。产品最终是为用户服务的，即使产品被客户买单，但最终用户用不起来，那么这也是个失败的产品。
所以，产品被用户认可，使用后能提升工作效率，同时给客户带来利益，这才是双赢的局面。
B. 测试需求
什么是测试需求，见名知意，要测啥？简单说也就是设计测试用例中的验证点，测试依据，这里包括功能性测试需求，也包括非功能性能测试需求。做测试的要学会从需求规格说明书中挖掘需要测试的验证点，进行用例设计。
例子：从软件需求规格说明书中获取测试需求
（举例目的在于让新手了解写用例并不是直接复制需求说明书中的内容，而是要挖掘测试点）
假设需求规格说明书中有如下一功能需求
功能描述：
功能名称: 快速搜索
功能描述: 可以根据人名或文章、标题的内容进行搜索
用户及角色: 注册用户
补充说明: 无
输入项：略
处理流程：略
输出项：略
即便仅有功能描述的情况下，我们也可对其进行挖掘测试需求：
1.输入是否支持中文？数字？英文？空格？
2.是否可以输入较长的搜索字符？
3.输入是否支持模糊搜索？
……
确定以上问题为测试需求后即可把它们作为用例设计的验证点，进行用例设计
