UML：构建SRS类图：太复杂了？

Question

我正在我的学校参加UML课程，而我的老师希望我们完成基本的，最低限度的任务，并且不会回答任何问题。话虽如此，系统的要求有用例 - 注册，学生记录，登录，课程记录和班级记录。它真正需要做的就是：

• 学生将登录系统，他们唯一能做的就是 寄存器。在注册页面中，它将列出可用的课程，a 学生会选择一个或多个，然后他们会列出课程 适用于每门课程。必须检查学生的记录 验证他们是否符合先决条件。
• 注册商可以登录系统，他们不仅可以注册学生，还可以查看和修改课程记录，课程记录和学生记录。
• 此外，课程可以是在线或现场，我想知道是否应该定义......
• 如果需要了解，我可以提供更多详细信息。

嗯，我认为我把它放得太远，我想我想就如何确定基本要求提出意见。

我也有几个问题：

1. SRS中是否需要登录对象？或者只是假设用户已登录？
2. 关于基数和多重性，这个概念是一样的吗？
3. 看看我的多重性，我是否犯了非常明显的错误？

至于减少复杂性，只有：类型，课程，班级，注册，学生和注册商才有意义吗？

Answer 1

系统需求规范远比简单的图复杂。有很多方法可以完成SRS，所以你的问题是被标记为主题过于宽泛的候选人。无论如何，这就是我所做的。

在第一步中，您需要自己对需求进行分组。第一个广泛的划分是分离功能和非功能需求。非功能性是那些不能固定到单个功能的要求。例如。性能，法律，安全，安全，你的名字。这些是您首先构建的类别，最终您在SRS创建过程中拥有一组类别。

对功能要求进行分组有点棘手。你通过综合用例来做到这一点。每个功能需求都需要通过一个用例来实现。您不需要详细介绍用例，但只需要粗略的故事。但是，一旦您将所有功能需求连接到用例，您的SRS就会准备就绪。

请注意，非功能性要求尚未相关。这是因为它们对后续阶段的许多功能和系统设计都有影响。只需要让它们结构清晰。

需要注意的另一件事是，要求本身应该可追溯到它们的起源。这意味着您需要参考纸张，会议，电话，个人谈话等等。

有许多细节使SRS的创建和维护成为它自己的科学，但以上是你的观点。

类图不一定是SRS的一部分。它是后来设计规范的一部分。

现在提出其他问题。

1. 在任何情况下，登录都不是业务对象。它是从“用户必须登录到...”
的要求派生的约束
2. 请参阅cardinality vs multiplicity
3. 我只是放弃 .. 符号。如果离开它意味着相同（未指定）。我将从凭证管理器中删除“登录”字样，因为它还可以处理注销等等。所以重点不对。如上所述，班级设计并不是SRS的一部分。