预订演示

请注意 : 本帮助页面不适用于最新版本的Enterprise Architect. 最新的帮助文档在这里.

前页 后页

良好要求的特征

通常,系统中的错误和缺陷可以追溯到需求工程,与之相比,文献中经常提到校正需求的成本很小,而一旦构建系统则需要较大的成本。因此,明确表达,管理和测试的需求对于任何系统开发过程都是必不可少的。 Enterprise Architect具有一个方便的“需求清单”元素,可从“需求工具箱”的“扩展需求”页面中获得。

Example Requirements Checklist element created in Sparx Systems Enterprise Architect.

清单可用于指示是否已准备好实施需求。

良好要求的素质

为了有效,必须完成一套要求,并始终如一,凝聚力和明确记录利益相关者的需求。 Enterprise Architect提供了广泛的功能和工具集,可帮助分析师生成高质量的需求集。

质量

描述

也可以看看

原子

需求应阐明单个利益相关者的需求或质量属性。当需求包含多个需求时,就不可能独立分析需求。 Enterprise Architect可以通过允许建模人员在“浏览器”窗口中创建需求层次Enterprise Architect来提供帮助,该层次结构可以分解为基本需求。

Level Numbering Requirements in Sparx Systems Enterprise Architect.

可达到的

需求中指定的需求必须是可以实现的。如果无法达到要求,则系统将无法交付涉众所要求的业务价值。 Enterprise Architect可以通过允许将每个需求追溯到实现元素(例如用例或组件)来提供帮助。关系矩阵可用于快速识别那些未追溯到较低级别元素的需求。

Requirement traceability across layers, modeled in Sparx Systems Enterprise Architect

内聚性

一组需求必须是一致的和有凝聚力的,并能表达系统的行为;必须确定任何差距,并且必须解决需求之间的重叠。遵循需求过程将极大地帮助您, Enterprise Architect拥有许多设施,可以轻松保持需求的凝聚力。可以使用“关系矩阵”来识别缺少的需求,例如,利益相关者及其需求的矩阵可以快速识别出没有需求的利益相关者。

关系矩阵

完成

每个要求都必须完整描述必要的功能或行为,以使利益相关者的需求得到满足。 Enterprise Architect可以使用团队库工具或“协作”窗口为团队成员提供帮助。一些分析师倾向于通过在Requirement元素后附加诸如“ TBC”之类的标签来标记需要完成的需求。 Enterprise Architect可以通过允许分析师搜索此标记的需求包并返回需要进一步工作的元素列表的方式来提供帮助。也可以使用此搜索来设置模型视图以填充视图。 “协作”窗口也很有用,因为添加的信息不是需求本身的一部分,并且不会被需求定义之外的文本污染需求的注释。

The Element Discussion facility can be used to discuss requirements, in Sparx Systems Enterprise Architect.

当前

需求必须是最新的并且反映当前的知识和项目状态。 Enterprise Architect可以通过对需求源进行建模来帮助分析师,并且需求本身可以追溯到这些工件,因此当更改源时,可以定位所有受影响的元素。

Requirements diagram for tracing requirement sources in Sparx Systems Enterprise Architect.

独立

需求应该彼此独立,并且不能有相互冲突或重复陈述相同需求的重叠语句。由于不可避免地会有一些重叠,因此需要一定程度的分析,但是可以通过在层次结构中创建需求并系统地进行工作来将这种重叠程度降至最低。 Enterprise Architect具有许多功能,包括“关系矩阵”(Relationship Matrix),可以帮助您识别重叠部分,从而为您提供帮助。强大而灵活的搜索功能还可用于识别重叠或冲突的语句。

Grouping by requirement status in a project search, in Sparx Systems Enterprise Architect.

可修改的

这意味着可以更改需求而无需修改其他相关需求。它也适用于软件(系统)需求规范,并且要求可以轻松进行更改。 Enterprise Architect可以为这两个问题提供帮助。可以通过搜索工具轻松找到需求本身,并且轻松更改文本和属性。系统需求规范是从模型自动生成的,因此只需更改一个或多个需求并重新生成文档,即可对其进行更新。

可追溯的

需求是特征或行为的规范,并非孤立存在,而是通常与上层流程实体(如涉众,业务驱动程序和目标)以及下层实体(如用例和组件)有关。 Enterprise Architect允许在任何方向上跟踪元素,并提供了许多强大的工具来可视化跟踪,包括关系矩阵,可跟踪性窗口和需求图本身。 “插入相关元素”工具可用于自动构建轨迹图。

Showing the relationships between Requirements and other elements in the Traceability Window, in Sparx Systems Enterprise Architect.

明确的

需求只能以一种方式来解释。模棱两可的需求可能导致项目被延迟,超出预算或具有错误的功能或行为。 Enterprise Architect可以通过使用元素讨论工具帮助分析师记录有关需求的评论来帮助消除歧义。

可验证的

如果可以对已实施的系统或产品进行测试以确定是否满足要求,则该要求是可验证的。达到此目的的关键是知道必须运行哪个测试以验证特定要求。 Enterprise Architect可以通过允许建模者追溯测试用例回到需求并以多种方式可视化它们之间的关系(包括使用关系矩阵)来提供帮助。测试结果也可以直接记录在Enterprise Architect 。

Example of information in element compartments in Sparx Systems Enterprise Architect.

必要

需求应记录真正需要的功能或行为,或指定系统或产品应遵守诸如标准之类的约束。 Enterprise Architect可以通过允许建模者将每个需求与其源联系起来并使用关系矩阵来提供帮助。没有来源的需求将被明显地识别为不必要或需要进一步调查。

可行

一项无法实施的要求将意味着利益相关者的需求将无法得到满足。最好尽快识别这些需求,以免使需求所有者失望。 Enterprise Architect可以通过允许分析师,建筑师,设计师和开发人员讨论需求并使用Collaborate窗口确定其可行性来提供帮助。