其实在需求阶段之前有个初始化阶段。初始化阶段是建立项目共同设想和基本范围的比较简短的起始步骤。为了在随后的细化阶段能够开始编程，它将包括对10%的用例进行分析、关键的非功能需求的分析、业务案例创建和开发环境的准备。主要有一下几点：
1）项目的设想和业务案例是什么？
2）是否可行？
3）购买还是开发？
4）粗略估计一下成本
5）项目应该继续下去还是停止？
想要定义设想并大致得出所需的预算，就必须研究需求。但是，初始化阶段的目标并不是定义所有的需求，或产生可信的预算或项目计划。
这是一个关键点，当我们叠加了固有的“瀑布”思维时会重蹈对UP（统一过程）项目的误解。UP不是瀑布，初始化作为UP的第一个阶段也不需要完成所有需求或建立可靠预算和计划。以上内容是在细化的过程中逐步完成的。
对于UP，我稍微解释一下UP（统一过程）已经成为一种流行的构造面向对象系统的迭代软件开发过程。特别是，Rational 统一过程（Rational Unified Process，RUP）是对统一过程的详细精化，并且已经被广泛采纳。因为UP对于采用OOA/D的项目来说是相对流行的迭代过程。
对于迭代呢，我也稍微解释一下，从字面意思就差不多已经知道了。迭代开发（iterative development）是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期小项目，称为迭代。
其实开发的模型有很多种，除了众所周知的瀑布模型，迭代开发外，还有迭代和增量式开发或者称迭代和进化式开发。早起迭代过程的思想是螺旋式开发和进化式开发。还有一个现在常提起也比较火的敏捷开发。
敏捷开发（agile development）方法通常应用时间定量的迭代和进化式开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性（快速和灵活的响应变更）的价值和实践。
下面就直接切入主题——需求
需求（requirement）就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件。UP提出了一系列的最佳实践，其中之一就是需求管理（manage requirement）。需求管理不主张采用瀑布的观点，即在编程之前项目的第一个阶段就试图完全定义和固化需求。在变更不可避免，涉众意愿不明朗的情况下，UP更推崇用“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求”。简而言之，就是通过迭代前秒地进行需求分析，而非草率和随意地为之。
进化式需求与瀑布式需求
注意，在UP的需求管理定义中使用了“不断变更”一词。UP能够包容需求中的变更，并将其作为项目的基本驱动力。这一点极为重要，也是迭代和进化式思想与瀑布思想的核心差异。
需求的类型和种类
- 功能性（Functional）：特性、功能、安全性。
- 可用性（Usability）：人性化因素、帮助、文档。
- 可靠性（Reliability）：故障频率、可恢复性、可预测性。
- 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率。
- 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。
- 实现（Implementation）：资源限制、语言和工具、硬件等。
- 接口（Interface）：强加于外部系统接口之上的约束。
- 操作（Operation）：对其操作设置的系统管理。
- 包装（packaging）：例如物理的包装盒。
- 授权（Legal）：许可证或其他方式。
UP如何组织需求
- 用例模型：一组使用系统的典型场景。主要用于功能（行为的）需求。
- 补充性规格说明：基本上是用例之外的所有内容。主要用于非功能需求。
- 词汇表：词汇表以最简单的形式定义重要的术语。同时也包含了数据字典的概念，其中记录了关于数据的需求、例如有效性规则，容许值等。词汇表可以详述任何元素：对象属性、操作调用的参数、报表布局等。
- 设想：概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。
- 业务规则：业务规则（也称领域规则）通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域和业务所需求的，并且许多应用应该遵从这些规则