需求的生命周期
获取需求的阶段
随时记录 不论任何时候，听到任何需求，都需要记录下来，记录是为了方便整理和回溯，哪怕是一句话的需求也要记录。 当然，对于严谨的产品经理来说，有更专业的名词，称为”产品需求池“。
判断需求的重要性 对需求本身有初步的重要性判断，可以简单的按照新增功能、体验优化、异常bug、功能bug等初步分类。 一般来说，最高优先级的为线上主流业务会导致的bug，这类bug会导致主流程不通，或者用户权益受损失的； 而优先级最低的为一些不敏感的文案显示，用户体验是否敏捷、方便等。
考虑需求来源 当收到需求时，一定要考虑来源对需求本身的影响，来源是否是用户的真实需求，还是局限于研发团队或者上级的猜想。 如果不是用户真实需求，或者用户根本不需要的部分，可以选择忽略。
了解需求背景 需求背景就是为什么要做这个需求，下面有主要的三类不要接的需求：
·没有说清楚原因的
· 不能说清楚需求本身的逻辑是什么
· 不符合用户的真实需求，只是意向 备注：永远要铭记，想清楚需求是否有意义，比直接行动来的有意义的多。
需求卡片 当你接到一条需求时，需要很好的记录，那么本文提供一种需求记录的格式方便快速整理你收集到的有效需求。
讨论和设计阶段 每隔一段时间应该讨论需求池中的需求，然后确定需求的优先级。默认优先级分为从p0-p3。
备注：在项目管理或者
测试中，参考的优先级应该按照需求的优先级来定，让整个过程更加可控。
紧急重要四象限法则 分为重要紧急优先，重要不紧急其次，不重要紧急再次，最后不重要不紧急。
KANO模型 从情感角度评价，一个需求是如何的，是属于必须做的，还是选做的。
方案的草稿 跟进第一阶段的需求卡片，针对每个细分需求提供产品交互方案
指定负责人和时间节点 针对每个需求，指定对应的产品负责人，可以按照模块划分，但不用定死。针对每个需求的具体落地需要提供截止时间点，觉得需求细化到可开发的程度便可以进入下个阶段。 所以你的需求卡片中需要增加需求负责人，需求初审稿截止时间。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
权威发布，测试选择不纠结！第15届软件测试行业报告，直击行业发展，把握未来方向！
