才能正确地分析出系统应该提供哪些功能。首先，研发团队一定要注意对涉众真实需求的收集和理解。更进一步看，在涉众需求的收集和定义阶段，风险主要存在于定义了错误的需要解决的问题；相对去后续阶段的设计而言，在定义系统需求阶段，系统工程师应该只是抽象地描述解决方案，这个阶段的风险存在于不必要地带入过多地设计约束，影响详细方案的可能选择。
可能有读者会抱怨或怀疑这个思想是不是太理想了:用户常常就告诉开发团队他关于解决方案的设计和想法，这时候怎么办？这就更要求我们的需求捕获人员有清晰的思路，首先，“用户可能自己也不知道自己需要什么”，这是常常发生的事情，我们需要适当地提出“为什么”来引导客户；其次，假定客户知道自己想要的，那么客户提出关于实现的想法也反映了他的潜在目标，也就成为了我们设计时的约束。
市场和研发的平衡
在很多上了一定规模的公司中，有两个团队是一定存在且非常重要的：市场部和研发部。市场团队主要和“人”打交道，进行市场的调研和需求的获取，这处在图2中沙漏的上半部分。在沙漏的下半部分是工程领域，也就是开发队伍工作的领域。对开发人员来说，他们很少有机会真正地面对客户，他们工作的基础就是需求。对一个项目或产品的成功， 这两个团队必须紧密合作，扮演好自己的角色。一旦此间的平衡被打破，团队就会遇到麻烦。很多公司里市场部门“坐大”，为了赢得客户的定单，或不深入理解客户的要求，或是直接“指示”研发部门按照自己对系统实现的理解进行开发。这都违反了上文中提及的需求捕获的关键原则。当另一方面，我也遇到这样一些公司，它们是由研发起家， 整个研发部门在公司中占有比较多的“话语权”。会有这样的开发经理或人员，可能是出于追求技术领先或完美的热情， 在满足用户需求的同时，也会增加设计/ 实现其他“多余”的功能点。这些功能点其实是“无源之水”，并没有实际的市场和用户需求与之相对应。
需求将市场部和研发部紧密地联系起来，让两者之间的有效连接并维护平衡的角色就是团队中的需求专家。市场部和直接的用户，以及相关系统的投资方、监管方、维护方等等进行交流，我们不能保证他们能够提供准确的清晰的需求描述，因为他们只是在提出他们的问题和对结果的期望，而且要求我们的客户去学习什么是好的需求和如何提需求是不现实的。现实的是团队中有这么一些人，熟悉领域且受到过需求管理方面的指导和培训，他们知道应该怎么去收集、分析和总结需求。例如在西门子， 负责捕获客户需求的工作主要由市场部人员去做，但并不是直接将这些需求转给开发部。有一个需求管理小组，隶属于研发中心，主要职责则相当于市场部和开发部的一个接口。需求工程师对从市场部那里获取的零散和庞大的需求文档进行整理和分类，然后提交给开发部。开发人员不需要和市场部争论哪些事情做得到还是做不到，而是由需求工程师来做。（具体参见《探索需求管理的三步曲》——《程序员》2005年9月刊） 这是一个很好的做法，需求工程师可以是一个职位，也可以是一个角色。单独的职位可能在小的团队中不太实际，但拥有这个角色的人自己必须很清楚自己的位置：是处在市场和研发中间，需要维护好平衡，做好接口的工作。
产品线需求 vs 具体项目需求
研发团队的项目性质很大程度上决定了需求管理做到的深度和广度。有项目经理问，我的项目周期常常只有几个月半年的，还需要做需求管理吗？诚然，若是一些没有专注业务领域的团队，他们项目的时间短，而且没有类似的后续项目，可以不必在需求管理上面投入太多的资源。而另一方面，如果这个项目是一个产品发展的某一个阶段，我们就要重新审视这个问题。就如一个做打印机的日本公司在上海的研发团队，他们的
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
