一个程序员最需要的就是反思，而往往反思是非常困难而且非常痛苦地一件事，因为你要打破自己以往的观念和想法，从中找到自己的缺点进而改正。
需求问题是软件开发过程中紧紧围绕的一个巨大问题，乃至整本书都在围绕着这个话题进行讨论。能否获得需求是软件成败的关键。
以往以来人们通过各种方法进行软件的需求分析，如结构化分析方法，面向对象方法，面向问题领域分析方法等，其成果能通过case工具，uml工具来完成。其中uml工具将需求分析成
果自动化转化成系统设计成果方面尤为突出，解决了长期困扰软件开发中需求分析和系统设计之间失真的问题。在我们日常的学习中，uml模式图也有为关键，大二上学期比较系统的
学习了uml工具，对其中的各类也有了比较简单的了解，在如今王辉老师的课上，各种软件的设计模式对应着相应的类图，而能不能分析好画好这些类图，当时学习的uml起到了至关重要的作用，学习真是一环扣一环！而在用例的描述中，用例描述完整性和准确性不够这是uml的一项缺点，还有项目的范围和目标的定义是在用例工作开始前需要先完成的工作，uml并不支持，需要我们进行切入的探讨与分析，在项目开始之前，如果不能找到一个确定的范围，就好像有方枯地上打井，打到地也不一定能打出水来。
人们的学习就好像是在画一格一格的圆，学习的越多，圆画的越大，事情往往也会变得越来越难，但无论遇到什么事情都需要有较好的心态去面对，不能被困难所打倒，也不能在困难面前过于自负，反而耽误了解决问题的关键时期。人到不惑之年的时候当听到有人说这件事很简单时，第一直觉是这件事就不简单。人们对做事的原则有个很经典胡总结：“复杂事情简单做，简单事情重复做，重复事情用心做。”这便是对心态的完美表述，人无祸而不立，树无根而不生。
软件的建设更需要软件规格胡说明。
书中所言，往往软件需求规格说明是软件开发者的宠儿，是软件需求的核心，开发人员通过软件需求规格说明来了解用户想要什么，想实现什么；而实际上软件需求规格说明并不是软件需求的核心不是软件需求工作的目标，真正的核心是业务需求，因为软件分析从业务需求分析开始，在用户需求分析的基础上进行的功能需求分析的非功能需求分析，软件需求分析的工作成果是软件需求规格说明，而软件需求规格说明主要是由功能需求分析和非功能需求构成。因此软件需求规格说明是真正软件需求的核心。
离开了业务，软件什么都不是；大部分人可能对此话嗤之以鼻，一般说的绝对的话往往是错误的，诚然我第一次听到此句也是如此的心理，但仔细想来，如果一个软件没有业务需求，便会像无的之矢，茫茫乎不知所终，最后沉默在软件的大潮里。现实中大家多采用场景卡片，系统原型，用例图，用户需求文档来获取用户需求，来让用户确定这是他想要的。从而确定自己的业务目标，不是说不可以，究其根来方法都是为目的来服务，只要找到所要追寻的目的多想些办法，多采取些措施又未尝不可。
形式逻辑的演绎方法可以用来解决需求的完整性问题，形式逻辑的论证方法可以用来解决需求的准确性问题。
在找寻业务根源过程中，常常会面临各种各样的变化，世界因为变化而精彩，而编程与软件开发如果面临各种各样的变化，那程序员肯定会头痛无比，哪怕多一点差别，程序的代码可能就会多出几百行。需求变化的根源往往在于客户，客户以为开发人员是万能的，自己想像的程序员一定会给自己完成，正是由于单方面的不了解往往会产生许多分歧，耽误开发的进程；客户服务对象是变化的根源，明确双方任务与能力，明确各自的初衷，往往会消除很多不便。