0

我正在学校上 UML 课程，我的老师希望我们完成基本的、最低限度的作业，并且不会回答任何问题。话虽如此，系统的要求有注册、学生记录、登录、课程记录和课堂记录的用例。它真正需要做的只是以下几点：

  • 学生将登录系统，他们唯一能做的就是注册。在注册页面中，它会列出可用的课程，学生会选择一个或多个，然后他们会列出每门课程的可用课程。必须检查学生的记录以验证他们是否满足先决条件。
  • 注册员可以登录系统，他们不仅可以注册学生，还可以查看和修改课程记录、课堂记录和学生记录。
  • 此外，这些课程可以在线或现场进行，我想知道是否应该定义......
  • 如果需要理解，我可以提供更多细节。

我复杂的 SRS

好吧，我想我走得太远了，我想我想就如何确定基本要求提出意见。

我还有几个问题：

  1. SRS 中是否需要登录对象？还是应该简单地假设用户已经登录？
  2. 关于基数和多重性，它是同一个概念吗？
  3. 看看我的多重性，我有没有犯任何非常明显的错误？

就使其不那么复杂而言，仅具有以下内容是否有意义：班级类型、课程、班级、注册、学生和注册商？

4

1 回答 1

1

系统需求规范远比简单的图表复杂得多。完成 SRS 的方法有很多，因此您的问题可能会被标记为离题太宽泛。无论如何，这就是我所做的。

第一步，您需要对需求本身进行分组。第一个广泛的划分是将功能和非功能需求分开。非功能性是那些不能固定到单个功能的需求。例如。性能、法律、安全、安保，应有尽有。这些是您首先构建的类别，最终您在创建 SRS 的过程中拥有一组。

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

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

另一件需要注意的是，需求本身应该可以追溯到它们的起源。这意味着您需要参考从哪里获得的论文、会议、电话、个人谈话等。

有很多很多细节使 SRS 的创建和维护成为一门自己的科学，但以上是您的关注点。

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

现在为您的其他问题。

  1. 在任何情况下，登录都不是业务对象。它是源自“用户必须登录到...”的要求的约束。
  2. 参见基数与多重性
  3. 我会简单地省略.. 符号。如果离开它意味着相同（未指定）。我会从凭证管理器中删除“登录”字样，因为它还将处理注销等等。所以强调是不对的。否则，如上所述，类设计并不是 SRS 的一部分。
于 2016-05-20T08:42:37.987 回答