为什么软件需求总是用“应该”而不是“将要”表述？
为什么当我logging需求时，它总是被称为“它应该这样做”与“它会这样做……”。
我知道这是一个奇怪的问题，但我从来没有find答案。 一直以来，“这就是你写的”。 我知道这是一个愚蠢的问题，但总是困惑着我。
基本上， RFC 2119是这样说的。 真正的答案就是英文不准确，除非你特别用人们多说的话来说明你的意思，而不是人们喜欢阅读的东西，有人花时间来说明某些单词应该是什么意思。
英语语法。 对于第二和第三人来说， 意志是说明性的 ，而第一人称是相反的。
经典的例子：
在水里挣扎：“没有人会救我，我会被淹死的！”
自杀：“没有人会救我，我会淹死！”
“意志”只是表示意图。 你可能会说：“我会修复这个错误”（你打算）
“应”表示义务。 你的老板可能会说“你应该修复这个bug”（这是一个命令）
请参阅http://en.wiktionary.org/wiki/shall和http://en.wiktionary.org/wiki/will
这可能是一个奇怪的答案，但是……我相信在要求文件中根本不需要使用“应该”，“应该”，“可能”和其他模态动词。 所有这些动词只会使文件难以书写，最重要的是难以阅读。 （而且我确信，可读性差就是为什么需求文档经常不能清楚地定义软件系统应该为其利益相关者做些什么的几个最主要的原因之一。
为什么使用“应”是如此普遍？
那么，正如其他答案中提到的那样，一个可能的原因是这种做法只是从法律文件中借来的。 很显然，要求确实代表了与客户的合同，所以将其与其他合同文件（即法律文件）联系起来似乎是自然的。 那么，我们都知道人们喜欢阅读法律术语。 🙂
还有些人认为将RFC 2119中定义的“必须/应该/可能的约定”应用于软件需求是有用的。 为什么？ 坦率地说，它击败了我。 在我看来，这是滥用好主意的典型例子。 在定义非常技术性的协议，接口或其他允许不同级别遵从的标准时，这些约定可能是有用的。 但即使在这种情况下，我认为这并不是实现目标的最有效方式。 我敢肯定，如果不把所有这些大写的SHALL，SHOULD和MAY都散布在散文之中，作者会清楚地标出每个要求并提供一个强制性的|推荐的|可选的属性。
我相信软件要求不应该用法律书写（除非你有一些奇怪的客户需要这样做）。 我相信，任何要求声明都更易于用现在时态和主动语态来书写和阅读（并保持）。 另外我认为“可选性级别”对于软件要求并不是一个好的内在属性。 每个需求必须具有优先级作为其内在属性（例如，这将有助于确定给定需求的实现是强制性的，推荐的还是可选的 ）。
因为我们总是有90％完成 ，那个function还没有在那里;）
编辑以前的评论 – 我吠叫错了树:)
我想是因为软件要求和规范文件的起源是合法的（即明确详细说明开发合同的期望），因此它们inheritance了一些法律惯例，如“应”而不是“意志”。
我曾经用“shall”而不是“will”来要求，但被要求把“should”改成“will”。
当我在要求文件中提到“下一个屏幕应该出现”时，也许我正在考虑可能出错的事情。 我的老板认为这听起来很虚弱，并要求我把它改成“下一个屏幕会出现”。
使用更具有启发性，宣布应该是什么。
威尔可以用来代替应用，但也常用来描述在某些条件下实际发生/观察到什么（并且预期的行为可能相对于给定的规范或理想应该发生或不应该发生）。
在国家电气规范</ nonprogramming> </ formerlife>中，他们使用“Shall”来表示一种重要性，缺less一个选项或备选scheme。 你要这样做，这样就没有别的办法了，如果你不按我们这里所说的方式去做，那你就错了。 应该取代一切（通常甚至是“例外”）。 就像其他人所说的那样，它来自法律背景。
“可以”，“可以”是用来表示你有select的事情，“应”表示你没有发言权; 这只是他们的方式，它将会完成。 ;）
对于我们非英语母语的其他帮助：
乍一看，“会”和“应该”与我们没有太大的区别，因为它们不是每天都用在我们听或读的英语中。 另一方面，“会”和“应该”比较常见，而且他们的区别比较熟悉，所以你可以把“意志”和“会”，“应该”和“应该”（然后“可以”和“可以“，如果不是已经）以某种方式在你的脑海里。
@Brent Longborough：谢谢你给出的例子和解释。 应该有一种方法来移植这样的基础知识。
- “Will”会宣告未来，至less你打算如何
- “应”指示必须做什么
这就是为什么规范使用“应”，而新年好的决议和星座运用“意志”。
一个。 本文中的“应”一词用于表示规范的强制性条款。
湾 本文中的“应该”一词用于表示规范中的一个理想的但不是强制性的项目。
C。 本文中的“will”一词用于表示将来的意图expression，但不是说明书的强制性条款。
d。 文中的“必须”一词表示一个假设，其实现超出了本文的范围。
即 文中的“可能”一词expression了一个可允许的做法或行为。 它不表示规范的要求。
F。 使用现在时态（例如，是）表示相关语句是支持说明书提供的解释性材料。
你有规范的答案，但在工作中的“如何编写要求”文件提供了一个更多的：
“应该”描述一个要求，即你的软件需要做的事情
“意志”将描述一个事实，即不pipe你的软件是否做它的事情都会发生
避免整个问题，并捕捉用例的需求。
如果你打算使用需求清单，我同意Yarik。 用动词或名词写出主动语态并开始要求陈述。
