功能需求文件

功能需求文件 (FRD) 是應用程式功能需求的正式宣告。它的作用與合同相同。在這裡，開發人員同意提供指定的各項功能。如果產品提供了 FRD 中指定的各項功能，則客戶同意認為產品令人滿意。

功能需求捕獲了系統的預期行為。此行為可以表示為系統需要執行的服務、任務或功能。該文件應根據特定專案的需要進行調整。它們定義了諸如系統計算、資料操作和處理、使用者介面以及與應用程式的互動等內容。

功能需求文件 (FRD) 具有以下特徵：

• 它證明了應用程式在未來幾年內能夠根據業務目標和業務流程提供價值。

• 它包含了應用程式的一整套需求。它不留任何空間讓人假設 FRD 中未陳述的任何內容。

• 它是與解決方案無關的。ERD 是關於應用程式要做什麼的宣告，而不是關於它是如何工作的宣告。FRD 不會將開發人員繫結到某個設計。因此，在 FRD 中引用任何特定技術的用法都是完全不合適的。

功能需求應包括以下內容：

• 輸入系統的資料的描述

• 每個螢幕執行的操作的描述

• 系統執行的工作流程的描述

• 系統報表或其他輸出的描述

• 誰可以將資料輸入系統？

• 系統如何滿足適用的監管要求？

功能規格旨在供一般受眾閱讀。讀者應該理解系統，但不需要任何技術知識就能理解此文件。

功能需求交付成果

業務需求文件 (BRD) 包括：

• 功能需求 - 包含正在開發的系統的詳細需求的文件。這些需求定義了系統必須具備的功能特性和能力。確保在業務案例中確定的任何假設和約束仍然準確並已更新。

• 業務流程模型 - 當前流程狀態的模型（“現狀”模型）或流程應如何發展的概念（“目標”模型）

• 系統上下文圖 - 上下文圖顯示了系統邊界、與系統互動的外部和內部實體以及這些外部和內部實體之間相關的資料流。

• 流程圖（現狀或目標） - 圖表以圖形方式描述業務流程的操作序列或資料移動。根據模型的複雜性，包含一個或多個流程圖。

• 業務規則和資料需求 - 業務規則定義或約束業務的某些方面，並用於定義資料約束、預設值、值範圍、基數、資料型別、計算、異常、必需元素和資料的關係完整性。

• 資料模型 - 實體關係圖、實體描述、類圖

• 概念模型 - 業務功能的不同實體及其相互關係的高階顯示。

• 邏輯模型 - 說明業務功能中涉及的特定實體、屬性和關係，並表示業務、技術或概念環境中所有資料的定義、特徵和關係。

• 資料字典和詞彙表 - 關於構成資料庫或類似資料管理系統基礎的資料模型中的資料元素、欄位、表和其他實體的詳細資訊的集合。

• 利益相關者地圖 - 確定所有受擬議變更影響的利益相關者及其對需求的影響/許可權級別。此文件在專案管理方法 (PMM) 的起源階段開發，由專案經理擁有，但需要在整個過程中由專案團隊更新，以識別新的/更改的利益相關者。

• 需求可追溯性矩陣 - 一個表格，說明各個功能需求與其他型別的系統工件之間的邏輯連結，包括其他功能需求、用例/使用者故事、架構和設計元素、程式碼模組、測試用例和業務規則。