从头读下来，第一眼看到，成功的软件都是一样的，失败的软件却各有各的失败处，我们编写程序的最终目的是什么，不是让别人知道自己编程能力有多厉害，只要能卖钱就好了，就算你使用的语言已经跟不上版本了，但是最终结果实现了就行，而我们失败的软件问题是什么没有人在乎，只有自己，我们的软件出了什么问题，它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败，所以，软件需求的分析十分的重要。
作者的亲身实例告诉我们，需求是多么的重要，改了百十行代码，东家不满意，又得改来改去，结果小组的人最终只得罢工，这似乎是软件工程程序员的通病，所以很多人不乐意进行代码的设计，但是，，“客户对需求改来改去的真正原因是什么呢？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了”。原文作者自己是如此总结的，所以说，软件需求分析对于一个程序员来说是多么的重要，只有真正明白了别人心中想要的程序，才能做出来最完美的程序。
但是，又不能被客户的需求牵着鼻子走，毕竟我们是专业人士，对自己的本职工作还是比别人了解的，我们知道如何才能真正实现一个软件，如果一味地听从东家的，不一定会成功，软件需求分析是我们做的，我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。
再说，一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的，做程序分析是事无巨细的，一旦程序完成，在更改角色就比登天还难，所以在任何情况下，都要做好完美的调查，但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
我们应当怎样做需求调研：初识
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险
我们应当怎样做需求调研：拜访
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求
我们应当怎样做需求调研：研讨会
业务研讨会比较灵活，应该合理组织，一定要注意两点：有效抑制个性化差异、分模块组织专项研讨会
我们应当怎样做需求调研：需求研讨
与客户探讨业务需求，对一些技术难以实现的需求，我们应当提出合理的解决方案