|
1. 在需求分析中有哪些问题需要注意？ 2. 你是如何理解需求分析这个职位的？ 1.进行管理软件项目的需求分析工作; 2.项目规划，项目交流，售前咨询和方案设计工作; 在这种情况下需要给自己和其他人留出一个定义需求的时间，同时尽量清晰地定义项目各方的工作范围和利益关系，确认项目的阶段性成果。否则项目即便启动了，也有可能会没完没了地拖下去。 良好的沟通能力，对于不懂软件的其他行业客户能够迅速沟通，获取用户的想法、目的；同时对内沟通，让内部的开发人员、项目经理理解用户想要的东西。 业务基础和理解能力,你应该对你们的产品和用户的行业都有比较深刻的理解，才能迅速的找到客户和公司项目、产品的结合点； 开发成本的评估，用户可能觉得很神奇的事情可能对开发很简单，客户觉得简单的事情也可能对开发是个悲剧。能够合理的引导用户需求，在前期规避项目风险； 还有就是文档能力、业务建模能力了
3. 如何应对客户多变的需求? 延展咨询作为一个新型的咨询实施一体化的公司，我们的宗旨是给客户提供最优化的解决方案，我们对待客户提出的需求都会从客户需求的本质去解决问题，不会仅仅从表象去满足客户需求，实际上我们解决客户问题的过程中，包含了我们的智慧和管理经验，所以，这个就是延展咨询实施一体化的本意。我们不是坚决不改程序，也不是客户说什么我们做什么，我们是和客户一起寻求解决方案。所以，我们做实施和一般软件公司和咨询顾问公司都是不一样的。我们是通过我们的管理智慧，融入到我们给客户提供的软件系统中，并且陪着客户一起把最佳解决方案找到，这样我们就最终解决了客户需求。 4. 自己的优缺点？ 为什么要应聘这个工作 觉得自己的优势在哪里等? 很多个，印象最深的是你觉得项目管理什么过程最考验项目经理? 1. 人员与时间管理 2. 风险与质量控制 3. 人事与公关处理
你觉得你在解决问题时凭逻辑推理还是仅凭感觉？请根据你以前的工作经历来谈谈你的体会。 举一个过去的例子说明，在做出决定时，必须进行认真分析、周密考虑。请说说你做决定的过程。 如果我们让你干这个职位的话，你怎样决定是否接受这个工作呢？ 你为什么干这一行，而不干其他行当呢？ 你一生中做出的最有意义的决定是什么？那个决定为什么有意义？那个决定是怎样做出来的？ 当你要决定是否试做全新的事情时，你对成功的把握性有多大？ 在你的前任工作中，你根据什么标准决定是否做些不属于你工作任务的任务项目？ 你为什么在事业的这个阶段决定寻找新的机会？ 假设你想要给自己找一位助手，有两位候选人，你怎样决定聘用哪一个呢？ 假如另一部门的某位员工经常来打扰你部门员工的工作，你有哪些办法可以解决这个问题？你会选择哪个办法？为什么？
综合分析能力面试题 沙漠救生记 汤老师，我面试的时候遇到这样一道题：沙漠中遇难，有四样东西，帐篷，两瓶水，绳子，刀。只能选择其中三样带走，你选择哪三样，并把每种选择都给分析一下。请问该怎么选择？ 答案： 这种问题通常用于小组讨论，如果用对个人进行测试，通常是要测试求职者的综合分析能力。题目本身没有绝对正确的答案，最重要地是逐一对所有的东西进行分析，最后，汇总自己的分析，选择最有利于救生的工具。
只要把每样东西进行分析，并做出自己的选择，条理、逻辑清楚就行。 本文来自中国范文网(www.)，原文地址：http://www./18414.html
怎么写需求文档？
1 与用户沟通前应进行充
通常，与用户沟通前的准备时间要远远大于正式会面沟通的时间。一般情况下，用户在和你连续交谈两个小时之后，就会失去热情和耐心，这是大部分人的共同特点。所以充分的准备工作至关重要。 准备工作包括对项目整体环境熟悉的准备工作和对具体业务进行调研前的准备工作。项目整体环境的熟悉工作需要了解:项目的背景、项目的目的、项目的利益相关方等信息，以便对当前项目的鹰钵情况有一定了解。项目经理博客 对具体业务调研前的准备工作包括:需求调研问题的准备、需求调研模板的设计、需求调研时间安排等内容。要充分珍视用户的时间，尽量避免由于准备工作不足而反复约见用户，给用户造成效率低下的印象。一旦发生这样的错误，以后可能就会很难约见到用户。 2 主动积极了解客户业务和相关知识
在计算机技术方面我们可能非常专业，但对于具体的用户业务可能并不十分清楚。这个项目对用户是否有帮助、某一系统功能是否有用、某一流程处理是否合理，在不了解用户业务的情况下，我们将很难做出判断。 因此只有在了解业务的基础上，我们才和用户有共同的沟通语言和业务理解，才能真正理解系统应具有哪些功能。笔者曾在经销商管理系统调研过程中，由于财务方面的知识有限，使得在对经销商财务部门的调研中对部分问题不是特别的理解。 当时，笔者向用户虚心进行请教，并在调研结束后及时对自己的财务知识进行了补充。应用领域的知识是无边无际的，在各种项目的调研过程中，肯定会出现由于需求分析者缺乏某一领域的知识而影响需求分析工作的准确、顺利进行。 遇到此类问题时，需求分析者应虚心向用户请教，同时应及时补充应用领域的知识。最好能够在调研前做好充分的准备。 3 对用户进行正确分类项目管理培训
组织中的用户在很多方面存在差异，例如:使用系统的频度和程度、计算机系统知识、所进行的业务过程以及个人的素质和喜好等。根据用户的特点，可对用户进行一定的分类。将用户分类并归纳各自特点，详细描述他们的个性特点及任务状况，将有助于需求的获取和分析。 不同的问题需要询问不同的人，对于操作细节的问题，要和实际负责操作的用户进行沟通，而对于关乎全局的问题，则要和相应的管理层用户进行沟通。如通过组织架构图得知仓库部门有三种角色:仓库主管、发货理货员、系统操作员。 我们发现仓库主管是对全盘业务相当熟悉的人，他负责协调本部门的全局事务;而发货理货员是部门的主要业务执行人;系统操作员则是仓库管理系统的直接操作者。若我们调研的目的是搞清该部门的整体性流程，我们会很自然地选择仓库主管作为访谈的对象。项目经理圈子 4 引导用户，使用户充分表达自己的想法
在与用户交谈中，如何引导用户说出他们的需求是非常关键的。恰当的提问，会使用户滔滔不绝，充分发表自己的意见和建议。而不恰当的提问，可能会导致用户无法回答或敷衍了事地进行回答。提问可分为封闭式提问和开放式提问。 封闭式提问目的明确。如:现在你们的送货单是手工填写还是电脑打印?但过多使用封闭式提问，会导致谈话枯燥，让用户感觉自己好像在接受审问。开放式提问是请对方对某一事物做进一步的解释，可使谈话达到一定的深度和广度。 如:你认为目前的工作中存在哪些可以改进的地方?开放式提问缺点是容易使谈话内容偏离主题。因此在谈话过程中，应采用封闭式和开放式提问相结合的方式。以简单问题开始、从用户熟悉的内容开始。每次只提一个问题、集中一个重点，宁问勿猜。 并尽量避免使用IT相关的一些术语，以便用户能够很好地理解我们的表达。 5 应实地了解用户工作流程项目管理论坛
实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据，并怎样使用这些数据，业务处理 过程中需要处理哪些单据，需要和哪些角色的用户发生关联等。这都将有助于明确产品的功能需求。 经验证明，与人们面谈关于他们如何完成任务时会有许多限制和不准确性，而这是任务观察可以直接解决的。特别是对于某些组织中普遍接受的规则和方法，用户认为你也应理所当然知道，而不曾提起时。 近年来，由于人机交互的复杂性惊人地增加，人机交互的观察和记录已引起人们的广泛注意。观察是一个主观的领域，很大程度上依赖于需求分析者的经验。 通过观察发现:某些客户要求送货单中的商品价格为含税价格，而有些客户则要求送货单上的商品价格为不含税价格;有些商品的税率为13%，而有的商品税率为17%; 有些客户要求送货单上的金额小数点后保留四位，有的客户又要求送货单上必须提供自己公司的商品编码等。而这些都是在调研中，用户不曾提起的内容。 6 分析需求可行性
柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选，这样的事也不干。” 柳传志为联想集团的决策确立了上述准则，同时也为可以行性分析指明了重点。可行性分析主要是针对某一需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。 许诺提供与用友、金蝶等系统的数据接口，将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间，开发与它们的接口也需要时间，而且用友、金蝶等这些系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。 人的方面主要考虑目标用户是否具有相应的素质和能力。在实际项目中，笔者曾对快速消费品行业经销商批次管理的可行性进行了分析。首先，批次管理将涉及到所有产品的出入库操作，并存在一个产品有多个批次的情况，因此批次管理对操作人员的能力和素质要求比较高。 其次，快速消费品行业的特点决定了产品的出入库操作极为频繁，因此，操作人员的工作强度比较大。再次，大部分经销商的仓库所在地都距离城镇比较远，因此工作人员的文化水平普遍不高。在综合考虑后，将批次管理的可行性定义为低。 对于复杂的项目，还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。 7 确定需求的优先级别
当客户的期望很高、开发时间很短且资源有限时，设定需求的相对优先级将有助于项目管理人员解决冲突、安排阶段性交付并做出必要的取舍。建立每个需求的重要性有助于规划软件的构造，以最少的费用提供产品的最大功能。 特别是对渐进式的项目，优先级的设定就显得更为重要，因为在这些开发中，项目时间安排极为紧迫并且交付日期不可改变，一些低优先级的需求就需要推迟到后续版本中进行实现或直接取消。 当众多用户因期望不同而就某些需求优先级的设定难以达成一致意见时，需求分析者可指出每一需求所需的费用、难度、技术风险或其他特定的与权衡需求有关的指标，来客观评价每一需求的优先级。 8 正确理解需求分析文档确认
需求分析是一项繁琐枯燥的工作，需要和用户不断的商讨、确认和反复。但大部分用户并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心在笔者曾负责的经销商管理系统中，经销商认为，库存过高将占用企业运转资金，增加企业负担; 库存过低则无法满足客户订单，从而导致交货周期延长，降低企业市场竞争力。由于经销商对当前可用库存十分关注，因此可用库存的优先级被定义为:高优先级。仔细考虑或回答你的问题。这很容易使你错误地认为用户已经真正地了解并认可了你的分析文档。 在需求分析文档上签字确认，通常被认为是用户同意需求分析内容的标志行为。而实际操作中，签字确认工作并未得到用户的充分重视。“他们要求我在需求文档上签名，于是我就签了，否则开发人员不开始编码。”用户的这种态度将可能给项目带来潜在的风险，如不断地进行需求变更等。 对于需要用户确认的需求分析文档，最好在用户确认前，就文档内容对用户进行一定的讲解，以确保用户完全理解并认可文档中的内容。若用户对文档中的内容存在修改意见，则修改后再与用户进行确认，直至用户完全认可文档中的内容为止。 通常为对项目有一个整体、准确的理解，需求分析所包含的内容通常大于项目范围所包含的内容。因此，应让用户理解对于某些功能的讨论并不意味着即将在系统中实现它。应使用户明白对需求分析文档的签字确认是建立一个需求的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。 需求确认将给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的用户与需求分析人员的关系，为项目的成功奠定坚实的基础。 9 结语
将知识从一个地方传送到另一个地方并不是一件简单的事情，而且原始的需求通常是以不完整的形式呈现的。它也许只是在某个现有系统的用户脑中，甚至有时用户都没有意识到他们知道什么。本文从引导用户、需求确认等方面对需求分析中应注意的主要问题进行了研究分析。 同时需求分析工作者也应在日常工作中加强学习，不断总结，使自己的需求分析能力得到不断的提升。 毫无疑问, 任何企业信息化项目启动的源头来自于系统业务需求调研，业务需求调研在软件工程价值链中处于首当其冲的位置,做好业务需求调研对于项目成败的重要性是不言而喻的。而如何做好业务需求调研却又不是件容易的事，因为它既是门科学更是门艺术，更需要长期的经验积累。 业务需求调研的方法多样，通常包括复查原有的表格和描述、主持与用户的业务访谈、原型建立、分发收集调查表、研究供应商的解决方案等方法。 而其中的业务需求访谈是一门被证明形之有效的技术和方法，然而怎样做好它，对有效的获得和分析业务需求均起着至关重要的作用。我们应当像重视软件开发过程那样关注管理业务访谈的过程和法则,做到“访谈前有准备,访谈时有效果,访谈后有总结”。如此一来,我们的需求访谈工作才能进入良性循环,我们的软件开发才能有保障。 正如人类发展历史蕴含着隐含的潜规则，业务需求访谈亦有其内在的法则所在，本文旨在挖掘这些规则以期同仁在业务需求访谈工作中有所参照和收获。 1、业务需求访谈前要从内容和目标上做好精心准备。 我们知道系统需求是新系统必须完成的功能和局限性。系统需求肯定不是生来就有的，也不是天生就存在需求分析员的脑海中，那么业务需要又在哪里呢？它存在于业务人员的脑海里,它存在与企业实践运作体系中。或者说它们并不一定存在，需求分析员的职责就在于通过包括业务需求访谈在内的各种方法使系统需求得以显示它清晰的本来面目。 业务需求访谈本质上是一种知识迁移过程,通过业务需求访谈需求分析员最终完成了从业务到需求的迁移。 既然业务需求访谈有如此的特点，就注定了我们必须对其有所准备。一般而言,我们应对访谈的目标和内容有专门策划,做到有备而来。 现在让我们举例说明应该如何做才能算是做好了“准备” ,假设王五是某家贸易公司的新任需求分析员,它的工作职责是对公司已有的订单管理系统进行改进,为此他将对公司的业务部门做一场业务访谈。 首先,我们应该确定访谈的对象。通过企业的组织结构图,我们得知业务部门通常有三种角色,即业务主管、业务、助理。 那么王五应该选择谁做第一次访谈的对象呢?我们有必要对每种角色作一番深入地认识, 我们会发现所谓主管，即总是对全盘业务相当熟悉的人,他负责协调部门全局；而业务是部门的主要业务执行人；助理则是管理系统的直接操作者。联想到本次访谈的使命是搞清业务部门的整体性流程,我们会很自然地选择主管作为本次访谈的对象。 接着,我们要确定访谈时间。主管一般都是比较忙的,他不会时时都在等你。因此,王五提前预约他,电话和登门拜访都是很好的办法。等他应约之后,协商一个确定的时间，再进入深层次的访谈也显得合情合理。 现在,我们只剩下一个访谈的内容需要准备了。我们可以拟定一些具体问题，这些问题越具体越好。最好打印出一份清单,这样访问过程可以按部就班地进行。当然,也学会有人认为不就是一场会谈嘛,何必搞得像晚会节目单一样? 但我们认为这实际上很有必要。“凡事预则立”,这是先贤站在哲学的高度对我们的启示。 王五访谈的具体问题由于篇幅所限就不在此一一列明,可以在相关资料上找到很好的答案。 2、选择访谈对象须由线及点，由点入线。 这是个选择访谈对象的问题，一般而言有两种方法。第一,选择工作角色，比如业务员、销售助理。第二,从业务主线入手，召集这条线上的角色。很显然，前一种方法容易实施，但容易陷入见点不见主线的陷阱。也就是说这个角色的主要工作职责是服务于哪条业务主线，你必须心知肚明。否则，访谈活动就变成了摸着石头过河了。一个成功的业务访谈者是访谈游戏的规则制定者，他必须知道他的对象链并心中有数。这样做访谈才不会跑题，才不会犯方向性错误。 我们仍然以上面的王五为例, 假设他也已完成了第一次对业务主管的访谈工作,下面他该如何把访谈进行到底呢? 按照点线原则,我们可以安排他对相关业务员和业务助理做访谈,由于这几个人的工作有相关联系性,我们可以采用应用联席会议的方式做为业务访谈的一种有效补充。事实上, 业务访谈和其他需求调研的方法是互相补充的关系。 另一方面,我们也可以根据业务部门的运作过程，对这条业务主线上的每个角色进行逐以地访谈。比如,王五所在的贸易的订单业务主线一般流程为：接订单->订单下达->采购->入库->收款。那么，他应该做出相应的访谈路线图。这样,他才能在一段时期内有效地把访谈工作进行到底。 3、访谈过程中坚持以我为主, 善于引导访谈对象。 访谈过程中我们要保持理性，自始至终以我为主,牢牢掌握访谈的主动权。因为只有访谈者掌握了访谈的方向和内容, 访谈的质量才有保证,效果才能预期。 优秀的需求分析员应该是有理性的人, 我们不能因为被访谈对象的情绪便打乱了我们本来已拟就的访谈计划。我们有必要树立目标法则,因之没必要特别在乎被访谈对象的一些抵触情绪。比如，王五和一个业务助理在谈话过程中，当他得知王五的系统计划很可能损害到他的潜在利益,他会变得情绪化, 会找些借口, 比如说他的薪水太低,因而不愿意配合。如果你也遇到类似情形,此时的你一定要冷静、理性地分析问题的症结所在 ,适当地引导被访对象，以使访谈工作继续进行下去。 另外,访谈对象总是有一些“防御”访谈者的手段，比如，被访谈对象对你的提问经常以“这是某某习惯”作答，那么你必须意识到这不是真实的答案，并且可以当面指出，让他逐步把对问题的回答引入到你在自己预设的轨道中——也惟有这样谈下去才能谈得更深入。一个好的分析访谈人员能够从表面挖掘出背后的真实商业规则，并且有这种发现需求真相的耐心和韧性,同时他必须很有主见,能够引导对方,达到既定的访谈目标。 4、访谈过程中要善于寻求异常和错误情况。 千万不要认为被访谈对象的话总是对的，他经常会说“应该”或者“可能”是这样的答案,但就是不说出当前的真实情况,。因而很多时候你需要求异思维去面对你的访谈对象，因为只有这样你才能挖掘到更多的业务细节。多问问“如果条件没有达到，你会怎么办?”,”如果不是这样你会怎么处理?”，而要少说"是"。 我们可以认为业务访谈是否有效的标志，在于能否更深入地探讨业务需求问题,。而能否进入访谈状态,需求分析员的性格很重要。需求分析员必须是那种有主见而不是那种唯唯诺诺的人,如果用户说什么你都只会说“是”,则意味着访谈应该提前结束——此乃业务访谈之大忌也。 正确的态度应该是客观理性的态度,不管用户说什么,你首先要分析,然后置疑,从而引导用户说出他们真正的需求所在。其实也需要耐心,我们觉得可以向优秀的新闻采访记者学习提问技巧, 他山之石可以攻玉。 总之，优秀的需求分析员善于说不，只会说是的需求分析员永远得不到真正的需求。 5、业务需求访谈要搞清“4W1H”。 业务需求访谈要搞清”4W1H”。 有人说新闻就是4W1H, 业务需求也有同样的特点。需求分析员要清楚地掌握某个需求,应该能够清楚该业务的4W和1H ,4W是“What、Who、When、Why”,1H是“How”。 What：业务内容是什么。 Who：业务过程会有哪些相关者。 When：业务过程什么时候发生,周期有多长。 Why：为什么会出现这样的问题。 How：为完成业务目标所采用的方法。 6、业务需求访谈要深入调查细节。 现代系统分析员重要责任是调查系统需求细节，而细节不会凭空出现的，而是深入跟踪、深入访谈调研的结果。不但要“知道是这样”，还要知道“为什么是这样”，也要知道“如果不这样那会是怎样”。 做需求下结论前要事先调查和掌握好所有正反两个方向的商业细节，如此以来需求分析结论和解决方案才有现实可行性。这里有一个很好的实例，一般而言，物料编码都是系统自动提供规则实现的，而某贸易公司的订单系统偏偏不提供系统自编码。面对此问题，我们必须搞清两个问题：其一是该企业的编码规则，其二是该企业的编码规则牵涉到的前置条件和后置条件。知其然也知其所以然，是需求分析员的主要课题。经过多方调查发现，该企业编码规则中有两位是客户的版本更改数，而这在系统中是无法提供出来的，因而物料自动编码就失去了实现的土壤。所以说仅仅满足于看到了业务现象是远远不够的,我们更要搞清楚现象背后的原因,我们还要有能力能够提供诸多方案以解释和改造目前的现状。 层层发问法也是深入调查而经常采用到的方法。 比如,最近收到的客户退货比以往多,因为生产质量不好；为什么生产质量不好,因为采购质量不如以；为什么采购质量下降,因为采购员的采购件单价低了；为什么价格低了,因为采购员的绩效考核现在以采购成本为重要指标。经过层层发问终于发现原来症结在采购的以采购成本为绩效考核是存在问题的。 7、学会提问的技巧，先以对方的角度想想问题的答案。 你提问的问题最好比较具体，可回答性强。不要一下问得太大，搞得谁都不好回答。也不要满口的专业术语，很多访谈者喜欢说些专业术语，搞得双方无法充分沟通。我们提倡多说双方都便于理解的话，并且以对方的理解角度去问问题。比如你是想知道商业过程和操作是什么，你就可以提问"你主要干什么？"或者问"你的主要工作职责有哪些?"、"你的主要日常工作有哪些?"。你想知道商业过程应该怎样完成，你不妨问道"你如何完成它？需要那些步骤？"而如果你想知道需求什么样的信息，你就问道"你要使用怎么样的表单或报告？"。 8、时刻要记得的四个字"胆大心细" “胆大”是指你在访谈过程中不要顾虑太多，应该放开心态，最大化的放大访谈效果。 “心细”是指你在访谈过程中观察到的访谈对象的业务操作动作细节，以仔细分辨、总结、归纳背景原因所在。 同时，心细带来观察能力的提升，而观察能力之于现代需求分析犹如二郎神的第三只眼，总能让你发现意外的需求访谈方向，发现不曾有人提及的需求。 9、做业务访谈实录有利于提高访谈能力。 一旦本次访谈结束，有必要回去做一番总结，不仅要总结出提炼的需求结论，更重要的是要回忆还原出整个访谈过程，以便事后仔细研摩得失，这对提高业务访谈的能力是大有俾益的。这个过程相当于围棋中的复盘，优秀的棋手对复盘过程也是一丝不苟，好的需求分析员亦然。 业务访谈是一件如此有个性的事情，正如记者各有各的风格但规则是暗合的，以上是本人在业务访谈过程中总结出来的业务“规则”，现抛砖引玉，以飨同仁。 a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。 b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。 c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。 d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生。 e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。 f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题。 g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解。 h) 最后，需求分析报告一定要双方共同签字确认。
令人烦恼的非功能性需求变更
在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。 （1）什么是非功能性需求？ 在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。 （2）非功能性需求变更的特点 让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。 其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。 为什么非功能性需求变更会频繁发生？
为什么非功能性需求不能固定下来呢？或定下来后就不许变了呢？通常有许多人会问这样的问题。实际上，当他变成了客户时，他可能就不会问这个问题了。 （1）非功能性需求容易产生理解分歧 在软件需求分析阶段，客户和开发人员对非功能性需求的理解呈现"大体上共识多，细节上差异多"的特点。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通，但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的，主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。 作为一个客户，大多数情况下是不懂技术的，但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能，然后通过口头或者笔头的方式告诉需求分析人员。简单的说，就是在这个阶段用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，或者是他们想象出来的东西。结果是当客户向需求分析人员提出需求的时候，往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来说只是一种描述，甚至只是某个角度的描述，但远远不能保证这样的描述可以得到百分之百的正确理解。 当客户提出要求之后，在双方认为理解大概没有分歧的时候，开发人员就开始工作了。但随着开发工作的不断进展，系统开始展现雏形，客户对系统的了解也逐步深入。这个时候，客户就会对系统的界面、操作、功能、性能等有一些了解，就有可能提出需求变更要求，而且这些要求很多是基于主观的、人为的因素。总之，他们了解得越多，新的要求也就会越多。 （2）没有明确的需求变更管理流程 在软件开发中的常识是，一旦发生需求变更不要一味的抱怨，也不要一味地去迎合客户的新需求，而是要管理和控制需求变更。但令人不解的是我们常常看到变更的提出、讨论和执行常常只停留在口头上。这样做有两个弊端：首先是时间一长，无论是当事人还是开发团队都说不清楚变更是因何发生以及结果怎么样了。显然，这对于提高项目质量、改进开发过程是很不利的。其次是由于缺乏形式上的约束和对变更代价的定量分析，变更会被非常随意地提出、或被草率地执行，也会大大影响项目的进展和开发质量。 因此，没有明确的需求变更管理流程，就会使需求变更变得泛滥。因为并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。 （3）没有让客户知道需求变更的代价 对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对开发人员的辛苦就会难以体会。 相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，软件开发团队就要为它服务。因此，客户对需求变更往往会肆无忌弹，将需求变更视为儿戏，随个人喜好随意变更需求。所以，在和客户接触时应该挑明态度，特别是要让他们清楚需求随意变更所带来的代价和风险。如果客户认为代价太大，那么开发人员就没有必要及时修改，按原来的进度走，但仍要记录变更，待下一版本在修改。 如何有效控制非功能性需求的变更? 做任何变更之前，我们都要考虑后果。由于非功能性需求变更在开发中所处的重要地位，一旦需求发生变化，影响面是很广的。因此，有效控制非功能性需求频繁变更是一件不容小视的事情。 （1）建立明确的非功能性需求基线 对于软件开发来说，变更无可避免，也无从逃避，只能积极应对。因此，在开发过程中，建立明确的非功能性需求基线是一件重要的事情。如果非功能性需求没做好，基线范围就含糊不清，就容易被客户抓住空子，往往要付出许多无谓的变更。如果非功能性需求基线做得好，文档清晰且又有客户签字，那么后期客户提出的非功能性需求变更就会大大减少。因此，在建立需求基线的时候千万不能手软，这并非要刻意针对客户，而是不能让客户养成经常变更的习惯，否则后患无穷。 （2）建立需求变更管理流程 需求变更对软件开发成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以必须要做好需求变更的控制。有句通俗的话说得非常好：需求变更管理的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。需求变更管理流程包括变更申请环节、审批人员、审批事项、审批流程等。 目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本核算准备好变更账。因此，凡未履行审批程序的变更，一律是无效变更不予受理。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才会使到需求变更逐渐变为不可控，最终导致项目的失败。 （3）确认客户是否接受变更的代价 需求变更作为一个计划外的风险对项目肯定存在冲击，只是大小的差别。而且客户的需求是永远不会满足的，可能一天一个样,为了达到控制频繁的需求变更。需要将变更后产生的成本进行评估与量化，形成分析报告提交双方领导。否则，一味的妥协只会让项目进一步恶化。因此，要让客户认识到变更都是有代价的，不要让客户养成随意变更的毛病。一般来说，如果客户认为该非功能性变更是必须的，而不是其上级领导拍脑袋提出的就会接受这些代价。通过与客户的沟通和协商，开发团队即使没有回报也不会招致客户的埋怨。 （4）加强合同约束力 虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。因为有时销售人员为使客户能够快速的签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，销售人员往往一看"应该"只是一个小小的修改，没有太大的影响，可能会直接答应能变更。所以，在与客户签订开发合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程等。 （5）加强感情沟通，注意沟通技巧 大多时候单靠合同的约束力是解决不了纷争的。客户着急了就是一句潜台词：做不做，不想做就滚蛋，想做的公司多着呢。例如，有时明明是不合理的要求，可是客户也会狡辩凭什么不给他们做，这可是合同范围内的工作。所以，单看合同是没用的。 那可怎么办呢？通常的做法是通过感情联络，争取客户的同情。我们常常对客户说的一句老生常谈的话，就是提需求也要讲究合情合理，这句话在变更管理中有着独特的意义。用我们的行话说是：做好需求变更管理控制只是做好了一半的工作，还有一半的工作就是去讲道理，去用心、用感情劝客户回头。 月有阴晴圆缺，潮涨潮落。变化并不一定总是给我们带来麻烦，有时也会带来惊喜。在软件开发中，对待客户提出的非功能性需求变更，我们需要用平常心去看待，不是一味拒绝，也不要一味答应。
|
|
|
