项目需求分析（项目的需求分析怎么写）

本文目录

• 项目的需求分析怎么写
• 项目需求分析的内容
• 站在需求的角度去分析一个创业项目,一般要考虑什么
• 如何做好ERP实施项目的需求调研（实施erp前所做的需求分析）
• 论述项目需求分析的技术与方法
• 需求分析的作用及如何进行需求分析
• 如何做好网站开发项目需求分析
• 需求分析方法有哪些
• 项目需求分析文档都包括哪些内容

项目的需求分析怎么写

项目需求分析怎么写 项目需求分析的概念　　需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specificatio郸); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析　　需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务　　简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程　　需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标. 分析与综合 逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型). 制订规格说明书 即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交. 评审 对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法　　需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论. 原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能. 原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个...... 软件的需求分析怎么写啊？ 1. 引言 1.1　编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体. 1.2　项目背景 1.2.1项目委托单位:****公司 1.2.2开发单位:***公司 1.3　定义 1.4　　参考资料 2. 任务概述 2.1　目标: 《1》 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示 《2》提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理. 2.2　运行环境: 《1》 硬件方面:Pentium级处理芯片 1兆显存的兼容显卡 256色,800*600的兼容显示器 标准兼容打印机 《2》软件方面: WIN95操作系统 2.3　条件与限制: 编程用计算机一台 完成期限2000/7/1 无资金供给 3. 数据概述 数据流程图如下: 3.1　静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据 3.2 　动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间 3.3　数据库描述: 人事管理数据库:公司内人员的个人详细信息,包括档案信息 销售管理数据库:当日销售记录及以前的销售统计,用于销售分析 财务管理数据库:公司内部账目及收支情况详表 技术管理数据库:公司所需各技术档案的详细记录(包括文档) 3.4 数据字典: 《1》数据流词条描述: 1.数据流名:登录信息 来源:用户的输入 去向:系统内部检验部分 组成:用户名,密码 流通量:每次登录输入一次 2.数据流名:登录结果 来源:系统 去向:用户 组成:返回信息 流通量:每次登录返回一次 3.数据流名:输入修改信息 来源:用户 去向:系统判断部分 组成:根据各数据库内容而不同 流通量:依用户输入而定 4.数据流名:反馈信息 来源:系统判断部分 去向:用户 组成:系统经判断后发回的字符数据 流通量: 依系统当前信息而定 5.数据流名:识别信息 来源:系统内部检验部分 去向:系统判断部分 组成:系统各数据库的标识信息 流通量:用户每次输入流通一次 6.数据流名:处理信息 来源:系统判断部分 去向:各数据库处理部分 组成:读取/修改标识,读取/修改的变量名称 流通量:用户每次输入流通一次 7.数据流名:读取修改 来源:系统判断部分 去向:系统各数据库 组成:读取/修改标识,读取/修改内容 流通量: 用户每次输入流通一次 《2》数据文件词条描述: 1.数据文件名:人事数据 简述:存储人员信息 数据文件组成:人员的各项信息(以CString类型为主) 2.数据文件名:销售数据 简述:存储当日及从前的销售记录 数据文件组成:销售的各项信息 3.数据文件名:财务数据 简述:存储财务管理信息 数据文件组成:财务管理的各项记录 4.数据文件名:技术数据 简述:存储公司内部使用的技术档案信息 数据文件组成:技术档案名称,内容 《3》加工逻辑词条描述: 1.加工名:检验 ...... 项目目标与任务需求分析应该怎么写？ 项目目标与任务需求分析=项目的目标和任务，目标和任务是什么就写什么了 项目需求报告要怎么写？ 听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。听棠所说到的几点，感受特别深：“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。 如何做需求分析 随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。 网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web 服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。 按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制： 1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务 需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。 （一）如何做好需求分析及变更管理？ 业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。 一：让客户畅所欲言，罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。 很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！ 二：透过现象分析潜在的需求 很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。 客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。 比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下...... 做程序，项目需求分析，一般做多久。 国内很多老一辈的根本不注重这一点。但国外的，很小的开始实战写需求了。因为他们一直认为需求是相当重要。每次都做项目前都是，乱七八操的需求分析，像个草搞。偶尔做一下，改一下。改一下需求，那么，原来的框架，编码都要改。而我同学他们的虽然做需求做了一个月多，但却是按需求很顺利的一气搞定。我问的是：无论是多大，还是多小的项目，都要把需求写清楚再做。 java 项目需求文档要怎么写？ 需求文档一般分两类 需求调研报告 需求分析报告 调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。 分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容： 项目的背景 项目的目标 项目的范围 用户特点 相关技术、规范标准等 相关约束 用户的组织结构、角色等 用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等 总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出

项目需求分析的内容

项目需求分析的内容至少包括五个方面：　　1．国家和地区需求分析　　通过对一个国家或地区的地理位置、自然特征、人口状况、经济结构、经济发展水平等方面的了解和研究，进而对项目的产品供需格局及趋势进行分析。这个分析是项目需求分析中最重要的一项，它直接关系到项目的发展前途。　　2．社会需求分析　　通过对社会和经济发展水平、产业结构、人文环境、自然生态环境、公众需求以及行业投资的了解和研究，进而对项目的社会需求进行分析。这一分析决定了项目的社会价值和意义。　　3．消费群体需求分析　　通过对消费人群的年龄、经济收人、消费水平、职业状况、知识水平等方面的了解和研究，区别消费结构群，进而对项目的消费需求进行分析。这一需求分析关系到项目的市场前景。　　4．项目业主需求分析　　通过对项目业主的投资期望和心态的了解和研究，进而对项目业主的需求进行分析。这一分析决定了项目的取合。　　5．项目实施需求分析　　通过对项目所使用的原材料、燃料、技术、设备、资金、人力需求以及环境等内容的了解和研究，进而对项目的实施需求进行分析。这一需求分析有利于提高项目的实施质量，保证项目顺利实施。

站在需求的角度去分析一个创业项目,一般要考虑什么

站在需求的角度去分析一个创业项目，一般要考虑:1、需求量（最好按地域分划）。这里指消费者在一定时期一定的价格水平下，愿意并且能够购买的某种商品的数量，而不是购买的欲望。2、需求的迫切程度。需求强度大需求弹性就小小，表示市场需求的容量或空间，可以用对该品类有需求的人口（目标顾客）与总人口之比来表示。3、需求的变动。指在某商品价格不变的条件下，由于其他因素变动所引起的该商品的需求数量的变动。这里的其他因素变动是指消费者收入水平变动、相关商品的价格变动、消费者偏好的变化和消费者对商品的价格预期的变动等。 注意与需求量变动概念的区别，不同于前者，需求量变动是指在其他条件不变的情况下，由于某商品价格的变化所引起的该商品的需求数量的变化。

如何做好ERP实施项目的需求调研（实施erp前所做的需求分析）

1.1从业务层面了解企业的概况与业务流程。通过需求调研，可以加深对企业整体运营情况的了解，如企业的背景、主要生产特点（包括主要生产的产品）、组织架构、人员职责等。如果是上市公司,可以通过企业的网站下载如财务报告等相关信息,加快对企业的熟悉程度。

1.2对相关模块人员的岗位和职责进行了解。在调研过程中,双方沟通会加大,进而了解企业的一些潜在文化,识别企业人员对ERP系统实施的态度(是积极支持?还是无所谓?或者消极抵触等),有助于顾问在日后的沟通中,有效避免项目实施的阻力。无数项目经验告诉我们,ERP系统项目实施,有效沟通是十分重要的。

1.3除了熟悉企业的业务流程与人员职责(人员关系)外,可以了解企业对ERP系统的期望,毕竟企业上ERP系统是需求解决或优化企业的一些问题的,所以,甲方提出的期望需求解决的问题,乙方顾问需详细记录,做在未来ERP系统设计时,重点考虑。对自己不熟悉的ERP系统解决方案,应提前进行方案熟悉与准备。2、需求调研的方式

从形式来讲,需求调研有问卷式、现场访谈、混合式（既包括问卷，也包括细节访谈）等。这些方式各有优缺点，应根据企业管理的水平和人员素质进行不同方式的需求调研。

2.1问卷式一般ERP系统实施方，根据多年的实施经验，总结出来了标准的需求调研问卷。这些问题一般与ERP系统的设计有关。

其次，问卷式适合企业管理水平较高，人员素质较高的情况下。如果不是，则易引起甲方相关人中反感，因为这类似让甲方做试卷，很可能填写的内容不全面。这样也使得甲方与乙方缺少了很好的沟通机会。2.2现场访谈式

现场访谈式一般是不可缺少的需求调研方式。这种方式，要求乙方顾问有较强的项目经验，需做好引导方式，将自己关心的问题，让甲方讲透彻，讲清楚。同时要求乙方顾问有速记的能力，将这些访谈的回答，快速准确的记录下来。记得以前大学的一位老师强调，速记是大学生的一项基本功。

访谈式的缺点，问的问题可能不全面，不系统，缺失一些重要的问题；另外就是如果不引导好，回答的问题与项目无关，影响访谈效率与效果。

然后，乙方顾问根据需求调研计划和需求调研问卷，进行详细访谈，将一些重要的问题，进行沟通和详细记录。这是问卷式访谈的补充和完善。3、需求调研的误区误区1：需求调研是形式作者曾经参与了一些大型SAP项目，这些SAP项目往往经历选取几家单位试点、一期推广和二期推广等实施过程。存在一些顾问没有参加试点，而直接进入推广项目。而推广项目的业务蓝图往往参照试点单位，于是这些推广项目的需求调研往往会流于形式，试想业务蓝图基本确定了，需求调研在某种意义上变更可有可无了？这样就容易认为需求调研就是走走过场。也有一些网友提出：他们企业的需求调研只有一天，就进行了项目实施的后续阶段。这些表象，都认为需求调研是不重要的，顾问负责推广ERP的标准功能就可以了。

误区2：需求越少越好有些顾问对自己的技术水平不够自信,担心用户提出比较复杂的需求。所以,在需求调研阶段,一些需求故意不去调研,甚至回避用户的一些需求。需求调研阶段,并非系统实现阶段,不需要出具详细的解决方案。此时的任务是充分了解企业的业务现状,只有充分了解了需求,识别了重要的需求,才能真正做到日后设计系统方案时回避需求。

4.1.1提前熟悉企业的业务概况可以通过以下途径来了快速了解企业的现况,如企业网站,信息披露(如上市公司),售前资料(如工作说明书)等。

4.1.2编制需求调研计划以生产计划模块为例,在培训产品的标准功能时(ERP概况培训),一般会按组织架构、基础数据、计划管理、车间执行等几个部分来介绍，同样在编制需求调研计划时也可按这几部分来制订需求调研计划，保证工作思路的一致性（未来在制订业务蓝图、系统实现阶段的单元测试等均可按这几部分），需求调研计划应包括：A、需求调研的内容（问卷）；B、需求调研的时间；C、需求调研的准备工作（要求客户方，如准备表单、记录、文件等）；D、需求调研的参加人员。4.2正式调研在准备好调研计划后,就进行了正式需求调研阶段。根据作者的一些调研经验,以下因素会影响调研的质量。4.2.1调研的对象:应该是企业的骨干,对需求调研对应的业务范围十分熟悉。否则会影响需求调研效果。4.2.2需求调研的场地:为了保证需求调研的效果,除了现场调研以外,避免在客户的办公室调研,主要是办公室环境不安静,而且办公室往往有调研对象的业务,不能做到专注,另外在办公室里有可能不能让调研对象畅所欲言。所以,调研最好在一个会议室里,小范围内进行详细讨论。

4.2.3需求调研的几个步骤:首先,顾问进驻调研地点后,应召开调研前的会议,双方人员的自我介绍。其次,顾问应说明需求调研的范围,目的与意义,引起客户的重视,并取得客户的支持。然后,进入需求调研,并在需求调研结束后,再次召开参与人员的会议,通报需求调研的内容与结果,目的是让双方确定需求调研内容是否完整与正确,形成当日需求调研的会议纪要。最后整理需求调研记录,形成最后的需求调研报告。与客户确定报告内容,是否有比较重大的遗漏,是否需要补充调研等。

5、需求调研的关键点以前的一个项目里,经常会遇到顾问在需求调研阶段,问的问题与项目无关,而相关的问题又问得不够深入。那么怎样的需求调研才是项目所需的,这里有一个非常重要的原则:需求调研是与未来ERP系统设计息息相关的,与下阶段的业务蓝图设计相关。而未来的系统设计,与业务蓝图大部分是基于系统的标准功能。所以,顾问要做到对系统的标准功能特别熟悉。简言之,顾问是带着"心中的系统功能"去需求调研的。

也曾发现,在业务蓝图设计阶段,顾问与用户之间又在沟通本应在需求调研阶段完成的工作内容,原因就是在于需求调研没有针对性,没有透彻性。出现了为需求调研而调研的现象。这方面,顾问应该下功夫积累经验,真正掌握系统标准功能,敏感用户的特殊业务。通过需求调研,顾问应该在脑海里将客户未来的业务蓝图,未来的系统功能设计有八成以上的"心中有数"。

论述项目需求分析的技术与方法

1、筛掉明显不合理的需求这个阶段的判断标准就是需求的合理性，用你的经验、专业知识，甚至是直觉，过滤掉大部分需求。比如，当前技术不可能实现的或意义不大的、投入产出比低的、明显不合理的需求。因为从各种不同渠道会收集到大量的需求，为了提高效率，你不得不这么做。当用户量达到一定规模后，光每天收到的用户反馈就够你喝一壶的。甚至因此，你不得不做一个用户帮助和反馈系统，来帮助你过滤和初步加工需求。有个简单的判断方法：这需求做了会怎样？不做又会怎样？如果做不做没多大区别，甚至做了会起到负效果，那就不需要犹豫了，可以直接过滤掉这条需求。2、挖掘用户的潜在需求和动机这是用户需求进化为产品需求的关键一步。用户需求：need，用户想要的。产品需求：solution，解决方案。可以是推荐算法优化、界面布局调整、新功能点，甚至是新产品等等以上是用户需求和产品需求的定义，用户需求是用户想要的东西，产品需求是满足用户需求的解决方案。用户毕竟不是专业人士，考虑问题的出发点是用户自身，这就需求产品经理去挖掘用户的潜在需求和动机。最著名的例子就是：If I had to ask customers what they want,they will tell me:a faster horse.“如果我当年去问顾客他们想要什么,他们肯定会告诉我：一匹更快的马.’”如果福特先生不去挖掘用户背后动机的话，可能就去研究马的配种问题了，而不会有福特汽车了。那么如何挖掘用户潜在需求和动机？用户需求的产生，带有很强的不确定性，受环境、情绪等各种因素影响。所以光看表面描述不行，得有代入感的去感受。可以通过以下几个要素进行场景分析：用户需求=谁（用户特征）+在什么情况下+想满足什么？比如你是Todo list产品经理，调研过程中，某用户反馈添加过程太麻烦了，没法批量添加。追问为什么需要批量添加后，对方回答，她是一名学生，想要把课程表导入到list中，方便查看。这时候你就明白了，对方是一名大学生，在添加操作的环节遇到了麻烦，她是想要添加课程表。这时候你就可以马上找到解决方法：可以利用OCR技术，只需扫描一下，直接将整张课程表导入进来。再深入思考一下！添加课程表就是最终的目的吗？显然不是，对方添加课程表后，一是为了方便查看，二是为了上课时间快到时提醒她上课。那么就可在导入后，行程一个可视化的日程表，提前提醒上课。这就是需求挖掘过程。3、需求归类整理挖掘到用户的真实目的后，会发现，多个看似不同的需求背后，原来是出于同一个目的。这就可以将这几个需求归纳为同一个。接着可以通过如下维度归类整理需求：1）判断是否有价值：广度、频率、强度如果使用人数很多、频率很高、需求也很强烈，那当然是好需求。如果这三者都不沾边，可以判断为无价值需求，可过滤掉。

需求分析的作用及如何进行需求分析

需求分析就是对客户提出的“要求”或者“需求”进行深入细致地调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么，为系统设计、系统完善和系统维护提供依据。

需求分析是项目计划阶段非常重要的环节，该环节决定了需要“实现什么”，为下一步如何去“实现”提供了明确的方向。

进行需求分析需要做到以下几点：

（一）需求获取：在准备阶段，我们首先要确定需求获取的目标及范围，根据你的目标来选择对应的方式获取需求。

（二）需求分类：一般情况下，我们会根据对象的不同，将需求分为业务需求、用户需求、功能需求等。

（三）需求筛选：有些需求是伪需求，有些需求则不具备实现价值，我们可以通过真实性、价值性、可行性三个维度来筛选需求，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求。

（四）需求提炼：对剩下的需求进行提炼，目的在于从获取的表面需求中提炼出客户的本质需求。找出“为什么要做”比“做什么”更重要。

（五）需求优先级排序：挖掘到客户的真实目的后，我们需要根据不同维度的需求归类方法，如KANO模型分析法、投入产出比ROI等，对其进行归纳整理并排出优先级，帮助产品有条理地安排开发秩序，避免盲目排序。

（六）产出需求文档：通过以上的分析，我们需要将收集到的需求进行分析、汇总、归类，输出产出需求文档，为接下来的工作做好铺垫。

以上是对需求分析的一些理解和思路，做好需求分析工作之后，就可以对可实现的需求进行落地方案的跟进。

如何做好网站开发项目需求分析

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解需求分析指需求的分析、定义过程。

原因

需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个forlinux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发forwindows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。

需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。

任务

简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。

过程

需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。

问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

制订规格说明书：即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。

评审：对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。

方法

需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。

原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。

原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。

原型主要有三种类型：探索型、实验型、进化型。

探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。

实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。

进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

在使用原型化方法时有两种不同的策略：废弃策略、追加策略。

废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。

追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。

需求分析20条法则

客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、分析人员要使用符合客户语言习惯的表达

需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。

3、分析人员必须编写软件需求报告

分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、要求得到需求工作结果的解释说明

分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、开发人员要尊重客户的意见

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、开发人员要对需求及产品实施提出建议和解决方案

通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、描述产品使用特性

客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、允许重用已有的软件组件

需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、要求对变更的代价提供真实可靠的评估

有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、获得满足客户功能和质量要求的系统

每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、给分析人员讲解您的业务

分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

12、抽出时间清楚地说明并完善需求

客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

13、准确而详细地说明需求

编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

14、及时作出决定

分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15、尊重开发人员的需求可行性及成本评估

所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

16、划分需求的优先级

绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

17、评审需求文档和原型

客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

18、需求变更要立即联系

不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

19、遵照开发小组处理需求变更的过程

为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

20、尊重开发人员采用的需求分析过程

软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

需求分析方法有哪些

问题一：需求分析有哪些方法 三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。 结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。 面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人骸的要求非常高。 问题二：项目需求分析的分析方法 需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略. 问题三：如何做好需求分析，需求调研 转载以下资料供参考 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解需求分析指需求的分析、定义过程。 原因 需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。 需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。 任务 简言之，需求分析的任务就是解决“做什么的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。 过程 需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。 问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。 分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。 制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。 评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。 方法 需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。 原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。 原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。 原型主要有三种类型：探索型、实验型、进化型。 探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。 实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。 进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。 在使用原型化方法时有两种不同的策略：废弃策略、追加策略。 废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成......》》 问题四：请问常用的需求分析方法有哪些？ 结构分析方法和面向对象分析法 问题五：培训需求分析的方法有哪几种 组织资源分析 如果没有确定可被利用的人力、物力和财力资源，就难以确立培训目标。组织资源分析包括对组织的金钱、时间、人力等资源的描述。一般情况下，通过对下面问题的分析，就可了解一个组织资源的大致情况。 组织特质与环境分析 组织特质与环境对培训的成功与否也起重要的影响作用。因为，当培训规划和组织的价值不一致时，培训的效果则很难保证。组织特质与环境分析主要是对组织的系统结构、文化、资讯传播情况的了解。主要包括如下内容： 系统特质指组织的输入、运作、输出、次级系统互动以及与外界环境间的交流特质，使管理者能够系统地面对组织，避免组织分析中以偏概全的缺失。 文化特质。指组织的软硬体设施、规章、制度、组织经营运作的方式、组织成员待人处事的特殊风格，使管理者能够深入了解组织，而非仅仅停留在表面。 资讯传播特质。指组织部门和成员收集、分析和传递信息的分工与运作，促使管理者了解组织信息传递和沟通的特性。 问题六：在需求分析阶段常用的图形工具有哪三种 1. 需求分析是准确的理解用的需求将其转换成需求定义，然后由需求定义转换成形式化的功能规约。需求分析的困难表现在问题的复杂性、交流的障碍、不完备和不一致性、需求易变性。 2. 结构化分析方法是采用自顶向下逐层分解的分析策略把一个复杂的系统分解成若干小问题然后分别解决 3. 数据流即数据通过一个系统时的变化方式。输入数据首先转换成中间数据，然后转换成输出结果数据。在此期间可以从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能间的接口。 4. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。 5. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的子功能，这就属于纵向分解了。 6. 数据流图是用来表示系统的功能的工具它表示系统的逻辑模型描述了数据流在系统中流动的情况它是一种功能模型。 问题七：如何做需求分析 随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。 网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web 服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。 按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制： 1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务 需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。 （一）如何做好需求分析及变更管理？ 业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。 一：让客户畅所欲言，罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。 很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！ 二：透过现象分析潜在的需求 很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。 客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。 比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下......》》 问题八：软件需求分析的方法和工具有哪些内容 1. 问卷调查法， 开发方就用户需求中的一些个性化的、需要进一步明确的需求，通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决 2. 会议讨论法 ，开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法，这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握 3. 界面原型法 ，开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取

项目需求分析文档都包括哪些内容

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段包括：

1. 业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

2. 用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

3. 功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

4. 非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

5. 需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。