学习编写规范有哪些资源?
在工作中,我经常负责编写规范,而且我还是坚持要首先获得规范的人。问题是我不确定规范的外观和内容。很多时候,当我的老板在写规范时(我们俩都没有经验),他们把表名和我认为不属于的东西放进去。那么,学习编写好的规范的好方法是什么?
编辑:功能规格应该包括诸如假设我指定一个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撰写的《无痛功能规范》。
他说,每个规范都应具备以下几点:
- 免责声明
- 一位作家。一位作者
- 情境
- 非目标
- 概述
- 细节,细节,细节
- 开放式问题
- 旁注