软件开发需求文档需要画用例图吗(软件开发需求文档范例)

软件开发 41
本篇文章给大家谈谈软件开发需求文档需要画用例图吗,以及软件开发需求文档范例对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 本文目录一览: 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):用来显示系统中软件和硬件的物理构架。

软件开发需要编写哪些文档?

这个问题没有一定的,因为这里有多种因素

如,开发阶段、文档化要求程度等,若是通过CMM评估的,文档就较多

一般的是按项目开发过程来分,基本的有

可行性研究报告(若是一个新项目且未确定的或应客户要求时需要,实际上大部份公司很少有这文档)

用户需求说明书(用户+开发人员共同确认)

软件需求规格说明书

设计说明书(体系结构、详细设计)

测试用例

用户手册

实现代码

这些文档中,包括一定的分析与设计图形,如用例图、数据库结构、ER图等

当然项目计划、测试计划也应算在内

其它的(如CMM要求的)

风险、估算方面的,质量保证方面的、配置管理方面、定义的模板、度量数据库等

具体需要多少文档就是要看项目实际

这方面的东西,可参考一些软件工程类的书

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于软件开发需求文档需要画用例图吗和软件开发需求文档范例的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

扫码二维码