正确分类UML图的客户要求？

Question

我需要将以下RQ归类为

• 设计目标，
• 设计决策，
• 功能要求
• 非功能要求

（所以我以后可以做类图和用例图）。

我想知道我是否在正确的轨道上（大胆的表情是我对每种要求的猜测）：

需求文档  购买承诺系统。

1. 该软件将计算工厂购买以生产其产品所需的许多详细信息。 （设计决策）

2. 该软件必须使用IBM PC计算机上的C ++或Java编程语言编写。 （设计决策）

3. 产品数量应等于4。（非功能需求）

4. 软件设计的总体目标是提高软件的可移植性。 （非功能要求）

5. 系统应接受有关每种类型产品的数量，数量和价格的数据作为输入（作为文本文件）。 （功能要求）

6. 每种产品的详细信息数量不得少于5。

7. 第一类和第二类产品应具有2个相同的详细信息。第二类和第四类产品应具有相同的详细信息。第三类产品应具有与第四类产品相同的两个详细信息，并且与第一类产品具有相同的详细信息。 （设计目标）

8. 操作员应通过登录名和密码登录并注销到系统。 （设计目标）

9. 在开始时，操作员必须提供以下数据项（应提供输入数据的验证）：

   • 工厂将在未来3个月内生产各种类型的产品。 （功能要求）

10. 软件必须为操作员的每个操作生成报告（报告应应操作员的要求保存在文件中）。该报告必须包含：（功能或设计目标要求） -购买所需的每一个细节。

    • 每个细节的总价。
    • 所有详细信息的总价

Answer 1

functional requirement告诉应该做什么。 non functional requirement讲述了有关软件应如何或软件应如何做的事情。

软件设计与软件的结构和行为有关。如果某些陈述似乎是武断的，并且您认为该软件可以满足所有要求，但又有所不同，那么很有可能它更多地是关于设计而不是要求。设计目标告诉设计必须确保的内容（模棱两可：在需求阶段，很难在非功能需求和设计目标之间做出区分）。设计决策是对软件行为或结构的决策。

考虑到这一点，这里进行分析：

1. 软件应执行的操作==>功能要求（FR）
   如果我们要对此进行更改，则该软件将不再执行预期的操作，因此不能作为设计决策。
2. 软件的外观==>非功能要求（NFR）
   与软件的结构或行为无关。该语言不会影响用例或类模型，因此它并不是IMHO的设计决策。
3. 关于对象模型中基数的任意决定==>设计决定（DD）
4. “设计目标” ==>设计目标（DO）
5. 软件应执行的操作==> FR
6. 关于对象模型的任意约束==> DD
   如果不小于3或不小于10，则该软件仍将满足功能要求。但是，这取决于上下文。如果事实证明，如果不遵守这些限制，则该软件将不适合特定用途，则可能是FR。
7. 对象模型上的任意约束==> DD
   该语句的目的不清楚。看起来有些任意约束可以允许归纳某些类别。
8. 软件应做什么==> FR
9. 关于交互的任意决定==> DD
   我认为可以在其他时候或以其他方式（1个月3次）输入数据。因此，我认为是DD。但是，有人可能会认为该系统应提供3个月的计划。因此不能排除FR，尽管我希望它的表达方式有所不同。
10. 软件应执行的操作==> FR

Answer 2

我记得在过去有关RQ的长期讨论中，具体的一个是Non-F还是F。但是，Wikipedia的定义很简单。

  

在需求工程中定义，功能需求指定系统的特定结果。

因此您的分类看起来还不错。但是，我不知道您的前两个分类应该是什么。看起来有点像MoSCoW，但事实并非如此。设计决策（至少对我而言）在需求中找不到。顾名思义，它们是来自设计过程的决策。此外，设计目标是NF的子类别。更重要的是您的NF未分类的事实。至少应包含一些子类（法律类，表演类等）。有关完整列表，请参见Wikipedia。