需求的业务环境

需求不是孤立出现的，而是通常在一个或多个业务文档中定义的业务问题或机会的上下文中定义或发现的。这些文档及其包含的信息可以包含在模型中，并为需求提供重要的锚点。

商业案例

商业案例是一个高级文档或论据，试图阐明启动项目的原因。对于需求分析师来说，这是一个重要的工件，因为它通常包含描述业务价值，驱动因素以及业务和技术风险的信息。它将工作放在业务中的其他功能的上下文中，并从高层次描述解决方案选项。它是需求的重要来源，应作为工件包含在模型中。

驱动因素和目标

业务驱动因素和目标通常由高级战略思想家（例如业务或企业架构师）记录下来。推动者定义了对于组织的运营至关重要的资源，流程或约束，而目标则描述了组织希望获得的职位。它们通常是企业级别的问题，因此应在单个项目级别之上建模。它们通常存在于高级文档中，即使组织层次上没有明确说明，分析人员也可以从以前的项目文档（例如Vision文档）中挖掘它们，并在项目包上方的企业包中对它们进行建模。资料库。

愿景与经营理念

尽管业务案例描述了启动项目的商业原因，但愿景通常会详细阐述机会或问题，以描述业务背景，市场地位，关键利益相关者和需求，解决方案选择和约束条件。远景通常不是在团队组建之前就创建的，并且可以成为需求信息的重要来源。所需的系统功能通常使用功能来表达。

Enterprise Architect具有广泛的工具和元素类型，可用于对远景文档的内容进行建模，包括用户，涉众，具有架构重要性的用例和需求，约束和部署环境。

政策和业务规则

政策是通常由治理机构定义和管理的高级原则或意图声明；业务规则是政策的实施。它们不是严格的要求，通常是在企业级别而不是项目级别定义的，这有利于它们在多个项目中的重用。可以使用定型的Requirement元素对策略和业务规则进行建模，并且可以从各个项目中跟踪业务和系统要求。法规和安全要求存在一些重叠，某些方法将这些要求视为业务规则的类型。 Enterprise Architect支持使用原型化需求对策略和业务规则进行建模，但是还具有强大的业务规则建模功能，可以为多种语言创建可执行代码。

• 在Enterprise Architect的Unified版和Ultimate版中都可以使用业务规则建模

利益相关者及其关注

不管项目是否在运行，利益相关者通常都有相同的关注点。例如，安全经理将关注敏感组织数据的漏洞，客户体验经理将关注访问速度，首席财务官将对投资回报感兴趣。这些问题可以在企业级别建模，因为它们是通用的并且独立于各个项目。它们将提供对项目级别需求的理解的来源，并将帮助确定需求格局中的差距。可以使用Enterprise Architect使用原型化的UML类对涉众进行UML并且可以使用被定型为涉众关注点的需求来对这些高级关注进行建模。