回顾过去的几年，无论是政府、企业等各类组织都充分认识到信息化的重要性，都把信息化手段作为一个实现跨越式发展的重要抓手，随之而来的是一系列硬件设备采购、网络系统建设、软件系统开发等项目。这些项目最为人诟病的当属软件项目。软件项目不成功的原因中，属于需求分析造成软件设计的错误和缺陷约占软件失败的64%，而属于程序代码的错误仅占软件失败的36%。可见，软件需求分析是决定一个项目成败的关键。
“软件需求不完整、不准确、描述不清晰、总变化”是在大多数失败的软件项目的原因分析报告中常见的描述。我们总是主观的认为软件需求工作是一个简单的事情，开个会写写文档就OK了，但是，这么简单的工作为什么总是做不好呢？我们需要反思问题到底在哪。
①软件需求的核心
软件需求规格说明只是软件需求工作的目标而非软件需求的核心，软件需求分析从业务分析开始，在用户需求分析的基础上进行的功能需求分析和非功能需求分析，软件需求分析的工作成果是软件需求规格说明，软件需求规格说明主要是由功能需求分析和非功能需求构成，这说明了软件需求是什么。
②完整性和准确性
用户说的需求并不一定完整、准确，需求分析人员长期以来无论采用场景卡片、系统原型、用例图、用户需求文档哪一种方式来获取用户需求，目的是让用户确认这是他想要的。但是实际上，用户就算说了是而获取到的需求也只是一部分，还有很多问题不能确定。用户只是提出问题的人，而对问题的深入研究是需求分析人员的重要工作之一，所以需求分析首先要从思想观念上转变过来，是需求分析人员根据用户提出的问题，在对用户业务资料和现场调研的基础上，用逻辑思维方法和系统科学方法对用户业务加以分析和研究，找出业务的内在要素、结构、关系、然后告诉用户业务的整体。
③需求变化的根源
需求变化的发起方可以是客户也可以是开发组织，变化会带来一系列文档、代码的变化，工作量也会随之增加。找到需求变化的根源，才能很好地控制需求的变化，才能为需求变化预留充足的余量。需求变化的源头在于客户业务所面对的服务对象的变化，将客户业务、对象业务和软件系统同时作为研究对象。变化是具有相对不变性，这个相对是具有一定时间性的，把这个时间设定为一个期限，那么在这个期限之内是相对不变的，这就是控制需求变化的法宝。
④软件需求的描述方式
自然语言的语义二义性一直被认为是使得需求分析和软件开发人员造成认识不一致的根本原因，但其实并不是这样。需求分析结果在软件的各个环节都会用到，而这就涉及到不同知识背景的工作人员，所以应具有普遍可认知性。大量的需求分析报告使用自然语言正是它具有普遍可认知性，导致软件开发失败的根本原因还是需求分析的指导思想、分析内容、分析出发点、分析粒度、分析方法等方面出现了问题，自然语言的二义性可以通过表格、图形等方法减少。
经过反思之后，我们应对软件需求分析工作重新定位，在本书中，作者给出了一种不同于以往的瀑布式、迭代式开发模式思想的星型环装开发模型。上一环节成果是下一环节的输入，需求分析是下一环节的约束。需求分析应将概要设计详细设计、软件编码等环节都作为自己的研究对象，所有与软件开发环节相关的约束信息是需求分析的文档中应包含的内容之一。