如何确保需求可以准确的移交至设计人员处？

xsnzhq

现在存在这样的问题：
1、需求人员完成需求工作后就撤出项目组，而去参加下一个项目，对于这种情况，则存在设计人员没有完全理解需求的情况，而导致不能很好的和客户或需求人员做沟通。
那么对于这种情况，我们是否需要制定一个需求移交报告来确保需求人员将需求准确的移交至设计人员，从而确保设计人员能正确理解需求？那么需求移交报告中应该包含什么内容呢？请大家指教。
2、需求人员认为可以接受的需求，但是设计人员之后却发现不能用现有技术来实现。
对于这种情况，是否需要设计人员可以尽早的参与到项目中，以保证所提需求都是可以实现的。
以上是我的问题，请大家积极讨论，帮助解答。多谢！

xsnzhq

这样的项目是不是需要制定一个《需求移交报告》和相应的流程呢？请大家指点！

chengxq

我说点我的想法，就算作交流
是否应该首先识别出这个需求开发项目组的流程，举个例子来说，我们公司是软件外包，所以需求人员就是开发人员，所以就不存在这个问题，所以我想首先应该根据项目实际当然包括公司实际，识别出或设计出项目开发需求的流程，包括需求开发到设计人员的需求理解，然后根据这个流程分出相应的活动以及各自的职责
按照你说出现的问题，这个出现的关键点是沟通存在的问题，那就是说沟通如何去做，谁管理，谁执行等等
个人感觉可能沟通计划比需求移交报告来的更实际点

xsnzhq

原帖由 chengxq 于 2009-3-31 16:24 发表
我说点我的想法，就算作交流
是否应该首先识别出这个需求开发项目组的流程，举个例子来说，我们公司是软件外包，所以需求人员就是开发人员，所以就不存在这个问题，所以我想首先应该根据项目实际当然包括公司实际， ...

实际上是存在沟通上的问题，但是我认为沟通文档不能完全代替需求移交报告，因为需求移交报告可以使责任明确，如果需求人员已经做了需求的培训和讲解，并且设计人员也已经确认自己理解了需求，那么在出现问题就是设计人员的事，如果设计人员没有在需求移交报告上签字那么需求人员就还有责任继续知道设计人员来理解需求。
不知道是不是这样，还需要大家指点

zhongmg108

原帖由 xsnzhq 于 2009-3-31 14:31 发表
现在存在这样的问题：
1、需求人员完成需求工作后就撤出项目组，而去参加下一个项目，对于这种情况，则存在设计人员没有完全理解需求的情况，而导致不能很好的和客户或需求人员做沟通。
那么对于这种情况，我们是否 ...

简单地说一下自己的观点:
1，确实应该有一个流程来控制的。需求应该经由相关方（包括设计人员）评审和认可的,设计人员签字或认可后，需求才算正式完成移交。
2，需求人员移交需求后仍然需要跟踪需求，需求人员应该参与设计的评审，跟踪需求是否恰当的实现了，需求的变更应该经由需求人员的认可。
3，为控制初始需求的质量，可以考虑将需求稳定度（变化百分比）做为考核需求人员的一个指标。

xsnzhq

原帖由 zhongmg108 于 2009-4-1 15:14 发表

简单地说一下自己的观点:
1，确实应该有一个流程来控制的。需求应该经由相关方（包括设计人员）评审和认可的,设计人员签字或认可后，需求才算正式完成移交。
2，需求人员移交需求后仍然需要跟踪需求，需求人员应 ...

楼上说的很好，但是现在很难用需求稳定度来考核需求人员，因为需求的变更往往并不是由于当初需求没有做好而导致，通常是由于客户自己对需求的理解发生了改变，通过项目不断的进行，客户对项目的理解也发生了改变，从而导致对需求发生了改变，而这却与需求人员无关。这个其实是应该衡量客户的，呵呵。因为通常在需求结束前，会进行需求评审，如果评审通过，说明客户对现在的需求的认可，那么再对需求做更改就是客户的问题了。我们就需要对变更的需求做分析，看是否有变更的必要性，就需要走变更流程来。
现在的状况是，需求人员当将需求移交给设计人员之后，就需要被抽调到其他项目了，那么他很难做到一直跟到设计，但是是不是可以要求需求人员来参加设计评审呢？通过设计评审来掌握设计是否符合需求呢！
请大家指教如何制定需求移交的流程和相应的文档，里面应该包含什么内容呢？具体流程是什么呢？