定義
功能建模是指在業務建模的基礎上，為解決業務領域的問題所需要的系統功能，並按照“系統—子系統—功能—程式”的思路編排，且需說明解決哪部分業務以及功能間的關係。
建模思路
1、理解業務體系，梳理出業務體系所在的問題域的層次關係；
2、確定系統邊界，明確接口關係；
3、確定系統分解規則，將系統分解成幾個子系統；
4、確定子系統所需的功能，按層次列出功能；
5、按[[IPO]]思路確定系統功能，輸入、處理、輸出。
6、按互動思路確定用戶界面。
功能建模在銷售管理系統中的套用
通過對銷售管理系統的分析，我們可以找出這樣一些角色：客戶、供貨商、採購員、銷售員、倉庫管理員、財會人員、資料庫系統。其中：客戶是從公司中訂購商品的人i供貨商是向公司提供進貨的商家．採購員負責與供貨商打交道即從商家進貨；銷售員負責與客戶打交道即銷售商品：倉庫管理員是記錄商品庫存、商品入庫出庫；財會人員負責整個公司的財務工作：與銀行互動進行支付處理；資料庫系統是提供數據處理方面功能的系統。整個系統協調工作，統一進貨，統一銷售．統一結算．統一退貨。
根據以上問題分析本系統的需求，可以初步確定這樣一些用例：
客戶：獲得清單、獲得訂單狀態、訂購貨物、取消訂單、退貨：採購員：進貨、向供貨商退貨、供貨商管理（添加、修改、刪除、查詢供貨商信息）：銷售員處理客戶退貨、客戶管理（添加、修改、刪除。查詢客戶信息）倉庫管理員：到貨入庫、退貨入庫、發貨出庫、退貨出庫、庫存統計等；財會人員：收款結算、客戶往來賬目處理、供貨商往來賬目處理、付款結算、其他收支等。
“訂購貨物”用例描述訂單通過該過程進入訂單處理系統。訂購貨物的過程是：當客戶選擇訂購貨物後．系統顯示訂購貨物界面。客戶輸入自己的姓名和住址．然後輸入要訂購產品的代碼．並且系統要將該項價格加到總值中去。完成以上的選擇之後，客戶輸入信用卡支付信息。客戶提交後，系統驗證輸入信息，並把該訂單作為未完成的交易保存。
“取消訂單”用例描述了客戶取消訂單的過程。客戶選擇取消訂單．客戶進入取消訂單界面。客戶選擇取消。如果這筆訂單中的產品還沒有運走，則系統在資料庫中刪除這筆訂單並更新訂單，向客戶賬號中加錢並更新賬目．把訂單中的產品放回庫存並更新產品數量。
“退貨”用例描述客戶將不滿意的產品退回公司的過程。當客戶選擇退貨時．首先查詢訂單，然後選擇要退回的貨物，提交之後，系統更新賬目．產品數量及訂單。
“更新客戶”用例描述當客戶信息發生變化時修改客戶資料的過程。當銷售員選擇更新客戶時，首先查詢客戶，然後填寫查詢條件．系統查詢出符合條件的若干客戶．選擇要修改的客戶，並選擇”修改資料”功能．系統驗證該用戶是否有修改許可權，系統查看是否其他人在使用該客戶資料．系統打開客戶資料修改視窗．輸入新資料並保存，系統驗證新資料的合法性，系統將客戶新資料保存到資料庫。
“進貨”用例描述採購員從供貨商家購進商品的過程。當採購員選擇進貨功能時，使用“查詢供貨商”用例，選擇供貨商．然後選擇要購進的貨物，提交之後，系統更新賬目，產品數量。
文檔目錄
1、引言
2、功能概述
1.1 業務背景
1.2 系統邊界
1.3 系統目標
1.4 系統框架
1.4 前提與約束
3、A子系統
3.1 A1功能
3.1.1 定義
3.1.2 進入條件
3.1.3 系統角色
3.1.4 功能列表
3.1.5 角色功能對照表
3.1.6 主事件流
3.1.7 子事件流
3.1.8 備事件流
3.1.9 退出條件
3.1.10 業務規則
3.1.11業務資料
3.1.12 相關功能
3.1.13 其他
3.2 A2功能
。。。。。。
4、B子系統
4.1 B1功能
4.1.1 定義
4.1.2 進入條件
4.1.3 系統角色
4.1.4 功能列表
4.1.5 角色功能對照表
4.1.6 主事件流
4.1.7 子事件流
4.1.8 備事件流
4.1.9 退出條件
4.1.10 業務規則
4.1.11業務資料
4.1.12 相關功能
4.1.13 其他
4.2 B2功能
。。。。。。
