UP具有三个公理：
- 用例和风险驱动
- 架构中心的
- 迭代和增量的
用例是捕获需求的方法没因此我们可以准确地说，UP是需求驱动的。
风险是另外一个驱动，因此如果你不主动攻击风险，风险就会主动攻击你。UP通过风险分析预测软件构造。然而这是项目经理和架构师的工作。
开发软件系统的UP发送方法是开发和演进一个健壮的系统的系统架构。架构描述了策略：系统是如何被分成组件，这些组件是如何交互和部署在硬件上。显然，高质量系统架构将产生高质量的系统，而不是很少谋划的，堆砌在一起的源代码的集合。
每个迭代包含正常软件项目的所有元素：
- 计划
- 分析和设计
- 构造
- 集成和测试
- 内部或者外部发布
在每个迭代中，有五个核心工作流，说明需要做什么以及需要什么工作技能。除了这五个核心工作流之外，还有其他工作流。如计划，评估以及与特定迭代相关的任何工作。然而，UP不包括这些。五种工作流是：
- 需求---捕获系统应该做什么
- 分析---精化和结构化需求
- 设计---用系统架构实现需求
- 实现---构造软件
- 测试---验证实现是否如期望工作那样
以上来源<<UML and the Unified Process Practical Object-Oriented Analysis &Design>>中文版（机械工业出版社）