3.1需求模型簡介
IEEE的軟件工程標準術語表將“需求”定義為：
用戶所需的解決某個問題或達到某個目標所要具備的條件或能力。
系統或系統組件為符合合同、標準、規范或其它正式文檔而必須滿足的條件或必須具備的能力。
上述第一項或第二項中定義的條件和能力的文檔表述。
RUP將“需求”定義為：
需求描述了系統必須滿足的情況或提供的能力，它就可以是直接來自客戶需要，也可以來自合同、標準、規范或其他有正規約束力的文檔。
兩者對于需求的定義大同小異，簡單點說，需求就是“軟件能為用戶做什么？”。
ROSE、VISO和Power Designer等CASE工具都提供了需求建模的相關內容，在軟件工程的歷史中，需求分析并沒有得到足夠重視，在過去的十年中項目團隊越來越認識到需求分析的重要性，并將其作為軟件過程中最關鍵也最困難的一個過程，因為它對軟件開發過程、產品質量，以及軟件是否能如期保質保量完成至關重要。
本節首先對需求采集和需求分析進行簡要介紹，而后對Power Designer中需求模型的功能進行簡要描述，從而使讀者對“需求模型 RQM”的概貌進行了解。
3.1.1 需求采集
需求采集的目標是為了獲取知識。一般由熟悉用戶所從事工作的資深人員進行需求采集工作，需求采集人員需要了解用戶和客戶希望軟件系統在哪些方面幫助他們。
需求采集和需求分析并不是先后進行的的兩個階段性工作，它們相互伴隨，并且交叉進行。在需求工作開始階段，更多的是進行需求采集工作，相伴進行的需求分析和整理工作占的比例偏少，但隨著掌握的需求信息越來越多，需求采集人員需要開展的對需求分析和整理工作也越來越多。
在進行需求采集前，需要進行準備工作，例如了解調研用戶所屬行業的情況、公司和部門的情況、列出需要詢問的問題、準備相關資料等。需求采集的方法五花八門，例如需求采集表、座談會、客戶訪談、現場參觀和調研、同類軟件分析等。通過需求采集活動，會收集客戶的眾多“原始需求”，需求采集的工作成果是《軟件用戶需求說明書》，為需求分析工作提供基礎。
3.1.2 需求分析
通過需求采集活動，將采集客戶的大量 “原始需求”，又稱為“用戶需求”，這些原始需求有可能相互沖突，需要進行過濾和分析。需求分析過程對采集到的原始需求進行分析、整理、辨別和歸納，最終形成系統的、明確的軟件需求。
需求分析的工作成果是《軟件需求規格說明書》，它精確地闡述了一個軟件系統必須提供的功能需求、非功能需求、必須達到的質量屬性指標以及它必須遵守的約束。《軟件需求規格說明書》應盡可能完整地描述各種條件下的系統行為。
《軟件需求規格說明書》參考目錄如圖3-1所示：
圖3-1 《軟件需求規格說明書》參考目錄
3.1.3 需求模型介紹
Power Designer中的需求模型（RQM，Requirements Model）是一種文檔式模型，它用來幫助相關人員分析任何一種文檔需求，并能鏈接在其它模型中的設計對象。一般使用RQM來表示任何結構化的文檔，例如需求規格說明書、功能說明書、測試計劃和業務目標等。并能將其導出為MS Word或實現從MS Word導入。
Power Designer的需求模型主要包括如下功能：
1）從結構化技術文檔中創建RQM；
2）檢查現有或導入的需求模型；
3）創建需求和設計對象（這些對象來自于其余類型的模型）的連接；
在Power Designer中，各種模型與其它設計對象的關系如圖3-2所示：
圖3-2 各種模型與其它設計對象關系圖
4）從其它設計對象中建立需求模型，或通過需求模型建立某些設計對象（例如業務規則、包和用戶用例等）。
5）從需求模型生成MS Word文檔或更新MS Word文檔。
MS Word文檔、需求模型和設計模型三者之間的關系如圖3-3所示：
圖3-3 MS Word文檔、需求模型和設計模型三者之間的關系圖
3.2手把手教你建立需求模型
本小節講解創建需求模型的方法，以一篇需求規格說明書模板為實例講解如何在Power Designer中進行需求模型設計和管理。
從“圖3-2”中可以看出，生成需求模型的方式多種多樣，主要有如下幾種形式：
1）新建RQM；
2）從已有的RQM生成新的RQM；
3）從其他模型導入生成RQM；
4）從MS Word文檔如生成RQM。
本章節主要講解在Power Designer中直接新建RQM的方法。
3.2.1創建RQM
選擇“File” ->“New”菜單項從彈出的新建模型窗口中選擇“Model types”->“Requirements Model”，或者新建模型窗口中選擇“Categories”->“Requirements and Planning”->“Requirements”，或在工作空間區域選擇“Workspace”->“New”->“Requirements Model”菜單。如圖3-4所示：
圖3-4 新建需求模型窗口
在上圖中“Model type”區域選擇模型類型，“Diagram”區域表示需求模型下的三種圖形，“Model name”用于設置需求模型的名稱，例如“需求模型實例1”。
從上圖中可以看出，在“Diagram”中需求模型有如下三種圖形：
1）需求文檔視圖（Requirements Document View）：通過二維表格的方式，以分層的方式表示系統需求。
2）追蹤矩陣視圖（Traceability Matrix View）：表示需求與設計對象、外部文件和其它需求之間的連接關系。
3）用戶分配矩陣視圖（User Allocation Matrix View）：標識需求與用戶或用戶組之間的分配關系。
一般創建“需求文檔視圖”文檔，創建后的空需求模型文檔如圖3-5所示：
圖3-5 需求視圖文檔空文檔
上圖的第一行是操作工具欄，“Title ID”所在列是表頭行，下面的各行是內容行。
3.2.2設置RQM模型選項
選擇“Tools”->“Model Options”菜單項，打開模型選項設置窗口，如圖3-6所示：
圖3-6 需求模型選項設置窗口
在上圖的左側區域有Model Settings（模型設置）、Requirements Fonts（需求字體）和Naming Convention（命名約定）三個節點，各個節點的定義如下：
Model Settings（模型設置）
Name/Code case sensitive復選框：表示RQM中的對象名稱和代碼是否區分大小寫，選中表示大小寫敏感，即區分大小寫，否則表示不區分；
Default按鈕：表示是否使用么默認配置，在Power Designer安裝完成時，初始的默認值是不區分大小寫，所以點擊“Default”按鈕后設置為不選中“Name/Code case sensitive”復選框，但是可以通過“Set As Default”按鈕更改默認設置。
Set As Default按鈕：將當前設置確認為默認設置。
Requirements Fonts（需求字體）
需求模型的字體設置窗口如圖3-7所示：
圖3-7 需求模型字體設置窗口
各個參數含義如下：
Text：設置需求文本和各個級別；
Font：設置字體，例如宋體、微軟雅黑等；
Font style：設置字形，例如加粗等；
Size：設置字號；
Color：設置字體顏色；
Effects：設置所選內容的顯示效果，“Strikeout”表示文字中間顯示刪除線，“Underline”設置文字下劃線。
Preview：顯示上述設置的預覽效果。
Naming Convention（命名約定）
需求模型的命名約定設置窗口如圖3-8所示：
圖3-8 需求模型命名約定設置窗口
上圖中各個參數定義如下：
Display：設置顯示內容，“Name”表示模型圖形中設置對象名稱，“Code”表示模型圖形中設置對象代碼，“Enable name/code conversions”表示對象名稱和對象代碼中可相互轉換。
Name/Code標簽：設置模型對象名稱/代碼的命名約定。
Name template：指定名稱模板；
Maximum length：最大長度；
Character case：字符的大小寫約定，“Uppercase”表示大寫，“Lowercase”表示小寫，“Mixed case”代表混合使用；
Valid characters：設定有效字符，勾選“All valid”表示全部有效；
Invalid characters：設定無效字符，勾選“No accents”代表沒有強調；
Default character：設定默認字符。
Name To Code/Code To Name標簽：設置模型對象名稱到代碼/模型對象代碼到名稱的轉換約定。
Conversion Script：設置轉換約定的腳本；
Conversion table：設置轉換表。
3.2.3設置RQM屬性
選擇“Model”->“Model Properties”菜單項，打開模型屬性設置窗口，如圖3-9所示：
圖3-9 需求模型屬性設置窗口
RQM屬性設置窗口默認包括四個選項卡，分別為“General”（通用信息）、“Detail”（詳細信息）、“Traceability Links”（追蹤鏈接信息）和“Notes”（注釋信息），點擊“More>>”按鈕可查看更多的屬性選項卡設置。
General選項卡：定義需求的通用信息。
Name：需求模型的名稱；
Code：需求模型的代碼；
Comment：需求模型的注釋信息；
File Name：未保存之前，此項顯示為空，需求模型保存后，顯示需求模型的存放路徑和文件名稱；
Author：文檔作者；
Version：文檔版本。
Detail選項卡：定義完成項目需求所需要的工作量（Workload），單位可設置為“天”或“小時”，可保留一位小數。Detail選項卡如圖3-10所示：
圖3-10 需求模型屬性設置窗口Detail選項卡
RQM所需要的總工作量是所有子需求的總工作量的總和，Workload 1、Workload 2、Workload 3和Workload 4分別表示該RQM分別給第一、第二、第三和第四個人或團度完成所需的工作量。
Traceability Links選項卡：設置RQM連接的設計對象和外部文件，以便幫助使用用戶更好的理解需求。Traceability Links選項卡如圖3-11所示：
圖3-11 需求模型屬性設置窗口Traceability Links選項卡
點擊上圖的“ ”按鈕彈出鏈接外部設計對象窗口，點擊“ ”按鈕彈出選擇外部文件頁面，可選擇本地硬盤上的“解決方案”或相關規范文檔作為鏈接文檔。
Notes選項卡：包括“Description”和“Annotation”兩個標簽，其中“Description”表示需求屬性的文字描述，“Annotation”表示需求屬性的公式化描述。
3.2.4編輯需求文檔視圖
在“3.2.1 創建RQM”小節創建了一個空的需求模型，接下來講解如何編輯需求模型，主要包括添加需求、編輯需求屬性、添加子需求、提高或降低需求層級和刪除需求功能。
以“餐飲在線點評系統”為例，有“管理門戶”和“會員門戶”兩個一級需求，在“管理門戶”下添加“系統管理”、“企業管理”、“會員管理”和“統計分析”四個子需求。在“會員門戶”添加“首頁”、“餐廳”、“團購活動”、“優惠活動”、“會員活動”和“會員中心”六個子需求。
1．添加一級需求
在需求文檔視圖窗口，點擊工具欄上的“ ”（Insert an Object）按鈕，或者單擊需求文檔視圖的空白區，或者使用“Ctrl+I”快捷鍵，可添加新的需求。新添加的需求具有默認的需求名稱（例如Requirement_1）和需求代碼（例如REQ_ 1）。
在需求文檔窗口中默認包括“Title ID”（需求ID）、“Full Descripiton”（需求描述）、“Code”（需求代碼）、“Priority”（需求優先級）、“Wordload”（工作量）、“Risk”（風險等級）和“Status”（狀態，包括草稿、已定義、已校驗、待評審和已評審五種狀態）。
2．編輯需求屬性
可以直接在在需求文檔窗口的編輯區域編輯主要屬性，也可雙擊某行，或單選某行后點擊“ ”（Propeities）按鈕，或者使用“Alt + Enter”快捷鍵打開編輯需求屬性窗口，如圖3-12所示：
圖3-12 編輯需求屬性窗口
從上圖可以看出，編輯需求屬性窗口常用的選項卡包括“General”（通用信息）、“Detail”（詳細信息）、“Traceability Links”（追蹤鏈接）、“User Allocations”（用戶或用戶組分配）、“Related Glossary Terms”（關聯的術語庫）和“Notes”選項卡，點擊“More>>”可打開更多的選項卡，例如“Extended Dependencies”等選項卡。下面對常用選項卡進行說明。
General選項卡：用于設置需求的一般信息，各項參數含義如下：
Parent：表示需求的父需求名稱，如果需求為一級需求，則顯示需求模型的名稱。
Title ID：表示需求的ID號，為需求的層級編號，自動生成，不可編輯，如果為一級需求按照1、2、3……N以此類推。如果為1下的二級子需求，按照1.1、1.2……1.N以此類推。
Title：表示需求的名稱，一般使用中文表示。
Code：表示需求的代碼，與后期的具體設計有關，一般使用英文、數字加符號表示。
Description：表示需求描述，可以用工具輔助完成富文本。可點擊“ ”按鈕，打開小箭頭后選擇“Microsoft Word”，可進入Word文檔編輯需求描述，在Word編輯完畢后點擊關閉按鈕會提示用戶是否將內容保存到需求文檔中，點擊“是”即可。因為可在Word中編輯，所以需求描述可以是帶格式的文本、表格或圖片等信息。
Detail選項卡：用于設置需求的優先級和風險等級等信息，如圖3-13所示：
圖3-13 編輯需求屬性窗口（Detail選項卡）
各項參數含義如下：
Comment：表示需求的簡要說明；
Stereotype：表示語義的擴展說明；
Type：表示需求類型，包括Undefined（未定義）、Design（設計）、Functional（功能）和Technical（技術）四種需求類型。
Status：表示需求狀態，包括Draft（草稿）、Defined（已定義）、Verified（已校驗）、To be reviewed（待評審）和Approved（已評審）五種狀態。
Priority：表示需求優先級，下拉列表中包括1~5的優先級值，每0.5一個刻度，數值越大表示該需求的優先級越高。
Selected：該復選框表示需求是否包含在工程中，選中表示包含，否則表示不包含。
Risk：表示需求的風險級別，包括Undefined（未定義）、Low（低）、Medium（中）和High（高）四種。
Verification：表示需求的測試級別，包括Undefined（未定義）、Automate Testing（自動測試）、Demonstration（演示）、Manual Testing（手工測試）和Mixed（混合測試）五種。
Traceability Links選項卡：設置改需求連接的設計對象和外部文件，以便為當前需求提供更詳細的依據和參考，與“設置RQM屬性“小節的該選項卡類似，不再贅述。
User Allocations選項卡：設置將當前需求指定到某個用戶或用戶組上，此操作需要首先建立用戶或用戶組，該部分內容在“3.2.5 創建用戶“和”3.2.6 創建用戶組“小節將進行詳細講述。在“User Allocations”選項卡點擊“ ”（Add Objects）按鈕，如圖3-14所示：
圖3-14 編輯需求屬性窗口（User Allocations選項卡）
在上圖中勾選用戶后點擊“OK”按鈕，在退回的“User Allocations”選項卡，通過修改TYPE列設置用戶所需完成的工作。TYPE可設置的值包括Undefined（未定義）、Design（設計）、Documentation（文檔）和Quality（質量）五種。
² Related Glossary Terms選項卡：設置將當前需求的專用術語，創建專業術語參考“3.2.7 創建專用術語庫”小節。在“Related Glossary Terms”選項卡點擊“ ”（Add Objects）按鈕，如圖3-15所示：
圖3-15 編輯需求屬性窗口（Related Glossary Terms選項卡）
² Notes選項卡：設置當前需求的文字或公式化描述，不再贅述。
3．添加子需求
在需求文檔視圖窗口，選擇某個需求后，點擊工具欄上的“ ”（Insert an Sub-Object）按鈕，或者使用“Ctrl + Shift + I”快捷鍵，可創建所選中需求的子需求。可使用父需求的打開、關閉按鈕打開或者關閉子需求。子需求添加后如圖3-16所示：
圖3-16 添加子需求后的需求文檔模型窗口
4．提高或降低需求層級
添加需求后，若發現需求層次不對，可通過工具欄上的“ ”按鈕將需求層級提高一級，使用“ ”按鈕將需求層級降低一級。
5．刪除需求
若發現某個需求不正確，想刪除該需求，可在需求文檔視圖的編輯區域選擇該行后按“delete”刪除鍵進行刪除，或點擊“工具欄”的“ ”按鈕進行刪除操作。需要注意的是，刪除某個需求時，若該需求下有子需求，也會被刪除。
6．修改顯示列
在需求文檔視圖編輯區域，默認只顯示“Title ID”（需求ID）、“Full Descripiton”（需求描述）、“Code”（需求代碼）、“Priority”（需求優先級）、“Wordload”（工作量）、“Risk”（風險等級）和“Status”列，若想對顯示列進行修改，可點擊工具欄的“ ”（Customize Columns and Filter）按鈕，或者使用“Ctrl + U”快鍵鍵，彈出顯示列設置窗口，如圖3-17所示：
圖3-17 編輯區域顯示列設置窗口
在上圖中可通過勾選或取消勾選對應的列后，點擊“OK”按鈕確認顯示項。
3.2.5創建用戶
用戶（User）是指跟需求有關的人員，例如需求分析師、系統分析師、開發人員和測試人員等。
在Power Designer的需求模型中可以創建用戶，一般采用選擇“Model”->“Users”菜單，在彈出的用戶管理窗口的編輯區域可以直接添加用戶，也可點擊“ ”（Add a row）按鈕添加用戶。用戶管理窗口如圖3-18所示：
圖3-18 用戶管理窗口
雙擊上圖中的某行，或者選擇上圖中的某行后點擊“ ”（Properties）按鈕，彈出用戶屬性窗口，如圖3-19所示：
圖3-19 用戶屬性窗口
用戶屬性窗口包括“General”和“Notes”兩個選項卡，其中：
² General選項卡：設置當前用戶的通用信息，各個參數的含義如下：
Name：用戶名稱；
Code：用戶代碼；
Comment：用戶注釋；
Stereotype：版本；
Email Address：用戶的Email地址。
² Notes選項卡：設置當前用戶的文字或公式化描述，不再贅述。
3.2.6創建用戶組
用戶組（Group）是指對進行分類，通常將具有相同特性的用戶組成用戶組。
在Power Designer的需求模型中可以創建用戶，一般采用選擇“Model”->“Groups”菜單，在彈出的用戶組管理窗口的編輯區域可以直接添加用戶組，也可點擊“ ”（Add a row）按鈕添加用戶組。用戶組管理窗口如圖3-20所示：
圖3-20 用戶組管理窗口
雙擊上圖中的某行，或者選擇上圖中的某行后點擊“ ”（Properties）按鈕，彈出用戶組屬性窗口，如圖3-21所示：
圖3-21 用戶組屬性窗口
用戶組屬性窗口包括“General”、“Group Users”和“Notes”三個選項卡，其中：
² General選項卡：設置當前用戶組的通用信息，各個參數的含義如下：
Name：用戶組名稱；
Code：用戶組代碼；
Comment：用戶組注釋；
Stereotype：版本；
Email Address：用戶組的Email聯系地址。
Group User選項卡：設置當前用戶組的用戶。可點擊“ ”（Add Objects）按鈕在彈出頁面中勾選N個用戶后點擊“OK”按鈕為用戶組添加用戶。如圖3-22所示：
圖3-22 為用戶組添加用戶窗口
Notes選項卡：設置當前用戶組的文字或公式化描述，不再贅述。
3.2.7創建術語庫
術語庫是術語的集合，術語用于表示某一專業的特殊概念，例如“餐飲在線點評系統”中的術語指的是“團購”、“會員”等專有名詞或縮略語等。
在Power Designer的需求模型中可以創建術語，一般采用選擇“Model”->“Glossary Terms”菜單，在彈出的術語庫管理窗口的編輯區域可以直接添加術語，也可點擊“ ”（Add a row）按鈕添加術語。術語庫管理窗口如圖3-23所示：
圖3-23 術語庫管理窗口
雙擊上圖中的某行，或者選擇上圖中的某行后點擊“ ”（Properties）按鈕，彈出術語屬性窗口，如圖3-24所示：
圖3-24 術語屬性窗口
術語屬性窗口包括“General”和“Notes”兩個選項卡，其中：
General選項卡：設置當前術語的通用信息，各個參數的含義如下：
Name：術語的名稱；
Code：術語的代碼；
Comment：術語的注釋；
Stereotype：版本。
Notes選項卡：設置當前術語的文字或公式化描述，不再贅述。
3.2.8創建業務規則
業務規則（Business Rules）是滿足業務需求的一系列規則，可以將客戶的要求、內部準則和政府的法律等都作為業務規則，例如用戶編碼、餐飲企業編碼、會員編碼的規則等。
在初始狀態，需求模型中的Business Rules為不可用狀態，需要通過新建擴展模型定義（Extended Model Definitions）來啟用業務規則，啟用業務規則的方法如下：
選擇“Model”->“Extended Model Definitions”，在擴展模型定義管理窗口中添加一行定義，如圖3-25所示：
圖3-25 擴展模型定義窗口
在上圖中雙擊“業務規則”行，或者選擇改行后，點擊“ ”（Properties）按鈕，彈出擴展模型屬性定義窗口，在該窗口選擇“Profile”節點后點擊右鍵，選擇“Add Metaclasses…”菜單項，彈出“Metaclass Selection”窗口，在該窗口選擇“PD Common”頁簽后勾選“Business Rule”，如圖3-26所示：
圖3-26 Metaclass Selection窗口
在上圖中點擊“OK”按鈕返回擴展模型屬性定義窗口，可看到此時添加了“Business Rule”子節點，完成啟用業務規則操作，此時在菜單“Model”下可看到多出“Business Rules”的選擇項。
選擇“Model”->“Business Rules”菜單項，在彈出的業務規則管理窗口的編輯區域可以直接添加業務規則，也可點擊“ ”（Add a row）按鈕添加業務規則。
業務規則管理窗口如圖3-27所示：
圖3-27 業務規則管理窗口
雙擊上圖中的某行，或者選擇上圖中的某行后點擊“ ”（Properties）按鈕，彈出用業務規則屬性窗口，如圖3-28所示：
圖3-28 業務規則屬性窗口
業務規則屬性窗口包括“General”、“Expression”和“Notes”三個選項卡，其中：
General選項卡：設置當前用戶的通用信息，各個參數的含義如下：
Name：業務規則名稱；
Code：業務規則代碼；
Comment：業務規則注釋；
Stereotype：版本；
Type：業務規則的類型，包括Constraint（約束）、Definition（定義）、Factor（事實）、Formula（公式）、OCL Constraint（OCL約束）、Requirement（需求）和Validation（批準）七種。
Expression選項卡：設置當前業務規則的表達式定義。
Notes選項卡：設置當前業務規則的文字或公式化描述。
3.2.9導出需求模型
選擇“Report”->“Reports”菜單項，彈出報表列表頁面，如圖3-29所示：
圖3-29 報表列表窗口
在上圖中點擊“ ”（New Reprot）按鈕，彈出新建報表窗口，如圖3-30所示：
圖3-30 新建報表窗口
在上圖中“Report name”指定“報表名稱”，在“Language”指定語言為“Simplified Chinese”（簡體中文），“Report template”用于指定報表模板，包括“<None>”、“Full Requirement Report”、“List Requirement Report”和“Standard Requirement Report”四個下拉選項，可選擇“Standard Requirement Report”選項，點擊“OK”按鈕后彈出報表選項設置頁面，如圖3-31所示：
圖3-31 報表屬性設置窗口
在上圖的左側為所有可選的報表導出項，右側為已設置報表導出項，讀者可以自行設置導出項，也可使用默認導出項配置，筆者只是刪除了“ ”節點的“%ITEM%”前的“需求”字樣刪除，而后點擊工具欄的“ ”按鈕導出RTF文檔，導出效果如圖3-32所示：
圖3-32 需求模型導出為RTF文檔效果圖
3.3餐飲在線點評系統案例需求模型
3.3.1系統目標
該系統主要使用用戶是廣大消費大眾、餐飲企業、食品提供商、運營管理員和運維管理員等，餐飲企業、特色菜、團購活動、優惠券、促銷活動等信息由餐飲企業進行維護，本系統中包括企業的開業時間、經營地點、食材等信息，方便消費大眾查詢。廣大消費大眾還可以通過該系統評價餐飲企業，并完成網上訂購。
可參考“大眾點評網”等知名網站，除基本的企業管理、食材管理、評價管理、會員管理、訂單管理，還可提供團購下單、團購活動、優惠券、促銷活動等功能。
3.3.2需求分析
餐飲在線點評系統案例的功能結構圖如圖3-33所示：
圖3-33 餐飲在線點評系統功能結構圖
管理門戶由運營管理員、運維管理員食材提供商、餐飲企業使用，使用基于角色的權限管理，不同的用戶能看到不同的菜單，并能根據登錄角色顯示不同的數據。
會員門戶提供給廣大互聯網用戶使用，大眾能通過該門戶進行注冊、評價餐飲企業、查看特色炒菜、查看團購活動、查看優惠券、查看促銷活動和團購下單等操作。
1、企業中心
² 企業信息管理
該功能提供給運營管理員使用。由企業管理員提交注冊申請信息，例如企業名稱、行政許可證號、類型、地址、企業圖片信息（可分類）、標簽、餐廳簡介、餐廳描述（富文本）、公司宣傳視頻、所屬菜系、特色、聯系電話、營業時間、詳細地址、管理員用戶名、管理員姓名、管理員聯系方式、管理員Email等信息。
該模塊的功能主要包括：
l 企業管理：主要包括注冊、審批、修改、刪除、啟用和停用功能。
l 食材提供商查看：查詢所選擇企業的食材提供商，通過“食材提供商管理”功能進行管理。
l 食材查看：查詢所選擇企業的重要食材，通過“食材管理”功能進行管理。
l 特色菜查看：查詢所選擇企業的特色菜，通過“特色菜管理”功能進行管理。
l 團購活動查看：查詢所選擇企業的團購活動，通過“團購活動管理”功能進行管理。
l 優惠券活動查看：查詢所選擇企業的優惠券活動，通過“優惠券活動管理”功能進行管理。
l 促銷活動查看：查詢所選擇企業的促銷活動，通過“促銷活動管理”功能進行管理。
² 食材提供商管理
該功能提供給運營管理員、餐飲企業使用。餐飲企業只能查看食材提供商信息，而運營管理員能查看所有食材提供商信息，并能進行查詢、新增、修改、刪除操作。
食材提供商信息主要包括：公司名稱、地址、聯系人、聯系電話、聯系Email、主營食材、營業執照、注冊資金、注冊地址、年銷售額等。
² 食材管理
該功能提供給運營管理員、餐飲企業、食材提供商使用。餐飲企業只能查看食材提供商提供的食材信息，運營管理員能查看所有食材信息，并能進行查詢、新增、修改、刪除操作。食材提供商只能查看本企業的食材信息，并能進行查詢、新增、修改、刪除操作。
食材信息主要包括：食材名稱、食材類型、食材價格、食材描述、食材圖片等。
² 特色菜管理
該功能提供給運營管理員、餐飲企業使用。特色菜一般由餐飲企業管理員自行維護，餐飲企業只能維護本企業的特色菜信息，而運營管理員能查看所有特色菜信息，兩者都能進行查詢、新增、修改、刪除操作。特色菜信息主要包括特色菜名稱、特色菜簡介、特色菜圖片等。
² 團購活動管理
該功能提供給運營管理員和餐飲企業使用。團購信息主要包括團購名稱、所屬餐飲企業、活動簡介、活動描述、活動價格、活動圖片、特別提示等。包括查詢、新增、審批、修改和刪除功能，餐飲企業只能管理本企業的團購活動，只有運營管理員才具有審批權限。
² 優惠券管理
該功能提供給運營管理員和餐飲企業使用。優惠券信息主要包括：優惠券名稱、短信內容、優惠券圖片、優惠券開始時期、優惠券有效期、所屬餐飲企業。包括查詢、新增、審批、修改和刪除功能，餐飲企業只能管理本企業的優惠券，只有運營管理員才具有審批權限。
² 促銷活動管理
該功能提供給運營管理員和餐飲企業使用。促銷活動信息主要包括：活動名稱、活動內容（富文本）、活動開始時期、活動有效期、活動結束日期、所屬餐飲企業、發布時間。包括查詢、新增、審批、修改和刪除功能，餐飲企業只能管理本企業的促銷活動，只有運營管理員才具有審批權限。
2、會員中心
² 會員管理
該功能提供給運營管理員使用，對本系統的會員進行管理，會員信息主要包括：姓名、手機號、登錄名、Email等。
² 積分管理
該功能提供給運營管理員使用，對會員積分記錄進行管理。包括查詢、調整積分等功能。
² 訂單管理
該功能提供給運營管理員和餐飲企業使用。訂單信息主要包括：訂單編號、會員名稱、餐飲企業名稱、下單時間等。
² 評價管理
該功能提供給運營管理員、企業使用。客戶能通過門戶對餐飲進行評價，包括評分等級、評分人、人均消費水平、口味等級、環境等級、服務等級、評價描述、圖片信息等。運營管理員能對所有評價進行查詢、詳情、刪除等操作。餐飲企業只能查詢本企業的評價信息。
² 會員消息管理
在注冊成功后，系統會自動發布消息通知，另外可針對客戶的瀏覽歷史等進行數據挖掘，為會員提供有針對性的推薦消息。會員消息在本模塊進行管理，主要包括查詢和查看詳情功能。
3、系統管理
管理門戶采用基于角色的權限管理，能為不同的角色設置權限，用戶可以屬于多個角色。系統管理用于對后臺的菜單管理、角色管理、用戶管理、、數據字典維護和日志管理功能。
² 菜單管理
對管理門戶的菜單進行管理。菜單屬性主要包括菜單編號、菜單名稱、菜單路徑、圖標、排序、是否葉子菜單、菜單描述、是否系統菜單。主要包括查詢、查看詳情功能。
² 角色管理
對管理門戶的角色進行管理，例如運營管理員、系統管理員和運維管理員等。角色屬性主要包括角色編號、角色名稱、角色描述、啟停狀態和是否系統默認角色，主要包括查詢、新增、修改、刪除、查看詳情和菜單分配功能。
² 用戶管理
對管理門戶的用戶進行管理，例如餐飲企業用戶，以及各個運營管理員、系統管理員和運維管理員用戶等。添加的用戶能登錄管理門戶對企業信息、會員信息等進行管理。主要包括用戶列表、添加、修改、刪除、角色分配、重置密碼、啟用和停用等功能。
² 日志管理
對管理門戶的登錄日志、操作日志、系統日志進行管理，包括日志查詢、日志詳情和日志導出功能。
² 數據字典維護
用于管理數據字典信息，例如“特色菜分類”、“企業類型”和“性別”等。包括新增參數、修改參數、刪除參數、啟用參數、禁用參數等。
4、統計分析
² 企業發展情況統計
使用圖表的方式展示各類型企業發展增長趨勢曲線圖和地域分布餅圖。
² 會員發展情況統計
使用圖表方式展示會員發展增長趨勢曲線圖和地域分布餅圖。
² 會員登錄統計
根據統計時間范圍、統計粒度（日統計、月統計）查詢平臺登錄數統計分析報表。
² 業務發展情況統計
使用圖表的方式展示訂單發展情況曲線圖和地域分布餅圖。
5、會員門戶
² 首頁
首頁可展示分類導航、餐廳搜索、熱門團購、熱門優惠、熱門餐廳、最新點評、推薦餐廳、會員活動和會員排行榜等信息。
² 餐廳
展示在管理門戶注冊并通過審批的餐飲企業信息，包括餐飲企業搜索、餐飲企業熱門排行榜、餐飲企業推薦排行榜、餐飲企業詳情、餐飲企業評價、相關圖片和宣傳視頻等信息。
² 團購活動
展示后臺審批通過的團購活動，包括團購活動分類搜索、團購詳情和下單等功能。
² 優惠券
展示展示后臺審批通過的優惠券信息，主要包括優惠券展示、優惠券搜索、優惠券詳情、打印優惠券和發送優惠券等功能。
² 會員活動
展示會員活動信息，能進行活動搜索和活動詳情。
² 會員中心
登錄后的會員可進入會員中心進行個人檔案、我的訂單、我的積分、我的收藏、我的評論、在線補開發票、站內信息、安全中心等功能。
3.3.3需求模型實現
根據“餐飲在線點評系統”的需求分析，采用本章上述小節的方法創建和編輯需求模型。
根據“3.3.2 需求分析”在Power Designer中創建和細化需求模型，第二層需求模型效果如圖3-34所示：
圖3-34 需求視圖模型的二級效果
第二層需求模型效果如圖3-35所示：