前页 后页

型号要求

无论使用什么过程,需求都是任何项目成功的基础。传统上,许多组织已将其需求存储和管理在电子表格和文字处理器等文本工具中,但是这些需求通常在开发过程中仍然隐藏。使用Enterprise Architect的基于模型的方法进行需求工程,可以将需求转换为一流的建模元素。它们可以显示在图表上,并与拥有它们的涉众相关,并且可以创建跟踪,将它们连接到其他下游过程模型元素,例如用例和应用程序组件。

可以将状态,阶段,复杂性和难度等属性分配给每个需求,这有助于您轻松管理它们。

特征

特征

详情

也可以看看

代表要求

在Enterprise Architect ,需求可以建模为:

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

模型中的要求

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

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

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

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

Numbering requirements in the Project Browser in Sparx Systems Enterprise Architect.

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

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

需求图 设计自定义文档模板

用例

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

Showing that a UML Use Case element realizes (implements) a Requirement.

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

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

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

可追溯性 追溯图示例 连接要求 用例 用例图 演员 复合元素 顺序图 通讯图 活动图 状态机 创建规则流活动