10

在工作中,我经常负责编写规范,我也是一开始就坚持要获取规范的人。问题是我不确定规范应该是什么样子以及它们应该包含什么。很多时候,当我的老板编写规范时(我们都缺乏经验),他们会输入表名和我认为不属于那里的东西。那么什么是学习编写好的规范的好方法呢?

编辑:功能规范是否应该包括假设我正在指定一个 Web 应用程序、输入类型(文本框、下拉列表等)?

4

5 回答 5

11

在我看来,开发文档中最重要的部分是让正确的人来做。

  • 需求文档 - 用户 + 业务分析师
  • 功能规范 - 业务分析师 + 开发人员
  • 技术规范(如何实际实现功能) - 高级开发人员/架构师
  • 用于调度目的的时间估计 -分配给任务的特定开发人员

让除高级开发人员/架构师之外的任何人定义表结构/接口等是徒劳的——因为更有经验的开发人员通常会将大部分内容扔掉。

Wikipedia 实际上是功能规范的一个良好开端,它看起来类似于您的规范 - http://en.wikipedia.org/wiki/Functional_specification

于 2008-09-22T03:16:05.653 回答
4

Steve McConnell 的Code Complete中有一个很棒的章节贯穿规范文档以及它们应该包含的内容。

当我的任务是在一家从未有过的公司建立架构和业务分析团队时,我使用 McConnell 的规范章节来创建技术规范文档的大纲。它随着时间的推移而发展,但从这个框架开始,我确保我们没有遗漏任何东西,结果证明它非常有用。

在编写规范时,我遵循的经验法则是尝试让技术文档始终从一般开始并转向具体——始终重申正在开发技术解决方案的业务问题或目标解决,因此阅读规范的人不需要去其他文档将其置于任何类型的上下文中。

于 2008-09-22T03:24:44.370 回答
2

请参阅Joel Spolsky 的无痛功能规格

他说每个规格都应该具备的一些东西:

  • 免责声明
  • 一位作家。一位作者
  • 场景
  • 非目标
  • 概述
  • 细节,细节,细节
  • 开放式问题
  • 旁注
于 2008-10-23T19:48:34.100 回答
1

重要的是把一些东西写下来,而不是担心格式。

于 2008-09-22T03:14:12.913 回答
1

购买书籍:Ian Sommerville 和 Pete Sawyer 的需求工程 ISBN 0-471-97444-7 或 Karl Wiegers 的软件需求 ISBN 0-7356-0631-5

于 2008-09-22T03:28:55.357 回答