预订演示
前页 后页

假设和约束模型

当分析师处理从启发过程中获得的信息时,他们通常会遇到最能描述为已做出的假设或限制解决方案的约束的陈述或条件。这些不是需求,但在需求开发过程中具有重要作用,因为它们具有影响解决方案的能力并且必须被理解。

业务约束

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

Example Feature with Constraint element modeled in Sparx Systems Enterprise Architect

假设

假设是一种被认为是正确但尚未得到证实的陈述。必须对假设进行建模并尝试对其进行验证,因为如果它们被证明是false的,那么它们有可能显着改变问题的定义和解决方案。它们可以是关于当前完成方式的陈述,也可以与未来的流程或解决方案有关。假设与风险相似,良好实践将规定它们的管理方式与风险相似。应在需求开发阶段相尝试验证它们。假设的一个例子是:“用户将知道在其他窗口应用程序中使用的工具箱图标的含义”。基于此假设,解决方案设计者可能计划不为图标实现工具提示。可以使用约束元素在Enterprise Architect中对假设进行建模,该约束元素可从“公共”工具箱页面获得,或者作为定型需求元素。它们可以使用依赖关系与一个或多个模型元素相关联。

Technical assumption modeled as a constraint in Sparx Systems Enterprise Architect

技术约束

技术约束是对解决方案的架构、设计、实施或部署的选择A任何限制。他们可以从企业架构中定义的原则开始,这些原则限制平台类型、编程语言以及购买或构建部分解决方案的决定。它们也可能是对解决方案必须实施或遵守的协议或标准类型的限制。文件大小和格式的限制也会限制解决方案的选择。与非功能性需求有一些重叠,分析师应该小心区分这两个概念。技术约束可以在Enterprise Architect中使用可从“公共工具”工具箱页面获得的约束元素或作为定型需求元素建模。它们可以使用依赖关系与一个或多个模型元素相关。约束也可以使用窗口创建为属性的属性。