一场战争开始前，最重要的就是情报。正所谓知己知彼，方能百战百胜。而软件开发前最重要的一点，莫过于用户需求的分析。做好了需求分析，才能有的放矢，避免开发出为开发而开发的软件。
如何准确的获取需求呢？书中给出以下步骤：
- 获取和引导需求（Elicitation）
- 分析和定义需求
- 验证需求
- 软件产品的生命周期中管理需求
软件的需求可以划分为：对产品功能性的需求、产品开发过程中的需求、非功能续期、综合需求等
值得注意的是软件的需求不仅仅包括用户的需求，还包括顾客、市场分析者、监管机构、集成应用商、软件团队、软件工程师等软件利益相关方的需求。软件开发中不一定能同时满足所有相关方的需求，需要注意优先级
用户的需求需要人和人之间的准确沟通，在软件开发的沟通链中，用户真正的想要的需求往往会发生变形，导致软件最终开发出来的并不是用户真正想要的。如何准确掌握用户的需求？书中列出以下方法：焦点小组、深入面谈、卡片分来、用户调查问卷、用户日志研究、人类学调查、眼动跟踪研究、快速原型调研、A/B测试等。但是也要注意在应用用户数据改进时，避免掉入吹毛求疵的陷阱。
如何在做“实用并创新的项目”中有理有据的说服别人？避免“二拍”方法（拍脑袋>拍胸脯>拍屁股）沟通？书中给出了NABCD模型。N是Need ,准确找到需求。A：Approach，靠谱的做法解决用户的问题。B：Benifit，给用户带来了什么好处？C: Competition，和竞争方相比，我们有什么优势，又有什么劣势？D：Delivery 如何把创新产品交到用户手中呢？
在得到需求之后，下一步就是功能实现。功能实现可以分为杀手功能/外围功能、必要需求/辅助需求四个象限划分。
划分好功能后，下一步就是制定计划，在计划制定和实施过程中，也需要准确估计计划实现需要的时间。首先要区分好目标、估计和决心。估计各项目所需要的时间，看似容易却不简单。如果混淆了三者，后果会很严重，历史上的“大跃进”就是典型的例子。软件项目的估计可以从自底向上和回溯两个方面来看。
项目要一点一点的做，感觉无从下手的项目要逐步分解成可以操作的工作。书中列举的常用的分而治之的方法就是WBS：Work Breakdown Structure WBS的目的就是从最终的产品开始，将项目分解成小型、具体的小件，“直到WBS的使用者（开发团队、接收方）达到共识。”