简述为什么要进行需求分析？需求分析的内容和主要步骤
1个回答
展开全部
简述为什么要进行需求分析？需求分析的内容和主要步骤
资料库需求分析阶段的主要任务：对现实世界要处理的物件（组织、部门、企业）等进行详细的调查，通过对原系统的了解，手机支援新系统的基础资料并对其进行处理，在此基础上确定新系统的功能。
系统分析报告的主要内容：1.系统概况，系统的目标、范围、背景、历史和现状；2.系统的原理和技术，对原系统的改善；3.系统总体结构域子系统结构说明；4.系统功能说明；5.资料处理概要、工程体制和设计阶段划分；6.系统方案及技术、经济、功能和操作上的可行性。
软体工程 中为什么要进行需求分析
不分析需求，怎么知道使用者要什么？
软体说白了是一种工鸡，工具就要按照使用者的要求和习惯来做。不能程式设计师自己想做什么就做什么
如何进行需求分析
专案需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的专案管理和专案分析能力；在具体的任务开展上，以不深入、不干扰承建方的自 *** 为主，除非在专案合作过程中发现承建方的专案管理以及专案分析能力存在很大的差距和不足。 为了保证专案的成功，监理方必须加强专案管理和专案分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。而专案的整体风险往往表现在需求分析不明确、业务流程不合理，使用者不习惯或不愿意去用承建方的软体。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握使用者的需求和方向，才能在将来的功能界定、开发范围上有发言权。 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解巨集观的问题，再了解细节的问题。 一个应用软体系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软体子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现介面。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解巨集观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可让程式设计师了解需求的本质，以便选用最合适的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 重点监控需求分析 由于专案的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软体需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网路建设时，客户方的办公人员大多不清楚计算机网路有什么用，更缺乏IT系统建设方面的专家和知识。此时，使用者就会要求软体系统分析人员替他们设想需求。工程的需求存在一定的主观性，为专案未来建设埋下了潜在的风险。 需求自身经常变动 根据以往的历史经验，随着客户方对资讯化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对专案的需求提出新的要求和需求变更。事实上，历史上没有一个软体的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软体的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。 分析人员或客户理解有误 软体系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作......
如何进行使用者需求分析
1.概念
需求的定义包括从使用者角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文件.我曾经目睹过一个专案中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文件,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白使用者的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"使用者所需要的并能触发一个程式或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于使用者的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从使用者需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,使用者并不能描述自己的需要,只就需要系统分析人员根据使用者的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有专案风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文件形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软体系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软体系统的介面.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立执行,它们之间介面是系统开发人员最头痛的问题.
对于商业终端使用者应用程式,企业资讯系统和软体作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文件,我们如何知道专案于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软体需求也是必须的.例如库、元件和工具这些供开发小组内部使用的软体.当然你可能偶尔勿需文件说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制程式码的代价远远超过重写一份需求文件的代价,这些血的教训正在国内的软体开发者身上发生.
近来,我遇到一个开发小组开发包括程式码编辑器在内的一套内部使用的计算机辅助软体.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出原始码档案,使用者当然希望有这个功能.结果这个小组只好手工抄写原始码文件以供程式码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文件,软体达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要整合到"错误跟踪系统"中的简单介面写了一页需求说明.而作业系统系统管理员在为处理指令码时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文件在开发过程中一直起指导作用.
3.需求分析过程
可把整个软体需求工程......
为什么要对企业员工培训进行需求分析
培训需求分析为企业培训工作提供了运作的基础，它是在企业培训需求调查的基础上，由培训部门、主管人员等相关工作人员采用各种方法与技术，对各种组织及其成员的目标、知识、技能等方面进行系统的鉴别与分析，以确定其是否需要培训及需要培训哪些内容的一种活动或过程。
（一）培训需求产生的原因
有效的培训需求分析是建立在对培训需求成因有效性的分析这一基础之上的，对培训需求形成的原因进行客观的分析直接关系到培训需求分析的针对性和实效性。培训需求产生的原因大致可以分为以下三类。
1．由于工作变化而产生的培训需求
企业处在不断发展变化的环境之中，不同岗位的工作内容也会相应地发生变化，为了适应这种变化，培训需求随之产生。
2．由于人员变化而产生的培训需求
无论员工原来从事何种工作，当他们进人一家新的企业或踏入新的工作领域时，为了尽快地进人工作状态，实现较好的工作业绩，培训都是他们的首要选择。
3．由于绩效变化而产生的培训需求
实现既定的或更优异的绩效是企业所希望的，但部分员工因各种原因，在其现有状况和应有的状况之间会存在一定的差距，由此也产生了相关的培训需求。
（二）培训需求分析的内容
培训的成功与否在很大程度上取决于需求分析的准确性和有效性。进行培训需求分析，除了以上对培训需求的形成原因的客观分析外，还要着重从培训需求的不同层面、不同方面、不同时期来进行培训需求分析。
1．培训需求的层次分析
（1）组织层面分析
培训需求的组织分析主要是通过对组织的目标、资源、特质、环境等因素的分析，准确地找出组织存在的问题与问题产生的根源，以确定培训是否是解决这类问题的最有效的方法。
由于企业是处于一定的社会环境中，随着政治、经济等因素的不断发展变化，企业发展的经营战略、组织所处的巨集观环境和发展趋势、组织现有的资源储备都会影响员工的培训需求。 （2）职务层面分析
工作分析的目的在于了解与绩效问题有关的工作的详细内容、标准以及完成工作所应具备的知识和技能。工作分析的结果也是将来设计和编制相关培训课程的重要资料来源。
通过对现有职务要求与担任此工作的员工的工作能力、工作绩效等方面进行比较，可以确定员工的培训需求。
（3）员工个人层面分析
员工个人分析主要是通过分析工作人员个体现有状况与应有状况之间的差距，来确定谁需要接受培训以及培训的内容。其分析的重点在于评价工作人员实际的工作绩效及工作能力。
2．培训需求的阶段分析
培训需求分析分为目前阶段培训需求分析和未来阶段培训需求分析。目前阶段培训需求分析是为了了解员工目前最需要培训的内容，以解决其目前的实际问题。未来阶段培训需求分析是为了了解员工未来一段时期所需的知识和技能，以便有计划、有针对性地对其进行培训。
三、如何进行培训需求分析
培训需求分析从层次上来划分，可以分为三个层面：组织层面分析、职务层面分析及员工个人层面分析。如何对每一个具体的层面进行需求分析？从哪些方面来进行需求分析？
（一）组织分析
1．组织目标分析明确、清晰的组织目标对组织的发展起著决定性、引领性的作用，同时也对培训规划的总体设计与实施起著决定性的作用。
2．组织资源分析
培训的实施需要有一定的人力、物力、财力等做基础。从财力上来说，组织提供的培训经费会影响到培训的范围、频率、执行力度等方面；从时间上来说，培训时间的合理安排是影响培训效果的重要因素之一；从人力方面来说，在培训需求分析过程、培训实施过程及培训评估过程中，......
在开发资料库系统时，为什么要做软体需求分析
只有做了软体需求分析，你才知道要建那些表，表结构是怎样的，表之间的关系是 怎样 的，知道了这些你才能做资料库系统设计
如何做好需求分析，需求调研
转载以下资料供参考
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
原因
需求分析就是分析软体使用者的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软体却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软体，最后却不满足使用者的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：使用者需要一个for linux的软体，而你在软体开发前期忽略了软体的执行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软体。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软体开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软体系统的开发中，他的作用要远远大于程式设计。
任务
简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解使用者的各项要求，并准确地表达所接受的使用者需求。
过程
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软体，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、效能需求(要达到什么指标)、环境需求(如机型、作业系统等)、可靠性需求(不发生故障的概率）、安全保密需求、使用者介面需求、资源使用需求(软体执行是所需的记忆体、CPU等)、软体成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软体功能，找出系统各元素间的联络，介面特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文件，描述需求的文件称为软体需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
方法
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软体的一个早期可执行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、介面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如演算法的可行性、技术的可行性或考察是否满足使用者的需求等。如：为了考察是否满足使用者的要求，可以用某些软体工具快速的建造一个原型系统，这个系统只是一个介面，然后听取使用者的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成......
网路工程为什么要进行需求分析
不进行需求分析，你怎么了解客户的需求，怎么给客户做网路规划，怎么给客户建设网路。
怎么做好一个需求分析师？
看看下面这个故事吧，也许看完了你就能明白了。。
先来看一个老掉牙的故事：福特说，我在设计汽车之前，到处去问人们“需要一个什么样的更好的交通工具？”，几乎所有人的答案都是 ── 一匹“更快的马”。
“更好的交通工具”代表使用者的“需求”；“更快的”是使用者对于解决这个“需求”的“期望值”；“马”是使用者对于解决这个“需求”的自假设“功能”。
一个初级的设计者，被使用者牵着鼻子走。听到“更快的马”以后，会马上去设计一匹“马”。这个时候，无论在“马”上如何做创新，思路已经框死，结果很难突破。最终只能出来平庸的设计，很难长久很容易被模仿和超越，实现不了多大的商业价值。
一个合格的设计者，和使用者一起走。听到“更快的马”以后，会考虑“更快的”这个“期望值”，围绕着它突破“马”的局限，去做设计。最终可能会出来很好的设计，但他们把“需求”本身抛到了脑后，最终只能简单的满足需求达到期望，而无法引导需求。他们绩以做出来成功的产品，但随着使用者期望的增长，这样的产品很 难有取得使用者的长久青睐，也很难取得商业上长久的成功。
一个卓越的设计者，自己会作为使用者的一部分深入了解他们，并带着使用者一起走。听到“更快的马”以后，他们会先去考虑需求是“更好的交通”工具，然后再结合 “更快的”这个主要期望。用对使用者最有价值的方式在的满足需求超越期望(把“马”这件事抛到脑后)，从而引导需求，并获取更丰厚更长久的商业利益，和使用者双赢。
不可否认，史玉柱是一个商业的天才。
他发现了“送礼”这个大需求，并发现了送礼的期望在于“面子”而非“ 实用”。于是他通过“广告”在推广的同时增加产品的“价值”，而非在产品质量上增加“价值”。春节，杭州人告诉我：“我们春节送礼都是送保健品，广告播什么就买什么，因为有 知名度”。但他忘记了，这样是否可以给使用者带来真正的长期价值。生活层次相对较高的行州人又告诉我“我们不买脑白金和黄金酒，那些都是骗人的档次低。我们买灵芝、鹿茸、人参、...”。
他发现了“砍人”的需求，并发现了“花再多钱也要砍死他”这个期望，最终使用了“网游”这个功能，用最简单粗暴的商业设计获取暴利。但他忘记了，这样做不能给人带来真正的价值，于是最后他在利用网际网路社群引导需求的时候遇到了问题 ...
福特是一个商业的天才，更是产品的天才。
他可以发现人们需要“更好的交通工具”这个大需求，并肯定了这个需求的渴望程度会随着社会交往的扩大会越来越强。同时他肯定了“更快的”这个使用者的首要期望，结合这个期望开始思考。然后，他又判断出汽车比火车有更低的成本，而且对于使用者更有价值，会替代火车。最后，他用“汽车”而不是“马”来满足需求、达到并超越期望， 同时引导使用者往下的进一步需求和期望... 于是，他的商业回报自然而然的产生了。
使用者的真正需求是什么？ 》 使用者的期望值是什么？ 》 如何做才对使用者最有价值，并让企业获利？ 》 如何超越期望并引导需求，获取更高更长久的商业利益？
这是一个必然思考逻辑，违背这个逻辑出来的产品势必难以获取长久的成功。从某种程度上来说，产品模式是“使用者真正需要的是什么？”，产品设计是“主要满足什么期望值，给使用者带去什么价值？”，商业模式是“用什么功能，如何赚钱？”，创新设计是“如何超越期望，获取更高更长久的利益？”。
所以，我在同意邵亦波所说“创业者更应该注重‘产品’”的同时，主张一个产品的主导者甚至是一个企业的领导者，更应该注重：
产品模式的设计：使用者真正需要满足的需求是什么？
产品的设计：让使用者达到什么样的期望？给他们带去什么价值？......
应该怎样开展需求分析
专案需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的专案管理和专案分析能力；在具体的任务开展上，以不深入、不干扰承建方的自 *** 为主，除非在专案合作过程中发现承建方的专案管理以及专案分析能力存在很大的差距和不足。 为了保证专案的成功，监理方必须加强专案管理和专案分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。而专案的整体风险往往表现在需求分析不明确、业务流程不合理，使用者不习惯或不愿意去用承建方的软体。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握使用者的需求和方向，才能在将来的功能界定、开发范围上有发言权。 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解巨集观的问题，再了解细节的问题。 一个应用软体系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软体子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现介面。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解巨集观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可让程式设计师了解需求的本质，以便选用最合适的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 重点监控需求分析 由于专案的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软体需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网路建设时，客户方的办公人员大多不清楚计算机网路有什么用，更缺乏IT系统建设方面的专家和知识。此时，使用者就会要求软体系统分析人员替他们设想需求。工程的需求存在一定的主观性，为专案未来建设埋下了潜在的风险。 需求自身经常变动 根据以往的历史经验，随着客户方对资讯化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对专案的需求提出新的要求和需求变更。事实上，历史上没有一个软体的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软体的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。 分析人员或客户理解有误 软体系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作......
资料库需求分析阶段的主要任务：对现实世界要处理的物件（组织、部门、企业）等进行详细的调查，通过对原系统的了解，手机支援新系统的基础资料并对其进行处理，在此基础上确定新系统的功能。
系统分析报告的主要内容：1.系统概况，系统的目标、范围、背景、历史和现状；2.系统的原理和技术，对原系统的改善；3.系统总体结构域子系统结构说明；4.系统功能说明；5.资料处理概要、工程体制和设计阶段划分；6.系统方案及技术、经济、功能和操作上的可行性。
软体工程 中为什么要进行需求分析
不分析需求，怎么知道使用者要什么？
软体说白了是一种工鸡，工具就要按照使用者的要求和习惯来做。不能程式设计师自己想做什么就做什么
如何进行需求分析
专案需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的专案管理和专案分析能力；在具体的任务开展上，以不深入、不干扰承建方的自 *** 为主，除非在专案合作过程中发现承建方的专案管理以及专案分析能力存在很大的差距和不足。 为了保证专案的成功，监理方必须加强专案管理和专案分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。而专案的整体风险往往表现在需求分析不明确、业务流程不合理，使用者不习惯或不愿意去用承建方的软体。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握使用者的需求和方向，才能在将来的功能界定、开发范围上有发言权。 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解巨集观的问题，再了解细节的问题。 一个应用软体系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软体子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现介面。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解巨集观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可让程式设计师了解需求的本质，以便选用最合适的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 重点监控需求分析 由于专案的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软体需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网路建设时，客户方的办公人员大多不清楚计算机网路有什么用，更缺乏IT系统建设方面的专家和知识。此时，使用者就会要求软体系统分析人员替他们设想需求。工程的需求存在一定的主观性，为专案未来建设埋下了潜在的风险。 需求自身经常变动 根据以往的历史经验，随着客户方对资讯化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对专案的需求提出新的要求和需求变更。事实上，历史上没有一个软体的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软体的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。 分析人员或客户理解有误 软体系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作......
如何进行使用者需求分析
1.概念
需求的定义包括从使用者角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文件.我曾经目睹过一个专案中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文件,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白使用者的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"使用者所需要的并能触发一个程式或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于使用者的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从使用者需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,使用者并不能描述自己的需要,只就需要系统分析人员根据使用者的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有专案风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文件形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软体系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软体系统的介面.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立执行,它们之间介面是系统开发人员最头痛的问题.
对于商业终端使用者应用程式,企业资讯系统和软体作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文件,我们如何知道专案于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软体需求也是必须的.例如库、元件和工具这些供开发小组内部使用的软体.当然你可能偶尔勿需文件说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制程式码的代价远远超过重写一份需求文件的代价,这些血的教训正在国内的软体开发者身上发生.
近来,我遇到一个开发小组开发包括程式码编辑器在内的一套内部使用的计算机辅助软体.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出原始码档案,使用者当然希望有这个功能.结果这个小组只好手工抄写原始码文件以供程式码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文件,软体达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要整合到"错误跟踪系统"中的简单介面写了一页需求说明.而作业系统系统管理员在为处理指令码时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文件在开发过程中一直起指导作用.
3.需求分析过程
可把整个软体需求工程......
为什么要对企业员工培训进行需求分析
培训需求分析为企业培训工作提供了运作的基础，它是在企业培训需求调查的基础上，由培训部门、主管人员等相关工作人员采用各种方法与技术，对各种组织及其成员的目标、知识、技能等方面进行系统的鉴别与分析，以确定其是否需要培训及需要培训哪些内容的一种活动或过程。
（一）培训需求产生的原因
有效的培训需求分析是建立在对培训需求成因有效性的分析这一基础之上的，对培训需求形成的原因进行客观的分析直接关系到培训需求分析的针对性和实效性。培训需求产生的原因大致可以分为以下三类。
1．由于工作变化而产生的培训需求
企业处在不断发展变化的环境之中，不同岗位的工作内容也会相应地发生变化，为了适应这种变化，培训需求随之产生。
2．由于人员变化而产生的培训需求
无论员工原来从事何种工作，当他们进人一家新的企业或踏入新的工作领域时，为了尽快地进人工作状态，实现较好的工作业绩，培训都是他们的首要选择。
3．由于绩效变化而产生的培训需求
实现既定的或更优异的绩效是企业所希望的，但部分员工因各种原因，在其现有状况和应有的状况之间会存在一定的差距，由此也产生了相关的培训需求。
（二）培训需求分析的内容
培训的成功与否在很大程度上取决于需求分析的准确性和有效性。进行培训需求分析，除了以上对培训需求的形成原因的客观分析外，还要着重从培训需求的不同层面、不同方面、不同时期来进行培训需求分析。
1．培训需求的层次分析
（1）组织层面分析
培训需求的组织分析主要是通过对组织的目标、资源、特质、环境等因素的分析，准确地找出组织存在的问题与问题产生的根源，以确定培训是否是解决这类问题的最有效的方法。
由于企业是处于一定的社会环境中，随着政治、经济等因素的不断发展变化，企业发展的经营战略、组织所处的巨集观环境和发展趋势、组织现有的资源储备都会影响员工的培训需求。 （2）职务层面分析
工作分析的目的在于了解与绩效问题有关的工作的详细内容、标准以及完成工作所应具备的知识和技能。工作分析的结果也是将来设计和编制相关培训课程的重要资料来源。
通过对现有职务要求与担任此工作的员工的工作能力、工作绩效等方面进行比较，可以确定员工的培训需求。
（3）员工个人层面分析
员工个人分析主要是通过分析工作人员个体现有状况与应有状况之间的差距，来确定谁需要接受培训以及培训的内容。其分析的重点在于评价工作人员实际的工作绩效及工作能力。
2．培训需求的阶段分析
培训需求分析分为目前阶段培训需求分析和未来阶段培训需求分析。目前阶段培训需求分析是为了了解员工目前最需要培训的内容，以解决其目前的实际问题。未来阶段培训需求分析是为了了解员工未来一段时期所需的知识和技能，以便有计划、有针对性地对其进行培训。
三、如何进行培训需求分析
培训需求分析从层次上来划分，可以分为三个层面：组织层面分析、职务层面分析及员工个人层面分析。如何对每一个具体的层面进行需求分析？从哪些方面来进行需求分析？
（一）组织分析
1．组织目标分析明确、清晰的组织目标对组织的发展起著决定性、引领性的作用，同时也对培训规划的总体设计与实施起著决定性的作用。
2．组织资源分析
培训的实施需要有一定的人力、物力、财力等做基础。从财力上来说，组织提供的培训经费会影响到培训的范围、频率、执行力度等方面；从时间上来说，培训时间的合理安排是影响培训效果的重要因素之一；从人力方面来说，在培训需求分析过程、培训实施过程及培训评估过程中，......
在开发资料库系统时，为什么要做软体需求分析
只有做了软体需求分析，你才知道要建那些表，表结构是怎样的，表之间的关系是 怎样 的，知道了这些你才能做资料库系统设计
如何做好需求分析，需求调研
转载以下资料供参考
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
原因
需求分析就是分析软体使用者的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软体却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软体，最后却不满足使用者的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：使用者需要一个for linux的软体，而你在软体开发前期忽略了软体的执行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软体。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软体开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软体系统的开发中，他的作用要远远大于程式设计。
任务
简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解使用者的各项要求，并准确地表达所接受的使用者需求。
过程
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软体，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、效能需求(要达到什么指标)、环境需求(如机型、作业系统等)、可靠性需求(不发生故障的概率）、安全保密需求、使用者介面需求、资源使用需求(软体执行是所需的记忆体、CPU等)、软体成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软体功能，找出系统各元素间的联络，介面特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文件，描述需求的文件称为软体需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
方法
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软体的一个早期可执行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、介面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如演算法的可行性、技术的可行性或考察是否满足使用者的需求等。如：为了考察是否满足使用者的要求，可以用某些软体工具快速的建造一个原型系统，这个系统只是一个介面，然后听取使用者的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成......
网路工程为什么要进行需求分析
不进行需求分析，你怎么了解客户的需求，怎么给客户做网路规划，怎么给客户建设网路。
怎么做好一个需求分析师？
看看下面这个故事吧，也许看完了你就能明白了。。
先来看一个老掉牙的故事：福特说，我在设计汽车之前，到处去问人们“需要一个什么样的更好的交通工具？”，几乎所有人的答案都是 ── 一匹“更快的马”。
“更好的交通工具”代表使用者的“需求”；“更快的”是使用者对于解决这个“需求”的“期望值”；“马”是使用者对于解决这个“需求”的自假设“功能”。
一个初级的设计者，被使用者牵着鼻子走。听到“更快的马”以后，会马上去设计一匹“马”。这个时候，无论在“马”上如何做创新，思路已经框死，结果很难突破。最终只能出来平庸的设计，很难长久很容易被模仿和超越，实现不了多大的商业价值。
一个合格的设计者，和使用者一起走。听到“更快的马”以后，会考虑“更快的”这个“期望值”，围绕着它突破“马”的局限，去做设计。最终可能会出来很好的设计，但他们把“需求”本身抛到了脑后，最终只能简单的满足需求达到期望，而无法引导需求。他们绩以做出来成功的产品，但随着使用者期望的增长，这样的产品很 难有取得使用者的长久青睐，也很难取得商业上长久的成功。
一个卓越的设计者，自己会作为使用者的一部分深入了解他们，并带着使用者一起走。听到“更快的马”以后，他们会先去考虑需求是“更好的交通”工具，然后再结合 “更快的”这个主要期望。用对使用者最有价值的方式在的满足需求超越期望(把“马”这件事抛到脑后)，从而引导需求，并获取更丰厚更长久的商业利益，和使用者双赢。
不可否认，史玉柱是一个商业的天才。
他发现了“送礼”这个大需求，并发现了送礼的期望在于“面子”而非“ 实用”。于是他通过“广告”在推广的同时增加产品的“价值”，而非在产品质量上增加“价值”。春节，杭州人告诉我：“我们春节送礼都是送保健品，广告播什么就买什么，因为有 知名度”。但他忘记了，这样是否可以给使用者带来真正的长期价值。生活层次相对较高的行州人又告诉我“我们不买脑白金和黄金酒，那些都是骗人的档次低。我们买灵芝、鹿茸、人参、...”。
他发现了“砍人”的需求，并发现了“花再多钱也要砍死他”这个期望，最终使用了“网游”这个功能，用最简单粗暴的商业设计获取暴利。但他忘记了，这样做不能给人带来真正的价值，于是最后他在利用网际网路社群引导需求的时候遇到了问题 ...
福特是一个商业的天才，更是产品的天才。
他可以发现人们需要“更好的交通工具”这个大需求，并肯定了这个需求的渴望程度会随着社会交往的扩大会越来越强。同时他肯定了“更快的”这个使用者的首要期望，结合这个期望开始思考。然后，他又判断出汽车比火车有更低的成本，而且对于使用者更有价值，会替代火车。最后，他用“汽车”而不是“马”来满足需求、达到并超越期望， 同时引导使用者往下的进一步需求和期望... 于是，他的商业回报自然而然的产生了。
使用者的真正需求是什么？ 》 使用者的期望值是什么？ 》 如何做才对使用者最有价值，并让企业获利？ 》 如何超越期望并引导需求，获取更高更长久的商业利益？
这是一个必然思考逻辑，违背这个逻辑出来的产品势必难以获取长久的成功。从某种程度上来说，产品模式是“使用者真正需要的是什么？”，产品设计是“主要满足什么期望值，给使用者带去什么价值？”，商业模式是“用什么功能，如何赚钱？”，创新设计是“如何超越期望，获取更高更长久的利益？”。
所以，我在同意邵亦波所说“创业者更应该注重‘产品’”的同时，主张一个产品的主导者甚至是一个企业的领导者，更应该注重：
产品模式的设计：使用者真正需要满足的需求是什么？
产品的设计：让使用者达到什么样的期望？给他们带去什么价值？......
应该怎样开展需求分析
专案需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的专案管理和专案分析能力；在具体的任务开展上，以不深入、不干扰承建方的自 *** 为主，除非在专案合作过程中发现承建方的专案管理以及专案分析能力存在很大的差距和不足。 为了保证专案的成功，监理方必须加强专案管理和专案分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个专案的开端，也是专案建设的基石。在以往建设失败的专案中，80％是由于需求分析的不明确而造成的。因此一个专案成功的关键因素之一，就是对需求分析的把握程度。而专案的整体风险往往表现在需求分析不明确、业务流程不合理，使用者不习惯或不愿意去用承建方的软体。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握使用者的需求和方向，才能在将来的功能界定、开发范围上有发言权。 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解巨集观的问题，再了解细节的问题。 一个应用软体系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软体子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现介面。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解巨集观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可让程式设计师了解需求的本质，以便选用最合适的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 重点监控需求分析 由于专案的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软体需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网路建设时，客户方的办公人员大多不清楚计算机网路有什么用，更缺乏IT系统建设方面的专家和知识。此时，使用者就会要求软体系统分析人员替他们设想需求。工程的需求存在一定的主观性，为专案未来建设埋下了潜在的风险。 需求自身经常变动 根据以往的历史经验，随着客户方对资讯化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对专案的需求提出新的要求和需求变更。事实上，历史上没有一个软体的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软体的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。 分析人员或客户理解有误 软体系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作......
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
