浅谈软件开发中的需求分析
“阿西莫耶”通过精心收集，向本站投稿了7篇浅谈软件开发中的需求分析，下面就是小编给大家带来的浅谈软件开发中的需求分析，希望大家喜欢阅读!
篇1：浅谈软件开发中的需求分析
浅谈软件开发中的需求分析
摘要：众所周知，想要做好软件 ，首先要做好需求分析，但是实际上人们对需求分析却不够重视。并且由于需求分析的错误引起的软件开发的错误在制作时是看不出来的，只有做完软件进行检测时才能发现，但是这时想要改正错误就要付出双倍的代价。下文就需求分析的相关问题进行了探讨。 关键词：软件开发 需求分析 分类号】：TP311.52 一.什么是需求分析 结构化软件开发一般分为分析、设计、开发、测试、验收与运行等阶段。开发前，会进行前期的可行性研究；在运行开始以后，还要进行后期维护。需求分析是结构化开发中的重要阶段。通常情况下，国内软件开发公司在做欧美和日本的项目时，对前期的可行性研究参与得较少，一般都是对方已经做完可行性研究，国内软件开发公司从需求分析开始做起，直到软件开发后的运行和维护。 所谓“需求分析”，是指对要解决的问题进行详细的分析，弄清楚客户的需求，包括需要输入什么数据，要得到什么结果，最后应输出什么，等等。可以说，软件工程当中的“需求分析”就是确定要计算机“做什么”。 二.需求分析的重要性 从需求分析的定义上，就可以看出需求分析在软件开发过程中的重要性了。需求分析做得不对，后面的步骤做得再好，也只能是南辕北辙，无法满足客户的要求。研究表明，改正产品付诸应用后所发现的一个需求方面的缺陷，比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现，在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但若在系统测试时发现则需要5D17个小时来修复。 需求工程的成功与否直接关系到系统给的命运，需求工程绝对不是软件开发的前期任务，而应该在整个系统的生命周期里都扮演着重要角色。在需求工程阶段解决和根除需求引起的问题可以大大降低生产和维护的成本，提高用户的满意度。在软件开发的过程中，需求工程阶段是了解用户需求的最佳时期，但很大一部分用户不知道、不了解需求工程，以至于在和他们交流的时候，他们都不能准确完整的说出自己的需求，因而对于从事需求工程的人员来说，能够正确的理解用户的需求观点，利用一些方法和技巧来启发用户阐述清楚自己的需求是很重要的。需求工程作为了解并实现软件开发者的目标的重要手段，有着不可替代的作用。 比如一个失败的案例：由于和客户签订了合同，5个月必须交付软件，开发时间紧迫，导致项目计划时做需求分析的时间只给了2周时间（理由是客户的文档已经提供好了，照着做即可）。结果，由于前期对客户文档理解得不是很清楚，导致开发进行到3个月的时候发现需求上有争议。在和客户确认后得出结论：如果要满足客户的要求，则需要对整体架构进行修改。虽然最后按期交付了软件，但是整个项目组最后两个月每天都在加班，包括周末，而且软件质量也没有得到客户的充分认可。 再如我们在了解客户需求的同时，应该尽量了解客户为什么要这么做，帮客户一起想需求，以便我们开发的软件能够更好地为客户服务。每天开完会后，我们应该把客户的需求整理好，发给同事进行研究分析，建立简单的基础模型并研究技术可行性。需求分析结束后，保持每周至少3次电话会议与客户进行沟通，随时了解客户的需求。最后正因为在前期阶段进行了这种细致的需求分析，项目组在很少加班的情况下，不但按时交付了项目，并且得到客户的充分认可。 三.软件需求分析的任务 软件工程的发展来源于信息需求对它的推动，现在互联网技术和应用越来越成熟，信息的获取也逐渐变得简单和完整，但是由于资源的开放性、系统与系统的相互渗透性、用户的变动性让需求变得多目的、多变化，增加了软件制作的难度，但同样带来了巨大的用户市场。需求的获取同样也是困扰软件工程的绊脚石。需求与资源的搭配不合理，就会影响软件工程的发展。未来适应变化多端的用户需求，必须让软件也随之变化。要满足多样化的信息需求，提取合适的信息需求建立模式，就要有相应的系统对需求信息进行分析和总结，通过程序化的模式来制定切实可行的软件方案。 在软件分析过程中，应尽可能地让更多的人参与进来，而不仅仅是软件分析师自己。在之前的美国项目中，在前期分析时软件开发的核心技术人员和测试人员就已经进入项目组，每天技术人员会对分析的结果提出技术实现的难点以及改进的方法，笔者在随后的会议上就会和客户进行讨论，尽量在满足客户需求的'同时，使用更简单可行的技术，这样就为以后的开发奠定了基础，使开发时的工作量大大减少。测试人员也在需求时提出从测试角度看到的问题，同样在需求分析阶段得到解决，节省了大量的开发时间。 需求工程在未来发展中会有如下几个方面的着重考虑：（1）缩小需求工程在理论研究阶段取得的成果同实际应用中得到的效果的差距，通过得到的结论来更好的设计软件；（2）规范需求工程的各种机制，可以有需求工程规格数据的搜集、整理、制作、实现以及维护，也可以有需求工程的问题的解决办法；（3）保证需求工程有较高的质量。这一点是需求工程最为关键的要求，质量的高低直接影响了未来实现效果的好坏。 需求工程就是对未知问题进行探索、处理的过程。未来必然会朝着对象具体化、分析自动化的方向发展。 四.进行需求分析的注意事项 1.需求分析是分析人员与用户共同的责任。用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而需求分析人员则要认真了解用户的要求，细致地进行调查分析，把用户“做什么”的要求最终转换成一个完全的、精细的软件逻辑模型，并写出软件的需求规格说明，准确地表达用户的要求。在一些项目中，由于时间紧迫，一些模糊问题没有及时澄清，导致最后返工，影响了项目进度。 2.需求分析阶段研究的对象是软件项目的用户要求。需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。在一些项目中，针对客户提出的需求，了解客户的意图后，发现技术上实现有很大难度。我们了解到这个需求对客户来说不是十分重要，于是和客户商量出一个折中的解决方案，绕过技术难点，并且没有降低客户满意度。 3.分析人员要使用符合客户语言习惯的表达，应主动积极了解客户业务和相关知识。需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语教给分析人员，而客户不一定要懂得计算机行业的术语。由于通常情况下客户对计算机术语了解不多，需求分析人员应该尽量将计算机术语转化成通俗易懂的语言，这样便于和客户沟通。而对于客户方面的术语，一方面不懂的时候一定要问；另一方面也要多学习。 综上所述，需求分析是软件开发周期中的重要阶段，关系到软件开发的成败。我们在软件开发中应该充分重视这一阶段，尽量将问题在这一阶段解决好，为后期的软件开发打好坚实的基础，使项目能够保质保量的完成。 参考文献： 【1】李德毅.需求工程----对复杂系统的软件工程的基础研究【J】.中国基础科学，，11（2）；56-57. 【2】李虹，闫德恒.基于项目需求工程理论的软件需求管理浅析【J】.国科技信息，，（16）；72-73 【3】李建平.软件需求工程过程管理的研究与应用【J】.科技信息，2011，（5）；66-67
篇2：关于SOA中需求分析的讨论
让我们回顾一下需求分析的历史，然后讨论SOA中如何来进行面向服务的分析和建模吧，
软件工程方法中，需求分析的方法跟问题域的复杂度和类型紧密相关。在早期，计算需求主要来自科学计算，其抽象手段主要是“数据结构+算法”。在沟通需求的时候，技术人员跟业务人员以自然语言为基础来沟通，然后以过程和/或函数以及数据结构为主要抽象手段，来建立分析模型。分析结果包含过程/函数、流程图、数据流图，复杂一些的，引入模块和子系统来分割。然后，用自然语言描述为主的文档来作为沟通的手段。如果我们还记得关于GOTO的讨论，我们了解，这个计算时代经过多年的发展，推动了结构化编程的发展和成熟。
伴随着商业计算逐渐成为主流，商业计算从早期类似于科学计算的财务等，转向更为广泛的领域，其计算的复杂度和类型，发生了很大的变化，这中间各种数据库技术曾经领衔主演了一段时间，我们按下不表。这期间，在“软件危机”的推动下，对象成为基本的抽象手段，将其高度内耦合的数据、状态和行为结合在一起，不仅提高了抽象度，也自然地反映人们认识和描述这个世界的方式。经过多年的实践、争吵和合作，人们总结出了很多关于对象分析和建模的方式，组件、接口、各种分析和设计模式，逐渐地被认识和流行，UML建立了图例和文档规范，以便沟通。这是软件界的一个巨大进步。在这种软件工程方法中，技术人员通常用自然语言同业务人员沟通，然后用“Use Case”（用例）来建立各种角色所看到的系统边界，再辅助以用户交互（UI）等必要的其他模型，建立一个系统的分析视图，然后，以对象（和组件）为基本手段，建立系统的分析模型，最后，用UML和一些过程如RUP提供的文档模板为基础，提供需求分析结果。这种分析方法，今天非常流行，也很有效。
但是，商业计算的情况再次发生巨大的变化——“整合”和“灵活性”成为主要的需求。经过几十年的发展，商业计算已经不再是过去白手起家的时刻，我们已经有了很多的“历史”，那就是我们已经建立起来的这么多的系统：每个企业都有IT系统，少到几个、几十个，多到几千甚至上万。人类花了这么多钱、这么多时间在这些系统上，没有了这些系统，核心业务会崩溃。但这些系统也给我们带来了巨大的麻烦——它们能够满足不同业务部门（Line of Business，LoB）的垂直需求，可是相互不往来、也不能或者很难相互往来，难以满足跨业务部门的水平需求，更不要说在今天这个平的世界里，如何将合作伙伴、客户连接起来，建立一个动态的商业价值网络。但是，全球化的经济结构和运作模式，互联网作为全球化的IT基础设施，从商业和技术两个角度，透过竞争，既给富有创新和执行能力的企业带来了一个前所未有的商业机会，又迫使跟随的企业不得不起而迎战——将业务模式调整到以客户为中心，将自己内部的业务系统连接起来，水平整合业务活动成为端到端的业务流程，透过这些流程，让整个公司的员工可以自由地得到业务活动需要的信息，轻松地相互协作，从而将整个企业的运作模式转化为一个扁平的结构，打破业务部门的边界，极大地提高企业的效率，得到更好的客户满意度，
即便如此，用户需求、市场情况、商业环境的快速变化作为这个时代的特点，要求企业能够快速调整自己的商业模型，因此，在整合的基础上，还要加上快速应变的灵活性要求。这就涉及到了软件的两个魔鬼：复杂度和演变。全面整合（整个企业，客户，合作伙伴）的系统，其复杂度再次提升，而灵活应变能力，在一个整合的世界里，大家都变，自己也没办法以不变应万变，究竟如何因变？所以，我们需要发展软件系统的构造方法，它既可以帮助我们将问题域进行良好的分割，分解映射为分布世界里的独立单元，又可以帮助我们灵活地将它们组合起来以完成一个完整的业务活动，这样一种新型的、富有弹性的分布式系统，是今天的商务世界所需要的，是商业计算的主要发展方向。SOA也好，正在热吵的Enterprise Web 2.0也好，都是我们期望用来解决上面这个问题的方法。
虽然，我们还处在这个早期，有赖于过去多年的EAI、分布式系统的构造实践，尤其是Web的发展，IT行业积累了不少的经验和技术来求解。让我们简要地看看现在这个阶段的解的重点：一个是将业务本身作为一个独立的实体，由业务人员自己自觉（而不是自发）地以业务世界的元素，比如业务活动，业务流程，业务规则，业务性能及其测评，建立起数字化的模型，其核心概念就说所谓的“服务”。在这个模型中，我们将看到一个清晰的图景：业务活动是如何影响业务绩效的，业务模型的问题在那里，如何改善。这就是所谓的“商业科学化”，请参看我在 Service Science方面的介绍。了解BPR (Business Process Reengineering) 的话，应该了解这件事情会在什么状态，它的困难在哪里。有了这个为基础，业务人员可以自己跟自己玩：市场需求变了（他们的需求），那业务模型怎么变化来适应？或者，有了一个市场图谋，如何变化自己的业务模型来适应？过去要猜，要靠某些精英的个人特质，有了这个模型，我们期待一个魔术的出现，就是可以用数学的方法来演算、模拟、推断，哪怕结果不是高度精确的，也可以给决策者一个合理的、基于数字的决策依据。然后，这个模型要清晰地被分解和映射到IT系统中的服务接口、组件和业务规则描述等等，然后将它们分配到各个应用（包括已经存在的）中，再在这个基础上，使用用例、组件（细粒度）和对象建立应用或者子系统的需求模型，我们可能需要增加新的模型，比如整合各个应用的模型，安全模型（整合情况下安全更复杂）等。看得到，这个模型对过去的业务分析（尤其是从BPR，或者其他以业务流程为基础的）是有继承的，但要看到，他们的出发点和追求的目标，有交叉但并不能等同，所基于的概念和方法，即使有所借用，却有很不相同的重点。站在发展的角度，我们期待着业务模型数字化、科学化的突破。
是故，我们认为SOA将业务建模作为一个全新的因素引入，如何建立一个好的业务模型，然后递次分解、映射到传统技术世界主导的分析和建模，如何保证其可追溯性（Tracability）将是以服务为中心的分析、建模的重要环节。
来自：tech.it168.com/soa/-12-10/200712101752926.shtml
篇3：工作流需求分析
用户的需求大概分为两部分：一部分是整个项目完全基于工作流来搭建开发，这也是很多工作流厂商患有“平台压迫症”的原因；另一部分是将工作流作为业务组件加入已有的项目中，推动业务的“审批”流转，
前者的要求显然更高，但也意味着有更多的利润。其实这一部分的用户又可以进一步的细分：一是技术能力比较差的公司，他们通过层层外包接到项目，而又没有实力自己开发，于是想通过采购工作流加上几个刚入门的程序员来完成整个项目的开发（这类用户往往也是业务平台最大的客户群），他们想着是一整套的开发解决方案，甚至包括业务分析；二是对业务编程的需求，他们需要流程引擎能够侵入业务编程的内部，对业务的状态和生命周期进行灵活的管理，从而最大程度的简化开发或者说满足一些复杂业务编程的需要。
后者的需求则比较简单，多是某一行业的项目公司，突然碰到有审批的需求了，采用工作流多是满足人工“审批”的需要，以及部分的统计分析。
需要承认，工作流其实与最终用户还差得很远，也就是说在众多厂商的网页上，那副著名的业务流程生命周期其实是一句空话。一句话说，就是那个什么流程设计器是给程序员用的，至于用户，哪凉快哪去。也就是说现在的工作流还不能给最终用户提供价值。OK，既然工作流的价值是提供给集成商的，集成商就会考虑成本，于是工作流能否提供一个完整的开发解决方案就成了最重要的考量，
最后说说市场。工作流其实有着很大的市场，只不过这个市场被开源工作流和平台瓜分掉了。因为目前的工作流不能给最终用户提供价值，所以集成商在遇到审批的需求时，首先想到的会是开源的工作流引擎，从jbpm、osworkflow的流行也可以看出这一点，并且知识的积累确实比购买工作流来的划算，同时很多公司通过积累也会有自己的流程组件，这并没有太大的难度。难度留给技术能力一般的公司，他们首先想到的会是一整套解决方案而不仅仅止于流程服务，于是平台出现了，平台说：“灰壳显灵，银弹来了。”
关于平台，有一个很时髦的流行词汇，叫“业务应用基础平台”，稍候待续。
#re: 工作流需求分析 -05-08 22:14 |天独
BPM（并不是一个核心的工作流，还包括他的周边，比方说流程设计器，表单设计器之类的）本身就是给一些刚入行的程序员用的，他的出现简化了开发，降低成本，缩短开发时间，在一定程度上提高软件公司的竞争力。
我们经理这样说BPM系统的营销，是一种专家营销！普通的营销员根本无法对这个产品进行营销，应为他们很难把握到产品的核心，在一些关键的问题上也很难说清楚。而且BPM使用的对象也是一些开发人员，就像博主说的自身没有足够的研发实力公司，或者需要快速开发项目。
呵呵，我也是刚接触BPM2个月，说错了勿怪！只是看到了博主的文章，才说点自己的看法的！
来自：工作流需求分析
篇4：系统需求分析
四、业务流程分析
作为A公司信息自动化系统主要子系统之一的设备管理信息系统，要实现A公司设备台账管理、设备维修与维护管理、配件管理等功能，将全厂的设备管理部门、设备使用部门、配件管理部门、财务等相关部门联系起来，达到准确、及时的业务信息的共享，形成如图3所示一个完整的设备管理体系，为设备管理职能部门及相关部门提业务信息和决策支持信息，
图3
A公司的设备管理包含以下业务内容：
1.设备基础信息管理
是对设备管理基础信息的建立和维护，包括设备代码、设备台账、机型所属配件信息、机型所属部位信息、设备随机资料和设备资产移动信息等的建立和维护。设备与其台账、资料、移动信息通过设备统一代码联系在一起;而设备与各层次使用单位的关系则通过层次代码体系加以保证;在机型一级通过机型所属配件信息、机型所属部位信息建立设备维修、改造、润滑及配件库存管理所需的相关信息;并建立和维护设备管理所有标准化管理代码。使管理部门能随时掌握设备资源状况，同时，为设备维修、改造、润滑管理提供所需的设备基础数据基础。
2.设备维修管理
设备使用部门根据设备使用的实际情况，及设备基础信息的内容、生产规划中生产主计划的安排，提报年度的立项维修计划，经过项目管理部门的审查和协调后，制定正式的立项维修计划，交由维修部门实行。维修部门在进行维修资源和维修能力的合理配置后，编制详细维修作业计划，进行预防维修工作，同时进行设备故障发生后的紧急维修，维修工作结束后提供维修的详细信息，包括维修报告、故障报告、事故报告等相关信息，用于维修活动的控制，并且对维修活动进行维修分析，以对今后的维修活动提供参考和指导。
3.设备改造管理
对于造成设备经常性故障，导致生产损失;或是影响设备效用发挥的设备设计上的不合理因素，通过进行设备改造，可以提高设备的利用率和效率，保证生产的正常进行。设备改造管理正是为了达到这个目的。
设备使用部门根据设备的实际使用情况和维修分析信息、设备基础信息的内容，以及生产规划中主生产计划的安排，提报年度的立项改造计划，经过项目管理职能部门的审查和协调后，制定正式的立项改造计划，交由维修部门实行。维修部门在进行资源和能力的合理配置后，编制详细改造作业计划，改造工作结束后提供设备改造报告，包括改造内容、费用、工时等相关信息，用于对改造活动的控制。
4.备件管理
对配件的计划采购工作进行全过程的管理和控制，各个环节的运行状况均有反馈信息加以描述，达到配件计划采购工作有序而切实地进行，
包括配件的需求管理，采购计划的制定，按照计划进行的采购工作的管理，和配件到货后的检验工作管理，并对采购行为的全过程进行跟踪，对各个环节的运行情况进行汇总统计。
5.库存管理
库存管理包括入库管理、出库管理、库存盘点、库存期末处理、库存分析、报废管理和外销管理。用于维护配件库存基本信息，实时处理各种出入库凭证，确保动态库存数据的正确，随时查询各种库存信息;库存分析功能针对配件库，及时分析库存构成及数量情况，以降低库存资金占用，并为制定采购、需求计划提供可靠数据;报废管理和外销管理针对处理库，用于不再具有使用价值的配件或积压配件的管理。
6.故障管理
设备故障管理是设备管理的一个重要方面，从不同角度对设备故障进行统计分析，对设备管理工作具有重要意义。通过建立设备故障树，可以在设备发生故障时根据故障现象快速查询到可能的故障原因，为解决故障问题提供保障。设备故障管理主要包括：收集整理设备故障信息，掌握设备故障规律，建立设备故障树，提供设备维修技术支持，降低设备突发故障。
五、性能需求分析
从实用、好用的角度出发开发A公司设备管理信息系统，建立面向企业设备管理全过程的管理与控制系统，在设计过程中主要考虑以下原则：
1.可操作性
原始信息皆由各相关部门录入，系统应尽量减少操作员的数据录入量，录入数据尽量通过设计下拉列表框来选择录入，这样的处理同时也避免了许多录入异常现象的发生。数据输入的格式应符合业务习惯，并且直观、方便。要求系统处理的数据能准确无误，同时输出信息要求直观、简洁。
2.可靠性
系统运行具有较高的可靠性，提供严格的并发控制，确保数据的一致性和正确性。
3.实用性
从用户的实际需要出发进行系统开发，不盲目追求高新技术的应用。
4.安全性
系统安全措施可靠、高效、可维护性好，有权限控制、口令控制、临时锁定控制，其中口令录入界面便于系统识别登录用户。
5.可维护性
为了保证系统的可维护性，要求具有详细的文档资料，同时，要求系统在功能设计上考虑可扩展性，以满足业务变动的需求。
6.可移植性
系统开发完成后，要能运行于任何由Windows NT/Windows 9X操作系统所构成的计算机网络环境下。
通过对A公司信息自动化系统总体结构和组织机构的介绍、以及对设备管理系统目标、业务流程、软件系统性能需求的分析，描述了A公司设备管理信息系统的系统需求，为下一步的系统设计打下了良好的基础。
篇5：需求分析报告
一、那些人应该参与网站开发项目的需求分析活动
需求分析活动其实本来就是一个和客户交流，正确引导客户能够将自己的实际需求用较为适当的技术语言进行表达（或者由相关技术人员帮助表达）以明确项目目的的过程。这个过程中也同时包含了对要建立的网站基本功能和模块的确立和策划活动。所以项目小组每个成员、客户甚至是开发方的部门经理（根据项目大小而定）的参与是必要的。而项目的管理者在需求分析中的职责有如下几个方面：
1、负责组织相关开发人员与用户一起进行需求分析。
2、组织美术和技术骨干代表或者全部成员（与用户讨论）编写《网站功能描述书（初稿）》文档。
3、组织相关人员对《网站功能描述书（初稿）》进行反复讨论和修改，确定《网站功能描述书》正式文档。
4、如果用户有这方面的能力或者用户提出要求，项目管理者也可以指派项目成员参与，而由用户编写和确定《网站功能描述书》文档。
5、如果项目比较大的话，最好能够有部门经理或者他授权的人员参与到《网站功能描述书》的确定过程中来。
二、完整的需求调查文档记录体系
在整个需求分析的过程中，将按照一定规范的编写需求分析的相关文档不但可以帮助
目成员将需求分析结果更加明确化，也为以后开发过程中做到了现实文本形式的备忘，并且有助于公司日后的开发项目提供有益的借鉴和模范，成为公司在项目开发中积累的符合自身特点的经验财富。
需求分析中需要编写的文档主要是《网站功能描述书》，他基本上是整个需求分析活动的结果性文档，也是开发工程中项目成员主要可供参考的文档。为了更加清楚的描述《网站功能描述书》往往还需要编写《用户调查报告》和《市场调研报告》文档来辅助说明。各种文档最好有一定的规范和固定格式，以便增加其可阅读性和方便阅读者快速理解文档内容，相关规定将在本文后面讨论。
三、向用户调查些什么
在需求分析的工程中，往往有很多不明确的用户需求，这个时候项目负责人需要调查用户的实际情况，明确用户需求。一个比较理想化的用户调查活动需要用户的充分配合，而且还有可能需要对调查对象进行必要的培训。所以调查的计划安排：时间、地点、参加人员、调查内容，都需要项目负责人和用户的共同认可。调查的形式可以是：发需求调查表、开需求调查座谈会或者现场调研。调查的内容主要如下：
1、网站当前以及日后可能出现的功能需求。
2、客户对网站的性能（如访问速度）的要求和可靠性的要求。
3、确定网站维护的要求。
4、网站的实际运行环境。
5、网站页面总体风格以及美工效果（必要的时候用户可以提供参考站点或者由公司向用户提供）。
6、主页面和次级页面数量，是否需要多种语言版本等
7、内容管理及录入任务的分配。
8、各种页面特殊效果及其数量（js,flash等）
9、项目完成时间及进度（可以根据合同）
10、明确项目完成后的维护责任。
调查结束以后，需要编写《用户调查报告》，《报告》的要点是：
1、调查概要说明：网站项目的名称；用户单位；参与调查人员；调查开始终止的时间；调查的工作安排。
2、调查内容说明：用户的基本情况；用户的主要业务；信息化建设现状；网站当前和将来潜在的功能需求、性能需求、可靠性需求、实际运行环境；用户对新网站的期望等。
3、调查资料汇编：将调查得到的资料分类汇总（如调查问卷，会议记录等等）
四、市场调研活动内容
通过市场调研活动，清晰的分析相似网站的性能和运行情况。可以帮助项目负责人更加清楚的构想出自己开发的网站的大体架构和模样，在总结同类网站优势和缺点的同时项目开发人员可以博采众长开发出更加优秀的网站。
但是由于实际中时间、经费、公司能力所限，市场调研覆盖的范围有一定的局限性，在调研市场同类网站的时候，应尽可能调研到所有比较出名和优秀的同类网站。应该了解同类网站的使用环境与用户的诧异点、类似点，同类产品所定义的用户详细需求（需要公司或者项目负责人有一定的关系）。市场调研的重点应该放在主要竞争对手的作品或类似网站作品的有关信息上。市场调研可以包括下列内容：
1、市场中同类网站作品的确定。
2、调研作品的使用范围和访问人群。
3、调研产品的功能设计（主要模块构成，特色功能，性能情况等等）
4、简单评价所调研的网站情况。
调研的目的是明确并且引导用户需求。
对市场同类产品调研结束后，应该撰写《市场调研报告》主要包括一下要点：
1、调研概要说明：调研计划；网站项目名称、调研单位、参与调研、调研开始终止时间。
2、调研内容说明：调研的同类网站作品名称、网址、设计公司、网站相关说明、开发背景、主要适用访问对象、功能描述、评价等
3、可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、可采用的原因。
4、不可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、不可采用的原因。
5、分析同类网站作品和主要竞争对手产品的弱点和缺陷以及本公司产品在这些方面的优势。
6、调研资料汇编：将调研得到的资料进行分类汇总。
五、清晰的需求分析输出――《网站功能描述书》：
在拥有前期公司和客户签订的合同或者是标书的约束之下，通过较为详细具体的用户调查和市场调研活动，借鉴其输出的《用户调查报告》和《市场调研报告》文档，项目负责人应该对整个需求分析活动进行认真的总结，将分析前期不明确的需求逐一明确清晰化，并输出一份详细清晰的总结性文档DD《网站功能描述书（最终版）》以供作为日后项目开发过程中的依据。
《网站功能描述书》必须包含以下内容：
1、网站功能
2、网站用户界面（初步）
3、网站运行的软硬件环境
4、网站系统性能定义
5、网站系统的软件和硬件接口
6、确定网站维护的要求
7、确定网站系统空间租赁要求
8、网站页面总体风格及美工效果。
9、主页面及次页面大概数量。
10、管理及内容录入任务分配。
11、各种页面特殊效果及其数量。
12、项目完成时间及进度（根据合同）
13、明确项目完成后的维护责任。
综上所述，在网站项目的需求分析中主要是由项目负责人来确定对用户需求的理解程度，而用户调查和市场调研等需求分析活动的目的就是帮助项目负责人加深对用户需求的理解和对前期不明确的地方进行明确化，以便于日后在项目开发过程中作为开发成员的依据和借鉴。
篇6：需求分析报告
相关资料数据以广州为例分析其人才需求状况，供广大求职者和有兴趣的朋友参考。
一、招聘热度 分析
自金融危机以后我国服装产量的持续低增幅，企业对产量增长的谨慎态度。近来欧盟纺织品服装市场需求低迷、部分市场向竞争对手国转移造成了国内服装企业的发展困境。就今年上半年而言，服装行业的人才需求并不十分给力，反映出服装行业整体发展缓慢。
从上图看，广州服装行业招聘职位数浮动不明显，6月低谷期后，7月略有所回升。业内人士分析认为，外贸形势短期内难有明显起色，但是随着欧美服装消费旺季的来临，第三季度服装出口或将有所回升。预计其人才需求也会有所增加。
二、招聘职位分析
据百才招聘网数据统计，7月份广州服装行业发布职位超过一万，仅次于上海。其中，美术/设计/创意类职位占29.01%，其次是销售类、经营管理类职位，占比分别为12.40%、11.78%。招聘职位中，以服装设计师、设计助理招聘职位数最多，占比均超过了15%。
三、招聘要求分析
根据分析，目前服装行业的人才学历要求较其他行业要略低，就广州招聘职位而言，其高中及以下学历占比达28.83%，本科仅占12.42%。从经验要求分析，0――2年、3――5年工作经验者需求量持平，均超40%。可以看出在服装行业人才对经验的要求较学历而言更严格。
四、行业薪酬 分析
根据数据显示，广州服装业整体薪酬水平居中，高薪占比比较小。薪资――3999元/月占比最大，达51.20%，万元及以上的月薪仅占比9.63%。这可能与服装行业整体产业性质相关，服装企业工厂员工占比较大，行业整体薪酬分布应该不会有太大的浮动。
篇7：需求分析报告
一、首次调研面积及户型选择意向分析
1、时间：2006年4月5日
2、地点：繁华路段，沿街门面、行政机关单位、事业单位、陌生拦截等处选择样本
3、调研方式：问卷填写、深度访谈
4、发出问卷：80份，有效问卷68份
5、样本人群基本情况
家庭人数：
文化程度：大专以上12人 中学（含高中、初中、中专）40人 其他16人
工作单位：经商或个体户36 事业或行政单位20 其他12
收入状况：
6、户型结构选择
从图中可以看出，客户对房型结构的选择中，三房两厅的占到高达40%的份额，加上18%的四房两厅和18%的三房一厅，合计占到76%的份额，只有不占1/4的人选择两房或其他户型。
7、户型面积选择
从图中可以看出，客户选择110―130平方米的比例占到35%，与上图中三房两厅40%的比例类似；90―150平方米的比例合计占到81%，加上150平方米以上13%，全部占到总份量的94%，90平方米以下的仅占到6%。
注：以上数据引自郑州深蓝咨询机构《项目全程营销策划报告》，以下数据是展示接待中心接待来访客户情况的数据统计分析
二、2006年5月份客户面积选择意向分析
户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 其他 合计
数量（组） 30 12 55 61 66 51 45 51 371
客户在提示作用下，除14%的客户选择其他户型外，86%的客户都能在120―150平方米之间选到满意的户型。
三、2006年6月份客户面积选择意向分析
户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 四房 其他 合计
数量（组） 24 20 49 32 41 20 16 43 61 306
客户在提示作用下，选择120平方米以上的占到80%，在其他20%的客户中，除部分选择复式户型的以外，选择其他户型的只有不足20%。
四、2006年7月客户对户型面积的意向分析
户型面积 90O 110O 120-130O 130-150O 复式及150以上 无具体意向 合计
客户量 5 6 34 47 15 8 115
需要130―150平方米的客户超过40%，而120―130平方米客户占30%，两者合计占到70%左右，是县城购房的主力目标客户群体。复式楼的.需求量也在13%，是县城高端购房人群之一。90―110平方米的人群占到9%左右，可以看作县城购房群体的补充目标人群。
结论：
综上所述，在豫北某县购房群体中，最少有60%以上的客户选择120―150平方米的房子，最高达到86%左右的比例。另有10―20%的客户选择150平方米以上的户型。只有不到10%的少量客户需求面积在90平方米左右或以下。
如果公务员小区的房型面积不能按照市场需求状况供应，将产生以下几点影响：
第一，单套面积较小的商品房非主流市场需求产品，一旦供应，()将只有极少数的目标人群购买，项目开发不可能达到预期的社会效益和经济效益；
第二，由于单套面积较小的房到成本增加，在销售价格不变的情况下，投资回报率降低；同时，在市场需求有限的环境下，将直接影响到开发企业的开发积极性；
第三，由于市场缺乏满足客户需求的产品，将造成市场供应产品的结构极度不平衡，对于目前市场上供应的大户型产品有着较大利好，将有可能进一步抬升房价，造成更多的客户买不起房；
第四，客户选不到适合自己的商品房，将取消或推迟自己的购房计划、或者选择其他的住宅获取途径来解决居住问题，无论对于政府税收、经济发展、扩大内需都有着较大的冲击；
第五，市场供应的商品房都是偏小面积，客户需求都是稍大或较大面积，开发商虽然知道消费者需求，但由于政府限制，不能按市场规律供应满足市场需求的产品，将形成各方均无法满意的局面，将破坏掉构建和谐社会的基础，间接影响到豫北某经济的快速稳定持续发展。
【浅谈软件开发中的需求分析】相关文章：
1.需求分析模板
2.需求分析岗位职责
3.需求分析范文
4.需求分析报告
8.项目需求分析报告
10.软件需求分析面试自我介绍
文档为doc格式
