需求转化到文档维护

  进入新单位很快3个月了，熟悉了新的流程后，总结一下需求转化的感受：

最先得到的需求参考有：产品说明书，交互和视觉稿，这个和其他公司基本一致，差别无非就是文档格式和语言表达。这个阶段我们要做的是：

  1. 三者对照一起通览几遍。我的习惯是打印出来，以便记录疑问，第二遍看的过程中试着自己去解答上一遍的疑问

  2. 几遍均看完后，整理Q&Alist，我的建议是表格形式，列标题包含：序号，模块名称，功能点，原文，提问内容/或理解待确定内容，提问人，提问日期，问题状态（New，closed，Renew）,答复内容，答复人，答复日期，备注

  3. 主动推进Q&Alist问题的解答和跟进，你可以求助的人有产品经理，交互设计师，开发项目经理，团队领导等，切记问题的发出和返回一定要使用邮件，如果是口头确认要立即邮件记录准时发送，维护信息和版本内容

  4. 当有问题返回时，确定理解后，可以关闭此问题；如果不理解还需澄清，就改为Renew，继续细化问题，等待回复。沟通渠道要采用多样的，不能死等，否则我们的邮件或问题将石沉大海。

  5. 开始使用导图工具，一级枝为模块名，二级叶为一级功能点，以后各级需考虑场景或影响因素，不断细化子叶，其中会让我们发现更多问题，继续整理Q&A

  6. 导图成型后，可称为工作量预估的基础，测试计划可以预估。。一般一个成熟的员工一天能写50条case，执行40-60条Case，执行量要看case的复杂度，比如这里很多工作的关键路径是数据的mock，环境的稳定性；计划要考虑测试策略，比如启动几轮，每轮回归的比例和环境等

  7. 根据导图整理成测试分析的功能点表格

  8. 功能点表格可有效的转化为测试用例和后期的需求跟踪矩阵，同时在测分评审时简单明了

  9. 评审会议前，一定将测分文档准备充分，有疑问或需要明确的内容可以标黄，会议上一并解决，比较高效。会议记录要记录清楚。

  10. 根据测分修改稿进行用例设计

  11. 需求跟踪矩阵可以直接使用功能表格，记录需求从冻结后的一起变化，如新增，修改，日期，影响工作量等

写的比较糙，更多的感受慢慢记录吧，现在每天工作13小时，已经连续2.5个月了，期间休息6天，高强度呀，成长也是很快的，加油！

本文出自 “叶子文文” 博客，谢绝转载！