软件开发需求文档需要画用例图吗（软件开发需求文档范例）
今天给各位分享软件开发需求文档需要画用例图吗的知识，其中也会对软件开发需求文档范例进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
软件开发需要编写哪些文档？
这个问题没有一定的，因为这里有多种因素
如，开发阶段、文档化要求程度等，若是通过CMM评估的，文档就较多
一般的是按项目开发过程来分，基本的有
可行性研究报告（若是一个新项目且未确定的或应客户要求时需要，实际上大部份公司很少有这文档)
用户需求说明书(用户+开发人员共同确认)
软件需求规格说明书
设计说明书(体系结构、详细设计)
测试用例
用户手册
实现代码
这些文档中，包括一定的分析与设计图形，如用例图、数据库结构、ER图等
当然项目计划、测试计划也应算在内
其它的(如CMM要求的)
风险、估算方面的，质量保证方面的、配置管理方面、定义的模板、度量数据库等
具体需要多少文档就是要看项目实际
这方面的东西，可参考一些软件工程类的书
我们应当怎样做需求分析：功能角色分析与用例图
在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获-需求整理-需求验证-再需求捕获的过程。
但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。
上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日自动触发器触发自动考核功能，自动考核功能从“税收征管系统”这样一个外部系统中采集数据。
在绘制用例图时一个值得思考的细节是，用例是怎样通过分析获得的。这个问题，在一些客户对信息化管理比较有经验的项目中不存在问题，因为在客户提供给我们的需求文档中就清晰地划分出了一项一项的功能。这些功能可能会在日后的需求分析工作中有所调整，但它从整体上形成了一个雏形，成为我们进行用例分析进而形成用例的依据。
有人说，我们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图，辅之以我们对图形的描述，客户怎么会看不懂呢？关键问题在于，我们没有将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不伦不类，客户当然就看不明白了。现在我们看看用例绘制都有些什么常见问题。
1. 没有正确理解用例图的视角。前面我反复强调了，用例图的视角是用户，也就是说，站在用户的角度来观察的我们需要设计的系统。从这个视角，用户看到的系统是什么呢？当然是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。从这个意义上说，那些技术性的功能不应当出现在这里，或者应当描述为用户可以理解的文字，比如“自动考核”。而那些应当绘制的用例，在取名时也应当站在用户角度去取名。举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料；“更新员工信息”对于用户来讲又是做什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。不论是“填写新员工资料”、“更改员工资料”，还是“员工注销”，对于客户都是日常工作中需要完成的操作，将用例命名为这些名字必然为用户所理解。同时，每一个用例对于用户来说应当是有价值的，也就是说，用户使用这个功能是要完成一项操作，或获得什么信息。比如上图的“自动考核”会产生一批考核结果，执行“预警监控单项查询”可以获得预警监控结果数据。
2. 图形绘制杂乱无章。一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。我们之所以将分析设计图形化，是因为图形能给人形象立体的感官，使人立即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。因此，我们绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。
3. 用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作，并且这些操作最终应当有一个明确的结果。
如上所示这个用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。每个用例都有确定的场景，明确的目的和结果。
功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
软件开发流程过程中有很多图分别都什么时候话
软件开发中都是使用UML图来画的，一共有9种。以下是使用Edraw亿图图示画的图例。
用例图（user-case diagram）：用来定义系统的功能需求。
图例：
2.类图（class diagram）：对静态结构的描述，用来定义系统中类和类之间的关系。
图例：
3.对象图：表示类的对象实例。通常用来示例一个复杂的类图，通过对象图反映真正的实例是什么，它们之间可能具有什么样的关系，帮助对类的理解。
图例：
4.状态图：类所描述事物的补充说明，类所有对象可能具有的状态，以及引起状态变化的事物。
图例：
5.序列图：反映若干对象之间的动态协作关系，在时间轴上，对象之间是如何交互的。
图例：
6.协作图：和序列图作用相同，比序列图多显示了对象和它们之间的关系（上下文关系）。
强调时间和序列则选择序列图；强调上下文相关则选择协作图。
图例：
7.活动图(activity diagram)：反映一个连续的活动流，用于描述某个操作执行时的活动状况。
图例：
8.组件图（component diagram）：反映代码的物理结构。
图例：
9.展开图（deployment diagram）：用来显示系统中软件和硬件的物理构架。
关于软件开发需求文档需要画用例图吗和软件开发需求文档范例的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
