在工作中我经常负责编写规范，而且我也是坚持首先获得规范的人。问题是我不确定规范的外观和应该包含的内容。很多时候，当我的老板在编写规范时（我们都缺乏经验），他们把表名和我认为不属于的东西放在那里。那么学习编写好规范的好方法是什么？
编辑：功能规范是否应包括假设我指定Web应用程序，输入类型（文本框，下拉列表等）？
答案 0 :(得分：10)
在我看来，开发文档中最重要的部分是让正确的人去做。
除了Sr. Developer / Architect之外，任何人定义表结构/接口等都是徒劳的 - 因为经验丰富的开发人员通常会把大部分内容抛出。
维基百科实际上是功能规范的良好开端，它似乎与您的规范相似 - http://en.wikipedia.org/wiki/Functional_specification。
答案 1 :(得分：3)
史蒂夫麦康奈尔的Code Complete中有一个很好的章节贯穿规范文档及其应包含的内容。
当我的任务是在一家从未有过的公司建立架构和业务分析团队时，我使用McConnell的规范章节来创建技术规范文档的大纲。它随着时间的推移而发展，但是从这个框架开始，我确保我们没有错过任何东西，结果令人惊讶地可用。
在编写规范时，我遵循的经验法则是尝试让技术文档始终从常规开始并转移到特定的 - 始终重申技术解决方案所针对的业务问题或目标正在开发解决问题，所以阅读规范的人不需要去其他文档就可以将其置于任何环境中。
答案 2 :(得分：2)
见Joel Spolsky的Painless Functional Specs。
他说每个规范应该有的一些事情：
答案 3 :(得分：1)
重要的是要记下一些东西，而不是担心格式。
答案 4 :(得分：1)
购买书籍： Ian Sommerville的工程需求工程Pete Sawyer ISBN 0-471-97444-7 要么 Karl Wiegers的软件要求ISBN 0-7356-0631-5