获取信息的第一步就是定义功能，在这个阶段描述产品是为了做什么的动作。假设是决策树的根源，那么客户说想要什么东西存在就是问题声明的提出。而客户说产品能够实现什么功能就是指他的测试功能。在描述功能方面，需要记录所有用户想要的功能，然后进行理解，不能记录记录用户不想要的功能。做到这些也需要一些技巧，首先要记录所有潜在功能，；理解明显的隐藏的以及装饰性的功能，识别未注意到的功能。实用功能启发的方式来进行识别功能，创造归功能的一直处理方法。
属性是客户希望的特征，要将属性和功能加以区分，属性不同的产品有可能功能会十分相似或相同。同一个属性可能会限定不止一种属性，此外在分析的时候将属性分类为必须、需要和忽略，这样可以有效地判断用户的期望。一个约束就是置于一个M类型属性之上的强制性条件，为了让最终的设计方案能够被别人接受必须满足每一个约束条件。每一个系统会存在他的边界，而我们在考虑约束条件时也要把它考虑在内。
偏好是附加在属性上的一种愿望，但却是可选择的条件。在需求中，偏好这个因素就会让开发者从备选方案中选出最好的最符合条件的方案，是我们的方案更好。往往在设计者把产品交付给使用者的时候，用户才会发现自己的偏好的存在。但是偏好不应该被过度使用。在确定这个因素的时候要清楚地将每个偏好区分开来，否则就会将两个或者多偏好混在一起，难以分辨。为了使编号变得可量化，可以采用多感官的信息展示，将能够收到所有信息的人的比例作为量化标准。有约束的偏好往往会变成价值，价值图可以帮助设计者分析每一种偏好的作用力来使自己的工作变得更有方向性。
失望和满意的差别不在于交电费的成果，而在于交付的成果与期望的匹配程度有多大。由于人不是完美的，人并不都是有逻辑的，人们对事物的理解程度不同等一系列因素，需要额外的一步来限制期望。为了计算认为因素的影响，可以使用希望限制的方法：产生专门的期望列表、产生期望列表、限制期望、让可能性保持公开。
然后项目需求阶段就进入了尾声，经过将含混性进行度量、进行技术复审、衡量满意度、测试用例、学习已存在的产品、达成协议几个阶段之后就可以结束了。首先，可以使用投票的方法进行含混性的测量，可以针对不同的问题对参与者进行调查，将三种含混性问题描述含混性、设计过程含混性和最终产品含混性加以明确并进行处理。复审阶段，技术附身为项目复审提供信息，项目复审还要考虑非技术主题的信息；附身的结果可以对需求调整以匹配资源，或是对资源调整以匹配需求。复查报告也要写的完整准确、为相关工作作为可靠的基础，为跟踪进程的目的而可度量，因为有了复审才能对于工作进度有一个可靠的衡量方法。
接下来可以进行用户满意度测试，为了避免用户不满意，需要从设计开始就一直测量用户满意度。另外，测试本身也可以作为我们寻找属性的工具，和设计者与用户交流的工具，它可以作为一个贯穿始终的内容来帮助设计者开展工作。接下来可以进行黑箱测试，用来获取项目可以做到的、实现的有哪些，黑箱测试的结果能够作为随后系统和产品测试的基础，所以这一步工作是必须的，为了测试开发到现在的任何需求的完备性、准确性、以及简明性也需要进行黑箱测试。
几乎没有“新”的产品完全都是新的，因为设计的所有产品几乎都会被拿来与已经有的东西作比较。要将自己的产品与现存产品做比较，看在产品中缺少了哪些功能，在自己的产品中是否有相应部分的实现。比较产品提出一份在新需求中可能遗漏的功能列表；然后访谈一些旧产品的使用者，提出一份当前系统中不见了的功能，再对自己的产品需求进行更正。在决策的时候，需要进行选择，假设和强迫接受，在避免错误假设的前提下将决策转化为协议。需求过程开始于含混行，最终却一定要结束于协议。