不同的利益相关者对抽象的层次有所不同。
这是很容易说 “谈话在业务层面，而不是技术”，但它并不一定那么容易做到。您正在设计的系统是一头大象，而您的涉众是检查它的盲人。有些人是如此深深地沉浸在制造工艺和常规，他们甚至不知道有是一个企业。其他人可能会在您想要的抽象级别上工作，但容易做出夸大甚至错误的主张，或者会进行如意算盘的思考。
不幸的是，您只需要以个人的身份认识所有个体，并了解他们的想法，学习如何解释他们所说的话，甚至决定忽略什么。
分而治之
如果您不想做某事，请将其发送给委员会。
不要见委员会。保持这些会议尽可能小。YMMV，但以我的经验，理想的人数是公开会议为3-4人（包括您自己），闭幕会议为2-3人（即当您需要回答特定问题时）。
我尝试与在业务中具有类似职能的人员会面。与Bean柜台在房间里扔给市场营销人员，实际上没有什么好处，也有很多损失。寻找一个领域的专家，让他们谈论这个主题。
没有准备的会议就是没有目的的会议。
其他一些答案/评论也提到了稻草人技术，对于那些似乎无法从中得到答案的麻烦人士来说，这是一个极好的方法。但是，不要过分依赖稻草人，否则人们会开始觉得自己像在铁路运输。您必须轻轻地朝着正确的方向推动人们，让他们自己提出细节，以便他们感觉自己拥有它们（从某种意义上说，他们确实拥有它们）。
你做什么，需要的是某种你是怎么想的商业作品的心智模式，以及如何系统应工作。 即使您不是特定公司的专家，也需要成为一名领域专家。对您的业务，竞争对手，市场上现有的系统以及可能与远程相关的任何其他事项进行尽可能多的研究。
到了那时，我发现使用高层结构（例如用例）最有效，这种结构通常使每个人都可以接受，但是提出特定问题仍然很关键。如果您从“如何为客户收费？”开始 ，您参加了很长的会议。提出暗示流程的问题，而不是一开始就提出流程：订单项是什么？如何计算？他们多久更改一次？有多少种不同类型的销售或合同？它们在哪里印刷？ 你明白了。
如果您错过了一步，通常会有人告诉您。如果没有人抱怨，那就拍拍自己，因为您已经隐式地确认了此过程。
推迟主题外的讨论。
作为需求分析员，您还扮演着促进者的角色，除非您真的很喜欢花所有的时间在会议上，否则您需要找到一种使事情保持正轨的方法。讽刺的是，这个问题成为最致命的，当你终于也让人们谈论。如果您不小心，它会使您花费大量时间铺设铁轨的火车脱轨。
但是-而且我很久以前很难学到了- 你不能仅仅告诉人们一个问题无关紧要。这显然与他们有关，否则他们不会谈论它。您的工作是让人们尽可能多地说“是”，并设置类似的障碍，这只会使您陷入“否”的境地。
这是许多人可以通过“行动项”保持的微妙平衡，基本上就是您已承诺可以回到某个时候的一般性讨论队列，通常以那些认为确实很重要的利益相关者的名字来标记。这不仅是出于外交的考虑，它还是一种有用的工具，可帮助您记住会议期间发生的事情以及以后需要澄清时与谁进行交谈。
不同的分析师以不同的方式处理此问题。有些像非常公开的白板或活动挂图，有些则无声地将其插入笔记本电脑，然后轻轻地搜索其他主题。无论您觉得满意如何。
你需要一个议程
几乎对于任何类型的会议都是如此，但对于需求会议则是双重事实。随着讨论的进行，人们的思想开始徘徊，他们开始想知道何时才可以开始真正关心的事情。如上所述，制定议程可以提供一些结构，并且还可以帮助您确定何时需要推迟正题之外的讨论。
不要在不清楚要覆盖什么以及什么时候进入那里的时候。否则，您将无法评估自己的进度，并且用户会因为长时间运行而讨厌您（假设他们尚未出于其他原因而讨厌您）。
模拟它
如果将PowerPoint或Visio用作模型工具，则可能会显得过于精致。这几乎是一个用户界面的诡异谷。人们会对餐巾纸绘图（或使用Balsamiq或Sketchflow之类的工具，看起来像餐巾纸绘图的计算机生成的绘图）感到满意，因为他们知道这不是真实的东西，这也是人们能够观看卡通人物的原因。但是，它开始看起来像真实的UI越多，就会有更多的人想要选择它并对其进行掌控，并且他们将花费更多的时间来讨论最终无关紧要的细节。
因此，一定要进行模拟测试（在初始分析阶段之后），以测试您对需求的理解-这是获取非常快速且详细的反馈的好方法-但请保持低调，不要急于嘲笑，直到您完成。非常确定您正在与用户保持一致。
请记住，模拟不是可交付的，它是帮助理解的工具。就像您在执行UI设计时不会被模拟束缚一样，您不能仅仅因为它们给了您的模型以赞许，就不能认为设计是可以的。我已经看到模拟被用作拐杖，或更糟糕的是，它们成为完全绕过需求的借口；确保您没有这样做。返回并将该模拟转换为一组实际需求。
耐心一点。
许多程序员很难相信这一点，但是对于大多数非同寻常的项目，您不能只坐下来一次制定完整的功能规范。我不仅在一次会议上谈论耐心，需求分析与代码的迭代方式相同。A组说些什么，然后B组说些什么，这与您从A组听到的完全矛盾。然后A组解释了不一致之处，事实证明这是C组忘记提及的事情。重复500次，你有什么大致类似的真理。
除非您正在开发一些小型的CRUD应用程序（在这种情况下为什么要完全满足需求？），否则不要指望一次，两，五次会议就能获得所需的一切。您将要经常听，说很多话，并经常重复自己。请注意，这不是一件可怕的事。这是与那些不可避免地要在您的交付物上签字的人们建立融洽关系的机会。
不要害怕改变技术或即兴创作。
项目的不同方面实际上可能要求使用不同的分析技术。在某些情况下，经典的UML（用例/活动图）效果很好。在其他情况下，尽管有我之前的警告，您可能还是从业务KSI入手，或者通过思维导图集思广益，或者直接进入模型。
最重要的是，您需要自己了解域，并在浪费他人时间之前做作业。如果您知道一个特定的部门或组件只有一个用例，但是它是一个非常复杂的用例，那么请跳过用例分析，然后开始谈论工作流或数据流。如果您不对应用程序实现的每个部分使用相同的工具，那么为什么要对需求的每个部分使用相同的工具？
注意地面。
在我阅读的用于需求分析的所有提示和技巧中，这可能是最常被忽视的提示和技巧。老实说，我认为与预定的会议相比，我偷听和闲聊的次数更多。
如果您习惯于孤立地工作，请尝试找出操作的位置，以便您可以听到the不休的声音。如果做不到，那就经常去厨房，卫生间或任何地方。通过聆听人们在喝咖啡和抽烟休息期间吹嘘或抱怨的内容，您会发现有关企业真正运作方式的各种有趣的事情。
最后，在两行之间阅读。
过去我最大的错误之一是过于专注于最终结果，以致我没有花时间真正听到人们在说什么。有时-在很多时候-听起来人们似乎什么都没做，或者对某种听起来毫无意义的程序procedure之以鼻，但是如果您真正专注于他们在说什么，您会意识到确实存在埋在里面的需求-或几个。
尽管听起来很老套和平淡无奇，但“ 五个为什么”在这里确实是一种有用的技术。每当您有那种下意识的“愚蠢”反应（不是您会大声说出来）时，就停下来，把它变成一个问题：为什么？为什么要重新键入此信息四次，然后进行打印，影印，扫描，再次打印，固定在刨花板上，用数码相机拍摄并最终通过电子邮件发送给销售经理？ 这是有原因的，他们可能不知道这是什么，但是找出它是您的工作。祝你好运。;）