初始不是需求阶段
初始阶段时建立项目共同设想和基本范围的比较简短的起始步骤。为了在随后的细化阶段能够开始编程，它将包括对10%的用例进行分析、关键的非功能需求的分析、业务案例创建和开发环境的准备。
什么时初始阶段
大多数项目需要一个简短的起始步骤，在该步骤中要考虑以下几类问题：
- 项目的设想和业务案例时什么？
- 是否可行？
- 购买还是开发？
- 粗略估计一下成本：是一万到十万美元，还是上百万美元？
- 项目应该继续下去还是停止？
想要定义设想并大致得出所需的预算，就必须研究需求。但是初始阶段的目标并不是定义所有需求，或阐述可信的预算或项目计划。
对于示范存在过于简化的风险，其理念是，就为了新系统的总体目标和可行性而言，只进行足以形成合力判断的调查，并能够确定是否值得继续深入研究即可，而深入研究是细化阶段的工作。
大多数需求分析是在细化阶段进行的，并且伴以具有产品品质的早期编程和测试。
用一句话来概括初始阶段：遇见项目的范围、设想和业务案例。
用一句话来概括初始阶段要解决的主要问题：涉众是否就项目设想基本达成一致，项目是否指导继续进行认真研究。
一下类比是否有帮助
在石油行业中，勘探一个新地域时要经历以下几个步骤：
- 确定是否已有足够的证据或业务案例来证明可以进行勘测钻探（初始阶段）。
- 如果有，则进行测量和钻探（细化阶段）。
- 提供油田范围和预算信息。
- 其他更多的步骤。
初始阶段的持续时间
初始阶段主要是为项目目标建立一些初始的共同构想，确定项目是否可行，并决定是否值得进入些话阶段加以认真研究。如果预先就决定项目必须进行，而且项目显然是可行的，那么初始阶段会更加短暂。这时候，初始阶段可能指包含第一次需求研讨会，并为第一次迭代制定计划，然后就快速地进入细化阶段。
初始阶段会创建的制品
迭代开发的一个重要观点是：在初始阶段只完成其中部分制品，在后续迭代中对其进行精化。而且，出发认定某制品很可能具有使用价值，否则不应该创建该制品。
- 设想和业务用例：描述高阶目标与约束、业务案例，并提供执行摘要。
- 用例模型：描述功能需求，在初始阶段，确定大部分用例的名称，详细分析10%的用例
- 补充性规格说明：描述其他需求，主要是非功能性需求。在初始阶段，多考虑关键的非功能性需求是有帮助的，其对架构将会阐述主要影响。
- 词汇表：关键领域术语和数据字典。
- 风险列表和风险管理计划：描述风险（业务、技术，资源和进度）及应对和缓解的方法。
- 原型和概念验证：澄清设想，验证技术思路。
- 迭代计划：描述第一个细化迭代的任务。
- 阶段计划和软件开发计划：对细化阶段的持续时间和工作量进行粗略估计。工具、人员、教育和其他资源
- 开发案例：就特定项目，对UP步骤和制品进行定制的描述。在UP中，通常会为特性项目进行定制。
是否意味着大量的文档
记住，这些制品都是可选的。要有选择地创建对项目却有价值的制品，如果其价值未被证实，则放弃之。
业务这是进化式开发，所有重要的不是在初始阶段创建我安装的规格说明，二十形成初始、改了的文档。这些文档将在细化迭代中精化，一边相应由早期编程和测试得到的既有价值的反馈。
创建制品或模型的重点不在于文档或图本身，二十其中蕴含的思想、分析和前期准备。
还要注意的是，可以在以后的项目中部分宠用以往项目中的制品。
何时知道自己并不了解初始阶段
- 当认为大部分项目的初始阶段会持续几周或更长时。
- 在初始街二段试图定义大部分的需求时。
- 期望初始阶段的预算和计划时可靠的。
- 定义架构（应该在细化阶段以迭代方式来定义架构）。
- 认为正确的用作顺序应该时：1.定义需求；2.设计架构；3.实现。
- 没有业务案例或设想制品。
- 详细编写所有用例。
- 没有详细编写任何用例。与之相反，应该详细编写10%-20%的用例一边获得对问题范围的真实认知。
初始阶段中有多少UML
初始阶段更关注对基本范围的理解以及10%的需求，这主要时以文字方式表达的。大多数UML图将出现在下一个阶段--细化阶段。