这本书是讲述关于开发项目的问题的。本书特别教师了开发项目的前期阶段，告诉了我们前期部分应该是怎么样的。
通常，在一个开发项目的初期，在我们想要投入自己更多时间之前，我们总会想要知道做这件事究竟会得到什么。那么，除非我们知道自己想要些什么，究竟永远不会确定会得到什么样的结果。
如果雇佣其他人来帮助自己开发，你就需要向他们描述你的构想，这种描述就叫做问题陈述或需求集合，这也是这本书所要探讨的主题。显然，需求是非常重要的，因为如果连我们自己都不知道或者说不起自己的需要，那么我们获得成功的机会自然会降低不少。
第一章——方法论是不够的
why？我们使用的通常是需求映射图，而不是需求本身，这就是需要“探索”的原因。
when？如果你总是使用映射图而不是实际地形本身，那么就需要确保对你所使用的不同映射图有一个共同的理解。在需求过程中，“你能够解释一下你的符号系统？”这个问题应该是司空见惯的，任何人不要因为问这个问题而感到愚蠢或不肯合作。
how？1.不要把所有的困难部分交给其他人负责，就想那个“万无一失蟑螂杀灭仪”一眼；2.在引进新方法是随时准备变化，特别是不要低估某些人为了配合新方法或新的符号系统所带来的浑南；3.认识到人是各不相同的，每一种映射方法都会以不同的方法要求每个参与者。接受这种差异，不要试图强迫人们与之或者因为其“愚蠢”而轻视他们；4.为了不遗漏任何人，在每一个步骤确定所有人都能读懂映射图；5.如果你发现自己由于符号系统的细微差别而变得情绪暴躁，请机制映射图不是实际图，而且世界上不存在一种完美的翻译。
who？所有使用映射图的人，尽管对每个映射系统来说，不是所有人都会一样能干。那些比较能干的人有责任来帮助那些相对能力较差的，并且千万不要用一种卡起来是屈尊的姿势去做。
第二章——在陈述需求中的含混性
缺少需求、含混的词语、无异中一如的假设都会造成需求中的含混性。
why？攻击含混性是因为含混性需要成本。
when？尽可能早地攻击含混性，因为即使你最终消除了它，在开发产品的早先阶段改正所需的成本比以后改正的成本少的多得多。
how？如何攻击含混性是权属的主题。但首先，一定要记住用一种非常有趣的方法来使用你的智慧——探索应该是一种乐趣。
who？即使我们自己。
第三章——含混性的来源
why？把回答来表并在一个柱状图中显示其分布的最重要的原因并不在于柱状图本身，而是气候的能找出含混性出现的来源的讨论。解释错误倾向于产生分离的聚类，而观察和会议错误倾向于在每一个聚类内部的变化中展示自己。
试着逐字会议需求或问题描述，这将能够解释那些必须在一个成功的需求被开发出来之前清楚屌的含混性。
when？使用任何一种含混性投票的结果的聚类启发来帮助分离其来源，要远胜于只使用其投票数量。
how？10对参与者需求文档某些部分的解释进行提问，并且把结果聚合成类；2.通过徐闻每一类的人们的想法分析这些聚类；3.在人么看事物有差别的时候，分离观察错误；在人们不能记住他们所看到的时候，分离会议错误。这些可能发生在同一个聚类内部；4.位计算聚类之间的分布，可以请参与者回忆那个他们认为的被问的问题，当然不能给他们看一遍。这个启发用于找出解释的含混性。5.在人们讨论其观察之后，其变换应归于新的问题解释，而不是改变回忆或提高了观察力。
who？任何需要理解需求的人或此类人群的代表都能够有效的参与到这个练习中来找出需求的来源。
第四章——可靠并不真实的直接问题的用法
why？你需要其他的工具和技术来辅助直接提问，因为为了获得成功，完全会接提问的方法将需要一个完美的人。
when？无论你在什么时候提出直接问题，你都需要工具来帮助你选择在决策树的谋者地方，那个直接问题是有意义的，并检验大难的意义。
how？决策树模型本身是一个用于辅助直接提问的显著的工具。另一个工具是支持寻找一些去问来说服客户除了问他们直接问题之外还有更多的事情要做。
who？任何提出或被提问到直接问题的人都应该理解人类的局限性，并指导获得信息的其他方法。