62

所以基本上我正在寻找好的模板来编写项目或工作请求的技术和功能规范。

你用什么？在编写规范时你能深入到什么程度？您可以提供的任何其他一般提示将不胜感激。

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

编辑：我读过 Joel 对Painless Specification的看法，我真的很喜欢它，但还有其他意见吗 :)

4

8 回答 8

32

关于一般提示；

我们正在实施一个流程

1) 业务需求声明 (BRS)

2) 功能规格

3) 技术规格

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

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

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

The customer owns the requirements. The developers own the tech specs, and the functional spec is a middle ground. Testing is done against the tech specs (usually unit testing) then against the functional specs (usually system testing) and then against the requirements (UAT).

The important part of this (and we are struggling with) is that the developers still need to deliver to the functional spec, and the original business requirements. In reality the functional and tech specs are just there for clarity.

In short, my main tip is to first work out the process you wish to implement. Then seek agreement from all parties involved in your proposed process, then work on the templates to fit. The templates themselves are only are a small part of the change you want to make.

于 2008-09-09T18:00:49.780 回答
18

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

于 2008-09-09T16:40:02.313 回答
7

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

对于技术规范，Steve McDonnell 的“ Code Complete ”有一个很好的清单，您可以从中获取一些信息。在我的上一份工作中，我只是从他的部分标题中制作了一个模板，并从那里进行了调整。

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

  1. UI（屏幕模型）
  2. 软件接口（插件等）
  3. 硬件接口（如果适用）
  4. 通信接口（服务、电子邮件、消息传递等）

还应该有一个业务规则部分，即在任何接口定义中都没有涵盖的重要功能。

于 2008-09-09T16:39:31.393 回答
6

如果您想购买一本书，Karl Wiegers 的 Software Requirements提供了一些文档的模板作为附录。不幸的是，我在工作，那本书在家里。如果有人方便的话，他们也许可以确认这一点。

于 2008-09-09T16:29:57.127 回答
5

我碰巧喜欢这个，其中包括：ReadySet。

他也卖专业版。

于 2008-09-09T16:56:30.527 回答
5

This is the best one I have found: http://www.jiludwig.com/templates/FRDTemplate.doc

于 2015-08-24T15:39:39.360 回答
3

从简单开始，然后按照自己的方式工作。由于这是您第一次使用此功能，因此请使用带有项目符号的 word 文档。写下来，再读一遍，并提供足够的细节，让它有意义。对于技术规范，您可能希望引导开发人员找到解决方案，但对于功能规范，“如何”应该完全缺失。

于 2008-09-09T17:40:39.203 回答
3

我建议在这里查看 Roberston 的 Volere 模板。他们是大西洋系统协会的一部分，与 Tom DeMarco 和“Peopleware”成名的 Timothy Lister 等人一起。

由于模板是受版权保护的，我不会在这里复制它，但给你一些主要的标题：

  1. 项目目的
  2. 利益相关者
  3. 强制约束
  4. 命名约定和术语
  5. 相关事实和假设
  6. 工作范围
  7. 业务数据模型和数据字典
  8. 产品范围
  9. 功能要求
  10. 外观和感觉要求...

还有更多，但这应该给你一个想法。模板中最有趣的部分是需求外壳，它列出了一种提示卡上的功能需求。再次受版权保护，但真正有价值。

请看第 9 章。

于 2008-09-09T17:45:16.277 回答