提示10-3：使用思维导图作为质量树！ #quality #quality-tree 思维导图提供了分层结构的能力（如树），但有时对读者更友好。思维导图工具通常允许在地图的不同部分之间进行引用。 你在下面找到一个例子。请注意一些条目处的小“+”符号，表示当前隐藏的其他信息。 我们喜欢在树中包含对特定场景的引用，在主要质量目标下面的示例中，例如性能、可用性、正确性等。 ...

提示10-5：考虑使用或应用（质量）场景！ #quality #quality-scenario #scenario 许多质量场景将与系统使用有关（应用程序场景、用例场景）。一些作者称这些为外部可见质量”。 这与功能、处理速度、计算或处理的正确性、错误数据输入的鲁大性、数据安全或机密性等顶级目标有关。 应用场景描述了当人类或通过任意接口使用时，系统应如何运行。 示例： 在图形用户界面上执行函数/用例XYZ需要不到一秒钟。成功登录后不到2秒，用户就会显示上周所有 ...

提示10-6：考虑变化（质量）场景！！ #quality #quality-scenario #scenario 除了使用或应用场景（见提示10-5）外，您应该考虑对质量要求的更改或修改。这包括任意更改请求，例如： 功能要求的添加或修改（即修改计算或验证规则） 适应修改后的质量要求（即改进的性能或吞吐量要求） 对服务级别协议变化的反应 此类变化场景涵盖了可维护性、可修改性、可变性或灵活性等重要质量目标。 一些例子： 新的（外部）支付提供商最多可以在两人周内集成。 ...

提示10-7：考虑故障/错误/故障（质量）场景！！ #quality #quality-scenario #scenario 你肯定知道墨菲定律：事情会失败，错误就会发生。 使用质量场景来记录或指定您的系统处理或必须处理的此类故障或异常的类型/类别。 示例： 如果外部支付提供商不可用，系统会在60秒内识别。然后，它将在60秒内通知管理员。 如果出现不可治疗的应用程序或运行时异常，系统将创建适当的日志记录事件，允许诊断错误，但不包含个人用户或 ...

提示11-1：与不同的利益相关者一起寻找问题和风险！ #risk #stakeholder #problem 首先广泛地搜索问题和风险，至少与以下利益相关者类别的代表一起： 项目或线路管理 产品所有者（如果适用） 开发团队 运营（或系统管理）团队 硬件专家 最终用户 可选的其他利益相关者团体来识别风险或问题… 安全专家 数据库专家 法律专家 业务分析 营销和/或销售人员 用户体验或可用性专家 审计师或审稿人… ...

提示11-4：分析_流程_的问题和风险！ #risk #problem 一些问题和风险源于系统内部和周围的流程，即： 需求流程：如果没有商定和明确的需求流程，从长远来看，这可能会导致问题。 开发流程（包括实施、测试、版本管理、配置） 构建、发布和部署过程可能会给系统带来严重问题。 测试和质量保证流程 管理流程：管理和相关决策流程可能与系统要求和/或质量目标不一致 ...

提示11-5：分析数据或数据结构的问题和风险！ #risk #problem 数据结构和数据内容都可能是风险或问题的根源。 甚至数据分发、复制、备份或同步都可能包含风险或问题。 ...

提示11-6：分析源代码的问题和风险！ #risk #problem #source-code 您应该应用源代码分析来识别风险和问题：静态（代码行、耦合、环络合等）和动态分析（即测试覆盖率、性能/线程分析）都有助于识别风险或问题。 ...

提示3-8：聚合（集群）带有端口的类似类别系统！ #context #port 如果您的系统与许多外部系统交互，您可以使用UML端口符号来表示此类类别的类别（或集群），而不是将所有外部系统显示为单独的符号。 这看起来类似于提示3-7（外部系统的类别），但不需要使用刻板印象，可能会节省一些绘图工作。 端口具有连接内部和外部的巨大优势：您可以描述哪个内部黑框与哪个外部类别通信。 请参阅以下示例：首先，您看到带有端口的上下文，下面您将找到带有端口和显式类别系统的更广泛版本。 ...

提示4-3：在质量要求的背景下描述解决方案方法！ #solution-strategy #quality #quality-scenario 在具有挑战性质量要求的系统中，您应该将质量场景的文档与解决方案策略相结合。 简要描述为实现具体质量要求而采取的解决方案方法。 见下表（已在提示4-2中显示） Quality goal Scenario Solution approach Link to Details <Q-goal 1> <Text& ...