软件开发，或者更具体地说，规范编写的常规步骤是什么？

我知道一些概念，例如瀑布方法，收集规范，用例等。但是，我想对此进行更正式的解释。

解决方案

回答

我发现公司通常是：

• 不要做规格。
• 有一个规格模板。每个规范看起来都与其他规范相同(即"标准")-它们都有相同的部分。

我也不喜欢每个规格都不同。试图使其适合于刚性模板，就像将书写成模板一样，儿童读物与成人书不同，烹饪书与...不同。

有些规格需要详细说明技术细节(例如文件格式)，但从用户角度介绍某些规格时就可以了(单击时执行x的按钮)。

我所见过的最好的规范是我可以接受并做的事情，而不必问规范作者任何问题。如果我必须提出问题，那么我认为该规范已失败。规范应该回答我所有的问题。

在编写规范时，我总是将其打印出来并阅读(打印时发现更多错误)。然后，我将其放置一天，然后再次阅读。如果发现任何错误或者遗漏任何内容，请更新规范，将其打印出来并阅读，然后放置一天。我一直这样做，直到没有发现任何问题为止。

规范应该易于阅读。我曾经收到一份120页的规格书，没有目录，没有页码。我要求规范编写者放入目录，她的回答是"不，我希望人们阅读规范以找到所需的内容，此后他们会阅读更多的内容"。我浪费了很多时间在规范中寻找所需的东西。那是一个糟糕的规格。

无论我们使用哪种方法编写规范，都没有关系，重要的是。该规范应易于阅读并回答所有问题。

回答

我们为规格使用基本模板，但是对于是否需要包括所有部分，我们具有一定的灵活性。我通常会提供一个目录，如果需要的话还会提供一个表格(用于屏幕截图，错误消息等)。

有时，我们从功能或者增强功能入手，编写完整的规范，然后进行编码。其他时候，我们将开始对其进行编码，然后回过头来根据事实充实规范。两种方法都对我们有用。我们的规范通常从用户的角度描述该功能的工作方式，尽管有时我们会包括一些技术细节，例如新表定义或者对现有类/模块/表单的更改。

我同意Dan的观点，如果最终结果对阅读它的人有用，那么这是一个很好的规范。我确实认为某种同意的格式是很好的，因此在查看多个规格时，我们可以快速找到某些类型的信息。

回答

Joel在这个主题上有一系列文章，他的建议(我同意)是为重要功能编写简短的清晰规范，然后将其传递给开发人员进行工作。

我们可能不希望做的是，在开始时尝试确定整个项目中的所有内容。坚持更高级别的规格，并在准备实现功能时逐步深入研究更多细节。这样，我们应该没有太多的文档开销，并且在开发之前没有太多的机会使规范过时(如果我们提前数周或者数月就这样做了)。

回答

我们是什么类型的规格？适合我们使用的规范取决于团队，他们将使用该规范以及任何项目文档要求。

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

开发开始后通常不维护功能规范。通常，功能规范是在项目开始之前建立的，用于评估项目的规模。与我一起工作的一位建筑师在Power Point中编写了一种功能规范。他参加了所有技术性和非技术性会议。它充满了易于阅读的带有点的图和页面，这些点和页面就像该项目的使命声明一样。

在整个项目中有时都会维护技术规范。如果保持最新状态，则可以用作维护参考。

回答

我同意@Dan的观点，每个规范都是不同的，并且看起来可能会非常不同。对我来说，重要的是要有一个使利益相关者都满意的一致流程，以及使他们的生活更轻松的任何工具(例如BRS模板)。

以下是对类似问题的一些解释。

我所看到的步骤是；

• 业务需求声明(BRS)
• 功能规格
• 技术指标

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

功能规范详细说明了所需内容，外观，字段长度等。

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

客户拥有需求。开发人员拥有技术规范。功能规范是中间立场。先根据技术规格(通常是单元测试)进行测试，然后对功能规格(通常是系统测试)进行测试，然后再对需求(UAT)进行测试。

重要的是，开发人员仍然需要交付功能规范，最重要的是满足原始​​业务需求。实际上，BRS在所有这一切中都是上帝，功能和技术规范只是为了清楚起见。