编写要求时应使用和必须使用的最佳实践

我之前发送了一封电子邮件，提醒我们的开发人员，在派生的需求中使用“应”一词不应追随您的功能需求。在编写功能需求时，单词“必须”用于描述派生的需求必须执行的功能。
派生=系统应为
功能正常=系统必须执行要求

它是由我们的一位前辈寄回的，这是错误的，应该在所有要求中使用。

我在这里错了吗？应该在所有要求中使用Shall。我还找不到任何东西可以支持它。

RFC 2119 “在RFC中用于指示需求级别的关键词”详细介绍了需求中不同词语的含义。

本文档中的关键词“必须”，“不得”，“必须”，“应”，“应禁止”，“应”，“不应”，“推荐”，“可以”和“可选”是按照RFC 2119中的描述进行解释。

从此文档：

• MUST等价REQUIRED并SHALL表明该定义是绝对必要。
• MUST NOT等同于SHALL NOT并表示这是对规范的绝对禁止。
• SHOULD等同于RECOMMENDED意味着有正当理由忽略特定要求，但需要权衡其含义。
• SHOULD NOT并且NOT RECOMMENDED意味着某种特定行为可能是可接受的或有用的，但同样，需要权衡这些含义。
• MAY意味着OPTIONAL需求确实是可选的。必须与可能实现或可能不实现可选要求的不同系统实现互操作性。

遵循此RFC SHOULD可以帮助确保内部文档与整个标准世界之间通信的一致性。

不知道您得出的结论是，shall并且must属于不同的文档级别。这是一个相当随意的区别，我所知道的任何来源都没有支持。

Shall并且must在词汇上是等效的。这是必需的操作。

是否使用shall还是must真的取决于要编写的文档的其余部分以及该特定句子的语法意义。

所以是的，你错了。但您始终使用shall而不是也是错误的must。它们代表相同程度的义务。

如果你碰巧的框架内工作DO-178或DO-254的指导方针，这些都有自己的定义，要求，一般和衍生的要求。但是，这些准则未指定应使用哪个词（例如应，必须，必须）来指定要求。

如果您的需求管理工具不会自动指出你派生需求，通过使用的使这些不同的功能要求必须的，而不是应 是有益的，例如证明派生需求核查目标也已达到。这可能是看似随意的文档要求的可能原因。

请注意，在DO-178和DO-254 衍生的要求实际上意味着已要求没有得到来自上级的要求的。因此，派生的需求本质上启动了新的可追溯性链。

DO-178和DO-254都是用于航空电子软件和电子设备开发的商业指南文件，只能从www.rtca.org上付费获得。