需求，是人们的期望。探索需求是寻找人们的期望的过程。探索需求的目的是试图找出人们对（待开发的）产品的期望。我们的产品，毋庸置疑，应该是有用的产品，还应该是新的产品。
开发是把人们的期望转化成一种能够满足其期望的产品的过程。
经过前辈们无数次的实践、分析总结出很多很多经验，可以说已经形成一套有效的软件开发方法，有人能会认为按照这一套思想就可以轻松完成所有的软件开发，但明显只是很荒谬的。CASE和CAD工具能万无一失地完成它们的工作，但是要正确地使用他们确实关键所在即为处理那些形式化所不能触及的地方。而在这个过程中，符号是一个很重要的存在，在一个映射图中，每一个符号的确定都是需要深思熟虑的，因为文档要给很多业外人员去看或者使用，这就会对此有很高的要求。但是跟用士兵分析地形一样，地图并不代表真正的地形，这正从侧面说明了图和符号并不与实际项目中的内容完全吻合，一切工作的前提都是要必须明白当前内容的目的，并从一定程度上规避可能会犯的错误。
在开发项目中，出现含混性的另一个原因是有一些非专业人员要求加入到复杂产品的设计中。绝大多数使用者更愿意尽可能少的学习产品设计，但是仍然会期望在需求过程中摆出他们的愿望。由于符号系统的不统一，使用者很多时候都是一副无知的表情。如果符号系统很简单的，同时又可以解决复杂问题，那肯定是建两全其美的方法，但是没有人愿意为这方面做无用的投资。
在映射系统中的特殊符号与其支持者所坚信的内容相比文笔会显得更重要。每一种符号系统都有利弊，还有各种各样的辅助工具，但是与映射系统关系最大 的工具是人的头脑。映射图最重要的特性是能够让所有相关的人员能够理解。
软件是以人为中心的，所以说需求也是以人为中心的，而在使用一些工具的时候往往会忽略人的因素从而导致含混性。由于需求阶段所发问题越多，以后付出的成本就会越少，所以说含混性是非常重要的。整个需求与系统范围边界是有相似之处的，只要划定了什么是我们的需求，什么不是我们的需求，那就会很容易地，感觉这个也相当于是把复杂的问题简单化地过程，而基本上所有的问题都会是这样一个解决的模式，这也说明了事物之间的共性。而且，要在探索中发现乐趣会别有一番风味。
含混性是由于对事物的不同理解而产生了不同的解释，在对于含混性难以分析出所以然的时候，可以采取一定的标准将大量的数据进行分类，从而找出其中的共性和特性，弄清含混性的来源，才能进一步进行对它的消除。另一方面，对于一个问题的描述不同也是一个很容易产生含混性的因素，往往由于人的文化背景、习惯和其他诸多因素的不同，会导致在对同一件问题进行描述时而产生不同，这往往也会给整个项目的需求过程带来十分重要的影响。
可靠但不真实的直接问题的用法。直接提问并没有错，但是没有其他工具和技巧辅助的直接提问对于正确的获得需求是永远不够的。决策树模型是一种用于弥补直接问题的工具。问题的次序在实践中和问题本身一样重要，所以需要一个有判断力的次序。仅仅因为我们知道某些事情并不意味着我们就能做好我们的所知和在手边的需求之间的关联。实际探索需求中，需要与客户的不断沟通来表达人类的局限性以达成一种双方都能接受的结果。
决策树模型是一种用于弥补直接问题的工具，这是一个行之有效的方法。在有含混性的问题时，将几个假设列举出来在进行筛选，一步一步重复操作，在发现出错时及时发现及时改正，直到找到正确的解决方案。要以客户的需要为目标，直到找到满足客户需求的那个叶子为止。而正确的次序问题也是十分重要的，当次序问题摆正之后会给整个过程带来很大的进展。而且在前期一定要话费很多精力，因为越靠近树根的地方越容易出错，在前期的方向对了会给后期工作带来很大的便利。但仅仅因为我们知道某些事情，并不意味着我们就能做好我们的所知和在手边的需求之间的关联，是因为现实生活比我们想象的要现实。