本书第Ⅳ部分和第Ⅴ部分分别是需求管理和需求工程的实施：
需求管理包括项目过程中所有保持需求协议的完整性、准确性和流通性的活动。需求管理的四大核心活动有版本控制、变更控制、需求状态控制和需求跟踪。可以将所有这些信息包含在一个需求管理过程描述中。或者，写单独的版本控制、变更控制、影响分析和状态跟踪过程。这些过程适应于整个组织，因为每个项目团队都会做这些通用任务。
流程描述应当确定负责每个需求管理活动的团队角色。项目的业务分析师通常对需求管理负有领导责任。业务分析师（BA）建立需求存储机制，定义需求属性，协调需求状态，跟踪数据更新并监控变更活动。流程描述中还应当指明谁有权修改需求管理过程，如何处理异常及遇到阻碍时如何升级。
需求开发活动包括获取、分析、描述和验证软件项目需求。需求开发的交付物包括业务需求、用户需求、功能/非功能需求、数据字典和各种分析模型。在这些交付物经过评审且核准之后，这些条目的任何已定义子集都可以组成需求基线。需求基线是干系人认可的一个需求集合，通常作为某一具体的计划发布版本或开发迭代的内容。项目针对交付物、约束、排期、预算、转移需求和合同可能还有其他协议。
确立一个需求集合的基线之后——通常是经过评审和核准之后——需求就会置于配置管理（或变更管理）之下。接下来的变更只能通过项目定义好的变更控制流程进行。在基线化之前，需求还在演进，所以没有必要针对此时的修改施加流程限制。基线可能由某一特定SRS（针对整个产品或者某一单独发布版本）中的部分或所有需求组成，或者由存储在RM工具中一组指定的需求组成，或者由敏捷项目某一迭代中一组达成一致的用户故事组成。
需求开发（RD）工具和需求管理（RM）工具提供的解决方案可以克服这些不足。RD工具可以帮助获取项目的正确需求并判断它们是否写得很好。RM工具可以帮助管理需求的变更、跟踪状态并跟踪需求到其他项目交付物的链接。做小项目的团队也许无法用到任何需求工具，只用文档、工作表或简单数据库来管理需求也行。做大项目的团队可以从商业需求工程工具受益良多。但这些工具无法替代经过精心定义的所有团队成员在开发和管理需求时都要遵循的流程。已经有有效方法但需要更高效率时再使用工具也不迟。不要指望工具能弥补业务分析和需求工程流程、培训或者经验的缺失。
无论何时，当人们被迫改变其工作方式时，本能的反应都是“这对我有什么好处？”然而，过程变革的结果并不总是美好的，因为这涉及每个人的既得利益。一个更好的问题是“这对我们有什么好处？”这更可能得到合适的回答。每个过程变革应当为项目团队、开发组织、公司和/或客户提供明显的收益。要求干系人花更多时间帮助创建更好的需求，因为他们唯一想到的是自己今天要做更多工作。但假如他们了解此投入可以换来项目后续的返工明显减少、支持成本显著降低以及客户价值显著提升，就会更愿意眼下多花一些时间。