【问题标题】:Templates of Technical and Functional Specs [closed]技术和功能规格模板 [关闭]
【发布时间】:2010-09-08 07:31:27
【问题描述】:
所以基本上我正在寻找好的模板来编写项目或工作请求的技术和功能规范。
你用什么?在编写规范时,您有多深?如果您能提供任何其他一般性提示,我们将不胜感激。
我的公司非常需要这些。我为承包商工作,现在我们根本不使用这些文件。
编辑:我读过 Joel 对 Painless Specification 的看法,我真的很喜欢它,但还有其他意见吗 :)
【问题讨论】:
标签:
project-management
specifications
specs
【解决方案1】:
关于一般提示;
我们正在实施一个过程
1) 业务需求声明 (BRS)
2) 功能规范
3) 技术规范
BRS 涵盖了业务问题,以及围绕解决方案、测试、安全性、可靠性和交付的要求。这定义了成功的解决方案。
功能规范详细说明了所需内容、外观、字段长度等。
技术规范详细说明了数据的来源,任何可能需要考虑的棘手代码。
客户拥有需求。开发人员拥有技术规范,功能规范是中间立场。测试是针对技术规范(通常是单元测试)然后针对功能规范(通常是系统测试)然后针对需求 (UAT) 进行的。
其中重要的部分(我们正在努力解决)是开发人员仍然需要交付功能规范和原始业务需求。实际上,功能和技术规格只是为了清楚起见。
简而言之,我的主要提示是首先制定您希望实施的流程。然后征求参与您提议的流程的所有各方的同意,然后使用适合的模板。模板本身只是您想要进行的更改的一小部分。
【解决方案3】:
你可以从 ieee 和其他地方购买模板,但我总是自己制作。
对于技术规范,Steve McDonnell 的“Code Complete”有一个很好的清单,您可以从中获取一些信息。在我的上一份工作中,我只是从他的部分标题中制作了一个模板,并从那里进行了调整。
就功能规范而言,重要的是定义所有接口:
- UI(屏幕模型)
- 软件接口(插件等)
- 硬件接口(如果适用)
- 通信接口(服务、电子邮件、消息传递等)
还应该有一个业务规则部分,即在任何接口定义中都没有涵盖的重要功能。
【解决方案7】:
从简单开始,然后按照自己的方式工作。由于这是您第一次使用此功能,因此请使用带有项目符号的 word 文档。写下来,再读一遍,并提供足够的细节,让它有意义。对于技术规范,您可能希望引导开发人员找到解决方案,但对于功能规范,“如何”应该完全缺失。
【解决方案8】:
我建议看看 Roberston 的 Volere 模板here。他们是大西洋系统协会的一部分,与 Tom DeMarco 和“Peopleware”成名的 Timothy Lister 等人一起。
由于模板是有版权的,这里就不复制了,给大家提供一些主要的标头:
- 项目的目的
- 利益相关者
- 强制约束
- 命名约定和术语
- 相关事实和假设
- 工作范围
- 业务数据模型和数据字典
- 产品适用范围
- 功能要求
- 外观要求
...
还有很多,但这应该会给你一个想法。模板中最有趣的部分是需求外壳,它列出了一种提示卡上的功能需求。再次受版权保护,但真正有价值。
在第 9 章中查看 here。