需求分析面试

需求分析面试用时可以删除你为什么干这一行，而不干其他行当呢你一生中做出的最有意义的决定是什么那个决定为什么有意义那个决定是怎样做出来的当你要决定是否试做全新的事情时，你对成功的把握性有多大在你的前任工作中，你根据什么标准决定是否做些不属于你工作任务的任务项目你为什么在事业的这个阶段决定寻找新的机会假设你想要给自己找一位助手，有两位候选人，你怎样决定聘用哪一个呢假如另一部门的某位员工经常来打扰你部门员工的工作，你有哪些办法可以解决这个问题你会选择哪个办法为什么综合分析能力面试题沙漠救生记汤老师，我面试的时候遇到这样一道题：沙漠中遇难，有四样东西，帐篷，两瓶水，绳子，刀。只能选择其中三样带走，你选择哪三样，并把每种选择都给分析一下。请问该怎么选择答案：，如果用对个人进行测试，通常是要测试求职者的综合分析能力。题目本身逐一对所有的东西进行分析，最后，汇总自己的分析，选择最有利于救备时间要远远大于正式会面沟通的时间。一般情况下，用户在和你连续交谈熟悉的准备工作和对具体业务进行调研前的准备工作。项目整体环境的目的目的、项目的利益相关方等信息，以便对当前项目的鹰钵情况有准备工作包括:需求调研问题的准备、需求调研模板的设计、需求调研时间安排等2主动积极了解客户业务和相关知识有哪些功能。笔者曾在经销商管理系统调研过程中，由于财务方面的知识有限，使得在对经销商财务部门识是无边无际的，在各种项目的调研过程中，肯定会出现由于需求分析者缺乏某一领域的知识而影响需求遇到此类问题时，需求分析者应虚心向用户请教，同时应及时补充应用领域的知识。最好能够在调研3对用户进行正确分类项目管理培训组织中的用户在很多方面存在差异，例如:使用系统的频度和程度、计算机系统知识、所进行的业务过不同的问题需要询问不同的人，对于操作细节的问题，要和实际负责操作的用户进行沟通，而对于关主、发货理货员、系统操作员。主要业务执行人;系统操作员则是仓库管理系统的直接操作者。若我们调研的目的是搞清该部门的整体性流程，我们会很自然地选择仓库主管作为访谈的对象。项目经理圈子引导用户说出他们的需求是非常关键的。恰当的提问，会使用户滔滔不绝，充恰当的提问，可能会导致用户无法回答或敷衍了事地进行回答。提问可分。如:现在你们的送货单是手工填写还是电脑打印但过多使用封闭式提问，会导致自己好像在接受审问。开放式提问是请对方对某一事物做进一步的解释，可使谈话以改进的地方开放式提问缺点是容易使谈话内容偏离主题。因此在5应实地了解用户工作流程项目管理论坛实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据，并怎样使用这些数据，业务处经验证明，与人们面谈关于他们如何完成任务时会有许多限制和不准确性，而这是任务观察可以直接一个主观的领域，很大程度上依赖于需求分析者的经验。通过观察发现:某些客户要求送货单中的商品价格为含税价格，而有些客户则要求送货单上的商品价格可行性这样的事也不干。”柳传志为联想集团的决策确立了上述准则，同时也为可以行性分析指明了重点。可行性分析主要是针需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。如在笔者曾经负责的一个项目中，用户要求新的管理系统应实现和用友、金蝶等管理系统的数据接口，以方便这些系的管理系统。统的数据接口，将为新系统的成功实施带来很大的风险。因为熟悉这些系也需要时间，而且用友、金蝶等这些系统存在多个不同的版本。因此与外否具有相应的素质和能力。在实际项目中，笔者曾对快速消费品行业经了分析。首先，批次管理将涉及到所有产品的出入库操作，并存在一个产品有管理对操作人员的能力和素质要求比较高。点决定了产品的出入库操作极为频繁，因此，操作人员的工作强度比较性定义为低。定需求的优先级别冲突、安排阶段性交付并做出必要的取舍。建立每个需求的重要性有助于规划软件的构造，以最少的费用并且交付日期不可改变，一些低优先级的需求就需要推迟到后续版本中进行实现或直接取消。当众多用户因期望不同而就某些需求优先级的设定难以达成一致意见时，需求分析者可指出每一需求8正确理解需求分析文档确认需求分析是一项繁琐枯燥的工作，需要和用户不断的商讨、确认和反复。但大部分用户并不只做这项用库存十分关注，因此可用库存的优先级被定义为:高优先级。仔细考虑或回答你的问题。这很容易使你错误地认为用户已经真正地了解并认可了你的分析文档。确认工作并未得到用户的充分重视。“他们要求我在需求文档上签名，于是我就签了，否则开发人员不开对于需要用户确认的需求分析文档，最好在用户确认前，就文档内容对用户进行一定的讲解，以确保对文档中的内容存在修改意见，则修改后再与用户进行确认，直至用户完全认可文档中的内容为止。、准确的理解，需求分析所包含的内容通常大于项目范围所包含的内容。因些功能的讨论并不意味着即将在系统中实现它。应使用户明白对需求分析文档的句号，并有助于形成一个持续良好的用户与需9结语将知识从一个地方传送到另一个地方并不是一件简单的事情，而且原始的需求通常是以不完整的形式认等方面对需求分析中应注意的主要问题进行了研究分析。同时需求分析工作者也应在日常工作中加强学习，不断总结，使自己的需求分析能力得到不断的提业务需求访谈中需要注意的重要法则(转)功能和局限性。系统需求肯定不是生来求分析员的脑海中，那么业务需要又在哪里呢它它存在与企业实践运作体系中。或者说它们并不一定于通过包括业务需求访谈在内的各种方法使系统知识迁移过程,通过业务需求访谈需求分析员最终完,是做好了“准备”,假设王五是某家贸易公工作职责是对公司已有的订单管理系统进行改进,为此结构图,我们得知业务部门通常地认识,我们会发现所谓主管，即总是对搞清业务部门接着,我们要确定访谈时间。主管一般都是比较忙的,他不会时时都在等你。因此,现在,我们只剩下一个访谈的内容需要准备了。我们可以拟定一些具体问题，这很有必要。“凡事预则立”,这是先贤站在哲学的高度对我们的启示。由于篇幅所限就不在此一一列明,可以在相关资料上找到很般而言有两种方法。第一,选择工作角色，比如从业务主线入手，召集这条线上的角色。很显然，前入见点不见主线的陷阱。也就是说这个角色的主主线，你必须心知肚明。否则，访谈活动就变成的业务访谈者是访谈游戏的规则制定者，他必须错误。假设他也已完成了第一次对业务主管的访谈工作,用应用联席会议的方式做为业务访谈的一种有效这条业务主线上的每个角色比如,王五所在的贸易的订单业务主线一般流程为：接订单->购->入库->收款。那么，他应该做出相应的访谈路线图。这样,他访谈过程中我们要保持理性，自始至终以我为主,牢牢掌握访谈的主动权。因为优秀的需求分析员应该是有理性的人,我们不能因为被访谈对象的情绪便打乱了计划很可能损害到他的潜在利益,他会变得情绪化,会找些借口,比经常以“这是某某习惯”作答，那么你必须意识到这不是真实的答案，并且可以这样谈下去才能谈得更深入。一个好的分析访谈人员能够从表面挖掘出背后的够引导对方,达到既定的访谈目标。4、访谈过程中要善于寻求异常和错误情况。谈对象的话总是对的，他经常会说“应该”或者“可能”是这样只有这样你才能挖掘到更多的业务细节。多问问“如果条件没，在于能否更深入地探讨业务需求问唯唯诺诺的人,如果用户说什么你都只会说“是”,则意味着访谈应户说什么,你首先要分析,然后置疑,从所在。其实也需要耐心,我们觉得可以向优秀的5、业务需求访谈要搞清“4W1H”。WH”。6、业务需求访谈要深入调查细节。现代系统分析员重要责任是调查系统需求细节，而细节不会凭空出现的，而是，也要知道“如果不这样那会是怎样”。做需求下结论前要事先调查和掌握好所有正反两个方向的商业细节，如此以来需求分析结论和解决方案才有现实可行性。这里有一个很好的实例，一般而言，物料编码都是系统自动提供规则实现的，而某贸易公司的订单系统偏偏不提供系统自编码。面对此问题，我们必须搞清两个问题：其一是该企业的编码规则，其二是该企业的编码规则牵涉到的前置条件和后置条件。知其然也知其。所以说仅仅满足于看到了业务现象是远远不够的,我们更要搞清楚现象背后的原因,我们还要有能力能够提供诸多方案以解释和改造目层层发问法也是深入调查而经常采用到的方法。8、时刻要记得的四个字"胆大心细"一旦本次访谈结束，有必要回去做一番总结，不仅要总结出提炼的需求结论，更重要的是要回忆还原出整个访谈过程，以便事后仔细研摩得失，这对提高业盘过程也是一丝不苟，好的需求分析员亦然。仁。仁图，并的措施是事先编制一个问卷调查之类的文免这种情况发生。e都要让客户明白和理解，客户在理解之旦出现问题不致出现双方互相推托责任纠缠不清的f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来g能够在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，毕竟功能性需求不实现的的变更,而且许多是看起来无关痛痒(1)什么是非功能性需求户需求、功能需求、行业隐含需客户对系统、产品高层次须实现的软件功能。所谓而必须具有除功能需求以护性、易用性和对技术和面、操作方便等一系列要(2)非功能性需求变更的特点求的特点。首大，但是实际的。原因是非功能那样，可以通过结构化和时候，我们经常采用软件美观大方等较模糊的描述词类描述词语都是脱离了软的描述，因此很难体现到软件为什么非功能性需求变更会频繁发生了呢通常客户时，他可能就(1)非功能性需求容易产生理解分歧发人员对非功能性需求的理解呈现"一般跟分析员的知识、背。即使通过反是永远不够清还只存在于大他所需要的软件在当前的工作所需，或者是求分析人员提出需求的时表达的，这样的表达结果断进展，系统开始展现雏时候，客户就会对系统的就有可能提出需求变更要为的因素。总之，他们了(2)没有明确的需求变更管理流程更不要一味的抱怨，也不和控制需求变更。但令执行常常只停留在口无论是当事人还是开和开发质量。变更都要立刻修改，更需要修改和什么时或者规划一下修改(3)没有让客户知道需求变更的代价根本原因。变更都是有代了解需求变更的后果。如发人员的辛苦就会难以体更认识不足，认为他此，客户对需求变更往往，随个人喜好随意变更需求。所是要让他们清楚需求随意代价太大，那么开发人员但仍要记录变更，待下一如何有效控制非功能性需求的变更影响面是很广的。因容小视的事情。(1)建立明确的非功能性需求基线性需求基线是一件重要的围就含糊不清，就容易被更。如果非功能性需求基么后期客户提出的非功能需求基线的时候千万不能让客户养成经常变更的习(2)建立需求变更管理流程的不是控制变更