简介 本章简要介绍迭代和进化式需求，并且描述特定的UP需求制品，以此为后续的面向需求的章节做好铺垫。
定义：需求 需求(requirement)就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件。
UP提出了一系列的最佳实践，其中之一就是需求管理（manage requirement）。需求管理不主张采用瀑布的观点，即在编程之前项目的第一个阶段就试图完全定义和固话需求。在变更不可避免，涉众意愿不明朗的情况下，UP更推崇用“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求”
简而言之，就是通过迭代巧妙地进行需求分析、而非草率和随意地为之。 需求分析的最大挑战是寻找、沟通和记住什么是真正需要的，并能够清楚地讲解给客户和开发团队的成员。
进化式需求与瀑布式需求 注意，在UP的需求管理定义中使用了“不断变更”一词。UP能够包容需求中的变更，并将其作为项目的基本驱动力。这一点极为重要，也是迭代和进化式思想与瀑布思想的核心差异。
寻找需求可以采用的方法 除“不断变更”之外，另一个重要的词是“寻找”。也就是说，UP提倡使用一些有效的技巧以获得启示，例如与客户一同编写用例、开发者和客户共同参加需求讨论会、请客户代理参加焦点小组以及向客户演示每次迭代的成果以求得反馈。 UP欢迎任何能够带来价值并提高用户参与度的需求启发方法。
需求的类型和种类 在统一过程中，需求按照“FURPS+”模型进行分类，这是一种有效的记忆方法，其含义如下：
》功能性（Functional）：特性、功能、安全性。
》可用性（Usability）：人性化因素、帮助、文档。
》可靠性（Reliability）：故障频率、可恢复性、可预测性
》性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率。
》可支持性（Supportability）：适应性、可维护性、国际化、可配置性
“FURPS+”中“+”是指一些辅助性的和次要的因素，比如：
》实现（Implementation）：资源限制、语言和工具、硬件等。
》接口（Interface）：强加于外部系统接口之上的约束
》操作（Operation）：对其操作设置的系统管理
》包装（Packaging）：例如物理的包装盒
》授权（Legal）：许可证或其他方式
其中某些需求可以统称为质量属性（quality attribute）、质量需求(quality requirement)或系统的“某属性”。这些需求包括：可用性、可靠性、性能和可支持性。在一般使用中，需求按照功能性（行为的）和非功能性（其他所有的行为）来分类，有些人不喜欢这种宽泛的分类方式，但这种方式已被广泛采用。
UP制品如何组织需求 UP提供了一些需求制品。同所有UP制品一样，它们都是可选的。其中关键的制品包括：
》用例模型：一组使用系统的典型场景。主要用于功能需求
》补充性规格说明：基本上是用例之外的所有内容。主要用于所有非功能需求，例如性能或许可发布。该制品也用来记录没有表示为用例的功能特性，例如报表生成
》词汇表：词汇表以最简单的形式定义重要的术语。同时也包含了数据字典（data dictionary）的概念，其中记录了关于数据的需求，例如有效性规则，容许值等。词汇表可以详述任何元素：对象属性、操作调用的参数、报表布局等。
》设想：概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。设想也概括了项目的业务案例。设想是简短的执行概要文档，用以快速了解项目的主要思想。
》业务规则：业务规则（也称为领域规则）通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域或业务所要求的，并且许多应用应该遵从这些规则。政府的税收法规是一个例子。领域规则的细节可以记录在补充性规格说明中，但是因为这些规则通常更为持久，并且对不止一个软件项目适用，所以应将其放入集中的业务规则制品（供公司的所有分析员共享），以便在这方面做出的分析工作能够被更好的重用。
制品的正确格式 在UP中，所有制品都是信息的抽象，它们可以存储在Web页，板报，或各种可以想象到的载体之上。