前页 | 后页 |
需求模型
无论使用何种流程,需求都是任何项目成功的基础。许多组织传统上在电子表格和文字处理器等文本工具中存储和管理他们的需求,但这些需求通常在开发过程中隐藏。使用企业架构师基于模型的方法进行需求工程将需求转化为一流的建模元素。它们可以显示在图表上并与拥有它们的利益相关者相关,并且可以创建将它们连接到其他下游流程模型元素(例如使用案例和应用程序组件)的跟踪。
可以为每个需求分配状态、相、复杂性和难度等属性,帮助您轻松管理它们。
特征
特征 |
细节 |
也见 |
---|---|---|
代表需求 |
在Enterprise Architect中,可以将需求建模为:
|
需求 内部要求 |
模型中的需求 |
需求元素可以在需求图中进行分组和组织。 需求元素通过聚合关系相互连接以形成层次结构:
开发一个包含数百个需求元素的包是很常见的,这些元素单独排列并以不同复杂性的层次结构排列。您可以选择一个包并使用“设计>包>管理>级别编号”功能区选项快速轻松地突出显示需求的顺序和排列。 此图显示了一个包中的许多需求,其中 Level Numbering 使顺序和排列清晰:
如果从包中添加、移动或删除元素,编号会自动调整。 此编号也可以应用于文档。 |
需求图表 设计自定义文档模板 包选项 |
使用案例 |
需求由使用案例、类、接口和组件等模型元素实现(实现)。有许多方法可以追溯要素的需求或服务模型的需求,或者开发需求的要素,在描绘需求的特征图中最为明显,可追溯性由实现关系连接的要素。实现连接器使项目团队的成员能够将设计目标和开发保持一致,并明确开发路径和目的。 更常见的实现关系是在需求和用例之间。 A需求可以通过一个或多个使用案例来实现,一个用例可以实现一个或多个需求。 虽然需求定义了必须满足的条件,但用例是定义和可视化如何满足该条件的关键。用例图描述A动作、流程和组件的逻辑分组以实现实现,并通过参与者参与元素的使用所需的结果,还定义了流程的用户和/或系统角色。 每个用例(作为一个复合元素)可以包含子图的组合,这些子图在更详细的情况下细节了特定活动或功能的实现方式——这些图包括序列、通讯、活动、状态机和企业规则流程图。每个用例的实际实现由类、部件和接口元素组织在它们自己的图中来实现。这些实现也可以在可可追溯性图中捕获和查看,描绘了从初始需求到测试和生产的完整开发路径。 |
追踪关系 示例可追溯性图表 连接需求 用例 用例图表 参与者 复合元素 序列图表 通讯图表 活动图表 状态机 创建规则流活动 |