第3章〓软件需求分析3.1软件需求分析概述
需求分析是整个项目开发流程的第一个环节，它是在用户和软件开发组之间建立对用户的共同理解，由软件开发组进行分析、精化并详细描述后，按文档规范编写出《软件需求规格说明书》（Software Requirement Specification,SRS）的过程。
软件需求分析特别重要。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中的一个简单步骤，但在过去十多年中，越来越多的人认识到它是整个过程中最关键的一个过程。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。许多大型应用系统的失败最后均归结到需求分析的失败： 要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
需求分析是一项重要的工作，也是最困难的工作。该阶段工作具有以下特点：
（1） 用户与开发人员很难进行交流。
在软件生命周期中，其他阶段都是面向软件技术方面的，只有本阶段是面向用户的。需求分析是对用户的业务活动进行分析，以便明确在用户的业务环境中软件系统应该“做什么”。但是在开始时，开发人员和用户双方都不能准确地提出系统要“做什么”，因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。软件工程与项目案例教程第3章软件需求分析（2） 用户的需求是动态变化的。
对于一个大型而复杂的软件系统，用户很难精确、完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确，有时进入设计、编程阶段才能明确，甚至到开发后期还在提新的要求。这无疑会给软件开发带来困难。
（3） 系统变更的代价呈非线性增长。
需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用1h，到设计、编程、测试和维护阶段解决，则要花费2.5h、5h、25h甚至100h的时间。
3.2软件需求分析过程3.2.1什么是软件需求从根本上讲，软件需求就是为了解决现实世界中的特定问题，软件必须展现的属性。
软件需求包括两部分： 功能性需求和非功能性需求。虽然功能性需求是对软件系统的一项基本需求，但却并不是唯一的需求。除功能性需求外，软件质量属性的特性称为系统的非功能性需求。这些特性包括系统的易用性、执行速度、可靠性，处理异常情况的能力与方式等。在决定系统的成功或失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。软件需求的组成见图31。
图31软件需求的组成
软件需求的属性包括可验证性、优先级、唯一性和定量化。
（1） 可验证性。这是软件需求的基本属性。软件需求必须是可验证的，否则软件的评审和测试就没有相应的依据。
（2） 优先性。软件需求具有优先级，应该能够在有限的资源（资金、人员、技术）情况下进行取舍。
（3） 唯一性。软件需求应唯一地标识出来，以便在软件配置管理和整个软件生命周期中进行管理。（4） 定量化。软件需求应尽可能地表述清楚，没有二义性，进行适当的量化，应避免含糊、无法测试、无法验证的需求出现。软件质量的可靠性和用户界面的友好性等非功能性需求的量化尤为重要。例如，系统应支持2000个并发用户，系统回应时间应低于10s，这就是需求的量化。
3.2.2需求分析过程中的角色
需求分析过程涉及各种角色的人员。需求分析人员应协调软件开发人员和各领域内的专家共同完成需求分析过程。软件的涉众（牵涉到的角色）随项目的不同而不同，但至少包括用户（操作人员）和客户。典型的需求分析过程中的角色如表31所示。表31典型的需求分析过程中的角色
角 色 名 称描述用户直接操作软件的人员，他们通常具有不同的业务角色，具有不同的业务需求客户软件开发的委托方或软件市场的目标客户市场分析人员对于没有具体客户的通用软件，市场分析人员将提供市场需要，并对实际客户进行模拟系统分析师对于类似的项目，系统分析师将对以前的系统进行评估，判断是否存在重用的可能对于涉众的各种需求通常很难完全满足，系统分析师应根据预算、技术等条件进行取舍。
3.2.3需求分析过程的迭代
软件需求分析是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围（工作范围）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决办法。需求分析过程要适应客户和项目的环境，并作为配置项纳入配置管理。关于配置管理的具体内容将在第8章中详细讲解。
当前的软件业面临着巨大竞争压力，要求软件企业开发的项目有更低的构建成本和更短的开发周期。有些项目受环境的影响很大，有些项目是对原有项目的升级，有些项目客户要求在指定的架构下完成。在项目初期，客户不能完全确定需要什么，对计算机的能力和限制不甚了解，所以需求分析过程很难一步到位。随着项目的深入，需求将随时间而发生变化。
因此，需求分析过程是一个迭代的过程，每次迭代都提供更高质量和更详细的软件需求。这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为需求不足而被推翻。但是，系统分析师都应根据项目计划，在给定的资源条件下得到尽可能高质量的需求。
在很多情况下，对需求的理解会随着设计和实现的过程而不断深入，这也会导致在软件生命周期的后期重新修订软件需求。原因可能来自错误的分析、客户环境和业务流程的改变、市场趋势的变化等。无论什么原因，系统分析师都应认识到需求变化的必然性，并采取相应的措施减少需求变更对软件系统的影响。变更的需求必须经过仔细的需求评审、需求跟踪和比较分析后才能实施。
3.2.4需求来源
理解问题域的第一步是提取需求，即确定需求的来源，识别软件的涉众，确立开发团队与客户间的关系。提取需求时，要求开发人员与用户保持良好的沟通。
软件需求的来源很多，要尽可能多地识别显式的来源和潜在的来源，并评估这些来源对系统的影响。典型的来源包括以下5种。
（1） 系统目的。这是指软件的整体目的或高层的目标。这是进行软件开发的动机，但它们通常表达得比较模糊。系统分析师需要仔细地评估这些目标的价值和成本，对系统的整体目标进行可行性研究。
（2） 行业知识。系统分析师需要获取业务领域内的相关知识。因为涉众对于通用的行业知识会略而不谈，一些行业惯例需要系统分析师根据环境进行推断。当需求发生矛盾时，系统分析师可以利用行业知识对各种需求进行权衡。
（3） 软件涉众。应充分考虑不同软件涉众的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致软件系统的失败。系统分析师应从不同涉众的角度去识别、表述他们的需求。用户的文化差异和客户的组织结构常常是系统难以正常实施的原因。
（4） 运行环境。软件的运行环境包括地域限制、实时性要求和网络性能等。系统的可行性和软件架构都依赖于这些环境需求。
（5） 组织环境。软件作为一个组织的业务流程支持工具，受到组织结构、企业文化和内部政策的影响。软件的需求也与组织结构、企业文化和内部政策有关。
3.2.5需求获取方法
常用的需求获取方法有以下6种：
（1） 实地参与业务工作。通过亲身参与业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
（2） 开调查会。通过与用户座谈来了解业务活动情况及用户需求。座谈参加者可以相互启发。
（3） 请专人介绍。
（4） 面谈。对某些调查中的问题，可以找专人询问。
（5） 设计调查表请用户填写。如果调查表设计得合理，这种方法是很有效的，也易于被用户接受。
（6） 查阅记录。查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解获取了用户需求后，还需要进一步分析和表达用户的需求。
3.2.6软件需求表达
如何有效地表达软件需求？这里建议使用用例建模技术。该技术是十多年来最重要的需求分析技术，在保障全球各类软件的成功开发中发挥了极其重要的作用。实践证明，用例建模技术是迄今为止最为深刻、准确和有效的系统功能需求描述方法。功能需求是指系统输入到输出的映射以及它们的不同组合，任何功能都必然要通过外部环境与系统之间的交互才能完成，因此，可以在内容和形式上把用例和系统的功能需求等同起来。
用例建模技术不同于结构化功能分解的特点有以下几个：
（1） 显式地表达用户的任务目标层次，突出系统行为与用户利益间的关系。
（2） 通过描述执行实例情节（交互行为序列、正常/非正常事件流），能够完整地反映软件系统用以支持特定功能的行为。
（3） 以契约（前置/后置条件等）的形式突出了用户和系统之间常常被忽略的背后关系。
（4） 部署约束等非功能需求与系统行为直接绑定，能够更准确地表达此类需求。
基于用例的需求表达体系如图32所示。
图32基于用例的需求表达体系
1. 用例图
1） 用例图概述
用例建模技术离不开用例图。在UML中，用例图又叫作用况图。它用于定义系统的行为，展示角色（系统的外部实体，即参与者）与用例（系统执行的服务）之间的相互作用。用例图是需求和系统行为设计的高层模型，它以图形化的方式描述外部实体对系统功能的感知。用例图从用户的角度来组织需求，每个用例描述一个特定的任务。用例图的组成元素如表32所示。表32用例图的组成元素
名称形式说明角色
角色名称代表与系统交互的实体。角色可以是用户、其他系统或者硬件设备。在用例图中以小人表示。例如“图书管理员”“读者”和“系统管理员”是与系统交互的角色用例
用例名称定义了系统执行的一系列活动，产生一个对特定角色可观测的结果。在用例图中以椭圆表示。这一系列活动可以是系统执行的功能、数学计算或其他产生一个结果的内部过程。活动是原子性的，即要么完整地执行，要么完全不执行。活动的原子性可以决定用例的粒度。用例必须向角色提供反馈续表
名称形式说明关联用户和用例之间的交互关系。用实线表示用例
关系用例与用例之间的关系。用带箭头的虚线表示。用例之间的关系可以用引申类型进行语义扩展，如include等用例模型可以在不同层次上建立，具有不同的粒度。
2） 用例层次 
把用例划分为3个目标层次： 概要层、用户目标层和子功能层，并通过引入巧妙的Why/How技术帮助分析者找到合适的目标层次，从而可以有效地把握用例的粒度（真正的用例最终应落实到用户目标层）。
值得注意的是，在实践中应该特别关注用户目标层用例。引入概要层用例的主要目的是为了包含一个或多个用户目标层用例，为系统提供全局功能视图；引入子功能层用例，则是为了表达用户目标层用例的具体实现步骤。
3） 用例范围 
根据范围的不同，用例可分为业务用例和系统用例两种。
业务用例的概要描述如下：
 它是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。
 它的实质是业务流程。
 它可以分为核心业务用例、支持业务用例和管理业务用例。
 它主要包括业务角色、业务活动、业务实体、业务规则。
系统用例的概要描述如下：
 它是系统执行的一系列动作，这些动作将生产特定主角可观测的结果值。
 它主要包括系统角色和系统的一系列交互过程。
当前的讨论边界（System under Discussion，SuD）一般比较容易确定，那么如何从用例的范围上判断一个用例是业务用例还是系统用例呢？如果某个SuD或者用例的范围包含了人及由人组成的团队、部门、组织的活动，那么针对这个SuD写出的用例必然是业务用例；如果该SuD仅仅是一些软件、硬件、机电设备或由它们组成的系统，并不涉及人的业务活动，那么针对这个SuD写出的用例就是系统用例。
4） 用例关系
用例关系分为以下3种。
（1） 角色和角色之间的关系。角色和角色之间只有继承关系，它表示子类角色将继承父类角色在用例中所能担任的角色。
（2） 角色和用例之间的关系。角色和用例之间只有使用关系，它表示角色将使用用例提供的服务。
（3） 用例和用例之间的关系。分为以下3种关系：
 包含关系。通常是指一个大的用例包含了几个小的用例，几个小的用例组成一个大的用例。
 扩展关系。是基于扩展点的两个独立用例（分别称为基本用例和扩展用例）之间的关系。扩展用例为基本用例的实例增添新的行为，其实质是扩展事件流的延伸，两个用例是相互独立的。
 继承关系。父用例可以特殊化为一个或多个子用例，这些子用例代表了父用例比较特殊的形式，子用例继承父用例的所有结构、行为和关系。
用例关系示例如图33所示。
图33用例关系示例
2. 用例描述
建立用例模型时，除了绘制用例图外，还要对用例进行描述，也就是详细展开每个用例的内容。用例描述可以是文字性的，也可以用活动图进行说明。文字性的用例描述模板如下： 用例编号：
用例名称： 
用例描述： 
前置条件： （描述用例执行前必须满足的条件）
后置条件： （描述用例执行结束后将执行的内容）
基本事件流： （也称主事件流，描述在常规条件下系统执行的步骤）
1. （步骤1）。
2. （步骤2）。
3. （步骤3）。
……
扩展事件流: （也称分支事件流，描述在其他情况下系统执行的步骤）
2a（扩展步骤2a）。
2a1（扩展步骤2a1）。
……
异常事件流： （描述在异常情况下可能出现的场景）

以“借书登记”为例，其具体的用例描述如下:用例编号： 3.1
用例名称： 借书登记
用例描述： 图书管理员对读者借阅的图书进行登记。读者借阅图书的数量不能超过规定的数量。如果读者有过期未还的图书，则不能再借阅图书。
前置条件： 读者取得借阅的图书。
基本事件流： 
1. 读者请求借阅图书。
2. 检查读者的状态。
3. 检查图书的状态。
4. 标记图书为借出状态。
5. 读者获取图书。
扩展事件流： 
2a如果用户借阅数量超过规定数量，或者有过期未还的图书，则用例终止。
3a如果借阅的图书不存在，则用例终止。
异常事件流：
无

3. 需求的优先级
每一个具有有限资源的软件项目必须理解需求所要求的特性、使用实例和功能需求的相对优先级。设定需求的优先级意味着权衡每个需求的业务利益和它的费用，以及它所涉及的结构基础和对产品的未来评价。项目经理必须权衡合理的项目范围和进度安排、预算、人力资源及质量目标的约束。
设定需求的优先级有助于项目经理解决冲突,安排阶段性交付，并且做出必要的取舍。
 当客户的期望很高、开发时间短并且资源有限时，必须尽早确定要交付的产品应具备的最重要的功能。
 建立每个功能的相对重要性有助于规划软件的构造，以最少的费用提供产品的最大功能。
 当采用渐增式开发方式时，设定需求的优先级特别重要。因为在开发过程中，交付进度安排很紧，并且日期不可改变，必须排除或推迟一些不重要的功能。
系统分析员的态度和做法如下:
 在需求分析阶段，应该明确地提出需求的优先级和处理策略，并在软件需求规格说明书中明确说明。
 应当在项目的早期阶段设定优先级，这有助于逐步作出相互协调的决策，而不是在最后阶段匆忙决定。
 评价优先级时，应该看到不同需求之间的内在联系以及它们与项目业务需求的一致性。
 在判断出某个需求的优先级较低之前，如果开发人员已经实现了将近一半的特性和功能，那么这将是一种浪费，这个责任应该由系统分析员承担。
与在客观世界中人们对事务的分类习惯和方法相一致，系统需求的优先级设定分成3类。例如： 高、中、低；基本的、有条件的、可选的;3、2、1;等等。
需求的优先级设定如表33所示。表33需求的优先级设定
优先级命名意义高一个关键任务的需求；下一版本所要求的 中支持必要的系统操作；最终所要求的，但如果有必要，可以延迟到下一个版本 低功能或质量上的增强；如果资源允许，实现这些需求会使产品更完美 基本的只有在这些需求上达成一致意见，软件才会被接受 有条件的实现这些需求将增强产品的性能；但如果忽略这些需求，产品也是可以被接受的 可选的一个功能类，实现或不实现均可 3必须完美地实现 2需要付出努力，但不必做得太完美 1可以包含缺陷 3.3项目案例3.3.1学习目标（1） 理解需求分析的概念及其重要性。
（2） 掌握软件需求分析中的用例建模技术。
（3） 掌握软件需求的表达和软件需求规格说明书的编写。
3.3.2案例描述
本书以亚思晟eGov电子政务项目作为贯穿全书的大型系列。本案例给出了真实的软件需求规格说明书文档。《eGov电子政务项目需求规格说明书》展现了功能和非功能需求及其文档的标准格式，通过它可以更好地熟悉和理解软件需求的表达。
3.3.3案例要点
在实际工作中，需要将需求分析过程通过软件需求文档记录下来。软件需求文档虽然可以有各种不同的格式，但它的主要内容均应包括用例描述和界面导航图。
3.3.4案例实施本节内容按照项目需求规格说明书的格式要求，标题和图均独立编号。
eGov电子政务项目需求规格说明书
1引言
1.1编写目的
本需求规格说明书对项目的背景、范围、验收标准和需求等信息进行说明，包括功能性需求和非功能性需求，确保所有参与者对用户需求的理解一致。
预期的读者有（甲方）的需求提供者、项目负责人、相关技术人员等，北京亚思晟商务科技有限公司（乙方）的项目组成员，包括项目经理、客户经理以及分析、设计、开发、测试等人员。
1.2背景
电子政务系统是基于互联网的应用软件。在研究中心的网上能了解到已公开发布的不同栏目（如新闻、通知等）的内容，各部门可以发布栏目内容（如新闻、通知等），有关负责人对需要发布的内容进行审批。其中，有的栏目内容（如新闻）必须经过审批才能发布，有的栏目内容（如通知）则不需要审批就能发布。系统管理人员对用户及其权限进行管理。
1.3定义
无
1.4参考资料
孟庆国，樊博. 电子政务理论与实践［M］. 北京： 清华大学出版社，2016.
2任务概述
2.1目标
电子政务系统是基于互联网的应用软件。通过此系统可以实现权限分配、内容管理和审核等核心业务，实现政府及事业单位组织结构和工作流程的优化重组，超越时间、空间和部门分隔的限制，建成一个精简、高效、廉洁、公平的运作模式，以便全方位地向社会提供优质、规范、透明、符合国际水准的管理与服务。亚思晟eGov电子政务项目（以下根据上下文简称本项目或本系统）是一个独立的软件，整个项目外包给北京亚思晟商务科技有限公司来开发和管理。
2.2用户的特点
本系统的最终用户为组织内的日常使用者、操作人员和维护人员，他们有较高的知识文化水平和技术专长。本系统的用户数量初步估计为几百人。
2.3假定和约束
假定本系统为自包含的，不过分依赖其他外部系统。本项目的开发期限为3个月。

3需求规定
3.1对功能的规定
整体功能用例图如图1所示。
图1
3.1.1一般用户浏览的内容管理
首页是数据量最大的一页，是为所有模块展示内容的页面。从首页还可以登录进入管理等后端功能模块。
首页内容布局如图2所示。
3.1.2系统管理
系统管理功能是供系统管理人员使用的，主要包括以下功能模块： 登录、栏目业务设置、栏目权限设置、用户管理设置。
3.1.2.1登录
1. 用例描述
（1） 角色： 注册用户（用户和管理员）。
（2） 前置条件： 无。
（3） 基本事件流。
① 用户进入本系统的登录页面（E1）。
② 显示登录页面信息，如“用户名”“密码”。
③ 用户输入用户名和密码，单击“登录”按钮（E2）。

图2
④ 验证登录信息。
⑤ 加载用户拥有的权限，并将相关信息显示在页面上。
（4） 异常事件流。
E1： 输入非法的标识符。
E2： 用户账号被管理员屏蔽，无法登录。
2. 用户界面图
用户在首页登录，如图3所示。
图3
用户输入正确的用户名和密码后进入系统的权限管理页面，如图4所示。
3.1.2.2栏目业务设置
1. 用例描述
（1） 角色： 管理员。

图4
（2） 前置条件： 用户必须完成登录的用例。
（3） 基本事件流。
① 当用户登录本系统（E1）后，单击“栏目业务设置”链接。
② 进入栏目业务设置页面。
③ 设置每个栏目的内容管理（S1）和内容审核（S2）选项（单击相应的图标来更改权限）。
（4） 分支事件流。
S1： 设置内容管理。
S1.1： 单击“内容管理”链接。
S1.2： 改变内容管理的权限。
S1.3： 返回栏目业务设置页面。
S2： 设置内容审核。
S2.1： 单击“内容审核”链接。
S2.2： 改变内容审核的权限。
S2.3： 返回栏目业务设置页面。
（5） 异常事件流。
E1： 用户账号被管理员屏蔽或删除，无法操作。提示用户重新激活账号。
2. 用户界面图
单击“栏目业务设置”链接，进入该模块，设定对各栏目是否进行内容管理和内容审核。
栏目业务设置是整个权限管理模块的最高级权限设置，它的操作可以影响到栏目权限以及所有与栏目有关的权限，如图5所示。
对每个栏目可以设定是否具有内容管理和内容审核的权限。对于某些栏目（如新闻），二者都要设置，因为新闻必须经过有关领导审核批准才可以在网上发布；而对于某些栏目（如通知），只需要进行内容管理，不需要进行内容审核，就可以在网上发布。

图5
3.1.2.3栏目权限设置
1. 用例描述
（1） 角色： 管理员。
（2） 前置条件： 用户必须完成登录的用例。
（3） 基本事件流。
① 当用户登录本系统后，单击“栏目权限设置”链接。
② 进入栏目权限设置页面。
③ 单击“设置”按钮。
④ 进入栏目权限设置的具体页面。
⑤ 选择用户名，单击“添加”（S1） 或“删除”（S2） 按钮，然后保存修改。
⑥ 该栏目的用户被添加或删除。
⑦ 返回栏目权限设置页面。
（4） 分支事件流。
S1： 添加用户。
S1.1： 选择用户后单击“添加”按钮。
S1.2： 添加用户。
S1.3： 单击“返回”按钮。
S1.4： 返回栏目权限设置页面。
S2： 删除用户。
S2.1： 选择用户后单击“删除”按钮。
S2.2： 删除用户。
S2.3： 单击“返回”按钮。
S2.4： 返回栏目权限设置页面。

2. 用户界面图
单击“栏目权限设置”链接，进入该模块，在这里主要为用户分配对于栏目的管理权限，这个业务也是本系统的核心，需要在所有部门里选择用户，为其分配权限，如图6所示。
图6
单击“设置”链接，进入如图7所示的页面。
图7
页面中左侧显示备选用户，右侧显示管理权限和审核权限。选择不同部门时，该部门的所有人员应该显示在备选用户列表里。单击上面的“添加”按钮时，用户会移入管理权限列表里；单击下面的“添加”按钮时，用户会放入审核权限列表里。这里有一个业务要注意： 一个用户不可以既分配到管理权限又分配到审核权限。

3.1.2.4用户管理设置
1. 用例描述
（1） 角色： 管理员。
（2） 前置条件： 用户必须完成登录的用例。
（3） 基本事件流。
① 当用户登录本系统后，单击“用户管理设置”链接。
② 进入用户管理设置页面。
③ 单击“新增”按钮（S1） 、“修改”按钮（S2） 和“删除”按钮（S3）。
（4） 分支事件流。
S1： 单击“新增”按钮。
S1.1： 单击“新增”按钮。
S1.2： 进入添加新用户页面。
S1.3： 添加用户基本信息，单击“添加”（E1）按钮。
S1.4： 保存用户信息。
S1.5： 返回用户管理设置页面。
S2： 单击“修改”按钮。
S2.1： 单击某用户信息行“修改”按钮。
S2.2： 进入修改用户页面。
S2.3： 修改用户资料，单击“修改”按钮。
S2.4： 更新用户信息。
S2.5： 返回用户管理设置页面。
S3： 单击“删除”按钮。
S3.1： 单击某用户信息行“删除”按钮。
S3.2： 删除该用户。
S3.3： 返回用户管理设置页面。
（5） 异常事件流。
E1： 输入非法的标识符。
2. 用户界面图
单击“用户管理设置”链接，进入该模块。用户管理设置页面用于显示用户、添加用户、修改用户、删除用户。
（1） 显示用户，如图8所示。
（2） 添加用户： 单击“新增”按钮，添加新用户页面如图9所示。
输入新的用户信息，然后保存数据。
（3） 修改用户： 单击“修改”按钮，修改用户信息页面如图10所示。
（4） 删除用户： 单击“删除”按钮。
3.1.3内容管理和审核
该部分主要包括以下功能模块： 用户登录、新闻管理、通知管理。


图8
图9


图10
3.1.3.1用户登录
1. 用例描述
（1） 角色： 注册用户（用户和管理员）。
（2） 前置条件： 无。
（3） 基本事件流。
① 用户进入本系统的登录页面（E1）。
② 显示登录页面信息，如用户名和密码。
③ 用户输入用户名和密码，单击“登录”按钮（E2）。
④ 验证登录信息。
⑤ 加载用户拥有的权限，并将相关信息显示在页面上。
（4） 异常事件流。
E1： 输入非法的标识符。
E2： 用户账号被管理员屏蔽，无法登录。
2. 用户界面图
输入用户名和密码，进入系统，如图11所示。
图11

当用户进入系统时，应该看到自己的权限信息，不同的用户拥有不同的权限。
图12表明用户拥有的权限是对一个栏目进行内容管理。图13表明用户拥有的权限是对一个栏目进行内容审核。
图12
图13

3.1.3.2新闻管理
1. 用例描述
（1） 角色： 管理员和高级管理员。
（2） 前置条件： 用户必须完成登录的用例。
（3） 基本事件流。
① 用户进入系统。
② 单击“新闻管理”链接。
③ 进入新闻管理页面（新闻列表）。
④ 单击“新增”按钮（S1） 、“修改”按钮（S2） 和“删除”按钮（S3）。
（4） 分支事件流。
S1： 单击“新增”按钮。
S1.1： 单击“新增”按钮。
S1.2： 进入新闻添加页面。
S1.3： 填写新闻内容（E1）。 
S1.4： 单击“保存”按钮。
S1.5： 保存数据。
S1.6： 返回新闻管理页面（新闻列表）。
S2： 单击“修改”按钮。
S2.1： 单击“修改”按钮。
S2.2： 进入新闻修改页面。
S2.3： 修改新闻内容，单击“修改”按钮。
S2.4： 保存数据。
S2.5： 返回新闻管理页面。

S3： 单击“删除”按钮。
S3.1： 选择要删除的新闻记录，单击“删除”按钮。
S3.2： 删除新闻。
S3.3： 返回新闻管理页面。
（5） 异常事件流。
E1： 输入非法的标识符或者格式不对。
2. 用户界面图
1） 新闻编辑
单击“内容管理”下的“综合新闻管理”链接，进入新闻编辑页面，如图14所示。
图14
可以预览新闻发布的效果，如图15所示。
图15