这是《需求分析与系统设计》的最后一部分，通过阅读的过程，渐渐的清晰了需求重要性，在需求分析阶段更加重要，在获取需求信息之后，还需要进行详细的分析，而且还要经过一些软件分析过程，经过建模分析，使过程更加明了。业务流程也更加顺畅。
在软件需求规格说明中，需要用图形和其他形式化模型来说明需求，为了完整地说明一个系统，有必要采取多种模型。UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作。规格说明的过程是迭代增量式的。对成功的建模来说，使用case工具是必须的。需求规格说明产生三种模型：状态模型，行为模型，状态变化模型。需求规格说明涉及需求确定期定义的客户需求进行严格的建模，重点放在那些系统将要提供的所期望的服务上。
体系结构设计解决多层物理体系结构及多层逻辑体系结构的有关问题。体系结构设计具有物理和逻辑两个方面。物理体系结构设计关注部署方案的选择及系统的工作负荷在多处理器上的分布。物理体系结构解决客户机和服务器问题，以及粘接客户机和服务器所需要的任何中间件问题。它将处理构件分配给计算机节点。大多数企业信息系统采用分层体系结构，相对于对等体系结构，分层体系结构定义计算层次。软件开发者知道创建小系统的困难是不能与大型解决方案的困难相比的。小系统易于理解，实现和部署。大型企业系统由相应随机事件的大量对象组成，这些随机事件会引发相互关联的操作混乱。没有清晰的体系结构设计和严格的过程，大型软件项目注定要失败。在迭代和增量软件开发中，使用技术细节不断地对模型进行细化，一旦技术细节考虑软件/硬件，分析模型就变成了设计模型。系统设计包括两个方面的主要问题:系统的体系结构设计和系统中程序的详细设计。体系结构设计是从系统的模块方面对系统进行描述，包括确定系统的客户机构件和服务器构件的解决方案策略。体系结构定义类与包的分层组织，将进程分配给计算设施，复用和构件管理。
计算可以用活动图建模，对象的交互可以用顺序图或者通信图来说明。行为规格说明提供系统的操作视图，主要任务是定义应用领域中的用例，并确定在这些用例的执行中将涉及哪些类，标示类操作和对象操作之间的信息传递。虽然对象交互也会引起对象状态的变化，但在行为规格说明中，我们只定义关于系统的冻结状态的操作视图，对象状态的变化将在状态变化规格说明中明确地描述。系统的行为，就是它展现给外部用户的，通过用例来描述，用例模型可以在不同的抽象层次上生成。它们可以将系统看做一个整体，说明开发中的应用所具有的主要功能单元。在分析期，用例通过关注系统做什么或者应该做什么来捕捉系统需求。在设计阶段，用例视图可以用来说明系统将要实现的行为。由用例制定的行为，要求通过计算以及对象间的交互来执行一个用例。
经过系统设计，在系统测试阶段也是与需求密切相关的。质量与变更管理活动跨越了整个开发生命周期。它们需要专门的文档，例如测试计划、测试用例文档和故障与改进文档。测试文档确定了测试需求，然后再将测试需求连接到用例文档中的用例需求。质量管理有两个非常正交的方面。用于质量控制机制时时被动的，但是用于测试驱动开发框架时，它可以是非常主动的质量保证活动。质量控制与系统服务和系统约束测试有关。系统服务测试可以是静态或动态测试。静态测试包括走查和审查——质量保证实践中的正式评审会议。而动态测试可以是针对规格说明的测试针对代码的测试。系统约束测试包括大量相关的不同测试。通常提出的变更请求要么是处理故障要么是处理改进。在变更管理工具中可以提交变更请求并追踪开发人员对它所做的处理。变更管理工具的主要功能就是建立变更请求与其他系统制品——特别是测试需求与用例需求——之间的可追终路径。