在编写设计规范文档时，我应该使用将来时态还是现在时态？

Question

我正在为一个大学项目写一份设计规范文件，并想知道我应该使用的时态。项目上的开发还没有开始，我只是在编写UI设计部分。

我是否应该使用：

这个应用程序是围绕一个两列布局，有一个标题元素。

或

这个应用程序将围绕一个带有标题元素的两列布局构建。

显然，在整个文件中，无论时态如何最好，我都会继续。

编辑来澄清我实际上在写什么

课程模块描述者说：

基于需求规范的详细的“设计规范”。完整的设计规范应该是全面的，并且应该允许第三方使用您的设计规范作为实现的基础。因此，它应该清楚、简明和详细。它可能包含:导航地图，清楚地显示如何链接各种页面或屏幕；一系列详细的故事板，用来说明页面布局、颜色方案、排版(字体、大小、样式、对齐)、媒体元素的使用(如图标、图形、声音、视频、动画)或交互样式。还应提出设计决定的理由。

Answer 1

这取决于你在写什么。

如果你在写要求，那么答案是“两者都不写”。另一个问题，在这里，软件工程解决了在编写需求时使用“应”和“必须”的问题。我在工作中使用的指导是，“应”是用来表示必须满足的任何要求，以使软件能够为客户所接受，“应该”标记期望的特性，“可能”用于标识任何可选的内容，而"will“是在强制和任何期望的或可选的特性实现后可以依赖的任何内容。如果不是以语句的形式编写需求，而是使用用例或用户故事，则需要遵循这种格式的约定。

如果你写的是已经存在的软件，那么你应该使用现在时态。这个软件已经存在了，所以它是“某物”或“做”某物。

如果您试图同时定义需求并记录设计方法，我建议不要这样做，并理解将软件必须公开的功能和软件的非功能属性分离开来的价值，而不是记录软件如何分解或如何使用软件。需求、技术设计和使用(用户手册)的分离是非常重要的。

为了满足你的具体需求，我认为最好的办法就是问问你的课程指导员或其他人，他们知道他们在寻找什么。在我的经验中，这种类型的文档并不存在于任何形式的现代软件开发中，因此询问专业的软件工程师如何生成一个您特定的客户(在本例中是您的教授或评分师)可以接受的文档不会给您最好的答案，尤其是因为我不认为“不要这样做，这是不太好的实践，看看您的开发方法和方法”的答案会让您在这个过程中走得更远。

基于需求规范的详细的“设计规范”。完整的设计规范应该是全面的，并且应该允许第三方使用您的设计规范作为实现的基础。因此，它应该清楚、简明和详细。它可能包含:导航地图，清楚地显示如何链接各种页面或屏幕；一系列详细的故事板，用来说明页面布局、颜色方案、排版(字体、大小、样式、对齐)、媒体元素的使用(如图标、图形、声音、视频、动画)或交互样式。还应提出设计决定的理由。

需求规范是软件实现的基础，无论是内部团队还是外部团队。它不仅应该具有您的功能特性，而且应该具有设计约束、性能和其他质量属性、用户特性、所需的界面等等。需求规范是客户和软件供应商之间的协议。

你被告知要放进文档中的确实是设计信息。但是，它与软件开发的“前期大设计”方法是一致的，在这种情况下，在“完成”设计之前不编写代码。但是，我不知道有很多组织采用这种方法。

Answer 2

考虑到你的文档是否会在软件完成后被阅读！

如果你正在写一份描述你想要构建的东西的提案，那么未来时态是可以的。

如果您想要编写在软件生命周期内将被维护的设计文档，那么未来时态就没有意义了，您应该使用“现在时”。毕竟，文档将描述您的软件是如何设计的。

Answer 3

--没关系，

重要的是规范的内容，而不是表示--“演示”包括语言之类的内容。这里的例外是，如果表现如此糟糕，读者在理解内容时会受到很大的阻碍，但是现在时态与未来时态并不会造成这种问题。