软件项目需求分析

软件项目需求分析（推荐8篇）

软件项目需求分析 篇1

软件项目需求分析总结

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。

软件项目需求分析 篇2

1 软件开发项目需求分析

在软件项目的开发过程中, 尤其是对于大型软件项目的开发, 开展需求分析是非常重要的环节。在软件项目的开发过程中使用需求分析, 即通过文档的形式研究用户关于软件项目系统的使用目的、使用功能、使用可靠性等, 从而使得所开发出来的软件项目更加符合用户的需求。在运用需求分析的过程中, 主要需要做好以下几方面的内容:首先需要识别用户的需求问题;其二需要分析和汇总用户需求;其三需要对用户各种不同的需求建立相应的文档;最后还需要对所建立的文档进行评审。由此可见, 应用需求分析, 需要软件项目的开发人员与软件项目的使用人员共同参与完成。

随着现阶段软件项目开发数量的日益增多以及软件项目开发的复杂程度日益增大, 在整个软件项目的开发过程中, 需求分析起着至关重要的作用。可以说, 没有做好相应的需求分析, 将会给整个软件项目的开发造成极大难度。特别是对于一些大型软件项目的开发, 一旦不能及时掌握用户的需求动态, 将会使所设计的软件项目很难满足实际的使用需求, 从而将会造成较大幅度更改, 进而产生巨大的资金及人力浪费。

2 软件开发项目需求分析存在的问题

2.1 用户参与度不足

由于需求分析的应用主要是对用户实际的使用系统进行使用功能、使用性能以及使用可靠度等方面的分析研究, 一旦用户不参与到需求分析的实际工作中或参与程度不够, 那么将会导致整个需求分析工作无法正常开展。虽然软件项目的开发人员对于系统的开发以及软件项目各方面的特性都非常熟悉, 但是大部分软件用户对软件项目的实际功能、性能等并不是十分了解, 进而导致用户对于系统相关的特性描述不全面, 导致软件项目的开发人员无法真正掌握用户的实际需求。这样势必会导致所开发出来的软件项目不能完全满足用户的实际心理需求, 进而会出现返工现象, 从而给软件开发企业带来巨大的人力和财力损失。

2.2 用户需求的不确定性

在运用需求分析的过程中, 如果用户对自身的使用需求不够确定, 那么将会给整个软件项目的开发工作带来极大难度, 不仅可能大幅度增加软件项目开发的复杂程度, 同时还可能出现软件项目规模不可控等情况。此外, 如果用户的需求不能确定, 那么可能导致软件项目的代码结构出现变化, 这就打破了代码规范中“高内聚、低耦合”的原则, 从而进一步加大了代码维护的难度, 最终导致所开发的软件项目的各方面性能受到影响。因此, 对于用户需求不确定的情况, 需要采取有效的措施来解决。

2.3 需求分析深入度和全面性不足

对于软件项目开发的需求分析需要做到彻底、深入, 并且还需要十分全面。然而在实际运用过程中, 由于对于需求分析的深入度不够, 导致所开发的软件项目可能出现功能划分、功能定义出错等问题。另外, 由于需求分析的不够全面, 可能导致用户所需求的一些功能不能完美展现, 这样有可能导致软件项目在使用过程中出现结构破坏的情况。由此可见, 对于需求分析的运用, 需要双方的共同努力, 从而使得所开发出来的软件项目具有更加完整的功能和特性, 以更好地满足用户的实际需求。

3 相应的解决措施

3.1 加强用户与开发人员的合作

为了保证在软件项目的开发过程中能够更好运用需求分析, 加强用户与软件开发人员之间的合作意义重大, 这是做好软件项目开发需求分析的基础和前提。在实际的需求分析过程中, 由于认知方面的问题, 用户对于软件系统的功能及特性认识肯定会存在一定的偏差, 而设计人员由于具有足够的专业知识, 能够准确掌握相应的性能和特点。加强软件用户与软件项目开发人员之间的合作, 能够使得开发人员帮助用户更加全面深入地了解软件系统, 从而使得软件开发人员能够更加精确和全面地掌握用户的实际需求, 从而有利于整个软件项目开发过程更好进行。

3.2 做好系统各类需求的状态跟踪

由于在运用需求分析时不仅需要分析软件系统的运行环境, 同时还需要考虑软件系统的稳定性、功能性等条件, 因此, 需要在需求分析的过程中加强对软件各类需求的状态跟踪。对于软件系统中数据结构的定义、子模块的功能和定义等进行有效的状态跟踪, 从而保证各模块的实际功能做得更好, 最终确保能够满足用户的整体需求。

3.3 提升需求分析的完整性和一致性

除了需要做好以上两方面的工作之外, 在需求分析的应用过程中, 还需要保证需求分析的完整性。保障用户软件系统实际需求功能及特性的完整性, 以保证软件系统能够更好地被用户使用。同时还需要保证软件系统的整体功能与各模块功能之间的一致性, 这样能够确保整个软件项目系统具有更高的稳定性。

3.4 运用好需求分析的各种开发工具

最后, 需求分析过程中所形成的各种文档, 是软件项目得以更好开发的基本参考, 因此, 还需要运用好各种开发工具加强对这些文档的审核和查阅, 从而帮助软件项目的设计者更好地掌握所开发系统的数据结构定义、所需要进行模块功能设计的图形等需求。运用好这些工具, 一方面有利于用户了解系统定义的准确度, 避免由于技术而引起沟通难题;另一方面有利于后续编码测试工作的顺利展开, 一些需求设计优秀文档甚至能够直接翻译成特定的编程语言。

4 结语

总而言之, 在开发软件项目的过程中, 及时掌握用户的需求, 根据用户对软件的实际需求功能开发软件项目意义重大。因此, 针对于软件开发人员与软件用户之间对于软件的需求存在差异的问题, 需要软件项目开发人员在开发软件项目之前, 充分收集用户的资料, 运用需求分析全面掌握用户对于软件项目的实际需求, 从而以更为专业的态度为用户开发出最佳的软件项目, 以实现软件企业更好发展。

参考文献

[1]张建成, 田青, 李刚.软件工程需求分析方法探讨[J].信息技术与信息化, 2010 (6) :74-77.

[2]樊林赋.面向IT项目的需求分析管理的方法研究及应用[D].上海:上海交通大学, 2012.

软件项目需求分析 篇3

【关键词】计算机 软件项目 需求分析

【中图分类号】TP311.52 【文献标识码】A 【文章编号】1672-5158（2013）04-0008-01

一、计算机软件项目管理涵义

项目是一件事情、一项独一无二的任务，也可以理解为是在一定的时间和一定的预算内所要达到的预期目的。具有明确的目标性、资源成本的约束性、项目实施的一次性、结果的不可逆转性以及创新性。

项目管理是指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。其对象是软件工程项目，和其他的项目管理相比有相当的特殊性。在计算机软件项目管理过程域中，主要包括：项目规划、立项管理、需求管理、项目监控、风险管理和结项管理等。

二、计算机软件项目管理中的需求分析内容

软件需求工程是计算机软件项目开发工作的一个重要源头，涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型；需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。

软件需求分析特别重要，在软件开发的过程中具有举足轻重的地位，但是我们常常会忽视两点：一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。

三、计算机软件项目管理中的需求分析目标

在计算机软件项目管理的实际工作中，管理者必须在每一项工作中，全面分析问题，正确评估任务，制定详细的计划表，从而实现既定目标。软件需求分析的主要实现目标包括：

1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整

性，促使用户在软件设计启动之前周密地、全面地思考软件需求；

2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；

3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据。

四、计算机软件项目管理中的需求分析的步骤方法

（一）获取用户需求。这是该阶段的一个最重要的任务，可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。首先，了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。其次对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。再次，需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：（1）对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；（2）将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”，（3）分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。最后，需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：（1）明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项），（2）使需求符合系统的整体目标；（3）保证需求项之间的一致性，解决需求项之间可能存在的冲突。

（二）分析用户需求。在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。可以通过审查业务流程、Demo界面和UML图，征求反馈意见。评审对软件系统运行时所处环境的要求。例如硬件、数据通信接口等等，在软件方面，采用什么支持系统软件运行（如操作系统、网络软件、数据库管理系统等）。从工作流程和数据流出发，逐步细化软件功能，找出系统各模块之间的联系、接口特性和客观限制，分析它们是否满足功能要求。针对可靠性、安全l生和扩展性评审，TCMS系统涉及公司内部最高机密，聘请第三方机构进行需求分析评审。

（三）文档编写。需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致。为此，我们还必须编写软件需求说明书，进一步理解业务需求，用户需求，功能需求，为设计、开发和测试以及产品相关人员的提供参考。软件需求说明书采用什么样的形式能够把功能描述清楚，如何让使用人员尽快了解产品的功能，采用什么样的编写方式，是软件需求分析人员需要考虑的问题。经过最近的摸索和积累，个人觉得编写需求文档不一定要长篇大论，要多用表格和流程图，并且至少包括以下内容：（1）目的。即使用场景描述，先用几句话简要概括做该软件是用来解决什么问题。不要一开始就描述功能，至少让设计人员大致了解该功能的使用目的。（2）涉众。软件是让谁来使用，列举所有可能使用到此功能的用户或者角色。（3）功能列表。菜单树，展示具体包含的子功能和上下级关系。由于不同类型用户关注的重点可能不同，所以最好应给出各子功能中对应的默认用户权限。（4）数据字典。列表描述功能涉及的字段名称、数据类型、取值范围、默认值、备注信息等。（5）流程图。描述用户使用的正常流程和异常流程，如果涉及到状态转换最好给出状态迁移图。（6）UI。展示所涉及界面布局和原型，不必描述具体提示内容信息，可以在字符串资源表中去定义。（7）相关影响。该功能对其他相关模块的影响，还有其他相关模块对此功能的影响。

（四）需求验证。与客户经过沟通或验证，会产生两种结果：一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。包括以下内容：（1）审查需求文档：对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。（2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。（3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。（4）确定合格的标准：确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。

参考文献：

[1]吴艳艳：周长伦：姜家轩：王春梅：许自国：：软件项目管理中的需求管理[J]：信息技术与信息化：2008年02期

[2]孙莉：：软件项目管理中的需求管理[J]：信息系统工程：2011年04期

软件项目需求分析 篇4

其中最大的原因就是从事网站或者类似的软件项目需求的许多人都不懂真正的软件项目需求是什么东西，包括我处理过的SAP/ERP项目这类都是同样的问题，尽管那不是网站;他们犯的一般共同的错误就是把网页表现形式(那其实是美工的工作)，以及内容的采排看作是需求，完全没有一个用例的观念。

用例，usecase，目前多见于UML下的对面向对象程序中的对象行为的表达;不过，这不是它的源泉;它之所以被看作是这类语言的标准URL描述手段，是因为面向对象本身就是在虚拟程序中模拟真实世界那样地工作;而真实世界，就是围绕着用例展开的。用例的观念其实也不能算是一个软件概念，只不过在软件领域定义得最为精确而已，今天从每个人的生老病死，婚姻嫁娶，其实都是一个个的用例的描述和实施。用例，顾名思意，就是假如(假设)出现某种情况，采取什么样的行动;可能会有什么样的结果;然后，根据这个结果，再采取什么样的行动……直到得到希望的某个最终结局。

用例也叫场景，软件，实际上就是对场景操作过程的描述，而不是一堆版面框架网页的集成。没有用例支持就不叫软件，更加不叫项目——连垃圾都算不上。很多时侯我们说需求不明确，其实就是说这个用例不清晰;在电子商务网站中，除了人员素质导致对基本概念方法不明白外，最可能的导因就是商业模式不明确，或者不成立。这个成立与否，实际上可以从上面的假如如何那般的推导中进行初步的可行性推演。所以，程序员实际上有两个层次，一个是你说什么他做什么，但永远没有结果的。他却的确实现了你(需求人员)提出的所有要求，但这个项目却必然是永远没有结果的，因为，它本身只是把这个程序员当成网页编辑用了，项目没有基本用例的支持。我想90%的程序员是这类程序员，没有用例明确定义也就没有软件能力的评估，因为软件人员不是美工。另一种程序员则可以从上诉推演中发现整个项目本身有没有用例，以及用例是否合理(理论上没有明显的逻辑障碍);虽然程序员一般不应该关心商业模式是否合理，但实际上他有这个能力，常常是第一个发现商业模式的问题，假如他也关心的话。

可惜大部分用户需求人员不明白这个道理，反而可能会以为程序员是在推卸责任，或者是刁难需求;也正因为这个原因，需求人员和实现人员的冲突在项目中屡见不鲜，倒不是个人矛盾的冲突，而是由于双方没能有一个基本的立足点。我见过这样的项目，需求人员建一个大型网站的需求就是一大箩的每个网页的非常详细的描述，到每个字每个连接……直至每个网页出现的次序，项目经理说一个笑话：万一他摔一跤，这箩子东西鬼才能再捡回原来的模样。的确，负责需求的客户方副老总和一帮企业需求编辑辛苦做了两个月，但其实这不是需求，而是使用这个项目软件的具体编辑排版的安排;根本不是程序员要看的东西。程序员需要的是使用这个网站时需要有那几种用例逻辑，然后抽象出其中的对象，根据对象建立存储方式(象数据库存储结构)和内容采摘方式。那大箩东东，实际上什么用处也没有的，

开发软件如同建房子，旁观者可能问一句：建房子啊就拍手说明白了，但对于开发员来说，如果得不到准确的房子细到砖砖瓦瓦的准确设计(需求定义);要知道建小平房和建金茂大夏都是建房子，建宾馆还是建殡仪馆也是建房子，到底客户要的是什么房子合适，不搞清楚干下去的程序都是不负责任的，或者是冒牌货。

不懂软件项目需求的需求人员一般会犯如下错误：

一是把版面美工形式看作需求，其实程序员看程序如同医生透过X光看一个人，看到的是骨架，至于是美人还是丑八怪如果能看出来，那个医生一定是变态的;

在开发过程中都强调实现用例功能实现，而不是首先色彩如何花梢漂亮，后者不但不是主要的，也不是次要的，在开发过程中什么都不是;一开始把精力放在这里当成需求实现是浪费时间浪费金钱。

二是把静态网页当成需求，特别是当把静态网页当成prototype时更经常犯这个错误;

常常说：按prototype做出来不就行了?实际上prototype本身如果不是看不出清楚的用例逻辑，就是可能有几种用例解释;何况真正变成动态程序，与静态的东西是不一样的。我在网上看到的美女明星下了台到眼前成了丑八怪，就是这个道理。而且更遭的是，客户还同时犯第一个错误，看着那里不顺眼就改一改版面还一天三变，不知不觉的基本用例就变成了另外一个东西，原来是宾馆现在成了盖殡仪馆，原来搞错了因为不知道躺的人不同叫不同的馆(死人还是活人)，试问，如何实现?项目开始和后期看到的同一个版面成为不同的故事绝对是经常出现的故事，软件上称为需求变迁，这是项目经常延期的最主要原因。

三是需求人员把定制了解成按客户所有想法迎合静态页面，而不是按客户的业务用例要求建立相应的程序;还要求程序员也这样做;

实际上，如果不能拨乱反正的话，任何项目到此为止已经是死路一条：那不是软件，无非是静态网页人员出租!需求人员常犯的另一个错误仍是不懂用例，就是把用例的使用方式当成了需求;这种错误有时连初级程序员都会犯，最典型就是把一个菜单栏目当成需求，而程序员无法从菜单中看出明显的简洁的用例逻辑——这是一个没有意义的菜单，天晓得里头是什么?同样地，里头的要干的东西还一天三变。事实上，同一种逻辑用例可以用到N个栏目，那是软件的使用而不是软件本身。

以上的错误常见于网站建设，所以网站建设最通常的结局是不了了之，大概占了50%以上，无论设入多少钱多少人花多少时间都是如此的;除非有人能够拨乱反正，让项目需求走上正道。而在ERP/DRP这类项目中，需求人员一般情况下是业务的行家，他们反而很容易理解用例是什么东西，象医院收费，绝对不会把精力放在收费界面有没有 女让收费员提神上，收费这个用例有多少个环节是他们理解的。这种项目需求最易犯的错误是让先进的计算机工具重复原始状态下的不合理的流程。最典型的笑话就是：手工审批要盖五个章，用五天时间;现在电算化效率提高了一百倍，所以可以盖五百个章(电子签名呢!)，时间嘛，仍然是五天!在这里，矛盾不是有没有用例，而是用例是不是合理的，最高效率的。

软件需求分析面试自我介绍 篇5

1.软件需求分析的过程

软件需求分析的具体过程可分为软件需求目标的认定、分析与综合、制定规格说明和最终评审。首先来看如何对软件需求目标进行认定，软件需求的目标是指系统分析工程师和程序开发工程师在软件需求分析过程中，确定目标软件工程的综合要求，并提出实现这些要求所需要的条件，以及需求应达到的标准。这些需求具体包括：

（1）功能需求：列举出所开发软件在功能上应做什么。

（2）性能需求：给出所开发软件的技术性能指标。

（3）环境需求：软件系统运行时所处环境的要求。例如硬件环境：主机类型、外围设备、数据通信接口；软件方面：系统软件平台（包括单机操作系统、网络操作系统及应用软件、数据库管理系统等等）；以及使用部门在操作人员方面应达到怎样的条件。

（4）可靠性需求：按照实际运行环境对所开发的软件提出要求，尽量在需求分析阶段将所有的问题进行暴露。对于运行实效后可能产生的后果要有充分估计，应对软件运行的可靠性提出较高的要求。

（5）安全保密要求：在软件的需求分析过程当中应当对所开发的软件的安全性进行特殊设计分析，使其在实际开发完成之后的运行过程中安全性能得到必要的保证。

（6）用户界面的需求：对于用户界面的细致性以及易用性进行需求分析使其达到客户要求。

（7）资源使用需求：通过需求分析使得所开发的软件在运行时所需的系统资源处于用户可接受范围。

（8）软件成本消耗与开发进度需求：通过需求分析对软件开发的进度和各步骤的费用提出大致要求，作为开发管理的依据。

（9）最后对于所开发系统得最终所能达到的目标进行分析，以便在开发过程中对系统进行必要的修改与补充。在我们的需求分析过程中这些问题都是必需要得出分析结果的，并且结果应当得到软件开发工程师的认可。

在实际的软件需求分析中，单单依靠上述过程是不够的，有时候我们还需要通过对所得结论的分析与综合来得出工程系统的详细逻辑模型。

例如，在面向对象的软件工程当中进行软件需求分析时，通过对整个工程的需求进行分析，我们得出的仅是该软件工程的综合项目需求。这时就需要整理逻辑模型。在这个过程中，分析与综合工作需要反复的进行。而常用的分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法（简称JSD法）、面向对象的分析方法（简称为OOA）等，以及用于建立动态模型的状态迁移图或Petri网等工具。

通过这一步之后，我们就可以将所得到的分析结果描述成软件需求规格说明书（简称SRS），并编写初步的标准格式用户手册。进行软件需求规格说明书以及标准格式用户手册时，不仅需要正确详实的需求分析数据，还需要较好的文字表达和组织能力。需求分析评审则是指在需求分析的最后阶段，对整个系统的需求分析工作给出其在正确性、完整性和清晰性等几个方面的最终评价。

2.软件需求分析的原则和工具

软件需求分析方法很多，其所使用的描述方法也各不相同，但他们都有着共同的基本准则。首先，他们都必须能够表达和理解问题所包含的数据域和功能域；其次，他们必须按照自顶向下、逐层分解的方式对问题进行分解和不断细化；最后，他们都要能够给出系统的逻辑视图和物理视图。这就说明在需求分析当中无论我们采取什么样的分析方法，都无一例外的会回归到对问题数据域与功能域的分析上来，并且对于问题的分析会自然而然的逐渐细化。

3.软件需求分析的方法

在软件需求分析中方法很多，不同的分析方法也都引入了不同的记号和分析策略。但与此同时，他们也具有着一些共同的性质，具体可以概括为：在支持数据域分析机制方面，所有的方法都直接或间接地涉及到数据流、数据内容或数据结构等数据域的属性。

多数情况下，数据流特征是用将输入转化为输出的变换过程来描述的，数据内容则用数据字典机制来明确表示，或者通过描述数据或数据对象的层次节后隐含地表示；在功能表示方法方面，功能一般用数据变换或加工来表示。还有在接口定义、问题分解的机制以及抽象的支持、逻辑视图和物理视图以及系统抽象模型方面都有着相同或相似的机制。在这里我们重点分析快速原型方法。在传统的软件工程方法学中，一贯强调的是自顶而下的分阶段开发，在每阶段实际开发之前必须对所开发项目进行严格要求的分析和定义。但实践表明，在系统建立起来之前很难仅仅依靠分析就确定出一套完整、有效的需求应用，并且这样预先定义的策略也无法适应用户需求的不断修正与变化。

由此，快速原型方法应运而生，他自顶向下的开发模式，是目前应用十分广泛的开发模式。快速原型方法是根据软件系统的需求快速产生出软件系统一个早期原形的过程。该原型能够表现出目标系统的功能和行为特征，但不一定符合其全部的实现需要。

通过这个方法，软件设计者可以利用原型得到系统可用性的反馈信息，未来用户也可以利用原型得到宝贵的早期经验。并且利用这样的一个快速原型尽早的获得更完整、更正确的需求与设计。

在软件的开发过程当中即使客户对于系统的要求发生了更改，也可以通过对原型就行改进而得到新的目标系统，不必再从头做起。而且在现实中存在的快速原型建造工具可以大大缩减创建系统的时间，可以在短期内迅速有效地建立起系统的原型，充分提高软件开发效率，提高软件质量、减少测试和调试的工作量，最终减少软件开发的总成本。

在快速原型法的实现过程中，由于建立原型的目的不同，实现原型的途径也有所区别，大致划分为以下三类：

（1）探索型。为研究探索而建立的原型。主要强调澄清目标系统的需求及所要求的特征。

（2）实验型。为实验而建立原型。主要强调在正式进行目标系统的大规模开发工作之前，通过建立原型来确定所提出的解决方法是否恰当。这种原型方法通常针对用户的问题的某个方案做出原型以供试验评估，该原型所实现的功能与最终产品的功能是有差别的。

（3）进化型原型。为演示而建立的原型。主要强调通过逐步的分析改进使系统适应变化了的需求。并最终生成一个演进式的系统开发模式。当采用进化型原型方法时，必须进行原型与产品间的变换，除了在开始阶段时采用单独的研究探索性原型方法及实验性原型方法外，圆形的生产环境必须与产品的生产环境集成在一起。

总而言之，快速原型法是具有相当大优势的。因为它可以为开发出较为有用的系统做出极大贡献，并且不会增加总的软件开发费用，开发原型所增加的投资可以因减少误解而节省下来。

参考文献：

[1]王继成,高珍.软件需求分析的研究[J].计算机工程与设计,,(8):18-21.

银行ATM机业务软件需求分析 篇6

银行ATM机业务软件

需求分析

1.1编写目的

为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，为了使用户与开发者更好地进行沟通，并在此基础上探索C程序语言的开发途径

和应用方法，使之成为整个开发工作的基础。本需求分析的预期使用用者ATM

系统软件开发有联系的决策人，开发组人员，支持本项目的领导和使用该系统的

用户。

1.2背景

软件名称：银行ATM机业务软件

ATM取款机项目设计小组

西安石油大学户县新校区软件0903行军蚁设计小组

1.3 定义 C语言是国内外广泛使用的一种计算机语言，C语言功能丰富，表达力强，使用灵活方便，应用面广，目标程序效率高，可移植性好，即具有高级语言的优点，又具有低级语言的许多特点。既可以用来编写系统软件，也可以用来编写应用软件。它的语言简洁、紧凑，使用方便、灵活；运算符丰富；数据类型丰富；具有结构化的控制语句；语法限制不太严格，程序实际自由度大。

任务概述

2.1目标

2.1.1 开发意图

ATM取款机现在为大家广泛使用，与人们生活息息相关。本项目主要利用学过的C语言知识来编写一个ATM自动取款机的程序，可以让大家更加深刻的了解ATM的工作原理，同时也让大家对程序设计流程的有了更近一步了解，为以后的找工作积累了经验。

2.1.2 应用目标

本次项目的设计以实用为主，主要应用于银行卡业务，由于银行卡方便快捷，使用户在外游玩工作中避免携带大量纸币带来的不安全隐患，更好的享受生活。

2.1.3 作用范围

使用ATM取款机的人群必须进行电子注册，必须遵守用户许可协议，了解相应的操作流程。

ATM取款机项目设计小组

西安石油大学户县新校区软件0903行军蚁设计小组

2.2用户的特点

本软件的用户主要分为以下两类： 对于ATM使用者：

a）一般的开户持卡人员； b）不要求具备任何专业知识；

c)普通用户使用存款，查询余额，转账，修改密码，查询存取历史明细等功能。

对于维护人员：

a）要求熟练掌握C语言的相关知识；

b）对软件开发的各个过程有所了解，以及各个模块的相互联系要清楚。软件的预期使用频度为频繁。

3需求规定

3.1JPG 查

账户登录

密码错误超过三次即冻结账户。

存款

用户在登入ATM系统后即可自助存款，存入货币面额仅限100元，一次性存入总金额不得超过2000元。

取款

用户在登入ATM系统后即可自助取款，用户输入的取款面金额必须是50元或100元的整数倍数，一次性取款金额不得超过2000元。ATM取款机项目设计小组

西安石油大学户县新校区软件0903行军蚁设计小组

转账

用户在登入ATM系统后即可向其它账户进行转账操作，转账金额无上线。

查询

用户在登入ATM系统后可查询当前账户的余额情况。

卡信息

卡内明细（姓名，卡号码，办理银行卡地点）交易明细

用户在登入ATM系统后即可查询账户历史交易记录等等。

退卡

交易结束，请及时取卡。

3.2对性能的规定

3.2.1精度

取款机的各个按钮要准确映射到取款机的某个键。在主菜单界面中，通过控制相应按钮切换功能，按功能键确认选择。本软件要求用户输入密码用户名为字母数字或下划线，且首位不得为数字。输入密码为6位整数。取款及转账金额为整型数据。户源，目标账户为数据库中存在的用户名，即字母数字或下划线，且首位不得为数字。

3.2.2时间特性要求

a)响应时间：

ATM取款机项目设计小组

西安石油大学户县新校区软件0903行军蚁设计小组

用户插入银行卡后，按系统提示输入相应信息，系统确认完成后，自动进入主菜单界面。在主菜单界面中，如果用户选择修改密码，先输入旧密码，在很短的时间内再输入新密码；如果用户选择了存款，系统在短时间内确认金额，进行交易；如果用户选择了取款，则输入金额后系统在较短时间内弹出纸币；如果用户选择了其他选项（如交易明细查询），要短时间内显示相应的信息。用户交易完毕，则选择退卡，请在三十秒内拿走银行卡，否则后果自负。b)更新处理时间：

在每次用户结束交易后，请系统及时进行信息更新。c)数据转换和传送时间： 用户本次进入系统，要与最近一次的保存进度一致。在进行各项交易中，用户的时间记录要准确，不能有延迟和提前。d)解题时间：

不能出现让用户费解的信息。

3.2.3灵活性

a)操作系统：该软件当遇到非预期输入数据或操作时，会进行报错处理，并要 求用户重新进行输入数据或操作。

b)同其他软件接口的变化：考虑到接口的变化，尽量将代码模块化，多提供一些接口类，提高代码的可移植性。

c)运行环境的变化：由于代码输入到不同的取款机，其虚拟机可能有所不同，所以编写代码时要考虑运行在不同平台上的问题，即代码的平台可移植性。d)计划的变化或改进：项目过程中可能要更改方案，如更换背景，更换按钮风格，或者调整每次系统输出信息的时间等。这些就要依赖于代码的可扩展性，可以不用更改很多代码。

3.3输入输出要求

1）用户名：字母数字或下划线，且首位不得为数字。2）密码：6位整数。

3）取款及转账金额：整型数据。ATM取款机项目设计小组

西安石油大学户县新校区软件0903行军蚁设计小组

4）户源，目标账户：即字母数字或下划线，且首位不得为数字。5）用户需求事务：通过人机交互界面进行选择。

3.4数据管理能力要求

1）该软件需要进行的数据管理主要为用户信息，需要创建一个表，主要记录如用户名，用户密码，用户余额，用户类型，用户开户日期，用户操作记录等。2）进度是记录当前用户所处的环境，如余额的数目，存储的金额，交易明细等。这些可以通过数据库保存。

3.5故障处理要求

软件故障：系统运行过程中可能在输入密码后并无任何提示信息，或者查询详单时无输出信息，内存泄漏等。这些都给用户带来不必要的麻烦，故在程序设计中，代码编写以及测试的时候都要仔细关注这些方面的问题。

硬件故障：某些硬件故障无法解决，应与相关部门及时联系，解决问题。

4运行环境规定

4.1设备

ATM取款机。

4.2支持软件

不需要其他软件支持

4.3接口

外部接口方面：

本软件同外部无软件接口，取款机存在按键与屏幕映射方面的接口。内部接口方面： ATM取款机项目设计小组

西安石油大学户县新校区软件0903行军蚁设计小组

各模块之间存在着内部联系，有些模块之间存在着信息共享的关系。

5.实验开发心得

这次的开发只是主要单纯从界面以及数据库的设计和一些接口效率内容所需要注意。我认为每次设计界面和后台需要比较多的心细以免有错误漏洞的错误，甚至很简单的逻辑也非常容易出错，都需要演练一遍才避免错误。

感谢李静锴给我解答课外疑惑问题

软件项目需求分析 篇7

关键词：需求分析,用户方干系人,项目经理,需求分析员

1 尽快熟悉项目用户方干系人全貌

项目用户方干系人,指所有可能受到项目结果重大影响的人,即项目的风险承担者,他可能是项目的受益者,也可能是项目的受害者。因此,应当从项目的启动开始,需求分析员及其项目成员就要分清项目用户方干系人包含哪些人和组织,通过沟通协调对他们施加影响,驱动他们对项目的支持,调查并明确他们的需求和愿望,减小其对项目的阻力,以确保项目获得成功。

2 采取正确的需求获取方法

软件开发项目的目的就是要实现项目用户方的需求,项目用户方的需求包含明确的和隐含的,也可以分为NEED,WANT,WISH等不同的层次。如果对项目所有用户方干系人没有进行足够的沟通和影响,使其尽可能地参与项目,则会出现客户方相关责任人不明确或对范围和需求责任心不强,提出的需求具有随意性,项目前期对需求的确认不够积极,或者是多个用户代表各说各话、昨是今非,项目后期需求变化随意等现象,这就会造成项目范围的蔓延,进度的拖延,成本的扩大,甚至项目的完全失败。

各种用户对系统具有不同的要求,如一个没有经验的用户关心系统是否简单易用,对于高级用户则关心产品的易用性和高效性。因而需要对用户进行分类,每一个用户类将有自己的一系列功能和非功能要求。在项目中,要尽早为产品确定并描述不同的用户类,这样就能从每一个重要的用户类代表中获取不同的需求。

项目需求具有双面性(用户与开发商)和多面性(项目中各干系人),因此,项目经理和系统集成者应了解用户干系人需求,用户干系人也应了解技术方面的需求,两者缺一不可。正确的需求获取需要了解需求的来源、用户的分类、用户的代表性、用户需求谁说了算数等因素。开发人员和项目经理要有足够的耐心聆听用户的讲述,要足够详细地了解每一个细节。项目管理者要善于将需求分类、归类,善于将需求文档化,并有所查询标记。

3 可视化需求调研,引导各种客户挖掘他们的需求

有的客户因为自己缺乏计算机知识,无法提出完整准确、隐含的或潜在的需求。若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想,不但要确定明确的需求,还要善于用启发的方式与用户探讨隐含的或潜在的需求,并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务,从而能够站在用户的立场看待软件需求,想用户所想,做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深人挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求,并且使需求更加全面完善。

对于高层领导,可以提供系统总体框架图;对于业务管理人员,可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员,可以用数据流图、实体关系图或UMI中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户,画出用户界面图来进行需求挖掘,是个比较有效的沟通方式。

4 详细描述各项业务,以便让所有客户确认

尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程,并将这些业务流程文档化后与客户进行讨论,对描述错误或不准确不精确的进行修改,最终让客户进行确认。从近年来开发的软件看,对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT(查增删改传),但具体业务都是分为若干步骤,每个步骤都有其业务名称,同一步骤可能对多个数据集进行不同操作,需要调查了解清楚才能设计出适合用户业务特点和习惯的软件,使开发出来的软件更受欢迎。

5 对项目用户方干系人的愿望进行平衡

不同的项目用户方干系人其愿望和追求的目标往往相差甚远,因此对项目用户方干系人的愿望进行平衡可能是非常重要而又相当困难的事情。例如:我曾在参与的某医院计算机管理系统项目中,遇到医院管理层希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析,同时为了对信息进行有效控制而增加一些审批流程;而门诊、药房等对外办公的基层窗口则因为客流速度的压力希望减少信息项的输人量;甚至有些不良的基层部门由于害怕建立透明度高的信息系统会影响他们的利益而消极地应付,即所谓反需求;而客户的客户(就诊的病人)则希望相关机构能够简化工作流程,加快办事速度,增加诊断情况和就诊费用的透明度;甚至项目组本身因为技术、资源、进度等原因,需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的,特别是消极的反需求是不能接受的,但他们的需求都是应当考虑全面并进行平衡的。

6 强调实现项目需求的层次递进性

了解该系统或者该项目用户所能够提供的最小的工程费用。当预计经费不能支持时,应当考虑将项目分期实施。在系统上、技术上对用户进行引导性建议,使用户了解集成商所要进行的工作,了解集成商是为了帮助用户实现他的需要、达到用户的目的,而不仅仅是为了赚钱,用户更了解集成商,也更了解自己的系统,有利于以后的项目合作、工程实施和系统维护。

7 编写需求文挡和进行需求评审与其他项目小组成员协作完善系统需求

文档资料是集成商重要的财富,贯穿于系统集成和项目开发的整个过程,其中包括法律文档、技术文档、资料文挡。文挡要求完整性、一致性、可修改性、可跟踪性。

教育软件市场需求分析 篇8

在学校建立和完善网络的同时，教育软件的应用业已成为这些已经建立自己校园网的学校目前最为关注的问题。“校校通”工程更是进一步推进了教育软件市场的发展，据赛迪顾问调查，2001年教育软件市场规模达到16.3亿元。

教育软件市场现状

目前市场上的教育软件种类很多，但基本上可以划分为教育资源库、辅助教学软件、教育管理软件和针对个人的学习软件几大类。学习软件包括各类语言、电脑教育，以及题库等类型的针对个人学习的软件，这类软件在教育软件中占有较大的比率，教育资源库自2001年以来一直保持快速增长，2002年上半年资源库在教育软件中占26.1个百分点。

教育软件区域市场分布的特点是华东、华南比较强，西部地区较弱，城乡差别突出。此类软件的主要采购地区仍然是信息化工程比较领先的大中城市，这说明原有的市场进一步提升，尚未开发出的西部市场，以及农村中小学的信息化工程仍然有待支持。

目前从事教育软件开发的厂商有200多家，产品也有3000多种，并且不断地有新产品问世。教育软件的市场份额占整个软件市场的17％左右。

科利华、翰林汇、金洪恩、中教育星等公司在教育软件领域都有一定的市场份额。这些厂商都开发包括资源库、课件库、网络教室、电子图书馆，以及学科同步学习软件等系列产品，并且能够提供相对完整的应用方案。各个开发商在教育软件市场中也有其侧重点，例如科利华学习软件市场占有量比较大，中教育星注重资源库的开发等。

随着教育行业信息化的不断深入，教育软件的需求量也不断在增长。其中资源库、辅助教学软件、教育管理软件等类别的教育软件的增长也各有不同。由于参与教育软件市场竞争的厂商不断增多，产品层出不穷，价格战无法避免。2002年上半年教育软件的价格普遍有所下降，教育软件价格的下降刺激用户对于学习软件的需求，英文学习软件的销售量增长非常突出，带动了原本不够活跃的学习软件市场。与此同时，其它软件的销售额的增长比率相对于销售量的增长比率都有不同程度的下降。

教育软件市场存在主要问题

据调查，我国68万所中小学实现信息化建设的不足10％，其中能有效应用信息化手段辅助教学和改革传统教育的更是很少。其中一个重要的原因是教育软件的应用水平远远不能达到教育信息化的需求。其中有学校的原因，也有开发商对学校教育缺乏足够的认识的因素。教育软件市场依然突显以下几个主要问题。

缺乏统一的规范和标准

教育行业是比较特殊的行业，各学校之间、学校与教委之间需要数据交换，但目前的情况却是各个学校在应用不同的产品之后形成了数据壁垒，这在很大程度上影响了信息化进程，而其中必然会产生资源浪费。“校校通”教育城域网的推进更突显了这一问题。

近日，国家教委颁布了《教育管理信息化标准》(第一部分：学校管理信息标准)。《教育管理信息化标准》将为教育部门对教育数据进行总体的规划和组织，建立起统一的数据平台提供有力的技术保证；它将带动教育管理信息存储、访问、更新、传递方式的变革，进一步减轻学校人力资源和财政管理的负担。

建立教育管理软件认证制度，防止一些低劣的管理软件进入教育系统，影响教育管理信息化工作的健康发展。同时，配合标准的实施工作，加快标准应用示范软件的开发与应用。《教育管理信息化标准》的出台，无疑会使得很多厂商的教育管理软件面临重大调整。

而对于整个教育软件行业，国家教育部将逐步出台教育信息化软件方面的标准和规范，要求教育软件开发商必须从全局考虑教育软件的设计。教育软件的整体规划是指设计上有超前意识，要通盘考虑，而不仅仅是着眼于眼前要实现的功能，要使整体方案具有良好的扩展性。

开发商对教学理解得不够深入

我国各类学校校园网已有一定规模。对于已经建立校园网的学校，最主要的任务已经由建网转向如何充分利用已有的校园网络、教育软件产品等教学资源，进一步加强教育理念、教学内容与方法的改革。对于这些学校来说，他们迫切需要的是采用一套软件系统，能够将已有的硬件设备整合起来，充分发挥其系统化、立体化的作用。

目前市场上资源库类教育软件虽然很多，但并未真正走进学校。资源库的设计在很大程度上忽视了教材的特殊性和教师、学生的互动性。教师教学比以往更加注重创新，为了提高教学效率，他们需要丰富的教学资源。但是，教学方法的不同，使得教师在应用资源的时候，会加入自己的理解，他们希望能利用已有的资源制作出能比较准确表达自己教学思想的课件。开发商提供的产品具有很好的原创性才能有更强的吸引力，这主要是解决了技术和设计上的问题，为了教师教学提供便利，尤其是对于教学难点的阐释，资源库具有很强的应用功能。资源库不一定要以量取胜，关键是要切合教学需要。但是，很多资源库软件开发工作缺乏针对性，对目前国内教育结构和教材、以及学生心理认识不够，设计出来的产品不能准确、灵活地表达教学的内容。另外，厂商更重视开发理科类教学软件，其他领域涉及的还不够充分。艺术类、体育类的教育软件很少涉及。教育软件在学科分类上需要更为丰富和清晰。

教育软件的应用尚未进入实质性阶段

尽管政府和教育部门在积极推进教育信息化工程，但是多数学校对于教育信息化的理解仍然停留在概念性的层次，还没有实质性的实施。原因也是多方面的，有些开发商在没有能力整合软件硬件，不具备系统集成能力的情况下，只向学校提供价格昂贵的硬件或随便搭配软件，导致应用无法开展。除此之外，一些学校受厂商影响，片面追求硬件设备的先进性和网络建设一步到位，结果软件和应用跟不上，设备闲置浪费。开发商和学校对于教育行业软件的应用的认识还没有与实际很好地结合。

教育信息化的一个重要内容是要对教师和学生进行信息化技术培训。由于目前教育软件厂商还不够重视产品服务，以及学校设备、师资条件的不足，教师和学生都没有能够得到良好的技术培训，致使大多数学校的信息化资源没有发挥应有的作用，教师对于教育软件资源的利用观念还没有提升到信息化要求的层次。

应试教育影响教育软件走向

需求是市场导向，教育软件的用户的应试教育思想成为影响教育软件发展的主要因素。首先是学校方面，有经验的教师大都在35岁以上，升学率的压力使他们没有更多的时间去了解教学软件，更无法有效应用。另一方面，主要表现在学习软件上，绝大多数个人用户在选择学习软件的决定因素是软件是否与教材同步，大都要考量软件是否紧扣课本。由于各地同一年级所有的教材亦有所不同，要找到完全符合用户理想需求的同步学习软件比较困难。2001年教学大纲调整以后，很多软件在用户眼里已经是过去式，目前市场上的学习软件大都标明是按照新的教学大纲设计等字样。应试教育思想在一定程度上阻碍了学习软件的转型。

软件价格影响市场规范

教育软件因为开发技术等方面原因，价格一直相对较高。例如，资源库的价格一般要上万元，应用于学校的资源库软件目前也只有几千套。大多数学校因为教育经费的问题，没有能力系统地购买教育软件。

教育软件厂商市场分割不明确，几乎每个厂商都涉及的所有类型的教育软件的开发。开发商上演的价格战让用户受益的同时，也使软件在质量上、满足用户需求方面大打折扣。抄袭情况严重，加之盗版的问题，教育软件市场要走向专业化、标准化还需要一定时间。

教育软件市场的发展前景

尽管教育软件市场还没有完全跟上教育的步伐，但其潜在的市场容量，国家政策支持，以及厂商与用户的有效沟通都在从不同方面推进教育软件的发展。目前，全国台式PC年销售量在1000万台以上，其中有50％以上进入了家庭，而知识经济时代所显示出来的知识的价值又让人们充分认识到了学习、教育的重要性。广大用户对教育软件的投入也有很大的增长，而这种增长的趋势还将因为国家教育政策以及教育软件市场的特性进一步升温。未来几年里，教育软件的需求量增长每年都将超过50％。

由于教育布局的调整，2001年全国职业类学校招生人数略有下降，而普通高中招生人数增长了85.29％万人，高等教育的招生规模继续快速增加，2001年普通高等教育招生268.28万人，比上年增加47.67万人，增长21.61％。成人高等教育招生增长25.48％。据赛迪顾问调查，全国各类学校拥有台式PC的数量至少在500万台以上，每年仍至少有10％的增长。这是一个动态市场。

政府不但从政策上支持高科技软件企业的发展，而且还投入大量资金建设教育基础设施，积极发展素质教育，这也就为教育软件市场提供了良好的成长空间。“西部大学校园计算机网络建设工程”项目于2002年上半年正式启动。该项目建设总投资9亿元。

未来的教育软件的目的将是为了真正完善人们的知识结构，提高人们的综合素质和竞争力。教育软件要适应新课程改革的需要，深入理解和考虑教材、教师、学生、环境等要素。教育软件不仅要具有开放性、交互性，前瞻性，也要有较好的二级开发能力。

从用户的角度考虑，教育软件应该内容精良，适用性强。教育软件的用户包括学生和教师，不同的人有不同的需求，软件的灵活性和创造性是尤其需要突出的。据了解，74％的教师表示非常需要教育软件来辅助教学。这说明，目前的教学软件还远远不能满足需求。

随着网络技术的飞速发展和网络使用频率的持续提升，人们将会越来越多地在网上接受教育，所以教育软件的网络化趋势是不可避免的。网络教学是今后学校教育的一个重要方向。软件与网络、教育与网络的融合是今后发展的必然趋势。