学习编写规范有哪些资源?

时间:2020-03-06 14:31:18  来源:igfitidea点击:

在工作中,我经常负责编写规范,而且我还是坚持要首先获得规范的人。问题是我不确定规范的外观和内容。很多时候,当我的老板在写规范时(我们俩都没有经验),他们把表名和我认为不属于的东西放进去。那么,学习编写好的规范的好方法是什么?

编辑:功能规格应该包括诸如假设我指定一个Web应用程序,输入类型(文本框,下拉列表等)之类的内容吗?

解决方案

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

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

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

除了高级开发人员/架构师之外的任何人定义表结构/接口等都是徒劳的,因为经验丰富的开发人员通常会将其中的大部分扔掉。

Wikipedia实际上是Functional Spec的一个良好的开端,似乎与Spec http://en.wikipedia.org/wiki/Functional_specification相似。

史蒂夫·麦康奈尔(Steve McConnell)的《代码大全》中有一章非常出色,贯穿规范文档及其应包含的内容。

当我受命在一家从未有过的公司中建立架构和业务分析团队时,我使用了McConnell的spec章节来创建Technical Specification文档的大纲。它随着时间的推移而发展,但是通过从这个框架开始,我确保我们不会遗漏任何东西,并且事实证明它非常有用。

在编写规范时,我遵循的经验法则是尝试使技术文档始终从一般文档开始,转而针对特定文档-始终重申要开发技术解决方案以解决的业务问题或者目标,因此阅读规范的人无需转到其他文档即可将其置于任何上下文中。

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

参见Joel Spolsky撰写的《无痛功能规范》。

他说,每个规范都应具备以下几点:

  • 免责声明
  • 一位作家。一位作者
  • 情境
  • 非目标
  • 概述
  • 细节,细节,细节
  • 开放式问题
  • 旁注