提示1-3：突出系统的业务目标！ #requirement #goal 您应该确保业务目标（目标）是明确已知的。实际上，这应该已经在项目合同或要求规范中了…… 与更详细的系统要求相比，业务目标通常更全球化，水平更高。 ...

提示1-5：确保您可以参考（现有）要求！ #requirement #thorough 如果您引用架构文档中的现有要求，例如为了证明设计决策的合理性，您需要确保这些要求可以通过短键或类似的东西进行唯一识别。 有时，您可以从需求文档中获取这些ID。 如果您的需求由工具（例如问题跟踪器）管理，您可以使用这些ID-使用一些工具，您甚至有稳定的URL。 ...

提示2-2：澄清约束的后果！ #constraint #stakeholder 您应该澄清约束的后果，例如由此产生的（额外）成本或努力。 如果限制带来不合理的后果（例如，只能满足于过高的成本），您应该与相关利益相关者进行谈判。 ...

提示3-14：注意外部接口的质量要求！ #context #quality-goal #external-interface 特殊质量要求可能适用于您自己系统的接口，也可能适用于您的外部系统，例如安全、吞吐量或可用性要求。这些所谓的“服务水平”需要谨慎对待，因为它们可能具有很高的实施和运营费用以及风险。 您可以在上下文图中注明特殊质量要求或目标。 在下面的示例中，您在外部接口上找到了两个标记，表明相应的接口影响了这些Q目标。 另请参阅（提示3-4（上下文中的风险）） ...

提示3-15：显示技术背景（以防硬件是您系统的核心）！ #context #technical-context 如果硬件、处理器、网络、传输通道或总线是系统的核心，则您应该在技术背景下记录或指定系统的这些硬件和基础设施。 特别是对于集成硬件/软件系统（嵌入式系统），您几乎总是需要技术背景。上面的嵌入式系统上下文图（右侧）就是这样一个例子。 然而，对于信息系统来说，在上下文中已经显示硬件和基础设施的某些方面可能也很重要，例如安全问题（见上面的网店示例）。 对于信 ...

提示3-16：使用技术上下文来描述协议或通道！ #context #thorough #technical-context 正如您在提示3-10（业务和技术上下文）中看到的，您可以在上下文中明确标记协议（SSH、HTTPS、VPN）或通道（CAN总线）。 唉：为了节省精力，您可能会用有关技术协议（如ftp、https或类似）的信息来修改业务上下文。请参阅提示3-17（用技术信息修改业务背景）。 ...

提示3-4：在上下文中明确指出风险！ #context #risk 您应该在上下文中明确指出的一些风险示例： 可用性风险：如果外部系统影响系统的可用性。 成本风险：如果使用外部系统很昂贵，则个人通话或其他类型的使用会花费金钱。例如信用卡支票或付款/预订服务。 安全风险：如果您从/向外部系统接收/发送合理数据。这可能会使这些接口对潜在的攻击者来说特别有趣。 外部系统的波动性（变化的高概率）：如果外部系统的接口经常变化（它们是“进行中的工作”） ...

提示4-6：证明解决方案策略的合理性！ #solution-strategy 解释为什么你或你的团队会做出某些决定。 “为什么”通常比“什么”或“如何”更重要。 ...

提示6-11：使用序列图来描述或指定运行时场景！ #runtime-view #scenario #sequence-diagram 使用（UML）序列图来处理运行时场景。它们清楚地表明了所有参与的构建块的责任-这有助于讨论构建块。 示例： 请参阅以下示例： 缺点（和建议） 使用图形建模工具时，创建和管理序列图可能需要花费大量精力。您可以通过使用文本DSL（域特定语言）来描述序列，并让somt工具为您渲染图表来加快该过程。 上图是使用（自由和开源的）PlantUML呈 ...

提示4-4：在解决方案策略中，参考概念、视图或代码！ #solution-strategy #concept #view #source-code 避免冗余，不要重复来自观点或概念的信息。 在解决方案策略的表格版本中（在提示4-2（解决方案策略作为表格）和提示4-3（具有质量要求的上下文中的解决方案））中，您应该仅简要记录-并参考（链接）arc42第5节（构建块）、第6节（运行时视图）或8节（交叉概念）中的详细解释。 外部文档或参考文献的链接是可以的，只要您的利益相关者 ...