需求将市场部和研发部紧密地联系起来，让两者之间的有效连接并维护平衡的角色就是团队中的需求专家。市场部和直接的用户，以及相关系统的投资方、监管方、维护方等等进行交流，我们不能保证他们能够提供准确的清晰的需求描述，因为他们只是在提出他们的问题和对结果的期望，而且要求我们的客户去学习什么是好的需求和如何提需求是不现实的。现实的是团队中有这么一些人，熟悉领域且受到过需求管理方面的指导和培训，他们知道应该怎么去收集、分析和总结需求。例如在西门子， 负责捕获客户需求的工作主要由市场部人员去做，但并不是直接将这些需求转给开发部。有一个需求管理小组，隶属于研发中心，主要职责则相当于市场部和开发部的一个接口。需求工程师对从市场部那里获取的零散和庞大的需求文档进行整理和分类，然后提交给开发部。开发人员不需要和市场部争论哪些事情做得到还是做不到，而是由需求工程师来做。（具体参见《探索需求管理的三步曲》——《程序员》2005年9月刊） 这是一个很好的做法，需求工程师可以是一个职位，也可以是一个角色。单独的职位可能在小的团队中不太实际，但拥有这个角色的人自己必须很清楚自己的位置：是处在市场和研发中间，需要维护好平衡，做好接口的工作。
产品线需求 vs 具体项目需求
研发团队的项目性质很大程度上决定了需求管理做到的深度和广度。有项目经理问，我的项目周期常常只有几个月半年的，还需要做需求管理吗？诚然，若是一些没有专注业务领域的团队，他们项目的时间短，而且没有类似的后续项目，可以不必在需求管理上面投入太多的资源。而另一方面，如果这个项目是一个产品发展的某一个阶段，我们就要重新审视这个问题。就如一个做打印机的日本公司在上海的研发团队，他们的项目周期也是半年左右，但是一个基本型号的打印机已经有二十年的历史。也就是说，现在的这款打印机是一个个小的项目的开发成果的累计。这时，该开发团队就需要很好的需求管理，而且需求管理已经不再局限在某个项目里。
市场的激烈竞争，企业自身的发展，我们看到一个产品的需求往往会非常多。如果全部实现，那将是一个“完美”的结果。时间和资源的现实面前，决策层需要进行选择：既要快速地将产品发布面世， 同时新的版本中也需要有足够地引起客户购买欲望的需求实现。
这里需要决策。孙子兵法中的“胜兵，先胜而后求战；败兵，先战而后求胜”早就阐述类似的道理：打胜仗的部队是在有胜算时之后才投入战斗，打败仗的部队先投入战斗，才寻求胜利的条件。需求工作的重要性是老生常谈的事情了，不是本文的重点。我们关注的是如何做出正确的决策而占得先机。
图3 沙漏的上半部分强调的是在产品和项目的规划阶段，我们需要将做出正确的决策以满足现在市场的需要。这体现在收集和记录正确的需求；对需求的重要程度做出准确的刻画；基于成本和效益来规划产品的路线图，将需求的实现分配到各个的项目中。在需求明确的前提，项目经理就可以带领他的团队开展工作，这个阶段的重点就是如何保证需求在每一个研发的每个阶段都得到严格的满足和测试，而切实保证需求驱动开发和保证需求驱动测试，是研发团队将事情做正确的关键。
决策的重要基础是对需求的重要程度进行排序。但排序的基准在哪里，且基准也会随着个人的角度和时间的推移而变化？如果读者参与产品和系统规划的工作，尝试着回答下面的问题：所有来自A地区客户的紧急程度为高的且估算工作量在180 个人天以下的所有需求有哪些？他们现在的项目状态如何？这是一个问题的简单样本，问题的实质在于决策者可能需要从多个角度去分析需求，并需要在众多需求中找出最重要的或者是当前最感兴趣的需求的子集。在没有方法的指导和工具的支持下，这个工作在竞争越来越激烈的现在是越来越难了，因为决策者往往面对多个产品， 多个市场，多个竞争对手，当然还有时间和成本的压力。
“沙漏”的具体实践
沙漏虽然是个比喻，但实际上有很多公司都在实践这种思路。以Telelogic公司开发DOORS 这个产品为例，该产品的信息架构也呈沙漏的形状（为了展现的方便，图4 为一个卧倒的沙漏）。在沙漏的前半部分，需求的来源主要分三大块： 客户反馈（Customer Feedback）、市场行销部门反馈（Sales and Marketing Feedback） 和竞争对手分析（Competitive Analysis）。基于这些原始的需求信息，产品部门总结出DOORS 产品的用户需求，而后是分析得到功能规格来满足用户的需求，再分模块去详细设计。
重点解释一下在离散的原始需求和正式的用户需求之间所发生的整合的动作。正如上文提及的，我们不能期望客户的反馈是清晰的，是结构化的，但提交给开发部门的需求必须是清晰的、准确的、抽象的和可测试的。整合的动作就是进行信息的梳理和转换。
重要的是，开发部门使用工具将整合的过程和思路记录下来。常常在一个项目中听到这样的抱怨：客户（甲方）说不清楚原来提出的需求有没有在开发中得到体现，或者是直到见到产品了，才能确定需求是否体现，体现在哪里；而开发团队（ 乙方）会抱怨客户总是到项目后端变来变去，但能和客户“讨价还价”的依据又太少。在沙漏的模型中，最初的需求文档可以是图4中列出的，更可以是其他的贴近客户和市场的记录形式，如Email，会议记录等等。整合的过程中，我们需要将用户需求中的某条需求将和上游的来源文档中的需求描述部分联系起来，如利用工具建立类似超链接的link。这样对于需求来源方（客户和市场部）可以清楚地知道自己的要求在正式的需求文档中是否有提及， 如何被描述；而对于开发人员来说，也知道这条需求的提出者是谁，原始的描述图4：一个“沙漏”的示例是如何的，方便地进行评审和确认。
整合还将帮助发现重复的需求：可能一个需求被多方提出，但归结到用户需求中只有一条需求，但该条需求对应关联到多个最初的需求来源。但这条需求得到满足的时候，多个涉众都应该能够通过关联知晓自己的需求被满足。此外，整合的意义还在于发现冲突的需求， 这时候就需要产品部门决策和平衡，必要时通知相关人员并做出解释。沙漏中流淌的是细沙，而我们面对是需求。细沙漏过后直接就沉入瓶底了， 但经过整合后的需求才刚刚开始它的演化之路，用户需求将被系统功能所对应满足，系统进而被分解成模块，同时测试的工作也将展开。这些信息之间的关联就是反映了需求在沙漏的下半部分被分解和验证的过程。这样，层层的关联可以让我们从沙漏的前方知晓后方的研发进度和状态同时，也可以为沙漏的后半部分中研发任务追溯到需求的源泉。
文章来源于领测软件测试网 https://www.ltesting.net/
