利用用例图描述用户需求共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 管理员登录后看到的主界面管理员登录后的主页面要求：显示个人便签信息，左侧显示系统菜单和个人基本信息，上标栏有“主页”、“重新登录”、“修改密码”、显示当前时间功能。
需求的用例描述
了解系统所依赖的其他系统、数据源和外部实体，以 及任何限制或约束。
编写需求用例
编写清晰、简洁的用例描述
使用简练的语言描述用例，包括前置条件、后置条件、操作流程 和结果等。
确定用例的优先级
根据业务重要性和紧急程度，为用例分配优先级，以便合理安排开 发进度。
编写验收准则
为每个用例编写明确的验收准则，以便于测试和验证。
需求的用例描述
• 引言 • 需求用例描述基础 • 需求用例的识别和编写 • 用例描述的详细内容 • 用例描述的常见问题 • 用例描述的实践建议
景
简述主题的背景信息，包括相关 领域的发展状况、市场需求等。
主题意义
阐述主题的重要性和意义，说明 为什么这个主题值得研究。
目的和目标
准确的，有助于团队成员更好地理解和实施需求。
用例的属性
用例的属性包括用例的标识符、名称、 描述、优先级、状态等。
标识符是唯一标识一个用例的编号或名称， 用于在文档和项目管理工具中追踪和引用。
名称是用例的简短描述，用于标识用 例的主要功能或目标。
描述是对用例的详细说明，包括参与者和 用例之间的交互以及用例的行为和条件。
优先级用于确定用例的开发顺序，高优先级的 用例通常先于低优先级的用例进行开发和实现。
状态表示用例的开发阶段，如草稿、 开发中、已完成等。
03
需求用例的识别和编写
识别需求用例
识别主要业务场景
从业务需求中识别出主要业务场景，包括业务流程、 角色和操作等。
识别非功能性需求
分析系统应具备的性能、安全、可用性等非功能性需 求。
目的
明确提出研究的目的，即希望解决什么问题或满足什么需求 。
目标
利用用例图描述用户需求
命名用例一般要 用动词开）什么是系统 系统代表的是一部机器设备或者是一个商务活动等，而并 不是所要实现的最终软件系统； 系统的边界用来说明构建的用例模型的应用范围（用例在 系统之内）。 在Rose 工具中没有体现！ （2）表示形式 用例图中的系统采用一个长方形框表示，系统的名字写在 方框的上面或者方框内
没有统一的格式，不能自动化地验证 ； 不能保证文档与程序同步。
（2）那我们怎么描述？--形式和内容是什么！
因为我们在系统开发时必须要了解并准确描述用户的各 个方面的需求，这包括功能、非功能以及环境的约束等方面 需求。同时，我们所采用的方法能否避免常规的方法所带来 的问题？
（3）我们可以采用UML中的用例模型方法！
网上银行系统中的用例关系人员管理系统中的用例关系3用例的横向方面的联系包含关联包含关联指一个基本用例的行为包含了另一个用例的行为这种包含关联是一种依赖关系被包含的用例不能独立存在只能作为包含它的用例的一部在rose中的实现状态在visio中的实现状态4用例的横向方面的联系扩展关联基本的用例必须声明若干新的规则扩展点扩展用例只能在这些扩展点上增加新的行为并且基本用例不需要了解扩展用例的实现细节注意区分扩展关系与前面的泛化关系的不同其一侧重于问题的特殊性而另一种则侧重于问题的延续性在修改和录入中都有保存的功能但还提供了除保存之外的附加功能
（2）参与者可能有 三大类 系统用户 （使用者或 者操作员） 与所建系统 交互的其他 系统 其它设备
因此，参与者不 完全都是“人”
（3）某项目中的各个参与者示例说明
（4）参与者之间的主要关系---泛化关系
特化或者继 承
（5）所要注意的问题
（6）如何获得系统中的参与者
4、用例模型中的用例（UseCase）
用例图的简单描述
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这一步还远没有完成，接下来应该对要实现的功能进一步分析，那些用例其实是一种，用例之间有那些关系，如上面列出的一般化关系，扩展关系等等。
跟我学统一建模语言UML——利用UML用例图描述用户的功能性需求
1.1跟我学统一建模语言UML——利用UML用例图描述用户的功能性需求1.1.1UML中的用例及用例图1、用例及用例图产生的技术背景在软件系统的需求分析与系统设计中，开发人员必须要了解并准确地描述软件系统用户的功能需求，以便于确定建立的对象。
很长时间以来，无论是传统的软件系统开发方法还是面向对象的软件系统开发方法，都采用自然语言（如中文）来描述对软件系统的需求其缺点是没有统一的格式，缺乏描述的形式化，随意性较大，常常产生理解上的含混及不确定性；在这种背景下，有关专家提出了用例（Use Case）的概念及其图形表示方法——用例图，这种方法很快得到广泛的应用。
2、用例模型的基本组成部件为参与者、用例和系统删除成员3、用例模型的基本组成部件中的参与者（1）参与者（Actor）参与者表示系统用户能扮演的角色(role)，这些参与者可能有三大类：系统用户、与所建系统交互的其他系统、时间。
1)软件系统用户：使用本软件系统的人；2)其他系统：可能是其他的计算机或者一些硬件或者甚至是其它软件系统；3)时间：时间作为参与者时，经过一定时间触发系统的某个事件。
例如，ATM机可能每天午夜运行一些协调处理。
由于事件不在本系统的控制之内，因此也是本软件系统的参与者。
（2）某个“网上书店”和“在线网校”项目中的各个参与者示例说明在“网上书店”项目中的参与者主要有用户和系统统管理员，而管理员使用控制面板对系统和用户管理，也就是进行系统设置，管理用户、用户组、权限，查看系统访问日志及用户使用情况等的统计信息。
在“在线网校”项目中的学校课程管理子系统中则有三个参与者在不同的应用中互动。
这三个参与者分别是学生，讲师以及系统管理者。
而学生参与者使用了系统中浏览课程以及注册课程的功能，而系统管理者参与者则是负责管理注册的学员，编排课程以及确认课程。
讲师则是主导课程的参与者，他可以浏览，开办以及移除课程（当然，必须是这个讲师自己的课程）。
用例描述模板
用例描述模板篇一：用例描述文档模板篇二：用例描述模板实验一编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例）用例描述模板是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。
写出用例是一种最好的理解和描述需求的技巧。
注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。
名称用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。
概述或简要描述单列一节概述该用例完成什么通常是有益的。
参与者列出此用例涉及的参与者和负责发起此用例执行的主要参与者。
触发器触发器是开始此用例的事件。
触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆(来自: 小龙文档网:用例描述模板)的一个预约电话”。
而在另一种情况下，触发者可能是此用例中第一个系统事件。
前置条件前置条件概述在用例可以开始前，什么必须为真。
通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。
典型的前置条件可以是“用户已成功登陆”。
后置条件后置条件概述当用例完成时什么是真。
在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。
区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。
事件路径或脚本基本的或正常的事件路径，通常应当作为不中止的交互序列出现。
对事件路径中的交互通常加以编号，以便于以后的参考。
可选和例外事件路径可选和例外事件路径可以完整地写出。
然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。
扩展点这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。
扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。
chap7 需求分析-用例图
Sample Use-Case Model Diagram
Copyright © 2004 The McGraw-Hill Companies. All Rights reserved
Benefits of Use-Case Modeling
• Provides a tool for capturing functional requirements(获取功能 需求).
Chapter 7
MODELING SYSTEM REQUIREMENTS WITH USE CASES 使用用例建模系统需求
Copyright © 2004 The McGraw-Hill Companies. All Rights reserved
An Introduction to Use-Case Modeling 简介 • One of the primary challenges in a system design process is the ability to elicit(提取) the correct and necessary system requirements from the stakeholders and specify them in a manner understandable to them so those requirements can be verified and validated.
– The stakeholder that is not the primary actor but receives something of value from the use case.
– e.g. the warehouse receiving aCoppyarigchtk©in20g04 TshleiMpcGraw-Hill Companies. All Rights reserved
需求分析——UML用例图STUD
-26-
用例图元素
用例
参与者 系统边界 直接关联 关联
<<extend>> <<include>>
扩展 包含 泛化
注释体
注释连接
-27-
2.1 识别参与者
参与者，Actor
关键词：边界 参与者：在系统之外，透过系统边界与系统
进行有意义交互的任何事物
-28-
非功能性需求
可支持性（Supportability）
-11-
内容安排
UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程
-12-
需求：饮料问题
我要一瓶饮料… 差不多，但我要无糖饮料…
难 捕
很好，不过我要绿茶的…
获
啊，没有大瓶的…
-37-
要点：用户观点而非系统观点
旅客
订票 查看今日航班
用户观点
处理订票
旅客
显示今日航班
系统观点
-38-
用例 VS. 功能
•呼叫某人 •接听电话 •发送短信 •记住电话号码 •……
用户观点
•传输/接收 •电源/基站 •输入输出（显示、键盘） •电话簿管理 •……
系统观点
-39-
用例的命名
执行者视角：
UML 2.0
2003年6月OMG采纳了UML 2.0的 Superstructure的提案
正式文本尚未发布 …
-6-
UML 9种图
类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。
（2）用例的纵向方面的关系-----泛化关联
泛化关联代表一般与特殊的关系，它充分体现了面向对象 的继承性
提供用例图的目的之 一是下面的描述
（1）什么是用例图
用例图是一种图形化的工具，它用简单的图形元素表示出
系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
（3）用例图的组成元素
在一个用例图中，一般主要 包含有 系统边界
2、子曰：“知之者不如好之者,好之者不如乐之者”
3、子曰：“三人行,必有我师焉”
4、子曰：“我非生而知之者,好古,敏以求之者也”
更多精品资请访问
更多品资源请访问
（4）用例的命名
每个用例应有唯一的名称
命名用例一般要 用动词开头 ！
命名的方式：用例通常用动词 + 名词短语来命名----如：
登录系统
（5）用例的UML图示
5、用例模型中的系统
（1）什么是系统
系统代表的是一部机器设备或者是一个商务活动等，而并
不是所要实现的最终软件系统；
系统的边界用来说明构建的用例模型的应用范围（用例在
根据继承关系：子类具有父类的所有属性，还可以拥有自 己的属性特点及行为---因此，父子用例也应该具有这些特 性。
网上银行 系统中的 用例关系
人员管理 系统中的 用例关系
（3）用例的横向方面的联系---包含关联
包含关联指一个基本用 例的行为包含了另一个 用例的行为
这种包含关联是一种依 赖关系，被包含的用例 不能独立存在，只能作 为包含它的用例的一部 分
系统用例：如报表打印
获得用例的手段可以有很 多种---可以是“不择手 段”！
说法不一，见仁见智！ 不同项目和面向不同的 用户都不一样！
（3）如何确定系统中的用例---参考文档说明
识别用例有一个简单的判断方法：用户（活动者）通过 系统实现×××目的。
一个系统中的用例的种类大致如下：系统的开始和停止的 用例、系统维护的用例、维护系统中存储的数据的用例、修 改系统行为的功能的用例和系统中代表业务功能的用例。
（2）那我们怎么描述？--形式和内容是什么！
因为我们在系统开发时必须要了解并准确描述用户的各个方 面的需求，这包括功能、非功能以及环境的约束等方面需求。 同时，我们所采用的方法能否避免常规的方法所带来的问题？
（3）我们可以采用UML中的用例模型方法！
项目开始时，Use Case视图的主要使用者是客户、分析人 员和项目管理员。
样的功能
3、用例建模方法最主要的优点----在于它是用户导向的
（1）用户可以根据自己所对应的用例来不断细化自己的需求。 （2）此外，使用用例还可以方便地得到系统功能的测试用例。
提供用例图的目的之二是帮助开发团队理解客 户对系统的各种功能需求。
本讲的简要回顾
1、子曰：“学而不思则罔，思而不学则殆。” “学而时习之”
在Rose中的 实现状态
在Visio中 的实现状态
（4）用例的横向方面的联
系---扩展关联
基本的用例必须声明若干新
的规则---扩展点
扩展用例只能在这些扩展点
上增加新的行为并现细节
其一侧重于问题的特殊性，而另一种则侧重于 问题的延续性（在修改和录入中都有保存的功能， 但还提供了除保存之外的附加功能）。
参与者 用例和用例关系
（泛化、使用和扩展等三 种形式）。
这在前面已经加 以说明过
2、用例图的主要作用 （1）面向用户
可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者；
也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者
表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统，则反映了系统能够完成什么
注意区分扩展关系与前面的泛化关系的不同
三、如何进行用例建模
1、用例建模的主要步骤
2、如何编写用例
3、各种用例示例点评
（1）用例示例点评一：错误用例：提取现金 （2）用例示例点评二：错误用例：提取现金 （3）用例示例点评三：错误用例：买东西
请见文档中的说明
书写用例的模板格式
四、UML中的用例图
1、用例图
一、UML中的用例及用例图
1、用例及用例建模技术产生的背景概述 （1）UML之前对系统的需求描述方法
一般是采用自然语言（如中文）来描述对系统的需求，这 样的方法有几个致命的缺陷。 缺乏描述的形式化，随意性较大，常常产生理解上的含混
及不确定性----自然语言的描述容易产生歧义 ；
没有统一的格式，不能自动化地验证 ； 不能保证文档与程序同步。
因此，参与者不 完全都是“人”
（3）某项目中的各个参与者示例说明
（4）参与者之间的主要关系---泛化关系
特化或者继 承
（5）所要注意的问题
（6）如何获得系统中的参与者
4、用例模型中的用例（UseCase）
（1）用例及其定义—某种特定的功能
用例的确定只是与 用户交流的目的， 而不是交流的手段
（2）用例的分类 业务用例：如报表数据汇总计算
这些人利用使用案例、Use Case框图和使用文档来确定系 统的高层视图
2、用例模型中的基本组成部件 （1）用例（UseCase） （2）系统
（3）参与者
3、用例模型的参与者
（1）参与者：参与者表示系统用户所扮演的各个角色(role）
（2）参与者可能有 三大类 系统用户 （使用者或 者操作员） 与所建系统 交互的其他 系统 其它设备
系统之内）。 （2）表示形式
在Rose 工具中没有体现！
用例图中的系统采用一个长方形框表示，系统的名字写在
方框的上面或者方框内
二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和包 含
（1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 系统层用例图：描述系统提供的全部主要的功能或服务。