好需求的特点

原子

要求应阐明单一利益相关者A需求或质量属性。当一个需求包含多个需求时，就不可能独立地分析这些需求。 Enterprise Architect可以通过允许建模者在浏览器窗口中创建需求层次结构来提供帮助，这些层次结构可以分解为原子需求。

可达到的

需求中指定的需求必须是可以实现的。如果需求无法实现，系统将无法交付利益相关者所需的业务价值。 Enterprise Architect可以通过允许将每个需求跟踪到实现元素（例如用例或部件）来提供帮助。关系矩阵可以用来快速识别那些没有追溯到下级元素的需求。

有凝聚力的

作为一个集合的需求必须是一致的、有凝聚力的，并能表达系统的行为；必须确定任何差距，并且必须解决需求之间的重叠问题。遵循需求流程将有很大帮助， Enterprise Architect具有许多功能，可以轻松保持需求的内聚性。可以使用关系矩阵来识别缺失的需求，例如，利益相关者及其需求的矩阵将快速识别没有需求的利益相关者。

完全

每项要求都必须充分描述将导致利益相关者的需求得到满足的必要功能或行为。 Enterprise Architect可以帮助团队成员使用团队图书馆功能或讨论和审阅窗口。一些分析师更喜欢将需求标记为需要完成，方法是在需求元素上附加一个标签，例如“TBC”。 Enterprise Architect可以通过允许分析师在需求包中搜索此标签并返回需要进一步工作的元素列表来提供帮助。也可以A此搜索设置模型视图视图以填充视图。讨论和审阅窗口也很有帮助，因为添加的信息不是需求本身的一部分，并且不会用不属于需求定义的文本污染需求的注记。

当前的

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

独立的

需求应该是相互独立的，并且没有相互冲突或重申相同需求的重叠声明。 A不可避免地存在一些重叠，因此需要进行一定程度的分析，但可以通过在层次结构中创建需求并系统地工作来将其保持在最低限度。 Enterprise Architect有许多特征可以帮助解决这个问题，包括关系矩阵，这将有助于识别重叠。实用且灵活的搜索函数也可用于识别重叠或冲突的语句。

可修改

这意味着可以更改需求而无需修改其他相关需求。它也适用于软件（系统）需求规范，并要求它可以轻松更改。 Enterprise Architect可以帮助解决这两个问题；通过搜索功能可以很容易地需求到自己，文字和属性也很容易改变。系统需求规范是从模型中自动生成的，因此只需更改一个或多个需求并重新生成文档即可对其进行更新。

可追溯

需求是对特征或行为A规范，不是孤立存在的，而是通常与利益相关者、业务驱动程序和目标等上游实体以及使用案例和组件等下游实体相关。 Enterprise Architect允许向任何方向跟踪元素，并提供许多有用的工具来可视化跟踪，包括关系矩阵、可可追溯性窗口和需求图本身。插入相关元素功能可用于自动构建跟踪图。

明确的

需求只能以A方式解释。模棱两可的需求可能导致项目延迟、超出预算或具有错误的功能或行为。 Enterprise Architect可以通过使用 Discussion功能帮助分析师记录有关需求的评论来帮助解决歧义。

可验证

A可以测试实施的系统或产品以确定已满足要求，则该要求是可验证的。能够实现这一点的关键是知道必须运行测试来验证特定要求。 Enterprise Architect可以通过允许建模者将测试案例追溯到需求并以多种方式可视化它们的关系来提供帮助，包括使用关系矩阵。测试结果也可以直接记录在Enterprise Architect中。

必要的

需求应该记录真正需要的能力或行为，或指定系统或产品应符合标准等约束条件。 Enterprise Architect可以通过允许建模者将每个需求与其源相关联并使用关系矩阵来提供帮助；没有源的需求将被明显识别为不必要或需要进一步调查。

可行的

不能执行A要求将意味着利益相关者的需要将无法得到满足。最好尽快确定这些需求，以免让需求所有者失望。 Enterprise Architect可以通过允许分析师、架构师、设计师和开发人员使用讨论和审阅窗口讨论需求并确定其可行性来提供帮助。