什么是初始阶段 大多数项目需要一个简短的起始步骤，在该步骤中要考虑以下几类问题：
1、项目的设想和业务案例是什么？
2、是否可行？
3、购买还是开发？
4、粗略估计一下成本：是一万还是十万美元，还是上百万美元？
5、项目应该继续下去还是停止？
想要定义设想并大致得出所需的预算，就必须研究需求。但是，初始阶段的目标并不是定义所有需求，或产生可信的预算或项目计划。
对于是否存在过于简化的风险，其理念是，就未来新系统的总体目标和可行性而言，只进行足以形成合理判断的调查，并能够确定是否值得继续深入研究即可，而深入研究室细化阶段的工作。
大多数需求分析是细化阶段进行的，并且伴以具有产品品质的早期编程和测试。
因此，大多数项目的初始阶段的持续时间相对较短，例如耗时一周或几周。实际上，在许多 项目中，如果初始阶段的时间超过一周，那么“初始”就失去了它的意义，因为初始阶段只需确定这个项目是否值得认真研究，而不是真正去深入进行研究（这项工作应留待细化阶段进行）。
用一句话来概括初始阶段：
预见项目的范围、设想和业务案例
用一句话来概括初始阶段要解决的问题：
涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究
在迭代开发和UP中，初始阶段的预算和计划是不可靠的。它只不过提供了对工作量的粗略估计，帮助人们决定是否将项目继续下去。
初始阶段的持续时间 初始阶段主要是为项目目标建立一些初始的共同构想，确定项目是否可行，并决定是否值得进入细化阶段加以认真研究。如果预先就决定项目必须进行，并且项目显然是可行的，那么初始阶段会更加短暂。这时候，初始阶段可能只包含第一次需求研讨会，并为第一次迭代制定计划，然后就快速地进入细化阶段。
初始阶段会创建的制品 PPT2列举了一般在初始阶段（或细化阶段早期）会创建的制品以及各个制品所解决的问题。后续几章将详细解释其中部分制品，特别是“用例模型”。 迭代开发的一个重要观点是：在初始阶段只完成其中部分制品，在后继迭代中对其进行精化。而且，除非认定某制品很可能具有实用价值，否则不应该创建该制品。因为是在初始阶段，所以相关的研究和制品内容都不多。
在初始阶段可能要进行一些编程工作，其目的是创建“概念验证”原型，（典型的）通过面向UI的原型来澄清一些需求，以及为关键的“显示阻塞”技术问题做一些编程实验。
是否意味着大量的文档 记住，这些制品都是可选的。要有选择地创建对项目确有价值的制品。因为这是迭代开发，所以重要的不是在初始阶段创建完整的规格说明，而是形成初始、概略的文档。这些文档在细化迭代中精化，以便响应由早期编程和测试得到的极有价值的反馈。
同样，创建制品或模型的重点不在于文档或图本身，而是其中蕴含的思想、分析和前期准备。这也正是敏捷建模的观点：建模的最大价值是增强理解，而非记录可靠的规格说明。
还要注意的是，可以在以后的项目中部分重用以往项目中的制品。一般在不同项目中，风险、项目管理、测试和环境这些制品都可能存在大量相似之处。所有UP项目都应该用相同的名称，以相同方式来组织制品（例如风险列表、开发案例等）。这样就可以方便地从以往项目中找出能够在新项目中重用的制品。
何时知道自己并不了解初始阶段
1、当认为大部分项目的初始阶段会持续几周或更长时
2、在初始阶段试图定义大部分的需求时
3、期望初始阶段的预算和计划是可靠的
4、定义架构（应该在细化阶段以迭代方式来定义架构）
5、认为正确的工作顺序应该是：1>定义需求 2> 设计架构 3>实现
6、没有业务案例或设想制品
7、详细编写所有用例
8、没有详细编写任何用例，与之相反，应该编写10%~20%的用例以便获得对问题范围的真实认知
初始阶段中有多少UML初始阶段的目的是收集足够的信息来建立共同设想，决定项目是否继续进行，以及项目是否值得进入细化阶段来认真研究。 初始阶段更关注对基本范围的理解以及10%的需求，这主要是以文字方式表达的。实际上，本书就是如此，大多数UML图将出现在下一个阶段--细化阶段