推荐3个制作流程图的工具：1、Visio很好用，很强大，微软出的，水平好的可以用它制作出任何东西来（水平一般的就会做得比较难看，这和微软风格有关，默认的都没啥美感）；2、EDraw（亿图），又强大又好用，很容易上手，做出来的东西也漂亮，功能也符合大多数的流程图需求，还能导出多种格式（位图和矢量都可以）；3、Axure图片网站用什么程序，这个主要是用来进行软件原型线框设计的，同时具有流程图功能，特点是非常简洁易用，如果作很单纯的说明性的流程图（注重功能讲解的），用这个很方便。
其中，EDraw和Axure都有试用版的，试用版在流程图的绘制功能上都是没有限制的，你尽可以用它们来完成任务。
你可以试试看，是不是你想要的。
另外，单从作美观的流程图的角度考虑，个人很推荐EDraw
软件系统结构图和功能模块图区别举例,画图说明。
系统结构图反映的是系统中模块的调用关系和层次关系，谁调用谁，有一个先后次序（时序）关系.所以系统结构图既不同于数据流图，也不同于程序流程图.在系统结构图中的有向线段表示调用时程序的控制从调用模块移到被调用模块，并隐含了当调用结束时控制将交回给调用模块。
结构化设计方法使用的描述方式是系统结构图，也称结构图或控制结构图。
它表示了一个系统 （或功能模块） 的层次分解关系，模块之间的调用关系，以及模块之间数据流和控制流信息的传递关系，它是描述系统物理结构的主要图表工具。
参考资料
做流程图用哪个软件最好
Diagram Designer（制作流程图的软件）： Designer是一款简单易用的矢量图编辑器，可绘制流程图、UML图、说明图和演示。
Diagram Designer矢量图像编辑工具可以筹建流程图，图表和滑动展览。
包括一个可定制的样板及调色板，简单的图绘图仪，支持使用压缩的文件格式。
Diagram Designer功能：自定义对象模板拼写检查 （参见下面的词典）导入/导出 WMF, EMF, BMP, JPEG, PNG, MNG, ICO, GIF 以及 PCX 格式
流程图可以用什么软件画？
展开全部 我们在很多的岗位都会使用到流程图，比如业务流程图、商业图、程序流程图等。
流程图可以让我们思维清晰，知道下一步该做说什么，1、首先找到迅捷流程图制作软件的下载资源进行下载，下载完毕之后安装在电脑上。
2、接着用鼠标双击电脑上的软件快捷方式打开软件，将软件打开之后就能看见软件的主界面了，接着在主界面上点击“创建新图表”。
3、紧接着在新弹出的界面左侧的流程图功能选项中进行选择，有工程图、流程图、图表以及布局图，这里我们选择流程图。
4、选择流程图后进行点击，会看见右侧有许多图形样式，我们找到自己喜欢的图形样式接着点击下方的“创建”按钮。
5、创建完毕之后就可以对图形进行文字的添加了，方法是选中思维导图图形，就可以输入文字了，当然在右侧也可以进行思维导图图形的填充颜色和线型颜色的设置。
6、最后一步是将思维导图文件进行保存点击“文件”—“保存”，就可以将画好的流程图进行保存了。
试列举两个大型应用系统的实例,说明软件在该系统中所起的关键作用...
1。概念 需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。 关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起。系统的分析人员说：＂我们想与你谈谈你的需求。＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂。 百事通 而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。 需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂。有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性： 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。
系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。 任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述。 2。需求分析的任务 开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分图片网站用什么程序，并且以后再对它进行修改也极为困难。 目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。 对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？ 然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。
近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。 相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。 事实上，需求文档在开发过程中一直起指导作用。 3。需求分析过程 可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示： 图4-1 需求工程域的层次分解示意图 需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面： 确定产品所期望的用户类别。 获取每个用户类的需求。 了解实际用户任务和目标以及这些任务所支持的业务需求。
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。 商讨实施优先级的划分。 将所收集的用户需求编写成文档和模型。 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ 。这种合同都包含在编写的需求文档与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。通常的需求管理活动包括： 定义需求基线（迅速制定需求文档的主体）。 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 以一种可控制的方式将需求变更融入到项目中。 使当前的项目计划与需求一致。 估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上。 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 在整个项目过程中跟踪需求状态及其。。。
需求分析实例
回答：海底行 神 10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。
与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小，以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。
这样说虽然很简洁，但似乎过于简单化。
需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。
你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。
把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参与者过多，就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。
这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。
当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。
你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。
用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。
所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。
用例在需求分析中的使用 多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。
Ivar Jacobson(1992)把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。
而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色（actor）和用例（用例）。
角色（actor）表示系统用户能扮演的角色（role）。
这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给...
版权声明
本文仅代表作者观点。
本文系作者授权发表，未经许可，不得转载。
发表评论