可选要求的更好用词？[关闭]

对于软件工程中的可选要求，哪个词更好？这句话是矛盾的。我在先前的项目中使用了“非核心要求”。

可能会使用术语“超出范围要求”。这意味着该需求已在您的流程中捕获并且可以跟踪，但是由于多种原因，例如预算，进度，时间，或可行性。

但是，短语“可选要求”通常用于表示范围内的某些内容，但不一定是系统必需的。它是需求优先级的度量。以我的经验，需求通常被优先考虑为强制性，合意性或可选性（尽管还有其他方案）。为了使一个项目被认为是完整的和完整的功能，必须满足所有强制性要求。给定足够的资源，接下来将实现理想的要求。最后，将包括任何被认为是可选的内容。

我相信混淆来自“需求”一词。用英语来说，要求是“需要的东西”或“强制性，强制性或必要条件”。但是，在软件工程中，术语“需求”仅是软件系统的记录特征。可选和强制性的概念描述了软件系统已记录特征的优先级。

我们称它们为“好拥有”功能，而不是要求。

对于软件需求文档，只要您使用符合RFC 2119的术语来表示需求级别，那么“ 可选需求”一词就可以了 -即以表明是真正的可选项目。

当您的说明文字暗示动词而不是形容词时，请使用“ MAY”而不是“ OPTIONAL”。

由于它很小且易于阅读，因此以下完全引用了RFC文本：

    网络工作组S. Bradner
    请求评论：2119哈佛大学
    BCP：1997年3月14日
    类别：最新最佳实践


            RFC中用于指示需求级别的关键字

    该备忘录的状态

       本文档为以下内容指定了Internet最佳实践：
       Internet Community，并要求讨论和提出建议
       改进。该备忘录的分发是无限的。

    抽象

       在许多标准跟踪文档中，使用几个词来表示
       规范中的要求。这些话经常
       大写。本文档对这些词的定义应为
       在IETF文件中解释。遵循这些准则的作者
       应该在其文档的开头附近加入以下短语：

          关键字“必须”，“不得”，“必填”，“ SHALL”，“ SHALL”
          NOT”，“ SHOULD”，“ SHOULD NOT”，“推荐”，“ MAY”和
          本文档中的“可选”应按照
          RFC 2119。

       请注意，这些词的作用力已根据要求进行了修改
       使用它们的文档级别。

    1.必须（MUST）这个字词，或「REQUIRED」或「SHALL」一词，表示
       定义是规范的绝对要求。

    2.不得使用此短语或短语“应禁止”表示
       定义是对规范的绝对禁止。

    3.应该这个词或形容词“推荐”的意思是
       在特定情况下可能存在正当理由而忽略
       特定项目，但必须理解全部含义并
       在选择其他路线之前，请仔细权衡。

    4.不应使用此短语或短语“不推荐”表示
       在特定情况下，当
       特定的行为可以接受甚至有用，但是完整
       应该理解其含义，并仔细权衡案件
       在执行此标签描述的任何行为之前。

    5. MAY这个词或形容词“ OPTIONAL”表示某项是
       真正可选的。一个供应商可能选择包括该物品，因为
       特定的市场需要它，或者因为供应商感到
       它增强了产品的质量，而其他供应商可能省略了相同的产品。
       一个不包含特定选项的实现必须是
       准备与另一种实现互操作
       包括该选项，尽管功能可能有所减少。在里面
       同样的实现包括特定选项
       必须准备与另一个实现互操作
       不包含该选项（当然，该功能除外
       选项提供。）

    6.使用这些命令的指南

       必须谨慎使用本备忘录中定义的命令类型
       和谨慎地。特别是，它们只能用于
       互操作或限制行为的实际要求
       造成损害的可能性（例如，限制转发）
       例如，不得将其用于尝试施加特定方法
       在不需要该方法实现互操作性的实现者上。

    7.安全注意事项

       这些术语通常用于指定具有安全性的行为
       含义。不执行MUST或
       应该或按照规范的规定进行操作，不得或不应
       不做可能是非常微妙的。文档作者应该花时间
       详细阐述不遵循的安全隐患
       建议或要求，因为大多数实施者将没有
       受益于产生
       规格。

    8.致谢

       这些术语的定义是所用定义的组合
       来自许多RFC。此外，建议
       由包括Robert Ullmann，Thomas在内的许多人组成
       Narten，Neal McBurnett和Robert Elz。

如果您的文档将RFC作为定义的来源，则不会有什么坏处：

本文档使用基于RFC 2119中指定的定义。

我很高兴这不是您的问题的答案，但就我的世界而言，这仍然是一个要求，即使出于任何原因您都无法实现。

我喜欢MoSCoW方法（这次必须拥有，应该拥有，可以拥有，不会拥有）将需求与用户进行分类，以及其他因素（在我所管理的世界中，需求可能是关键的也可以是非关键的，而且很多争论超出了可选但很关键的要求。）

可选要求的一个更好的说法是“ 建议 ”

如何将其标识为可选功能或可选任务。仅在确定项目中的某个时间点有足够的时间和金钱来完成这些功能时，才可以执行这些操作。

如果发生外部事件，也可以触发它们。如果客户切换到Windows 8，则需要完成以下任务...

功能说明应包括确定是否完成的期限。

需求在软件工程中分为四个区域：

1. 业务需求：关注系统的总体业务目标
2. 用户需求：关注用户的目标以及用户使用系统实现业务目标所要做的事情
3. 功能需求：系统必须执行哪些功能和任务才能实现业务目标
4. 非功能性需求：除了功能性需求外，还有哪些需求。这包括环境，约束，界面，维护问题等。

现在，需求可以是Optional或Mandatory，具体取决于我上面概述的上述4类。可选要求也可以落入正在考虑的系统范围之内，也可以不在其范围之内。可选要求是避免“ 作用域蠕变”并准确定义您的作用域的好方法。

可选要求将始终是软件工程的一部分，因为它们可以帮助我们确定范围，并且是避免范围蠕变的好方法。您永远不能说它们与SDLC的工程实践相矛盾。但是，必须对需求进行优先排序和明确定义。

在Volere模板中，使用了“等候室”一词。

...此模板旨在用作您的需求规范的基础。该模板提供适用于当今业务，科学和软件系统的每种需求类型。它提供了清单，结构和可追溯性来满足您的需求...该模板是独立于工具的，并且已成功与Yonix，Requisite，DOORS，Caliber RM，IRqA和其他流行工具一起使用...

Suzanne Robertson和James Robertson 在“ 掌握需求过程 ”一书中描述了Volere技术。

在我的公司（航天器）中，它们被称为“目标”，表示已对其进行了记录，并会付出更大的努力来实现目标，但如果未达到目标，则该系统仍将被视为成功；“欲望”（不是一个真实的词，但是你有），表示有人想要它们，他们正在努力达到目标的状态，但尚未被接受或记录在案；或“爬行需求”，它是一种更贬义的需求，表示试图占用资源但在试图实现“足够好”的项目中不值得的东西，在这些项目中他们会妥协或威胁达到实际需求。

如果对您的要求进行了优先排序，则可以将其视为低优先级要求。

我很惊讶，没有人提到这些被称为“目标”。我工作过的每个公司都给他们打电话。通过使用单词“将”或“应该”代替“应”来表示它们。有时，当谈论数字时，它们会包含在大括号中。例如，系统应连续运行100 {250}小时而无需操作员注意。这意味着必须满足的要求是100小时，但目标是250小时。

附带说明一下，除非涉及某种形式的激励措施，否则很少有人真正设计出满足目标要求的产品。

术语“需求”有时用于可选要求。但是，它可能不适用于正式文件。

我很惊讶所有答复都与项目开发中的跟踪要求有关。尽管是一名开发人员，但我从来没有担心这种情况下的过多术语。当我第一次阅读该问题时，我认为它与用户产品规格有关，而不与产品开发有关。例如，百科全书可能将彩色打印机列为可选要求。如果您想充分利用该应用程序，则需要它，但如果要查看屏幕，则是可选的。但是，如果您有例如黑白打印机该怎么办？如何明确您的应用程序是否在某些照片看起来不太好的严格限制下工作？还是根本不打印？再举一个例子，我应该如何检查打印机评论，以检查多功能打印机中墨水是必需还是可选的要求？换句话说，我仍然可以扫描吗？无论是作为产品开发者/销售者还是作为消费者，都欢迎有关术语和搜索内容的一些提示。

我将它们称为“可选功能”，而不是可选要求。需求听起来像您必须拥有的东西，而功能听起来像是原始产品的附加组件。