提示1-10：使用“模范业务流程模型”来描述功能需求！ #requirement #functional-requirement 您可以将功能需求描述为“模范业务流程模型”。他们从利益相关者的角度以及所使用的工具和材料来描述过程。 请考虑以下示例： ...

提示1-8：使用编号列表来描述功能要求！ #requirement #functional-requirement 在这种情况下，您还可以使用编号列表作为简单而实用的方式来描述活动、程序或流程。活动然后，tip-1-6的图表可以记录如下： 鉴定 选择一个产品 检查客户类型 私人客户，加上增值税（增值税） 业务客户，索取增值税号 创建发票 如果您必须描述并发过程，活动图见提示1-6是更好的选择 ...

提示2-1：考虑组织内其他系统的约束！ #constraint 如果您不知道系统的任何限制，请开始查看组织内的其他系统。 ...

提示2-4：文档设计和开发约束！ #constraint 除了组织限制（见提示2-3）外，技术限制可能也适用于您的系统的设计和开发。这可以是管理层或组织本身关于硬件、运营、技术选择、产品使用、框架或参考架构的指导方针。 披露这些限制，以便开发团队能够及时适应它们。 另见提示2-3（组织约束） ...

提示2-5：区分不同类别的约束！ #constraint #essential 如有必要，区分技术、组织和政治限制或重叠惯例（例如，编程指南、文档、命名或组织惯例）。 ...

提示2-3：记录组织限制！ #constraint 时间和预算等组织限制在开发团队中不受欢迎是有充分理由的，因为它们非常强烈地限制了设计或实施决策的自由。因此，披露这些类型的约束。 有时，这些限制与开发过程、第三方合同或法律问题有关。与您的管理层讨论它们。 另见提示2-4（技术限制）。 ...

提示3-1：明确划分您的系统与其环境的界分！ #context #external-interface 定义“内部是什么”您的系统和外部的内容。 您应该将您的系统与其他IT系统划分，以展示它如何适应现有的IT环境，提供或使用哪些外部接口，以及哪些用户或角色正在使用该系统。 这样，您就可以显示系统的范围：您的系统的责任是什么，其类别系统的责任是什么。 您可以在下图中找到一个示例：它显示了网店的上下文，该网店将付款处理委托给外部提供商（将此责任从网店的范围中删除）。 ...

提示3-2：将上下文显示为图表！ #context #external-interface #essential 在图形上下文边界中，您应该将整个系统显示为黑框，例如，作为单个组件。 您有各种图形选项： 我们最喜欢的：UML组件或软件包图 UML用例图 任意的“盒子和线条”图表 无论如何，您应该将您的系统放在中间，并将其他系统、角色、用户等放在它周围。 ...

提示3-3：将上下文图与表格相结合！ #context #essential 您应该始终用表格来补充上下文图。通过这种方式，您可以减少图表中的标签数量，并轻松添加解释、理由或横切引用。上面的综合上下文图需要这样的表格解释。 我们只显示相应表格的摘录，但您应该考虑这个典型的“图形/表格”对的一些特征： 您应该在图表中使用抽象或通用术语的短标识符。我们在示例中使用“服务”或“市场数据”，然后在表格中更详细地描述 在表中参考更详细的解释，例如，如果您正在使用域语言中 ...

提示7-1：记录您的技术基础设施（硬件）！ #deployment-view #hardware #infrastructure 描述系统运行的技术基础设施（又称底层硬件）。这应包括： 节点，即处理器、服务器、集群……及其 关系（通道），即总线、网络或无线连接， 其他硬件元素，即防火墙、路由器、交换机、存储等。 您可以使用UML部署图或自由格式图形，如下所示： 如果您的利益相关者喜欢此类图形图标或符号：使用具有定义语义的一致符号集！ 委托硬件文档 尝试将硬件和基础 ...