技术和功能规范模板[关闭]

一般提示;

我们正在实施一个

1)业务需求声明(BRS)

2)功能说明

3)技术规范

BRS涵盖了什么是业务问题,以及解决方案、测试、安全性、可靠性和交付方面的需求。这就定义了什么可以成为一个成功的解决方案。

功能规范详细说明了需要什么、它应该如何显示、字段应该有多长等。

技术规范详细说明了数据的来源,以及可能需要考虑的任何复杂代码。

客户拥有这些需求。开发人员拥有技术规范,而功能规范是一个中间地带。测试是根据技术规范(通常是单元测试)进行的,然后是针对功能规范(通常是系统测试),然后是针对需求(UAT)。

这其中的重要部分(我们正在努力解决)是开发人员仍然需要交付到功能规范和原始业务需求。实际上,功能和技术规范只是为了清晰起见。

简而言之,我的主要建议是首先制定出您希望实现的流程。然后,从参与您建议的流程的所有各方寻求一致意见,然后根据需要制定模板。模板本身只是您想要进行的更改的一小部分。

不是模板,但Joel写了一个 couple of articles 在编写功能规范时,他还 sample here .

你可以从IEEE和其他地方购买模板,但我总是自己制作。

对于技术规格, Code Complete 史蒂夫麦克唐纳有一个很好的清单,你可以从中得到一些信息。在我上次的工作中,我刚从他的分区标题中创建了一个模板,并从那里对其进行了调整。

就功能规范而言,重要的是定义所有接口:

1. UI(屏幕模型)
2. 软件接口(插件等)
3. 硬件接口(如适用)
4. 通信接口(服务、电子邮件、消息等)

业务规则也应该有一个部分,在功能上很重要,但在任何接口定义中都没有涉及。

如果你想买一本书, Software Requirements by Karl Wiegers 有一些文档的模板作为附录。不幸的是,我在工作,那本书在家里。如果有人方便的话,他们也许可以证实这一点。

我碰巧喜欢这个,除了其他: ReadySet .

他也卖专业版的。

这是我找到的最好的一个: http://www.jiludwig.com/templates/FRDTemplate.doc

从简单开始,从那里开始工作。因为这是您第一次使用它,所以请使用带有项目符号点的Word文档。写下它,重新阅读它,并提供足够的细节使它有意义。对于技术规范,您可能希望引导开发人员找到解决方案,但是对于功能规范,“如何”应该完全缺失。

我建议看一下罗伯斯顿的Vollee模板 here . 他们是大西洋系统协会的一部分,还有像汤姆·德马科和蒂莫西·利斯特这样的“Peopleware”名气的人。

由于模板是受版权保护的,因此我不会在此处复制它,而是提供一些主要标题:

1. 项目目的
2. 利益相关者
3. 强制约束
4. 命名约定和术语
5. 相关事实和假设
6. 工作范围
7. 业务数据模型和数据字典
8. 产品范围
9. 功能要求
10. 外观和感觉要求 …

还有很多,但这应该给你一个主意。模板中最有趣的部分是需求shell,它列出了一种提示卡上的功能需求。再次获得版权,但真正有价值。

看 here 在第9章中。