使用Power Designer工具设计需求模型RQM

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所示：

 

图3-35 需求视图模型的三级效果