云娜古道道道道
如何进行软件需求分析
展开全部 1.概念需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说：＂我们想与你谈谈你的需求.＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂.百事通而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人.需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂.有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂.这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难.目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了.相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：图4-1 需求工程域的层次分解示意图需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面：确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以...
解决方案：购买财务软件需要注意什么问题
展开全部 对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。
怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。
软件开发的意义也就在于此。
而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
--- 经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。
通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。
另外，我们也得为政府部门提供关于商品营运的报告。
”-- -分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。
”-- -经理觉得奇怪：“我不是刚告诉你我的需求了吗？”-- -分析员：“实际上，您只说明了整个项目的概念和目标。
这些高层次的业务需求不足以提供开发的内容和时间。
我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。
”-- -经理：“业务人员都在招商。
他们非常忙，没有时间与你们详细讨论各种细节。
你能不能说明一下你们现有的系统？”--- 分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。
我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。
我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。
”--- 经理坚持道：“行了，行了，我们没有那么多的时间。
让我来告诉您我们的需求。
实际上我也很忙。
请马上开始开发，并随时将你们的进展情况告诉我。
”--- 风险躲在需求的迷雾之后- --以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。
在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。
这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。
这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。
若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。
因此可见——需求分析奠定了软件工程和项目管理的基础。
-- -拨开需求分析的迷雾--- 像这样的对话经常出现在软件开发的过程中。
客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。
那么，我们就拨开雾影，分析一下需求的具体内容：-- -·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
--- ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
--- ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
-- -·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
--- ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。
“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
--- 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。
其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
--- 下一层次需求——用户需求，必须从使用产品的用户处收集。
因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。
例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
--- 经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。
用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。
如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
--- 在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。
除非遇到的需求极为简单；否则不能这样做。
如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
--- 优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。
只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
--- 由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
-- -客户的需求观-- -...
如何做需求分析
一、 我们应当如何做需求分析需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
这就是敏捷开发倡导的需求反馈。
敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。
只有这样才能及时纠正需求理解的偏差，保证项目的成功。
二、我们应当怎样做需求调研1.初识。
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。
这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
（1）高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析，应当与高层领导谈。
（2）中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。
他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。
（3）基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。
他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。
但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。
另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。
而他们关心的则是每项操作的细节。
俗话说：万事开头难。
如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。
随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
2.拜访。
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。
在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。
不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。
尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。
3.研讨会。
（1）由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。
划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；（2）集中式的业务研讨形式和分散式的业务研讨形式；（3）有效抑制个性化差异、分模块组织专项研讨会。
4.业务研讨在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：（1）由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。
这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
（2）能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。
这类客户，他们能熟练使用电脑，对信息化管理是清楚的。
他们提出的业务需求从整体上应当是八九不离十的 。
但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。
（3）能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。
这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。
但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。
解决办法：业务领域分析：客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？（1）我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
（2）在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。
（3）还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。
（4）需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。
只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代...
需求分析的详细分析
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
需求分析就是分析软件用户的需求是什么。
如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。
如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的（相信大家都有体会）。
比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。
当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。
在一个大型软件系统的开发中，他的作用要远远大于程序设计。
需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。
这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求（软件运行是所需的内存、CPU等）、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。
最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。
请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。
评审通过才可进行下一阶段的工作，否则重新进行需求分析。
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。
但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。
建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。
如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。
以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。
系统构造完成后，原来的模型系统就被废弃不用。
探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。
进化型属于这种策略。
客户与开发人员交流需要好的方法。
下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。
如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、 分析人员要使用符合客户语言习惯的表达 需求讨论集中于业务需求和任务，因此要使用术语。
客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标 只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。
这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。
为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。
如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。
3、 分析人员必须编写软件需求报告 分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。
通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人...
软件需求分析在软件工程中的作用,有哪些软件需求分析的方法。
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。
在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发，能否获得成功，最重要的是需求分析的工作。
因此，软件需求分析能力和水平，对软件项目至关重要。
一般的分析方法和步骤如下：⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
金蝶软件常见问题及解决办法？
1、固定资产折旧年限超期问题现在很多客户都有一些固定资产，使用时间已经过了折旧年限，但由于以前的种种原因，折旧没有提完且该固定资产还在使用，此时如果录入固定资产时按实际情况录入，尤其是在系统提示：该固定资产使用时间已过折旧年限，是否继续，此时如果选择是的话，帐套起用后，所提折旧均为错误，因为必须人为地把固定资产从入账到帐套起用时所提折旧期间数改小，才能避免这个问题。
2、购销存生成凭证注意事项（金蝶2000系统）工业版中通过购销存模块生成凭证时，如果凭证一方下挂核算项目，当凭证信息输入完整后，直接按保存按钮，那么在保存该凭证对应的购销存单据时，系统会提示凭证核算项目不能为空，且无法保存该单据。
解决的方法是凭证信息输入完整后，不要直接按保存按钮，而是在凭证的空白处点击一下鼠标左键后，再点击保存按钮。
3、重做操作系统时如何恢复帐套？（金蝶2000系统）方法1：在金蝶软件安装目录里（一般情况是c:\program files\kdwin70），找到贵公司的帐套文件和system.mda文件，拷贝即可。
重装系统和软件后，再将帐套文件和system.mda文件复制到安装目录下即可。
方法2：通过备份帐套，然后再恢复帐套即可（推荐使用此方法）4、损益表重算后无数字 出现此问题可能的原因是用户自已手工录入了损益凭证。
关于损益类凭证必须通过软件中的“结转损益”功能自动生成，不可手工结转。
5、某一用户查询不到其它用户的凭证（金蝶2000系统） 出现此问题可能的原因是授权范围限制。
通过工具→用户授权→按选定指定的用户→授权→操作权限→权限适用范围→所有用户即可。
6、结帐、反结帐、反初始化等操作时，系统提示“当前用户有冲突”（金蝶K/3系统） 在windows“开始”菜单——“程序”——“K/3系统”——“客户端”——“系统工具”，找到“网络控制管理工具”，输入用户名和密码后，清除列表中的内容即可。
7、金蝶K/3系统反结帐功能（金蝶K/3系统） 金蝶K/3系统中总帐系统、现金管理系统、固定资产系统、工资系统、应收系统、应付系统等财务子系统以系统管理员身份登陆系统后，按住shift键再点击“期末结帐”即可反结帐。
金蝶K/3物流系统无反结帐功能。
8、核算项目与明细科目的联系 在手工记帐方式下为了核算诸如应收、应付款等科目往来明细，就必须设置大量的明细科目，工作量很大，科目体系也很繁杂。
为了解决这一问题，金蝶软件系统采取在科目下挂核算项目这一处理方法，一方面科目无须设置大量的明细科目，很简洁，且核算项目可以在所有的子系统共享，另一方面又可以实现对所核算项目的明细核算，真可谓一举多得。
建议：核算项目不要允许分级设置9、K/3中做工资费用分配生成凭证时，系统总是提示生成的凭证条目为一条，不能生成凭证（金蝶K/3系统） 这是因为在职员管理中职员的类别没有选上所导致的（职员类别至少需要设置两项），录入职员时不录入职员类别系统不会提示，生成凭证时要涉及到职员类别这一项。
需要检查职员属性的类别设置。
10、客户端登录时提示“Active无法创建对象” （金蝶K/3系统）出现此问题可能是客户端无法连接到服务器，解决步骤如下：重启客户端；如果重启客户端仍然提示此错误，请在windows“开始”菜单——“程序”——“K/3系统”——“客户端”——“系统工具”，找到“远程组件配置工具”，进行客户端测试（点击对话框中“测试”按钮，不要直接点击“确定”按钮）；如果测试不通表明客户端安装或者客户端与服务器连接上出现问题，采用排除法一个个处理。
设计院云终端解决方案需要多少钱
看你项目实际需求而定，用户一般使用什么软件，需要达到什么样的功能与性能，是办公 程序设计还是图片处理不同的产品应用不一样 现在市面上面的云终端 VD2000 是共享服务器桌面，服务端使用微软的2003，利用系统的VDP协议，合适 办公文档处理设计 图片处理 最好能使用到服务器虚拟化，
什么叫解决方案工程师？
展开全部 解决方案工程师主要针对特定行业、特定环境、特定的需求进行的系统的需求分析，找出客户的所有的需求功能点、通过对公司产品及以往案例的经验，补充还没有满足需求的部分重点设计，形成一个具有竞争性优势的解决方案。
在这过程中，需要解决方案工程师具备很广的知识面，如果是IT行业的解决方案工程师，可以要涉及的知识包括：网络、软件开发、服务器、存储、云计算、视频等。
另外对本行业的公司都要有一定的了解，知道竞争对手的产品及解决方案，对一些其它行业的某些知名公司也要有所了解，因为以后可能在某个解决方案中要用到其它行业公司的某项技术或产品来补充完善解决方案时会有很大的帮助。
总结：解决方案工程师需要有比较强的专业技术能力、敏锐的市场嗅觉、有前瞻性、考虑问题要非常充分、而且需要有很强的表达能力与沟通技能。
...
工作流解决方案是什么意思？
工作流解决方案，即以工作流引擎、工作流软件为基础，满足各行各业的流程需求，为各行各业的各个系统提供一个优质的解决方案。
社会中的各行各业，和我们的生活中，流程无处不在，例如贷款申请流程、考试报名流程、企业管理流程等等，因此也需要相对应的解决方案，例如办公解决方案，财务报销解决方案，合同管理解决方案，人力资源管理解决方案，游戏研发管理系统等等。
行业应用软件解决方案的价值一个方向由市场供需情况决定，在市场供需一定的情况下，另一个方向上由组成解决方案各部件的质量决定，如果各部件都是高质量产品，解决方案的竞争力就强，市场价值也比同行大，这就是工作流解决方案的价值所在。
在国内的各个工作流厂商中，慧正工作流还是不错的，他们的引擎提升解决方案的市场价值，从而支持合作伙伴在行业有更大的市场空间，更高的市场占有率
