功能规格

规格以及开发层次的系统工程模型。在系统开发时，会生成许多的规格，在不同的层级描述系统。这些规格是组态基准线的核心。如此处所述，基准线除了参考系统阶层的不同层级外，也会在不同设计阶段定义基准线

系统工程和软件开发里的功能规格（functional specification）、功能规格文件（functional specifications document）或功能需求规格（functional requirements specification）是指说明系统或是组件需要实现功能的文件，也常常是需求规格中的一部分。

此文件一般会描述系统使用者需要的资讯，及其输入和输出要有的性质（例如在软件系统中）。功能规格多半是针对对应需求文件（例如产品需求文档）的技术层面回应，因此其中会用到需求分析阶段的结果。在较复杂的系统中，一般会有多层的功能规格，包括系统层级的、模组层级以及技术细节层级。

简介

功能规格着重其功能，不会定义系统的内部运作，也不会包括系统功能实现方式的规格。

功能规格里的功能需求可能如下：

若使用者按下OK按钮，对话窗会关闭，焦点回到对话窗显示之前的主视窗。

此需求描述用户和软件系统之间的互动。用户按OK按钮，提供输入给系统，系统应该要回应，回应方式就是关闭对话窗。

功能规格里的主题

目的

功能规格有许多的目的，对专案的一个主要目的是让团队提早有某种程度的共识，在进行像撰写源代码、测试用例之类的耗时工作之前，可以提早得到共识。一般来说，会在专案持份者的审核之后才会有共识，而且已经找到成本效益最好的方法，可以达到软件需实现的功能。

1. 让程序员知道要建立的系统。
2. 让测试者知道要测试的对像。
3. 让利害相关人知道会得到的结果。

流程

在有序的软件工程生命周期（瀑布模型）中，功能规格会说明要实现的系统，接下来，系统架构文件会说明在特定软件环境下如何实现各个功能。若是原型系统开发，一般会在需求分析完成后产出功能规格，或将功能规格成为需求分析的一部分。

团队在功能规格上达到共识之后，一般会认为此功能规格“已完成”或是“已签核”。接下来软件开发团队以及测试团队会以此功能规格为基础，撰写程式码以及测试用例。在进行测试时，会将功能规格中所定义的行为，视为系统应该有的行为，并且和系统实际行为互相比较。

方法

在撰写电脑软件的功能规格文件时，很常用的方式是用简单的wire frame呈现，也可以用准确、经过美工设计的UI画面截图来进行。在这些内容完成后，利害相关人会核可这些画面范例，也可以将范例中的图像元素编号，撰写其说明文件。例如登入画面会有编号1的用户名称栏位，以及编号2的密码栏位。这些编号可以在说明文件中声明，让软件工程以及后续的测试者此功能的细节。此作法的好处是在这些范例中可以加入许多的设计细节。

功能规格的例子

• 高级微控制器总线架构
• 统一可延伸固件界面
• Multiboot规范
• Real-Time Java规范
• 单一UNIX规范

相关条目

• 基准化分析法
• 软件开发过程
• 规范 (文档)
• 软件验证及确认

外部链接

• Painless Functional Specifications, 4-part series by Joel Spolsky