利用用例图描述用户需求共21页文档

1系统需求和需求分析说明书模板Mohit系统需求和需求分析说明书模板第一部分概述1．项目名称及背景➢项目名称➢开发背景2．文档说明第二部分任务说明1．功能概述2．用户环境浏览器(如IE 6以上版本)+网络开发(生产)环境:第三部分需求分析1．实现功能➢系统用例图用户业务逻辑如下图所示：95➢管理员功能清单功能编号功能名称文中标题编号备注101 人事管理101001 机构管理101002 部门管理101003 员工管理➢普通用户功能清单2．用例说明➢ [用例1] ●用例图●描述●参与者➢[用例2] ●用例图●描述●参与者➢[用例3] ●用例图●描述●参与者➢[用例4] ●用例图●描述●参与者➢[用例5] ●用例图●描述●参与者➢[用例6 ●用例图●描述●参与者➢[用例7] ●用例图●描述●参与者➢ [用例8]●用例图●描述●参与者➢ [用例9]●描述文件搜索功能：可以按条件查询需要的文件。

●参与者//*参与者，参与用例的对象*// ➢[用例10]●用例图发送消息消息管理管理消息●描述消息管理主要包括：创建消息、修改消息、删除消息、发布消息。

●参与者//*参与者，参与用例的对象*// ➢[用例11]●用例图●描述●参与者➢[用例12] ●用例图●描述●参与者➢[用例13] ●用例图●描述●参与者➢[用例14]●用例图●描述●参与者3．用例关系附1.2 系统设计说明书模板系统设计说明书版本历史第一部分概述1．文档说明2．系统需求概述第二部分系统总体结构第三部分系统设计类图//*系统中主要的、关键实体类图，参考图如下*//➢[用例1]实现●时序图//用例1的时序图，参考图如下*//●描述界面设计1．公共模块界面设计说明：页面设计要求尽量使用div布局完成。

所有的GridView要求实现分页功能。

图1.1用户登陆首页用户登陆首页要求：只有当用户名、密码都正确时才能通过验证。

107图1.2 管理员登录后看到的主界面管理员登录后的主页面要求：显示个人便签信息，左侧显示系统菜单和个人基本信息，上标栏有“主页”、“重新登录”、“修改密码”、显示当前时间功能。

Use Case View Summary这段文字是翻译自Mark Priestley《Practical Object-Oriented Design with UML》的，算是对用例图作个总结，增加我自己的理解和记忆，也希望对大家有所帮助。

●用例视图（use case view）包括actors 和用例(use cases)。

Actors描述了用户在和系统交互的过程中可以扮演的角色。

用例描述了系统提供给actors的功能。

●用例定义了用户和系统之间的某种特定类型事务。

某个特定类型的交互，或者说用例的实例可以在场景(scenarios)中描述。

UML并没有给出用例和场景的正式定义。

●场景可以被定义为陈述了用例所描述的基本的事件发生过程，并且陈述了可能发生的异常情况。

●用例图（use case diagram）画出了参与在系统中的actors和用况。

一个actor和一个用况之间存在关联说明这个actor参与这个用况其中。

●用例和用例之间， actor和actor之间可以存在一般化关系（类似于类class之间的超类、继承），就是说某个用例或actor是另外一个的特殊情况。

●用例之间还存在这“包含（include）”关系，就是说一个用例可以包含另外一个。

类似于函数调用，这为用例的重用提供了一种机制。

●用例之间的另外一种关系“扩展(extend)”运行一个用例提供可选的功能。

通过定义扩展点和何时执行何种功能来定义这种关系。

这些信息在用例图中是可选的。

●一个用例或者场景的实现描述了足够实现这个用例（或场景）功能的，可交互对象的结构。

●序列图（sequence diagram）和协作图（collaboration diagram）画出参与在一个交互中的对象和他们之间互相发送的消息，可以描述一个用例的实现。

译文就到此为止了，我想大概的就我的理解说明一下，以防止大家看的摸不着北。

Use case view是由需求到最终实现的第一步，目标系统需要有那些潜在或者明显的功能，有那些目标用户，这些东西画出来后use case这一步还远没有完成，接下来应该对要实现的功能进一步分析，那些用例其实是一种，用例之间有那些关系，如上面列出的一般化关系，扩展关系等等。

1.1跟我学统一建模语言UML——利用UML用例图描述用户的功能性需求1.1.1UML中的用例及用例图1、用例及用例图产生的技术背景在软件系统的需求分析与系统设计中，开发人员必须要了解并准确地描述软件系统用户的功能需求，以便于确定建立的对象。

很长时间以来，无论是传统的软件系统开发方法还是面向对象的软件系统开发方法，都采用自然语言（如中文）来描述对软件系统的需求其缺点是没有统一的格式，缺乏描述的形式化，随意性较大，常常产生理解上的含混及不确定性；在这种背景下，有关专家提出了用例（Use Case）的概念及其图形表示方法——用例图，这种方法很快得到广泛的应用。

2、用例模型的基本组成部件为参与者、用例和系统删除成员3、用例模型的基本组成部件中的参与者（1）参与者（Actor）参与者表示系统用户能扮演的角色(role)，这些参与者可能有三大类：系统用户、与所建系统交互的其他系统、时间。

1)软件系统用户：使用本软件系统的人；2)其他系统：可能是其他的计算机或者一些硬件或者甚至是其它软件系统；3)时间：时间作为参与者时，经过一定时间触发系统的某个事件。

例如，ATM机可能每天午夜运行一些协调处理。

由于事件不在本系统的控制之内，因此也是本软件系统的参与者。

（2）某个“网上书店”和“在线网校”项目中的各个参与者示例说明在“网上书店”项目中的参与者主要有用户和系统统管理员，而管理员使用控制面板对系统和用户管理，也就是进行系统设置，管理用户、用户组、权限，查看系统访问日志及用户使用情况等的统计信息。

在“在线网校”项目中的学校课程管理子系统中则有三个参与者在不同的应用中互动。

这三个参与者分别是学生，讲师以及系统管理者。

而学生参与者使用了系统中浏览课程以及注册课程的功能，而系统管理者参与者则是负责管理注册的学员，编排课程以及确认课程。

讲师则是主导课程的参与者，他可以浏览，开办以及移除课程（当然，必须是这个讲师自己的课程）。

用例描述模板篇一：用例描述文档模板篇二：用例描述模板实验一编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例）用例描述模板是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。

写出用例是一种最好的理解和描述需求的技巧。

注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。

名称用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。

概述或简要描述单列一节概述该用例完成什么通常是有益的。

参与者列出此用例涉及的参与者和负责发起此用例执行的主要参与者。

触发器触发器是开始此用例的事件。

触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆(来自: 小龙文档网:用例描述模板)的一个预约电话”。

而在另一种情况下，触发者可能是此用例中第一个系统事件。

前置条件前置条件概述在用例可以开始前，什么必须为真。

通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。

典型的前置条件可以是“用户已成功登陆”。

后置条件后置条件概述当用例完成时什么是真。

在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。

区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。

事件路径或脚本基本的或正常的事件路径，通常应当作为不中止的交互序列出现。

对事件路径中的交互通常加以编号，以便于以后的参考。

可选和例外事件路径可选和例外事件路径可以完整地写出。

然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。

扩展点这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。

扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。

需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor ）提供的一段完整的服务。

从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。

但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含（inelude）、扩展（extend）和泛（generalization）几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)包含关系：使用包含（Inclusion ）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。

基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。

但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。

员工考勤系统TITLE \* MERGEFORMAT 用户需求规格说明书目录0. 文档介绍 (3)0.1文档目的 (3)0.2文档范围 (3)0.3读者对象 (3)0.4参考文档 (3)0.5术语与缩写解释 (3)1. 产品介绍 (5)2. 产品面向的用户群体 (5)3. 产品应当遵循的标准或规范 (5)4. 产品范围 (5)5. 产品中的角色 (5)6. 产品的功能性需求 (6)6.0功能性需求分类............................ 错误!未定义书签。

6.M F EATURE M ................................... 错误!未定义书签。

6.m.n Function M.N .......................... 错误!未定义书签。

7. 产品的非功能性需求 .......................... 错误!未定义书签。

7.1用户界面需求.............................. 错误!未定义书签。

7.2软硬件环境需求............................ 错误!未定义书签。

7.3产品质量需求.............................. 错误!未定义书签。

7.N 其他需求 .................................. 错误!未定义书签。

附录A：需求建模与分析报告...................... 错误!未定义书签。

A.1需求模型1 ................................. 错误!未定义书签。

A.N 需求模型N ................................. 错误!未定义书签。

附录B：需求确认................................ 错误!未定义书签。

0. 文档介绍为了实现企业考勤管理的各种需求,实现整个管理过程的自动化，无纸化办公，方便管理层的管理，改变原有不合理的人工管理方式存在的一些漏洞等。

客户关系管理系统用例图举例客户关系管理系统1 概述客户是公司最宝贵的资源，为了更好的发掘老客户的价值，并开发更多新客户，XX公司决定实施客户关系管理系统。

希望经过这个系统完成对客户基本信息、联系人信息、交往信息、客户服务信息的充分共享和规范化管理；希望经过对销售机会、客户开发过程的追踪和记录，提高新客户的开发能力；希望在客户将要流失时系统及时预警，以便销售人员及时采取措施，降低损失。

并希望系统提供相关报表，以便公司高层随时了解公司客户情况。

客户服务是一个涉及多个部门，存在一定流程的工作。

客户服务水平的高低决定着公司的核心竞争力。

该客户关系管理系统应提供一个客户服务在线平台，使客户服务处理过程中相关人员能够在线完成服务的处理和记录工作。

1.1 目的本文档的编写为下阶段的设计、开发提供依据，为项目组成员对需求的详尽理解，以及在开发开发过程中的协同工作提供强有力的保证。

同时本文档也作为项目评审验收的依据之一。

1.2 范围本系统包括：营销管理、客户管理、服务管理、统计报表和基础数据五个功能模块。

另包括权限管理模块用于系统的用户、角色和相关权限，收发邮件功能用于获得客户的详细需求，文档管理功能用于客户信息文件的存储。

2 系统说明2.1 概述客户关系管理系统用于管理与客户相关的信息与活动，但不包括产品信息、库存数据与销售活动，这三部分内容有其公司销售系统进行管理。

但本系统需要提供产品信息查询功能、库存数据查询功能、历史订单查询功能。

2.2 用户与角色与本系统相关的用户和角色包括：系统管理员：管理系统用户、角色与权限，保证系统正常运行。

高管：审查客户贡献数据、客户构成数据、客户服务构成数据和客户流失数据。

客户经理：维护负责的客户信息。

接受客户服务请求，在系统中创立客户服务。

处理分派给自己的客户服务。

对处理的服务进行反馈。

创立销售机会。

对特定销售机会制定客户开发计划。

执行客户开发计划。

对负责的流失客户采取“暂缓流失”或“确定流失”的措施。

1.1如何应用UML用例图描述软件系统的用户需求（第3/3部分）1.1.1UML用例的事件流1、用例所涉及的主要事件（1）用例的事件流用例的事件流是对完成用例行为所需的事件的描述。

事件流描述了一个用例的行为实现的主要过程。

（2）作用可以通过一个清晰的，易被用户理解的时间流来说明一个用例的行为。

（3）用例的事件流建模的基本要求在事件流中包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流。

（4）为什么要应用用例的事件流建模对用例进一步细化，同时也为后面的动态建模提供基础。

2、一个用例的事件流的组成（1）所应该包含的内容----可以参考提供的格式模板（2）主要的内容1)简要说明：描述该使用案例的作用（可以不写出）；2)前置条件：开始使用该用例之前必须满足的系统和环境的状态和条件（必要条件而不是充分条件）3)主事件流：用例的正常流程（事件流是关注系统干什么，而不是怎么干），也称为用例的路径。

4)其它（备选）事件流：用例的非正常流程，如错误流程5)后置条件：用例成功结束后系统应该具备的状态和条件（但不是每个用例都有后置条件）（3）主事件流（用例的路径）事件流中可能包含有基本路径、备选路径、异常路径、成功路径和失败路径等几个方面的内容。

但首先要写基本路径，因为它是客户最想看到和最关心的东西。

3、描述用例的事件流的主要方式●结构化语言（用例事件流）每个用例只描述没有大的分支的行为的单个线索，在事件流中要对事件流进行结构化说明（主事件流和备选事件流）。

利用用例事件流，可以很细腻的表达一些用例的过程，但是，当用例的事件流比较复杂的时候，单纯用文字表达难以清楚的表示相互之间的关系，特别是一些并发关系，这时，可以借用活动图来表示。

●UML中的顺序图作为交互图中的一种，顺序图显示了参与交互作用的参与者或对象，以及它们生成的按时间排序的事件。

通常，顺序图显示特定用例实例产生的事件并且侧重描述消息在对象之间如何传送。

1.1如何应用UML用例图描述软件系统的用户需求（第2/3部分）1.1.1UML中的用例图及在Rose/Visio中的实现1、什么是用例图（1）用例图及其主要作用在面向对象分析的方法中通常使用Use Case来获取软件的需求。

Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。

通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。

注意：1)用例内容描述包含了定义系统实际需求和功能的重要信息。

2)除了可以用用例以外，用户还可以选择另一种方式：绘制活动图3)然而，记住以下这一点是很重要的：用例应该便于与最终用户沟通，如果采用比较正式的结构，如活动图，可能会使人们不习惯对用例的内容进行解释，从而造成沟通上的不便。

（2）为什么要采用用例图来描述需求用例图是一种图形化的工具，它用简单的图形元素表示出软件系统的参与者、用例以及它们之间的联系。

通过用例图能够较好地避免了软件系统在功能表达方面的歧义性，便于软件系统的最终用户和软件系统的开发人员共同理解系统的需求，取得一定的共识。

（3）用例图中的参与者和用例之间的通信参与者和用例之间的使用关系，在用例图中表示为一个带箭头的直线。

（4）用例图的组成元素在一个用例图中，一般主要包含有系统边界、参与者、用例和用例关系（通信、使用和扩展等三种形式）。

（5）Use Case方法最主要的优点●在于它是用户导向的用户可以根据自己所对应的Use Case来不断细化自己的需求。

此外，使用Use Case 还可以方便地得到系统功能的测试用例。

●建立用例模型的目的建立用例模型的目的则是帮助开发团队理解客户对系统的各种功能需求。

2、UML用例图在网上书店项目中的具体应用---确定项目系统中的角色（参与者）的种类在本项目的设计中主要是要考虑有多少种不同类型的用户？都是哪几种类型的用户，用户的角色如何定义；用户的访问权限如何分配等。

（1）在网上书店应用中根据应用的要求，可能会有1)图书信息的浏览者(Visitor，没有进行购买行为的用户)2)图书的购买者（读者用户）3)收银员（如财务人员）4)管理员和超级管理员(Administrator，系统管理员)。

用户需求流程说明书・1・用户需求流程说明书ifl<r樓火团队用户需求流程说明书1用例图1.1用户采购需求客户端園Sain 自UseCaseDiagraml图6T用户采购需求客户端用例图顾客添加商购務车组护<<indude»牛成订单这拜支付万式<<indude»使用优惠码«indude?>--^Windudc>> '<<inclydc»«indude>>图6-2仓库管理用例图1・3用户退货需求用例图系统管理员组合樓火团队 用户需求流程说明书・3・1.2仓库管理用例图圍 Main 禺 Use Case Diagram 1仓库管理员图6-3用户退货需求用例图组介樓火团队用户需求流程说明书2用例描述1）.用户登录1.0用例名称：用户登录客户端功能：用于与服务器建立连接，连接成功后登录服务器。

l.i简要说明:本用例的功能主要向服务器发送连接请求，并向服务器提供验证所需耍的用户名和密码。

1.2事件流:1.2. 1基本流：1用户填写用户名、密码、服务器IP地址、端口号。

2用户请求登录。

3客户端程序检査用户填写的内容是否合法（具体要求请参照1.3特殊需求），如果未通过检查, 则转向备选流1。

4客户端程序向服务器发送连接请求，如果出现连接超时，转向备选流2。

5服务器接收请求，连接成功。

6服务器验证用户名和密码，如果验证没有通过，转向备选流3。

7验证通过，显示客户端程序主窗体。

8用户执行其它操作将退出本用例。

1.2.2备选流：1. 2. 2. 1备选流1：1如果客户端检査没有通过，比如没有输入用户名，应捉示“用户名不能为空！”，如果输入的用户名超过了指定的列数，应提示“用户名的列数不能超过x列！”，诸如上面的提示均是有效提示。

2用户返回基本流1。

1. 2. 2. 2备选流2：1如果用户请求连接超时，将返回“服务器连接超时，请与网络管理员联系！”的消息。

RequirementAnalysisSpecification需求分析规格书1版本更新記錄目录1版本更新記錄 (1)2用例圖 (4)3用例:GR _UC001創建收貨單 (4)3.1用例活動圖 (4)3.2參與者 (4)3.3用例觸發事件 (5)3.4用例概要 (5)3.5用例流程詳述 (5)4用例：GR_UC002召回收貨單 (8)4.1用例活動圖 (8)4.2參與者 (8)4.3用例觸發事件 (8)4.4用例概要 (8)4.5用例流程詳述 (9)5用例：GR_UC003沖銷收貨單 (9)5.1用例活動圖 (9)5.2參與者 (9)5.3用例發生條件 (10)5.4用例觸發事件 (10)5.5用例概要 (10)5.6用例流程詳述 (10)6類圖Class Diagram (11)6.1類圖 (11)6.2系統主類 (11)6.3其他公用類 (13)7系統接口簡介 (13)2 用例圖3 用例:GR _UC001創建收貨單3.1 用例活動圖收貨單創建者：[Creater]屬於變動角色，由具有[角色管控權限]的人指定。

2. 收貨單申請者：[Applicant]發出收貨申請的人，其他人可以代替該角色起草[收貨單]。

3. [GA 總務]4. 例外控制成員:[Exception Controller]CreaterApplicant屬於變動角色群體，由人為指定。

如果[收貨單]被提交給[SAP系統]進行處理，出現失敗情況，則該角色會參與到[收貨單]創建過程，否則不參與。

3.3 用例觸發事件1.在用例流程中，如果按鈕[Submit]被點選，則系統發送[通知郵件]給[Applicant]和下一個關卡的[User]。

2.在用例流程中，如果按鈕[Approve]被點選，則系統發送[通知郵件]給下一個關卡的[User]，如果點選該[Approve]按鈕的當前使用者是最後一個關卡，則系統發送[通知郵件]給[Submitter]和[Applicant]。