需求分析10条法则（完整文档）

下面是小编为大家整理的需求分析10条法则（完整文档）,供大家参考。

　

　需求分析的 0 10 条法则

　历尽千辛万苦，终于签署合同，T IT 供应商拿到了用户提供的几页 “ 需求书 ”; 然后就凭借自己的理解立即投入开发，等生米熬成粥才发现满足不了用户需求，接下来就是艰难、反复地修改，最后开发人员厌倦了，用户也厌倦了，当然项目款也遥遥无期。这样的案例可谓比比皆是! !

　比起不成功的项目，一个成功的项目在开发者和客户之间往往采取了更多交流方式T ;IT 供应商不仅与终端用户或潜在用户群交流，而且对用户感性、朴素的认识进行抽象，提取出潜在逻辑关系，准确把握客户的真正需求，然后才进行软件开发。作为项目开发 者和最终用户之间的 “ 桥梁 ” ，O CIO 如何推进开发人员和终端用户的 “ 对接 ”? 如何从用户笼统、感性的描述中抽象出潜在逻辑关系? ?

　拨开需求 “ 迷雾 ”

　业务部门的主管甚至 O CIO 经常试图代替终端用户说话，但通常又无法准确说明 “ 用户需求 ” 。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中; ; 否则，产品很可能会因缺乏足够的信息而遗留不少隐患。

　需求分析是软件开发和项目管理的基础，但业务部门经常三言五语就把开发人员 “ 打发 ” 了，业务人员笼统、感性的描述对开发人员来说就像 “ 雾里看花 ” ，一些开发人员只好按 照自己的理解去写 CODE 。要拨开需求分析的 “ 迷雾 ” ，就要先了解需求分析的 “ 程序 ” 。

　需求分析包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定

　义与范围文

　档中予以说明; ; 用户需求描述了用户使用产品必须要完成的任务，应在使用实例或方案脚本中予以说明; ; 功能需求定义了开发人员必须实现的软件功能，

　使用户利用系统能够完成他们的任务，从而满足业务需求; ; 非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、 规范和约

　束，操作界面的具体细节和构造上的限制等; ;需求分析报告所说明的功能需求充分描述了软件系统所应具有的外部行为，在开发、测试、质量保证、项目管理以及相

　关项目功能中起着重要作用。

　业务部门的主管通常阐明 “ 业务需求 ” ，即产品的高层次概念和主要业务内容，为后继工作建立指导性框架; ; 但 “ 业务需求 ” 并不能为开发人员提供开发所需的许多细节说明。“ 用户需求 ” 必须找系统的最终使用者，他们最清楚要使用该产品完成什么任务和一些非功能性的特性需求，如程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点 的软件产品。业务部门的主管甚至 O CIO 经常试图代替终端用户说话，但通常又无法准确说明 “ 用户需求 ” 。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中; ; 否则，产品很可能会因缺乏足够的信息而遗留不少隐患。

　在实际需求分析过程中，由于业务部门工作很忙，经常没有时间或者觉得没有必要与 T IT 人员讨论需求分析，有时甚至希望 T IT 人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单; ; 否则千万不能这样做。

　优秀的软件产品基于优秀的需求分析，而优秀的需求分析来自于客户和开发人员之间的有效沟通 和合作。只有当双方参与者都知道自己需要什么，成功的合作需要什么，才能建立良好的合作关系。

　十项基本法则

　如果 O CIO 尝试着问一些愚蠢问题，例如：

　“ 以我的理解，你们收到订单后，会 ……” 。业务人员立刻就会指出你的错误，并开始滔滔不绝谈论业务，这一招就叫 “ 抛砖引玉 ” 。

　开发人员与业务部门的交流需要好的方法。下面建议 10条法则，开发人员和业务部门可以通过评审以下内容并达成共识; ; 如果遇到分歧，可通过协商达成对各自义务的相互了解，以便减少日后的摩擦。

　① 先导入管理思想，再梳理业务流程

　“ 百闻不如一见， 百见不如一尝。

　” 没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上 P ERP 系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等O ;CIO 必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。

　需求的思维过程，充分研究用户执行任务时决策的过程，并抽象出潜在逻辑关系，把一些 “ 常识 ” 性东西用逻辑来实现。例如，当 T IT 人员与护士交流医嘱处理过程时，护士会告诉 T IT 人

　员，护理级别有特级护理、一级护理、二级护理、 三级护理以等; ; 饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来，就可能出现

　同一个病人既是一级护理又是二级护理，既吃流食又吃半流食的可笑情况; ; 这些矛盾的避免原来是靠护士的大脑来判断的常识性问题，而用计算机来判断 “ 常识 ” 是最难的，也是最容易忽视的。经过反复探索，协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组，当护士选择特级护理的时候，自然排斥了一

　级、二级和三级护理。李包罗说：

　“ 在与医生、护士沟通的过程中，T IT 人员不是要成为临床专家或者护理 专家，而是要用 用 T IT 知识去梳理医生护士的要求，变成一种计算机可以实现的概念，超越了手工的功能才会受到业务部门的欢迎。

　”

　② 表达要符合业务部门语言习惯

　需求讨论集中于业务需求和任务，必然使用各种业务术语。如果开发人员是 T IT 厂商，O CIO 应将有关业务术语教给开发人员，同时还要把 T IT 人员常用的一些术语 “ 翻译 ” 给业务人员，做到交流畅通无阻。

　③ 了解业务部门的业务及目标

　只有充分了解业务部门的具体业务，才能开发出满足其需求的软件。为充分了解业务人员的具体需求，O CIO 要和开发人员一起到业务部门去观察他们的实 际工作流程，甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统， CIO还要亲自用一下目前的旧系统，明白目前系统是怎样工作的，了解其流程情况以及可供改进之处等。

　④ 掌握各种沟通技巧

　需求分析的过程实际上是个沟通的过程，O CIO 要想方设法吸引业务人员说出其需求。有时候，尝试着问一些 “ 愚蠢 ”的问题也有助于用户打开话匣子。如果 O CIO 直接要求业务人员写出业务是如何实现的，十有八九无法完成; ; 但如果尝试着问一些实际的问题，例如：

　“ 以我的理解，你们收到订单后，会。。。

　” 。业务人员立刻就会指出你的错误，并滔滔不绝 的开始谈论业务，这一招就叫 “ 抛砖引玉 ” 。

　⑤ 对业务需求进行逻辑分析

　业务人员对需求的表达通常是笼统、感性、琐碎的， CIO要尽量理解业务人员用于表述他们需求的思维过程，充分研究用户执行任务时决策的过程，并抽象出潜在逻辑关系，把一些 “ 常识 ” 性东西用逻辑来实现。例如，当 T IT 人员与护士交流医嘱处理过程时，护士会告诉 T IT 人

　员，护理级别有特级护理、一级护理、二级护理、三级护理以等; ; 饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来，就可能出现

　同一个病人既是一级护理又是二级护理，既吃流 食又吃半流食的可笑情况; ; 这些矛盾的避免原来是靠护士的大脑来判断的常识性问题，而用计算机来判断“ 常识 ” 是最难的，也是最容易忽视的。经过反复探索，协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组，当护士选择特级护理的时候，自然排斥了一级、二级和三级护理。李包罗说：

　“ 在与医生、护士沟通的过程中，T IT 人员不是要成为临床专家或者护理专家，而是要用 T IT 知识去梳理医生护士的要求，变成一种计算机可以实现的概念，超越了手工的功能才会受到业务部门的欢迎。

　”

　⑥ 以通俗的语言编写软件 需求报告

　T IT 人员应将从业务人员那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法等，然后编写软件需求报告。

　“ 需求分析报告 ”是 是 T IT 人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写; ; 报告中可以大量使用图表，但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

　⑦ 描述产品的使用特性

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

　⑧ 业务人员和 T IT 人员互相尊重

　如果业务人员与 T IT 人员不能相互尊重，那关于需求的讨论将会遇到障碍。参与需求分析的业务人员有权要求 T IT 人员尊重他们并珍惜他们为项目成功所付出的时间; ; 但业务人员也要尊重 T IT 人员的需求可行性及成本评估。所有软件功能都是有成本的，业务人员所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。T IT 人员会拒绝或实现不了业务人员的一些要求，业务人员也应该尊重 T IT 人员的意见。

　⑨ 有需求变更要立即联系

　不断的需求变更，会给在预定计划内完成的产品质量带来严重的不利影响，但需求变更又是不可避免的。在开发周期内变更越在晚期出现，其影响越大; ; 变更不仅

　会导致代价极高的返工， 而且工期将可能被延误，特别是在主体架构已完成后又需要增加新特性时。所以，一旦客户发现需

　要变更需求时，请立即通知 T IT 人员。

　⑩ 需求确认仅仅是以后讨论的 “ 基线 ”

　在 “ 需求分析报告 ” 上签字，通常被认为是业务部门同意需求分析报告的标志性行为，然而在实际操作中，业务人员往往把 “ 签字 ” 看作毫无意义的事情。有时这个领导同意了，那个领导却不同意; ; 即使每个相关人员都签了字，也照样“ 翻供 ” ，通常的理由是：

　“ 他们要我在需求文档的最后一行签名，于是我就签了，否则他们不开始编码 !” 同样的问题也发生在仅把 “ 签字确认 ” 看作是完 成任务的 T IT 人员身上，一旦有需求变更出现，便指着 “ 需求分析报告 ” 说：

　“ 您已经在需求分析报告上签字了，所以这都是按照您的要求开发的。

　”- - 这两种态度都是不对的，因为业务人员不可能在项目早期就能说清楚所有业务需求，变更需求是必然现象。在“ 需求分析报告 ” 上签字确认，仅仅是需求分析过程结束的标志，它意味着 “ 需求分析报告 ” 是以后讨论的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。

　揭开需求分析的迷雾，为前期的需求开发工作划上一个清晰的句号，有助于客户和开发人员之间形成持续良好的关系，为项目的成功打下 坚实的基础。

　需求分析的风险

　客户有时会提一些看上去很 “ 酷 ” ，但缺乏实用价值的功能; ; 若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时 O CIO 要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。

　不重视需求分析的项目组将 “ 自食其果 ” ，但重视了并不一定能写出完美的需求分析报告，因为需求分析中还有很多陷阱，稍微不慎 O CIO 就可能掉进业务需求的 “ 陷阱 ” 。需求分析中常见的陷阱有以下几种：

　首先是无足够用户参与。业务部门经常不明白为什么收集需求和确保需求质量需要费那么多功 夫。由于业务部门工

　时 作很忙，有时 T IT 人员很难与业务人员坐在一起交流业务需求; ;即使费了九牛二虎之力坐在一起，业务人员也讲不明白自己的真正需求。为确保需求分析的质量，O CIO 一方面要让 T IT 人员与尽量多的业务人员交流; ; 另一方面，应让具有代表性的用户在项目早期就直接参与到开发队伍中来，一同经历整个开发过程。

　其次是业务需求无休无止。业务部门在开发中若不断补充需求，项目就可

　能越变越大以致于超过计划及预算范围。计划并不总是与项目需求规模与复杂性、风险及需求变更实际情况相一致，使得问题更难解决。要想把需求变更范围控制到

　最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。另一方面，O CIO 要确定一个提需求分析的最后时间，不能放任业务人员无休止的提需求分析。

　同样，用户需求是模糊的。模糊性是需求规格说明中最可怕的问题。模糊的需求会让开发人员在错误的问题上浪费时间，让测试人员无所适从。一位系统测试人员说，他的测试组经常误解需求，因此不得不重写许多测试用例，再次进行许多测试。

　最后是不必要的 “ 画蛇添足 ” 。

　“ 画蛇添足 ” 是指开发人员力图增加一些用户 “ 欣赏 ” ，但需求分析说明中并未涉及的新功能。有时 T IT 人员花了非常...