问在功能需求文档中，假设部分是否危险？

EN

遵循建议的指导，将假设从功能需求文档中排除在外，取决于以下几点。

首先，文化和项目有多严格？

有时，建议的做法被视为事实上所需的做法。这是“良好的做法”，以确保这些事情是多么强烈地被推荐，而在实践中，这些东西是必需的。努力让你知道，如果你坚持或不遵守“指导”，后果会是什么。这是我的免责声明。

第二，指导背后的理由是什么？

那么，指导功能性需求、文档编制者和贡献者的理由是什么，而不包括专门讨论假设的部分？

在我的经验中，人们和项目有时会以不同的方式看待功能需求。在某些情况下，功能需求(所发生的和排序的或发生的事情)明显不同于系统或服务需求(在哪里或如何发生)。当系统或环境是工作的中心(例如，设备或服务接口或设备驱动程序)时，找出区别可能会被证明是比它更有价值的工作，因此在这些情况下，我会声明这是我的第一个假设，然后继续前进。

在功能性需求文件的情况下，不包括假设部分的理由可以推定为，如果一节假设是必需的，那么也许需求就不起作用了。换句话说，如果您认为应该对包含的需求进行文档化的相关假设；需求可能对实现或特定服务过于具体，并且可能不属于该特定文档。另一方面，也许这些要求确实属于，但只是以一种不同的方式重写，而不是那么具体，以至于某个具体的实现和相关的假设就不再适用了。其目的可能是，该指南不是一项禁止，而是作为对文件编制者和撰稿人的一种健全检查或橙色标志。

如果我要从最严格的意义上处理功能需求文档，系统和服务需求就不会出现在那里。如果这些类型的需求不包括在功能规范中，那么您就不太可能需要做出或声明任何类型的全局假设(通常是与环境或用户相关的)。如果您发现全局假设开始应用于所包含的需求，它可能表明需求不是作为功能需求编写的，或者是环境或用户是工作的中心。

如果没有假设部分，那么程序员在编写代码时就会有未知的假设。

当你在做一些事情的时候，你必须不断地做出深思熟虑和不明智的假设--你最好把它们写下来。

假设是一个强有力的词。你肯定想要一个假设部分。但你也确实想要验证这一部分的准确性。

例如，如果你在设计一个假设所有用户都是高级用户的应用程序，那么它最好是真的。

因此，基本上，把它称为你想要的(假设，先决条件，任何东西)，但它需要在那里，这样人们才能意识到是什么驱动了你的设计选择。