编写项目规范，传统路线

Question

软件开发的一般，传统步骤/阶段是什么，或者更具体地说，是规范编写？

我知道瀑布方法，收集规范，用例等概念。但我想要一个更正式的解释。

Answer 1

我发现公司一般都是：

1. 不要做规格。

2. 有一个规范模板。每个规范看起来都像其他规范（即“标准”） - 它们都有相同的部分。

我也不喜欢。每个规格都不同。试图让它适合一个严格的模板就像把书写到模板上 - 儿童书与成人书不同，烹饪书不同于...... ....

某些规范需要进入技术细节（例如文件格式），但是从用户的角度出现时，其他规格也很好（单击时按钮会显示x）。

我见过的最好的规格是我可以采取的，并且无需询问规范作者任何问题就可以做到。如果我不得不提问，那么我认为规范失败了。规范应该回答我的所有问题。

当我编写规范时，我总是将其打印出来并阅读它（我在打印时发现更多错误）。然后我离开它一天再读一遍。如果我发现任何错误或想到任何错误，我会更新规格，将其打印出来并阅读并保留一天。我一直这样做，直到我发现它没有任何问题。

规范应该易于阅读。我曾经拿过一个120页的规格，没有目录，也没有页码。我要求规范作者提交一份目录，她的答案是“不，我希望人们阅读规范，找到他们正在寻找的东西，从那以后他们会阅读更多内容”。我浪费了很多时间来查看那些寻找内容的规范。这是一个糟糕的规范。

无论你用什么方法来编写规范都没关系 - 结果是重要的。该规范应易于阅读并回答所有问题。

Answer 2

乔尔有关于topic的一系列文章，他的建议，我同意，是为重要的功能编写简短的规范，并将它们传递给开发人员。

您可能不想做的是尝试在开始时指定整个项目中的所有内容。坚持使用更高级别的规范，并在准备好实现功能时逐步了解更多细节。这样你就不会有太多的文档开销，并且你的规范在开发之前没有那么多的机会变得过时（如果你提前几周或几个月完成它）。

Answer 3

您的意思是什么类型的规格？您使用的正确规范将取决于您的团队，他们将使用规范和任何项目文档要求。

规格应针对目标受众量身定制，并应考虑文档的预期使用期限。我使用了功能规格和技术规格。对于功能规范，主要目标受众是客户端，对于技术规范，目标受众是开发人员和IT团队（用于部署）。

开发开始后通常不会保留功能规格。通常，功能规范是在项目开始之前构建的，用于评估项目的大小。我工作的一位建筑师在Power Point中编写了一种功能规范。他把它带到了他所有的技术和非技术会议上。它充满了易于阅读的图表和带点点的页面，我们使用这些点作为项目的任务声明。

技术规范有时在整个项目中得到维护。如果保持最新，它可以用作维护的参考。

Answer 4

我同意@Dan，每个规格都不同，可能看起来很不一样。对我而言，重要的是拥有一个让利益相关者都满意的一致流程，以及任何能让他们的生活更轻松的工具（如BRS模板）。

以下是similar question的一点点。

我看到的步骤是;

1. 业务要求声明（BRS）
2. 功能规格
3. 技术规范

BRS涵盖了业务问题，以及解决方案，测试，安全性，可靠性和交付方面的要求。这定义了什么将成为一个成功的解决方案。

功能规范详细说明了所需的内容，外观应该是多长，等等。

技术规范详细说明了数据的来源，可能需要考虑的任何棘手的代码。

客户拥有这些要求。开发人员拥有技术规范..功能规格是一个中间立场。测试是根据技术规范（通常是单元测试）进行的，然后是针对功能规范（通常是系统测试），然后是针对需求（UAT）。

这一点的重要部分是开发人员仍然需要提供功能规范，最重要的是原始业务需求。实际上，BRS在所有这些方面都是上帝，功能和技术规范只是为了清晰起见。

Answer 5

我们为规范使用基本模板，但我们在是否需要包含所有部分方面具有一定的灵活性。我通常会包含一个目录，如果需要，还可以包含一个数字表（用于屏幕截图，错误消息等）。

有时我们从功能或增强开始，编写完整的规范，然后进行编码。其他时候我们会开始编码然后返回并在事后充实规范。这两种方法都适合我们。我们的规范通常会从用户的角度描述该功能的工作原理，尽管我们有时会包含新表定义或现有类/模块/表单更改等技术细节。

我同意丹，如果最终结果对那些阅读它的人有用，那么这是一个很好的规范。我认为有一些商定的格式是好的，所以你在查看多个规格时可以快速找到某些类型的信息。