因此，基本上，我正在寻找用于在项目或者工作请求上编写技术和功能规格的良好模板。

你用什么？编写规范时我们有多深入？我们可以提供的任何其他一般性提示将不胜感激。

我公司急需这些。我为承包商工作，现在我们根本不使用这些文件。

编辑：我读过乔尔关于无痛规范的观点，我真的很喜欢它，但是还有其他意见:)

解决方案

回答

如果我们想购买一本书，Karl Wiegers的《软件要求》有一些文档的模板作为附录。不幸的是，我在工作，那本特定的书在家里。如果有人方便使用，他们也许可以确认。

回答

我们可以从ieee和其他地方购买模板，但是我总是最终自己制作模板。

对于技术规范，史蒂夫·麦克唐纳(Steve McDonnell)的"代码完成"(Code Complete)有一个不错的清单，我们可以从中获取一些信息。在我的上一份工作中，我只是从他的节标题中制作了一个模板，然后从那里对其进行了调整。

就功能规范而言，重要的是定义所有接口：

• UI(屏幕模型)
• 软件界面(插件等)
• 硬件接口(如果适用)
• 通讯界面(服务，电子邮件，消息传递等)

还应该有一个有关业务规则的部分，这些规则在功能上很重要，而任何接口定义中都没有涉及。

回答

不是模板，但是Joel写了几篇有关编写功能规范的文章。他在这里也有样品。

回答

我碰巧喜欢其中之一：ReadySet。

他也出售专业版。

回答

从简单开始，然后从那里开始。由于这是我们第一次使用该文档，因此请使用带符号的Word文档。编写，重新阅读并提供足够的有意义的细节。对于技术规范，我们可能希望引导开发人员寻求解决方案，但是对于功能规范，应完全缺少"方法"。

回答

我建议在这里看看Roberston的Volere模板。它们与" Peopleware"成名的汤姆·德马科和蒂莫西·李斯特等人一起是大西洋系统协会的一部分。

由于模板受版权保护，因此我不会在此处复制它，而是为我们提供一些主要的标题：

• 项目目的
• 利益相关者
• 强制约束
• 命名约定和术语
• 相关事实和假设
• 工作范围
• 业务数据模型和数据字典
• 产品范围
• 功能要求
• 外观要求...

还有更多，但这应该可以给我们一个想法。模板最有趣的部分是需求外壳，该外壳列出了某种提示卡上的功能需求。再次受版权保护，但确实有价值。

在第9章中查看。

回答

一般提示；

我们正在实施

1)业务需求声明(BRS)

2)功能规格

3)技术指标

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

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

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

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

其中(我们正在努力)的重要部分是，开发人员仍然需要交付功能规范以及原始的业务需求。实际上，功能和技术规格只是为了清楚起见。

简而言之，我的主要技巧是首先制定我们希望实施的流程。然后，与我们提议的过程中涉及的所有各方寻求协议，然后研究适合的模板。模板本身只是我们要更改的一小部分。