UML 图的客户需求的正确分类？
Correct classification of client requirements for UML diagrams?
我需要class将以下 RQ 确定为
- 设计objective、
- 设计决策，
- 功能要求，
- 非功能性要求
（这样我以后可以根据它们做class图和用例图）。
我想知道我是否在正确的轨道上（粗体是我对每个要求的猜测）：
需求文档
采购承诺系统。
该软件用于计算工厂生产其产品所需采购的一些细节。 （设计决策）
软件必须在计算机IBM PC上用C++或Java编程语言编写。 （设计决定）
产品数量应等于 4。（非功能性请求）
软件设计的一个总体目标是提高软件的可移植性。 （非功能性要求）
系统应接受有关每种产品的详细数量、数量和价格的数据作为输入（制作为文本文件）。 （功能要求）
每类商品的详细信息数量不少于5.
第一类和第二类产品应该有2个相同的细节。第二类和第四类产品应该有一个相同的细节。第三类产品应该有 2 个与第四类产品相同的细节和一个与第一类产品相同的细节。 (设计Objective)
操作员需要通过用户名和密码登录和注销系统。 (设计Objective)
开始时，操作员必须提供以下数据项（应提供对输入数据的验证）：
- 工厂提前3个月生产的各类产品数量。 （功能需求）
软件必须为操作员的每个操作生成报告（报告应按操作员的要求保存在文件中）。报告必须包括：（功能或设计 Objective Req）
-需要购买的每个细节的数量。
- 每个细节的总价。
- 所有细节的总价
我记得过去关于 RQ 是非 F 还是 F 的长期讨论。但是，Wikipedia 有一个简单的定义。
As defined in requirements engineering, functional requirements specify particular results of a system.
所以你的分类看起来不错。不过，我想知道您的前两个分类应该是什么。对于一个相当完整的列表，看起来有点像 MoSCoW, but then again it does not. Design decisions (at least to me) are nothing to be found in requirements. They are, what the name suggests, decisions coming from a design process. Further a design objective is a sub-category of NF. Even more important is the fact that your NFs are not classified. There should be at least a handful of sub-classes (legal, performance, etc.). See Wikipedia。
A functional requirement tells what the software shall do. A non functional requirement 讲述了一些关于 软件应该如何或它应该如何做它所做的事情。
软件设计是关于软件的结构和行为。如果某些陈述看起来很武断，并且您认为该软件可以满足所有需求，但方式不同，那么它很可能更多地是关于设计而不是需求。一个设计objective说明了设计必须保证什么（含糊不清：在需求阶段，很难区分非功能性需求和设计objective）。设计决策是对软件的行为或结构的决策。
考虑到这一点，这里分析一下：
- 软件应该做什么 ==> 功能需求 (FR)
如果我们改变这个，软件将不再做预期的事情，所以它不能是一个设计决定。
- 软件应该如何 ==> 非功能需求 (NFR)
与软件的结构或行为无关。该语言不会影响用例或 class 模型，因此恕我直言，这并不是真正的设计决策。
- 关于对象模型中基数的任意决定 ==> 设计决定 (DD)
- "aim in the design" ==> 设计 objective (DO)
- 软件应该做什么 ==> FR
- 关于对象模型的任意约束==> DD
如果它不小于3或不小于10，软件仍然满足功能需求。然而，这取决于上下文。如果不遵守这些限制，结果表明该软件不适合用途，那么它可能是 FR。
- 对象模型的任意约束==> DD
此语句的目的不明确。它看起来像是一些可以允许概括某些类别的任意约束。
- 软件应该做什么 ==> FR
- 任意决定交互 ==> DD
我认为数据可以在另一个时刻输入，或者以不同的方式输入（3 次 1 个月）。所以我认为是DD。但是，有人可能会争辩说该系统应提供 3 个月的计划。所以不能排除 FR，尽管我希望它有不同的表达方式。
- 软件应该做什么 ==> FR
我需要class将以下 RQ 确定为
- 设计objective、
- 设计决策，
- 功能要求，
- 非功能性要求
（这样我以后可以根据它们做class图和用例图）。
我想知道我是否在正确的轨道上（粗体是我对每个要求的猜测）：
需求文档 采购承诺系统。
该软件用于计算工厂生产其产品所需采购的一些细节。 （设计决策）
软件必须在计算机IBM PC上用C++或Java编程语言编写。 （设计决定）
产品数量应等于 4。（非功能性请求）
软件设计的一个总体目标是提高软件的可移植性。 （非功能性要求）
系统应接受有关每种产品的详细数量、数量和价格的数据作为输入（制作为文本文件）。 （功能要求）
每类商品的详细信息数量不少于5.
第一类和第二类产品应该有2个相同的细节。第二类和第四类产品应该有一个相同的细节。第三类产品应该有 2 个与第四类产品相同的细节和一个与第一类产品相同的细节。 (设计Objective)
操作员需要通过用户名和密码登录和注销系统。 (设计Objective)
开始时，操作员必须提供以下数据项（应提供对输入数据的验证）：
- 工厂提前3个月生产的各类产品数量。 （功能需求）
软件必须为操作员的每个操作生成报告（报告应按操作员的要求保存在文件中）。报告必须包括：（功能或设计 Objective Req） -需要购买的每个细节的数量。
- 每个细节的总价。
- 所有细节的总价
我记得过去关于 RQ 是非 F 还是 F 的长期讨论。但是，Wikipedia 有一个简单的定义。
As defined in requirements engineering, functional requirements specify particular results of a system.
所以你的分类看起来不错。不过，我想知道您的前两个分类应该是什么。对于一个相当完整的列表，看起来有点像 MoSCoW, but then again it does not. Design decisions (at least to me) are nothing to be found in requirements. They are, what the name suggests, decisions coming from a design process. Further a design objective is a sub-category of NF. Even more important is the fact that your NFs are not classified. There should be at least a handful of sub-classes (legal, performance, etc.). See Wikipedia。
A functional requirement tells what the software shall do. A non functional requirement 讲述了一些关于 软件应该如何或它应该如何做它所做的事情。
软件设计是关于软件的结构和行为。如果某些陈述看起来很武断，并且您认为该软件可以满足所有需求，但方式不同，那么它很可能更多地是关于设计而不是需求。一个设计objective说明了设计必须保证什么（含糊不清：在需求阶段，很难区分非功能性需求和设计objective）。设计决策是对软件的行为或结构的决策。
考虑到这一点，这里分析一下：
- 软件应该做什么 ==> 功能需求 (FR)
如果我们改变这个，软件将不再做预期的事情，所以它不能是一个设计决定。 - 软件应该如何 ==> 非功能需求 (NFR)
与软件的结构或行为无关。该语言不会影响用例或 class 模型，因此恕我直言，这并不是真正的设计决策。 - 关于对象模型中基数的任意决定 ==> 设计决定 (DD)
- "aim in the design" ==> 设计 objective (DO)
- 软件应该做什么 ==> FR
- 关于对象模型的任意约束==> DD
如果它不小于3或不小于10，软件仍然满足功能需求。然而，这取决于上下文。如果不遵守这些限制，结果表明该软件不适合用途，那么它可能是 FR。 - 对象模型的任意约束==> DD
此语句的目的不明确。它看起来像是一些可以允许概括某些类别的任意约束。 - 软件应该做什么 ==> FR
- 任意决定交互 ==> DD
我认为数据可以在另一个时刻输入，或者以不同的方式输入（3 次 1 个月）。所以我认为是DD。但是，有人可能会争辩说该系统应提供 3 个月的计划。所以不能排除 FR，尽管我希望它有不同的表达方式。 - 软件应该做什么 ==> FR