2.1 需求模型简介
IEEE的软件工程标准术语表将“需求”定义如下：
1）用户所需的解决某个问题或达到某个目标所要具备的条件或能力。
2）系统或系统组件为符合合同、标准、规范或其他正式文档，而必须满足的条件或必须具备的能力。
3）上述第一项或第二项中定义的条件和能力的文档表述。
RUP将“需求”定义为：需求描述了系统必须满足的情况或提供的能力，它可以直接来自客户需要，也可以来自合同、标准、规范或其他有正规约束力的文档。
两者对于需求的定义大同小异，简单来说，需求就是“软件能为用户做什么”。
在软件工程的历史中，需求分析并没有得到足够重视，在过去的10年中，项目团队越来越认识到需求分析的重要性，并将其作为软件过程中最关键、最困难的一个过程，因为它对软件开发过程、产品质量，以及软件是否能如期保质保量完成至关重要。
2.1.1 需求采集
需求采集的目标是获取知识。一般由熟悉用户所从事工作的资深人员进行需求采集工作，需求采集人员需要了解用户和客户希望软件系统在哪些方面帮助他们。
需求采集和需求分析并不是先后进行的两个阶段性工作，它们相互伴随，并且交叉进行。在需求工作开始阶段，更多的是进行需求采集工作，相伴进行的需求分析和整理工作占的比例偏少，但随着掌握的需求信息越来越多，需求采集人员需要开展的需求分析和整理工作也越来越多。
在进行需求采集前，需要做准备工作，如了解调研用户所属行业的情况、公司和部门的情况，列出需要询问的问题，准备相关资料等。需求采集的方法五花八门，如需求采集表、座谈会、客户访谈、现场参观和调研、同类软件分析等。通过需求采集活动，收集客户的众多“原始需求”，需求采集的工作成果是《软件用户需求说明书》，为需求分析工作提供基础。
2.1.2 需求分析
需求采集活动将采集客户的大量“原始需求”（又称为“用户需求”），这些原始需求有可能相互冲突，需要进行过滤和分析。需求分析是对采集到的原始需求进行分析、整理、辨别和归纳，最终形成系统的、明确的软件需求。
需求分析的工作成果是《软件需求规格说明书》，它精确地阐述了一个软件系统必须提供的功能需求、非功能需求、必须达到的质量属性指标以及它必须遵守的约束。《软件需求规格说明书》应尽可能完整地描述各种条件下的系统行为。
《软件需求规格说明书》参考目录如图2-1所示。
2.1.3 需求模型的功能
Power Designer的需求模型（Requirements Model，RQM）主要包括如下功能：
1）从结构化技术文档中创建RQM。
2）检查现有或导入的需求模型。
3）创建需求和设计对象（这些对象来自于其余类型的模型）的连接。
4）从其他设计对象中建立需求模型，或通过需求模型建立某些设计对象（如业务规则、包和用户用例等）。
5）从需求模型生成Word文档或更新Word文档。
Word文档、需求模型和设计模型三者之间的关系如图2-2所示。