在工作中,我经常负责编写规范,我也是一开始就坚持要获取规范的人。问题是我不确定规范应该是什么样子以及它们应该包含什么。很多时候,当我的老板编写规范时(我们都缺乏经验),他们会输入表名和我认为不属于那里的东西。那么什么是学习编写好的规范的好方法呢?
编辑:功能规范是否应该包括假设我正在指定一个 Web 应用程序、输入类型(文本框、下拉列表等)?
在工作中,我经常负责编写规范,我也是一开始就坚持要获取规范的人。问题是我不确定规范应该是什么样子以及它们应该包含什么。很多时候,当我的老板编写规范时(我们都缺乏经验),他们会输入表名和我认为不属于那里的东西。那么什么是学习编写好的规范的好方法呢?
编辑:功能规范是否应该包括假设我正在指定一个 Web 应用程序、输入类型(文本框、下拉列表等)?
在我看来,开发文档中最重要的部分是让正确的人来做。
让除高级开发人员/架构师之外的任何人定义表结构/接口等是徒劳的——因为更有经验的开发人员通常会将大部分内容扔掉。
Wikipedia 实际上是功能规范的一个良好开端,它看起来类似于您的规范 - http://en.wikipedia.org/wiki/Functional_specification。
Steve McConnell 的Code Complete中有一个很棒的章节贯穿规范文档以及它们应该包含的内容。
当我的任务是在一家从未有过的公司建立架构和业务分析团队时,我使用 McConnell 的规范章节来创建技术规范文档的大纲。它随着时间的推移而发展,但从这个框架开始,我确保我们没有遗漏任何东西,结果证明它非常有用。
在编写规范时,我遵循的经验法则是尝试让技术文档始终从一般开始并转向具体——始终重申正在开发技术解决方案的业务问题或目标解决,因此阅读规范的人不需要去其他文档将其置于任何类型的上下文中。
重要的是把一些东西写下来,而不是担心格式。
购买书籍:Ian Sommerville 和 Pete Sawyer 的需求工程 ISBN 0-471-97444-7 或 Karl Wiegers 的软件需求 ISBN 0-7356-0631-5