这种情况到底作为需求变更还是BUG来处理?一直困惑，拿来大家讨论
需求文档在需求评审并基线化后，进入设计等下一环节。在后续阶段/过程中，发现基线化的需求文档中的问题。如：计算公式给错了，或漏了重要的业务规则。而这些问题可能是项目内的疏忽或泄露造成，而不是用户提的需求。
这时，你们为了把这个问题解决：是进行 “需求变更”还是“缺陷跟踪”？
你们组织是怎么确定的？ 应该是做先提出需求变更,在变更过程中做好需求跟踪,做好其他相应的文档都能及时做好修改.而缺陷跟踪是伴随在需求变更过程中的,看需求是否得到正确修改.
[ 本帖最后由 xiaonan 于 2006-11-1 11:07 编辑 ] 你说的有道理。
查到法道自然中列了: 需求变更的原因:（1）开发中碰到的突发问题。（2）开发人员与用户沟通造成的问题。（3）项目组成员的失误。
仔细再想了想，需求变更主要分析的是影响，特别关注对后续工作产品、人员的影响。变更措施中，对需求的问题走缺陷跟踪的修改，或者直接走变更措施，只要在需要时能度量此类问题到即可。
忽想到感觉奇怪的是，很少有提如:设计变更，即：中间阶段/过程引起变更进行控制的，其影响可能涉及上下游，这块几乎少有关注，在以往参与许多项目中，却遇到不少。 有时候需求要变更是无法避免的,但我们可以制定变更流程来应对这种变更.可能还是个流程制定规范问题.变更本身并不可怕,可怕的是变更 后引发的问题有没有能够正确的处理
[ 本帖最后由 xiaonan 于 2006-11-2 16:02 编辑 ]
加一个类型
加一个类型：优化 先要做需求变更 重要是一定有把问题跟踪并解决了．所以先在ＢＵＧ的等级定义里给出一个等级包含了需求变更方面的内容（这是测试前期就开始做的准备工作，因为这种现象很正常），做得跟踪管理．
然后提出需求变更，做好变更管理．
最后问题解决后再把ＢＵＧ关闭． 这种问题引起的BUG级别通常很高吧，需求要是错了，通常都会引起很大的返工，还是把时间多一点用在需求上吧 首先它是一个缺陷。
另外，因为修改对象已经被基线化为下游工作产品的基础了，所以必须还应作为一个变更处理。以保证其所关联的影响都被修改。
在工具上一般如下：
1，缺陷跟踪系统中录入这个缺陷；
2，如果识别为已经基线化的工作产品的修改，且影响到下游工作产品，则倒入到变更控制系统；
3，在变更控制系统中做指派多个处理人触发多个任务，并绑定相应配置项；
4，仅当所有人完成修改后，作为一个状态同步到缺陷系统中关闭这个缺陷。(当然，也可以做的更细，就是分别翻转缺陷的多个状态)
页:
[1]
