功能規格

規格以及開發層次的系統工程模型。在系統開發時，會生成許多的規格，在不同的層級描述系統。這些規格是組態基準線的核心。如此處所述，基準線除了參考系統階層的不同層級外，也會在不同設計階段定義基準線

系統工程和軟體開發裡的功能規格（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