第五篇 开发篇
很多时候不同的是具象，相同的是抽象。善用抽象可以透过复杂的现象看到简单的本质。需求规划是以业务为核心的，需求开发是以技术为核心的，但是它们是基于业务事项同一个抽象映射下展开的。需求分析时要知道业务系统和软件系统两端的语境并知其语素的转换和映射关系。需求获取无须与用户进行交互，只要仔细阅读需求规划报告，有问题时与需求规划人员沟通就可完成需求获取工作。需求构架师时客户业务和用户业务的代言人需求获取时需求开发工作的第一个环节，也是连接需求规划和需求开发领域的中间环节，软件获取的关键在于需求获取人员需要熟悉业务系统和软件系统两端的知识。需求获取上承需求规划，下启需求分析。需求获取的难点是如何选取合适的软件系统的要素来取代或改进业务系统的要素。需求获取不是简单的对需求规划的照搬；需求规划已为需求获取提供了足够的业务需求。
编制项目视图和目标的工作要点是“基于需求规划成果、遵照工作模板编写、引入软硬件技术支持”。项目视图和目标的编制是为软件系统确定范围和目标，视图是事项和方向的集合，目标是方向明确下的路标。需求获取是从需求规划大量成果中选取本次软件系统开发所需要的，项目视图和目标的编制的大部分信息可以继承与需求规划。项目范围有时比项目目标要重要得多，不要再让新的软件系统成为信息孤岛，系统关联分析的工作的重点在于人、设备、系统与待建系统间的交互关系和交互内容的分析。系统关联关系的工作成果由系统关联图和系统间接口模式文档和系统间交互模式文档三部分组成。
第六篇 管理篇
需求工程分为需求规划、需求开发、需求管理。需求管理的工作目的是在客户和开发人员之间构筑一个需求基线，确保需求工程全过程的质量、成本和进度是需求管理的目标。需求约定是需求管理的前提，依据需求约定进行计划、检查、调整是需求管理工作的具体活动。需求管理的关键过程领域不在于收集和分析项目需求，而是假定已收集了软件需求或已由更高一级给定的需求。CMM过程能力成熟度模型对需求管理是一个有用的指导，管理工作是让务虚工作和务实工作达到有机结合后就可以实现“无为而治”这一管理的最高境界。
版本号是采用量化方式来解决同名而内容不同的一个手段，某个内容的版本号可以使协同的各方人员在同一个内容上进行工作。变更是对需求文档中的需求内容进行增加、修改、删除、由难变易或由易变难，这些变更提出都是常见的，一项变更事项会引发一连串与其相关事项的变动，先判断变更的真伪，再判断变更带来的工作事项完整性。“木桶定律”是管理变更要遵循的一个定律，变更控制需要与变更相关的各方共同参与，群策群力。变更控制过程可以使多方人员的协同从无序变成有序，工具是可重复方法的固化，工具比人更能严格的履行职责。
跟踪能力本质上是保证正确的因有正确的果的能力，跟踪的动机就是在事前建立起需求全过程的关系链。
第七篇 组织篇
一个组织的价值在于能给客户提供有价值的服务，建立需求分析体系是一个落实这一理念的抓手。需求分析部门是具体承担和管理软件需求分析的部门，是业务部门和技术部门的桥梁。产品规划部门既是一个业务部门，也是一个技术部门，是介于业务部门和技术部门中间的一个特殊组织。