模型假设和约束

当分析师处理从启发过程中获取的信息时，他们通常会遇到以某种方式最好地描述为假设或限制解决方案的陈述或条件。这些不是需求，而是在需求开发过程中起重要作用，因为它们具有影响解决方案的能力并且必须被理解。

业务限制

业务约束是对解决方案的设计，实施或部署可以做出的选择施加的业务限制或限制。它们通常是预算，时间和资源的限制，但可以是任何类型的限制，例如业务部署的上下文，其中解决方案不得更改分支机构员工当前的工作方式。业务约束还可能会限制信息的访问或显示，例如“报告中只能显示信用卡号的后四位”。业务规则存在一些重叠，分析师应谨慎区分这两个概念。可以使用“通用”工具箱页面中的“约束”元素或原型化的“需求”元素在Enterprise Architect中对业务约束进行建模。它们可以使用依赖关系与一个或多个模型元素相关。也可以使用“属性”窗口将约束创建为元素的属性。

假设条件

假设是一种被认为是真实的陈述，但尚未得到证实。必须对假设进行建模，并尝试验证它们，因为如果它们被证明是错误的，则有可能在问题的定义以及解决方案上发生重大变化。它们可以是关于当前工作方式的陈述，也可以与将来的流程或解决方案有关。假设与风险相似，优良作法将规定它们以与风险相似的方式进行管理。应该尝试在需求开发阶段尽早进行验证。一个假设的示例是：“用户将了解其他Windows应用程序中使用的工具箱图标的含义”。基于此假设，解决方案设计人员可能计划不实施图标的工具提示。可以使用“通用”工具箱页面中的“约束”元素在Enterprise Architect中对假设进行建模，也可以将其作为原型的“需求”元素。它们可以使用依赖关系与一个或多个模型元素相关。

技术约束

技术约束是对解决方案的体系结构，设计，实现或部署可以进行的选择上的任何限制。它们可以从企业体系结构中定义的原则开始，这些原则限制了平台的类型，编程语言以及决定购买或构建部分解决方案的决定。它们也可能是解决方案必须实施或遵守的协议或标准类型的限制。文件大小和格式的限制也可能会限制解决方案的选择。非功能性需求存在一些重叠，分析人员应谨慎区分这两个概念。可以在Enterprise Architect使用“通用”工具箱页面上可用的Constraint元素，或将其作为原型的Requirements元素，对技术约束进行建模。它们可以使用依赖关系与一个或多个模型元素相关。也可以使用“属性”窗口将约束创建为元素的属性。