型号要求

代表要求

在Enterprise Architect ，需求可以建模为：

• 外部需求-对系统或过程的期望，系统或过程必须提供的东西，以要素为模型；例如业务需求或利益相关者请求-此级别的需求具有其自身的属性，并在文档报告中单独报告
• 内部需求–对现有元素的需求，即元素必须完成或必须完成的工作，定义为元素的属性

模型中的要求

需求元素可以在需求图中进行分组和组织。

Requirement元素通过聚合关系相互连接以形成层次结构：

通常，要开发一个包含数百个需求元素的程序包，这些元素要单独排列并以不同复杂性的层次结构排列。您可以选择一个包，然后使用“设计>模型>管理>级编号”功能区选项来快速，轻松地突出显示需求的顺序和排列。

下图显示了包中的许多需求，其中级别编号使订单和安排变得清晰：

如果从包装中添加，移动或删除了元素，编号将自动调整。

该编号也可以应用在文档中。

用例

需求由模型元素（如用例，类，接口和组件）实现（实现）。有很多方法可以跟踪由元素建模的功能或服务的需求，或者跟踪开发需求的元素，这在描绘需求和通过实现关系连接的模型元素的可追溯性图中最为明显。 Realize连接器使项目团队的成员能够始终保持设计目标和开发，并明确开发路径和目的。

更常见的实现关系是在需求和用例之间。需求可以通过一个或多个用例来实现，而用例可以实现一个或多个需求。

在需求定义必须满足的条件的同时，用例是定义和可视化如何满足条件的关键。用例图描述了实现所需结果的动作，过程和组件的逻辑分组，并且通过使用Actor元素还定义了参与过程的用户和/或系统角色。

每个用例（作为一个复合元素）可以包含子图的组合，这些子图更详细地定义了如何实现特定活动或设施-这些图包括序列，通信，活动，状态机和业务规则流程图。每个用例的实际实现是通过在其各自的图中组织的Class，Component和Interface元素实现的。这些实现也可以在可追溯性图表中捕获和查看，描绘了从最初的需求到测试和生产的完整开发路径。