需求工程

需求工程（RE）是在工程设计过程中定义、记录和维护需求的过程。它在系统工程和软件工程中很常见。

需求工程一词的首次使用可能是在1964年的会议论文“维护，可维护性和系统需求工程”中，但直到1990年代末IEEE计算机协会出版后才开始使用。教程于1997年3月发布，并且建立了有关需求工程的会议系列，该系列会议已发展成为国际需求工程会议。

在瀑布模型中，需求工程是开发过程的xxx阶段。后来的开发方法，包括用于软件的Rational Unified Process（RUP），都假定需求工程将在系统的整个生命周期中持续进行。

需求管理是系统工程实践的一个子功能，在国际系统工程理事会（INCOSE）手册中也有索引。

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

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

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

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

在德国进行的一项有限研究提出了实施需求工程中可能存在的问题，并询问受访者是否同意这是实际问题。结果并未呈现为可推广的结果，但表明主要的感知问题是需求不完整，目标移动和时间限制，较少的问题是沟通缺陷，缺乏可追溯性，术语问题和职责不明确。