必不可少的需求规范

情景

情景一：

        测试阶段，小A发现某新功能未考虑覆盖安装的逻辑，且当前开发实现的方式不合理。与产品、开发沟通后需要增加覆盖安装的新逻辑。但是开发和测试都要增加工作量，需要再次排期。因为改动较小未按照需求新增处理，但当前也没有针对此问题的流程。

 

情景二：

        滑动光标出现使用技巧功能，由原来的只出现一次改为出现三次。但是之前的另外一个策略是如果用户使用过此功能则不展现此技巧。新版本测试中，小A发现使用过移动光标，此技巧不再出现。与产品沟通后，优化后的策略是即使使用过也要展现三次，但是需求文档没有写使用过功能是否展现技巧的逻辑。小A按照bug报给了开发，开发认为需求未写不属于bug。

目的

        针对上面遇到的问题，为了让前期需求细节考虑不全的问题跟踪规范化、合理化，避免任何方疏忽造成上线问题。我们特指定了需求补充流程，解决原流程未覆盖的需求细节漏洞问题。

流程概况

 

 

执行方案

提交需求补充的前提：测试与产品意见达成一致，需要完成此问题。

1）测试人员：

A. bug系统中提交bug时，标题处添加字段【需求补充】，与其他类型bug进行区分。

如：

B. 需求补充均指派给对应需求的产品人员。

2）产品人员：采纳指派开发修改时，需要将补充后的需求文档作为附件添加的当前bug中。

3）bug系统中指派流程

 

        以上是我们组内的指派流程，大家可以根据自己组内的流程进行简化。