我正在寻找编写项目或工作请求的技术规范和功能规范的好模板。
你们都用什么？在编写规范时，你们深入到哪个层次？我应该注意哪些一般性的建议？
我的公司非常需要这些。目前我们根本不使用这些文档。
编辑
我已经阅读了Joel有关Painless Specification的看法，我真的很喜欢它，但还有其他意见吗？
8个回答
32
关于通用技巧：
我们正在实施一个过程：
1）业务需求声明（BRS）
2）功能规格说明书
3）技术规格说明书
BRS涵盖了业务问题以及与解决方案、测试、安全性、可靠性和交付相关的要求。这定义了一个成功的解决方案。
功能规格详细说明了需要什么，它应该看起来像什么，字段长度等。
技术规格详细说明了数据来自何处，可能需要考虑的任何棘手的代码。
客户拥有需求。开发人员拥有技术规格，功能规格是一个中间地带。测试针对技术规格进行（通常是单元测试），然后针对功能规格进行（通常是系统测试），最后针对需求进行（UAT）。
重要的部分（我们正在努力解决的）是开发人员仍然需要按照功能规格和原始业务需求交付。实际上，功能和技术规格只是为了清晰而存在。
简而言之，我的主要建议是首先确定你希望实施的过程。然后寻求所涉及的所有方面的同意，然后制定适合的模板。模板本身只是你想要进行的变化的一小部分。
- Mark Nold
7
您可以从IEEE和其他地方购买模板，但我一直都是自己制作的。对于技术规范，《代码大全》（Steve McDonnell著）有一个很好的清单，您可以从中获取一些信息。在我的上一份工作中，我只是将他的章节标题制作成了模板，并从那里进行了微调。
至于功能规范，重要的是定义所有接口：
1. UI（屏幕模型） 2. 软件接口（插件等） 3. 硬件接口（如果适用） 4. 通信接口（服务、电子邮件、消息等）
还应该有一个业务规则部分，涵盖任何接口定义中未涉及但在功能上很重要的事项。
至于功能规范，重要的是定义所有接口：
1. UI（屏幕模型） 2. 软件接口（插件等） 3. 硬件接口（如果适用） 4. 通信接口（服务、电子邮件、消息等）
还应该有一个业务规则部分，涵盖任何接口定义中未涉及但在功能上很重要的事项。
- Guy Starbuck
3
从简单入手，逐步深入。由于这是您第一次使用此功能，因此请使用带有项目符号的Word文档。写下来后，请仔细阅读并提供足够的详细信息以使其有意义。对于技术规格，您可能需要引导开发人员走向解决方案，但对于功能规格，“如何”应完全缺失。
- srclontz
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接