我正在为学校的项目创建一个用例，我对前置条件字段感到困惑。我可以理解“必须登录”或“需要帐户”等先决条件。
但是，如果软件是本地设置怎么办？对我来说，前提条件是“需要安装软件”听起来合乎逻辑。但另一方面，这个前提条件看起来很奇怪，否则，你首先就不会有这个用例。
简而言之，我的问题是：系统要求或软件安装能否成为前提条件的一部分？
解决UML问题核心的非常好的问题 - 它的语义很弱。因此，你的问题的答案是 - 可能是对的，可能是错的。 UML设置符号规则，并且仅定义基本元素语义（例如，“必须按顺序实现前提条件......”）。
我们甚至可以进一步提出“操作系统应该正确配置”等前提条件，甚至更糟 - “计算机有电”......这些讨论很容易变成哲学。 :)
根据我的经验，有一种方法可以使用例高效 - 构建另一个UML模型，一个互补的UML模型，用于制定前提条件，后置条件甚至用例场景（你可以为场景提出前提条件的相同问题）那么 - 这是一个场景的正确抽象？或者，“打开计算机？”是场景中的有效步骤？）。
为了实现这一点，我通常使用概念类图 - 我对我的域进行建模，然后根据这些元素（类及其属性）表达前/后条件和场景，并且仅使用这些元素。这很有意义，特别是知道前/后条件查询系统的状态，整齐地反映在对象/值上。
回到你的例子，如果你想知道“软件需要安装”的前提条件，你只需要问自己“我真的需要一个带有attribut'isInstalled'的课程'软件'吗？”
然后你很可能意识到你可能不需要这个前提条件，因为它太过“低级别”并超出了我的域名范围。现在您只需要定义您的域名。 :)这是一个类似情况的简单示例，演示了这个想法（请记住，用例和类模型是在不同的图表上绘制的）：
这种方法不仅可以更容易地指定用例，而且可以制作允许域规范，业务规则识别和系统设计的第一次抽象的补充类模型。
祝好运并玩得开心点！
让我们记住，用例对软件/系统需要实现的内容提出了很高的要求。这样，前提条件应仅与您正在构建的软件（或系统）有关，而与外部元素无关（例如，“计算机已连接并打开”不是一个好的前提条件）。例如，当您开始将用例视为序列或活动图时，前置条件为您提供了一些线索，即可能需要在软件中进行检查，可能需要调用其他一些操作/模块/类。此实现练习将帮助您确定前提条件将采用的形式，即使根据应用程序的结构仍然需要它。
举个例子，如果您希望用户登录或不使用不同的行为，或者操作需要不同的权限，则可能需要“必须登录”前提条件。
因此，一些系统要求可以是先决条件（例如，与设备的连接），并且一些软件安装可以是前提条件（例如，所需的伴随产品集成），但仅在它们对用例本身具有直接影响时。为您的应用程序安装软件不应该是一个先决条件：应用程序无法检查它是否未安装，因为它无法运行它确实执行然后它显然已安装...
对我来说，系统要求和/或软件安装可以是前提条件的一部分，但一如既往，它必须与您的用例相关。例如，如果安装或未安装硬件或第三个工具，您的系统将具有不同的行为。