首页软件开发正文

软件开发需求文档需要画用例图吗（需求分析画用例图吗）

软件开发 2023-01-22T19:09:09 1499

本篇文章给大家谈谈软件开发需求文档需要画用例图吗，以及需求分析画用例图吗对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。本文目录一览： 1、我们应当怎样做需求分析：功能角色分析与用例图

本篇文章给大家谈谈软件开发需求文档需要画用例图吗，以及需求分析画用例图吗对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

1、我们应当怎样做需求分析：功能角色分析与用例图
2、UML用例图
3、需求中如何画用例图
4、软件开发流程过程中有很多图分别都什么时候话
5、我在进行文档管理系统的设计与开发，我现在进行到需求分析阶段，如果用UML的话，应该画些什么图？谢谢
6、软件开发需要编写哪些文档？

我们应当怎样做需求分析：功能角色分析与用例图

在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获-需求整理-需求验证-再需求捕获的过程。

但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。

需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。

对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。

一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。

上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日自动触发器触发自动考核功能，自动考核功能从“税收征管系统”这样一个外部系统中采集数据。

在绘制用例图时一个值得思考的细节是，用例是怎样通过分析获得的。这个问题，在一些客户对信息化管理比较有经验的项目中不存在问题，因为在客户提供给我们的需求文档中就清晰地划分出了一项一项的功能。这些功能可能会在日后的需求分析工作中有所调整，但它从整体上形成了一个雏形，成为我们进行用例分析进而形成用例的依据。

有人说，我们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图，辅之以我们对图形的描述，客户怎么会看不懂呢？关键问题在于，我们没有将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不伦不类，客户当然就看不明白了。现在我们看看用例绘制都有些什么常见问题。

1. 没有正确理解用例图的视角。前面我反复强调了，用例图的视角是用户，也就是说，站在用户的角度来观察的我们需要设计的系统。从这个视角，用户看到的系统是什么呢？当然是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。从这个意义上说，那些技术性的功能不应当出现在这里，或者应当描述为用户可以理解的文字，比如“自动考核”。而那些应当绘制的用例，在取名时也应当站在用户角度去取名。举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料；“更新员工信息”对于用户来讲又是做什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。不论是“填写新员工资料”、“更改员工资料”，还是“员工注销”，对于客户都是日常工作中需要完成的操作，将用例命名为这些名字必然为用户所理解。同时，每一个用例对于用户来说应当是有价值的，也就是说，用户使用这个功能是要完成一项操作，或获得什么信息。比如上图的“自动考核”会产生一批考核结果，执行“预警监控单项查询”可以获得预警监控结果数据。

2. 图形绘制杂乱无章。一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。我们之所以将分析设计图形化，是因为图形能给人形象立体的感官，使人立即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。因此，我们绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。

3. 用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作，并且这些操作最终应当有一个明确的结果。

如上所示这个用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。每个用例都有确定的场景，明确的目的和结果。

功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。

UML用例图

UML(Unified Modeling Language)，统一建模语言,又称标准建模语言，是为软件系统建立可视化模型。主要包括用例图、时序图、协作图、活动图、部署图、构件图、类图、状态图等等。

之前有写过UML时序图：产品经理必备之UML时序图

用例图（Use Case Diagrame）是UML的一种，主要用来描述用户、需求、系统功能之间的关系，能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。

用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。

用例图可以帮助我们更全面的考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。

1、参与者：是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者不一定是人，也可以是部门，也可以是外部系统，也可以是其他事物。通常用人形图标表示。

2、用例：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。通常用椭圆表示。

用例注意事项：

用例粒度的确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。

一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机打电话是个完整的场景，拿起手机只是一个步骤。

一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。

3、系统边界：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。

4、关系：

（1）关联关系：用一条实线表示，这条实线一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或谁启动谁。

（2）归纳（泛化）关系：表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。

用带空心箭头的实线表示，箭头指向被泛化的用例，即子用例指向父用例，泛化是从下到上的过程。（子用例继承父用例所有的结构、行为和关系，是父用例的一种特殊形式。）

（3）包含关系：表示用例与用例之间的关系，其中一个用例（父用例）的行为包含了另一个用例（子用例）的行为。

用虚线箭头+表示，箭头指向被包含的用例。一般是父用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。

（4）扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。

用虚线箭头+extend字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。

1、不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。

2、画图是为了表达、传递信息，当我们画用例图时，不管画的多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。

阅读原文

对产品经理感兴趣的朋友，可以移步“ 需求管理 ”，期待共同交流。

需求中如何画用例图

UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。 2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述： 4、泛化(generalization) 泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。 ***************************************************************** (1)系统整体用例图 (商品用例图) （购买信息用例） (用户资料用例) 按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议! 转：UML中扩展和泛化的区别泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下： ●泛化侧重表示子用例间的互斥性； ●包含侧重表示被包含用例对Actor提供服务的间接性； ●扩展侧重表示扩展用例的触发不定性；详述如下：既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况： ⒈无条件发生：肯定发生的； ⒉有条件发生：未必发生，发生与否取决于系统状态；因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

软件开发需求文档需要画用例图吗（需求分析画用例图吗）

软件开发流程过程中有很多图分别都什么时候话

软件开发中都是使用UML图来画的，一共有9种。以下是使用Edraw亿图图示画的图例。

用例图（user-case diagram）：用来定义系统的功能需求。

图例：

2.类图（class diagram）：对静态结构的描述，用来定义系统中类和类之间的关系。

图例：

3.对象图：表示类的对象实例。通常用来示例一个复杂的类图，通过对象图反映真正的实例是什么，它们之间可能具有什么样的关系，帮助对类的理解。

图例：

4.状态图：类所描述事物的补充说明，类所有对象可能具有的状态，以及引起状态变化的事物。

图例：

5.序列图：反映若干对象之间的动态协作关系，在时间轴上，对象之间是如何交互的。

图例：

6.协作图：和序列图作用相同，比序列图多显示了对象和它们之间的关系（上下文关系）。

强调时间和序列则选择序列图；强调上下文相关则选择协作图。

图例：

7.活动图(activity diagram)：反映一个连续的活动流，用于描述某个操作执行时的活动状况。

图例：

8.组件图（component diagram）：反映代码的物理结构。

图例：

9.展开图（deployment diagram）：用来显示系统中软件和硬件的物理构架。

我在进行文档管理系统的设计与开发，我现在进行到需求分析阶段，如果用UML的话，应该画些什么图？谢谢

简单地了解一下UML设计中有的图例及基本作用。首先对UML中的各个图的功用做一个简单介绍： 1、用例图描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

2、类图类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。 3、对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。　

　4、活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。　

　5、状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。 6、序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。

7、协作图和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。

8、构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。　

　9、部署图（配置图）是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。一：这九种模型图各有侧重， 1:用例图侧重描述用户需求， 2:类图侧重描述系统具体实现；二：描述的方面都不相同， 1:类图描述的是系统的结构， 2:序列图描述的是系统的行为；三：抽象的层次也不同， 1：构件图描述系统的模块结构，抽象层次较高， 2：类图是描述具体模块的结构，抽象层次一般， 3：对象图描述了具体的模块实现，抽象层次较低。在有的文献书籍中，将这九种模型图分为三大类：结构分类、动态行为和模型管理： 1：结构分类包括用例图、类图、对象图、构件图和部署图， 2：动态行为包括状态图、活动图、顺序图和协作图， 3：模型管理则包含类图。