功能規格

系统工程和软件开发裡的功能規格（functional specification）、功能規格文件（functional specifications document）或功能需求規格（functional requirements specification）是指說明系統或是組件需要實現功能的文件，也常常是需求規格中的一部份ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary。

此文件一般會描述系統使用者需要的資訊，及其輸入和輸出要有的性質（例如在软件系統中）。功能規格多半是針對對應需求文件（例如产品需求文档）的技術層面回應，因此其中會用到需求分析階段的結果。在較複雜的系統中，一般會有多層的功能規格，包括系統層級的、模組層級以及技術細節層級。
簡介
功能規格著重其功能，不會定義系統的內部運作，也不會包括系統功能實現方式的規格。

功能規格裡的功能需求可能如下：

若使用者按下OK按鈕，對話窗會關閉，焦點回到對話窗顯示之前的主視窗。

此需求描述用户和軟體系統之間的互動。用戶按OK按鈕，提供輸入給系統，系統應該要回應，回應方式就是關閉對話窗。
功能規格裡的主題
目的
功能規格有許多的目的，對專案的一個主要目的是讓團隊提早有某種程度的共識，在進行像撰寫源代码、测试用例之類的耗時工作之前，可以提早得到共識。一般來說，會在專案持份者的審核之後才會有共識，而且已經找到成本效益最好的方法，可以達到軟體需實現的功能。

 讓程序员知道要建立的系統。 
 讓測試者知道要測試的對像。
 讓利害相關人知道會得到的結果。

流程
在有序的軟體工程生命週期（瀑布模型）中，功能規格會說明要實現的系統，接下來，系统架构文件會說明在特定軟體環境下如何實現各個功能。若是原型系統開發，一般會在需求分析完成後產出功能規格，或將功能規格成為需求分析的一部份。

團隊在功能規格上達到共識之後，一般會認為此功能規格「已完成」或是「已簽核」。接下來軟體開發團隊以及測試團隊會以此功能規格為基礎，撰寫程式碼以及測試用例。在進行測試時，會將功能規格中所定義的行為，視為系統應該有的行為，並且和系統實際行為互相比較。

方法
在撰寫電腦軟體的功能規格文件時，很常用的方式是用簡單的wire frame呈現，也可以用準確、經過美工設計的UI畫面截圖來進行。在這些內容完成後，利害相關人會核可這些畫面範例，也可以將範例中的圖像元素編號，撰寫其說明文件。例如登入畫面會有編號1的用戶名稱欄位，以及編號2的密碼欄位。這些編號可以在說明文件中聲明，讓軟體工程以及後續的測試者此功能的細節。此作法的好處是在這些範例中可以加入許多的設計細節。

功能規格的例子
 高级微控制器总线架构
 統一可延伸韌體介面


 單一UNIX規範
相關條目
 基準化分析法
 软件开发过程
 规范 (文档)
 軟體驗證及確認

參考資料

外部連結
 Painless Functional Specifications, 4-part series by Joel Spolsky

Category:系统工程
Category:软件文档
Category:軟體設計