目前我们在项目中经常遇到这样的问题：
1 ，发生需求变更的时候， 可能没有及时通知到所有相关人员，也没有去更新需求文档，  比如测试人员在发现了问题去问开发的时候， 才知道原来此处需求已经改过了
2，开发人员在开发时，或者测试人员在编写测试用例时才发现有些需求模糊或者了解不够清楚的地方， 这个时候如果直接和PM进行了沟通， 却没有及时通知到其他相关人员， 在后期沟通的时候也会出现问题，

针对这样的情况， 想知道大家是如何解决的呢？

我们原先都强调要求过程中的需求变更必须知会相关人员的.

从楼主这个问题看,简单的说,你们公司没做好代码文档的配置管理,没做好需求的跟踪.软件需求一但通过了评审,就应该基线化,纳入配置管理库.而在配置管理库中的文档或代码不能再轻易进行修改.当有需求要进行变更的时候,就必须提出申请,写需求变更计划,审核通过,才有权限进行需求变更.然后配置管理员一定要做好需求的跟踪.,凡是跟变更需求有牵连的开发人员和测试人员都要同步的通知到和及时让他们做好相应部分的各类文档的修改.这样就不会出现上述问题了.

[ 本帖最后由 xiaonan 于 2006-9-15 11:45 编辑 ]

强烈同意"xiaonan "的观点，如果只是些细节的变动的话，建议在文档更新后，及时Email或者其他途径通知相关开发测试人员。如果改动较大，建议通过会议的方式及时确认，并告知相关人员，然后再进行文档的修改和任务的继续。

好象也应该具体问题具体分析哟,有的是跟着项目走的,客户到了项目的后期,突然要增加需求,客户就是上帝,他的需求不得不改,这怎么还评审,确定

配置管理没做起来时,需求变更都不规范,想变就变,好像需求变更是很正常似的,最烦就是这个问题了.
也想探讨这些问题.多多交流

我们确实是做不到:不允许或规定用户不能对需求进行变更.既然这样,我们就要定义好需求一旦变更时的流程.其实,我们不怕用户需求有变更情况,怕的是没有变更的处理方法.所以,首要任务是定义好需求管理,包括变更的流程.这样以后,也就无所谓需求是不是经常改变了.

应该有一个产品定义部门，他们负责产品定义，功能需求的变更首先应该通知产品定义部门，然后产品定义部门出具变更文档，提供给开发、测试，做为实现依据。

我们公司的情况和楼主的差不多,测试部门主要是通过与开发部门紧密联系来实现的

引用:

原帖由 miny19 于 2006-9-15 17:20 发表
强烈同意"xiaonan "的观点，如果只是些细节的变动的话，建议在文档更新后，及时Email或者其他途径通知相关开发测试人员。如果改动较大，建议通过会议的方式及时确认，并告知相关人员，然后再进行文档 ...

同感,而且应该有版本管理工具吧,只要有变动,就要把最新版本的需求提交

赞同yoyoa的说法, 定义好需求管理,包括变更的流程.

或者往大说,整个开发过程需要好好整理,因为目前很多公司开发过程就极不规范!

与客户沟通后，填写需求变更单，让用户确认签字后给PM Review，放入VSS，大家都可以看。

我们都是通过会议 的方式进行的

恩，谢谢大家的建议， 大家确实都提出了很好的办法，
特别是Xiaonan提出的需求文档配置变更的部分， 我们现在确实没有做起来。
目前暂时采取的办法是要求项目经理将每一个变更都需要有所记录， 或者以邮件的形式通知， 最好是更新到需求管理文档上，以后开发和测试都只以最新的需求文档为主。
目前我们也在做需求基线管理的事情， 希望可以很快看到成效。

谁能告诉我CMO和CCB在企业中的作用啊。

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。