文/秋之川
这是《落叶》文集里第 322 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第八章 你真的理解了什么是软件需求吗？
当我只是个测试执行人员
我走进老大的办公室，把我自己梳理的答案告诉了他，他冲我微微一笑，问了我一个问题：“你真的理解了什么是软件需求吗？”
我不假思索地回答道：“当然理解啊，我好歹也看过很多需求文档，并且评审过不少需求了呀。我平时接触的过的需求文档和评审，都是由各种各样的产品功能和产品优化组成的，比如新增一个用户取消订单的功能，或者是提高用户搜索结果的匹配精准度等等，所以，需求就是指的产品一个个功能要求。”
老大说，“你跟很多人一样，都把用户自己提出的或产品经理给出的解决方案当作了需求，不管是取消订单，还是提高搜索结果匹配精准度，都不是用户最原始或者说最真实的需求，这些其实都是最后的功能性需求。”
“我们要理解的不就是最终的功能性需求吗？”
“你平时看到的的确就是这些功能性需求，如果你只是从依据需求梳理测试点或者设计测试用例的角度来看，理解了功能性需求，也差不多满足要求了。但是，如果你想站在测试项目管理者的角度，做好需求的评审、分析和设计，那还有些不足。”
当我是个测试项目管理者
我们先来看下软件需求的基本概念：
- 为了解决问题或达到目标，用户所需的条件或能力；
- 为了满足协议、标准、规范或其他限定性文档、系统、系统组件、产品或服务需要具备的条件或能力；
- 需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望；
我再把老大跟我说了 N 个小时的有关需求的理解提炼成了一句话：
软件需求就是为了满足用户想解决某个问题、想达成某个目标，或作为某种角色时需求提供的一些功能或非功能性的软件能力。
当我理解了这个概念之后，也就很清楚自己在评审需求时最应该首先弄清楚哪些东西：
- 产品的用户是谁，如果不清楚用户，也就谈不上需求，需求只可能来自用户的期望，而不可能来自产品本身；
- 用户有哪些不同的角色，以及每个角色之间的关系，和每个角色都有哪些业务；
- 业务流程和逻辑关系，根据 1 和 2，是可以绘制出 Use Case 图（UML，统一建模语言）的；
- 产品的功能模块、分类，模块之间的关系和优先级，在理清楚不同角色的用户、业务流程和逻辑关系之后，这些也可以梳理出来了；
- 不同角色的用户是怎么使用每一个功能的，也就是每一个功能被使用的场景；
- 非功能性的需求有哪些，比如性能上的要求，安全上的要求，兼容性上的要求等等；
如果弄清楚这些，到了后面的测试设计阶段，也是受益匪浅。
《告诉你如何从执行测试到管理测试》带你迈出第（8）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
网友评论