活动

需求工程中涉及的活动差异很大，这取决于所开发系统的类型和所涉及组织的特定实践。这些可能包括：

1. 需求启动或需求启发–开发人员和利益相关者见面，询问他们关于软件产品的需求。
2. 需求分析和协商–确定需求（如果开发是迭代的，则包括新需求），并解决与利益相关者的冲突。书面工具和图形工具（后者通常在设计阶段都可以使用，但有些人在现阶段也发现它们很有用）已成功地用作辅助工具。书面分析工具的示例：用例和用户案例。图形工具的示例：UML和LML。
3. 系统建模 –一些工程领域（或特定情况）要求在产品开始建造或制造之前对产品进行完整的设计和建模，因此必须提前执行设计阶段。例如，在批准和签署任何合同之前，必须详细说明建筑物的蓝图。许多领域可能会使用生命周期建模语言来派生系统模型，而其他领域可能会使用UML。注意：在许多领域，例如软件工程，大多数建模活动都被归类为设计活动，而不是需求工程活动。
4. 需求规格说明–需求记录在称为需求规格说明（RS）的正式工件中，该工件仅在经过验证后才成为正式文件。如果需要，RS可以包含书面和图形（模型）信息。示例：软件需求规范（SRS）。
5. 需求验证–检查记录的需求和模型是否一致并满足涉众的需求。只有最终草案通过了验证过程，RS才能成为正式文件。
6. 需求管理 –管理自需求开始以来与需求相关的所有活动，在系统开发过程中进行监督，甚至直到使用后（例如更改、扩展等）

这些有时被表示为按时间顺序排列的阶段，尽管在实践中，这些活动之间存在相当大的交错。

事实证明，需求工程显然有助于软件项目的成功。