提示10-4：使用质量树作为清单！ #quality-tree #thorough #iso-25010 您在[tip 1-14（质量要求清单）]//tips/1-14）中发现了一个略微不同的概念。 使用图形质量树（或思维导图）的清晰度来识别质量要求中的潜在差距： 与您的决定性利益相关者讨论质量目标和要求，最好在联合研讨会上讨论。 从类似于ISO-25010质量树的东西开始。 1让你的利益相关者创造高质量的场景2将这些场景附加到特定的质量树 ...

提示11-2：分析（外部）界面的问题和风险！ #risk #problem #external-interface #interface 接口（通常是外部接口）是问题的根源，或者至少承担了系统的某些质量要求，即可用性、鲁棒性或安全性。 另请参阅关于上下文和范围的提示提示3-14（外部接口的质量要求） ...

提示12-2：将术语表记录为表格！ #glossary #lean 将术语表记录为按字母顺序排列的架构和开发中使用的最重要术语的表格。包括经常性业务或需求术语，如果这些没有在其他地方定义。 如果利益相关者以各种语言工作，您可以包括其他语言的规范性翻译。 术语表可能与领域驱动设计的“无处不在的语言”相同或相似（因此也可以包含在 arc42 第8节（交叉概念）中） ...

提示12-5：保持术语表紧凑！避免琐事。 #glossary #lean 保持词汇表中的术语数量相当少：根据我们的实践经验，10-30个术语通常足以解释真正重要的事情。 您不想在词汇表中编写另一本百科全书或重新创建维基百科！ 避免琐事，包括系统问题和解决方案空间中的具体术语。 “UML”（“统一建模语言”的缩写）和“Java”（编程语言）都不需要在术语表中解释。 ...

提示12-6：让您的“产品所有者”或“项目经理”负责术语表 #glossary #lean 在敏捷项目设置中，产品所有者可以负责维护术语表，在更传统的设置中，这可能是项目经理。 ...

提示3-18：解释域接口及其技术实现之间的关系！ #context #interface 如果您的域接口通过不同的技术通道、协议或接口在技术基础设施中实现，您应该明确描述这两个区域之间的映射。 这种情况的简单例子可以在下图中找到。关系（映射）可以很容易地用表格来描述： 域界面 技术实施 制动中断，驾驶员覆盖，每分钟回合，节流阀，位置 CAN公交车 用户命令 驾驶舱中的开关、钥匙、杠杆 状态信息 音频输出，在驾驶舱中显示 ...

提示3-19：将技术上下文推向部署视图！ #context #technical-context #deployment-view #lean 如果您更专注于领域主题（因此没有技术上下文），您可以将技术和基础设施推迟到部署视图（arc42第7节）。 如果技术和基础设施对您很重要，那么您应该在技术背景下给出这个概述。 ...

提示3-5：将上下文限制为概述，避免太多细节！ #context #essential #lean 记录所有外部接口 您应该记录所有外部接口或类别，尽管分类或抽象是一个有效的选项。 避免在此处进行过于详细的界面描述 请参阅以下反例-其中包含太多详细信息，用于上下文真实上下文图： ...

提示3-6：通过分类简化上下文！ #context #essential #lean 保持上下文小而简单：对具有强烈相似性的外部接口、系统或用户角色进行分类。明确表明它们是类别或抽象。 请参阅以下示例-上下文仅包含一个“报告”接口（“类别”），该接口在 level 1 上分为两种不同类型的报告。 我见过超过50个（！）的上下文图外部类别，在这种情况下，分类是减少视觉混乱并使图表再次可理解的绝佳方式…… ...

提示4-1：尽可能紧凑地解释解决方案策略（例如关键字列表）！ #solution-strategy #concept #lean 尽可能紧凑地解释解决方案策略（例如作为关键字列表） 在关键字中解释您的解决方案策略，例如作为相关决策或方法的简短列表。 您将细节解释为 arc42 第8节（交叉概念）中的概念。 你应该强调创建概述，而不是完整性或详细的解释。 另见提示4-2（解决方案策略作为表格）。 ...