第2篇　需求工程

第5章　需求工程概述

        需求工程，是构建管理信息系统的第一步工作，是对客户的现状和需求进行调研，并按照工程化的方法和标准完整、准确地记录和分析客户的需求，它的成果是进行后续设计工程的基础。

5.1　基本概念

5.1.1　定义与作用

1．定义

        需求工程，是指采用工程化的方法和标准，收集、记录和分析客户对信息化的需求，并最终确定系统需要实现的功能以及功能的相关特征和约束。需求工程包含三个主要的部分：需求调研、需求分析、需求管理。

        注：关于需求管理

        需求管理是需求工程中非常重要的内容，包含对需求的跟踪、控制、变更、版本管理等内容，它是保证系统的内容、质量、进度的重要手段，需求管理的内容更加偏重于软件的过程管理。

2．作用

        需求工程的作用归集为一句话就是：收集客户想要做什么，最终确定实际做什么。

        对于一个应用软件的开发来说，需求工程成果的质量极大地影响着这个软件的设计结果，是决定成败的主要环节，从客户那里完整地获取、记录、分析与确认需求，并正确地传递给后续的工程是一个需求分析师的必备能力。需求工程的分析成果形成的需求规格说明书不但是后续设计与开发的依据，同时也是客户对完成系统评估、验收的依据。

        另外一方面，需求工程的内容也极大地影响着软件开发的成本、技术、周期、资源、质量以及最终客户的满意度等诸多方面。需求工程的成果不但会影响客户最后获得的效果，也会影响到软件开发者的最终利益。

5.1.2　内容与能力

        需求工程的核心工作是需求调研和需求分析，最终的主要交付物有两个。

1）需求调研成果（需求调研资料汇总）

        从客户现场通过面对面的调研收集到的第一手需求资料，包括用图形、文字和表格等方式记录的原始资料，形成需求调研资料汇总。

2）需求分析成果（需求规格说明书）

        基于前述的调研资料进行分析，识别出最终需要进行开发的全部内容，并且通过客户确认，最终形成需求规格说明书，这是后续设计、开发过程的依据。

5.1.3　思路与理解

1．需求的收集与确认

        从客户不清晰的原始需求到可以进行编码开发的过程中，对收敛贡献最大的部分是②需求工程，而比较容易进行规范化、标准化作业的是③～⑤的部分。②将①的复杂内容梳理并形成了清晰的需求说明规格书。③将②的成果再进一步抽提、转换成为架构、功能和数据的设计成果。④将③的成果再进一步抽提、转换为组件、机制的构成方式。⑤将④的成果用编码的形式开发成为最终的软件。

        从图形的推进变化上可以看出，需求工程②担负着将原始需求①的内容理出头绪并形成一份清晰明了、可以确认的需求规格说明书的任务；而③～⑤的一系列工作，越靠后的部分就越单纯，复杂度降的越低，要做的事就越收敛。②需求工程是开拓者，它担负了最为杂、乱、累的工作，从客户原始需求到编码的5个步骤中对收敛起的作用最大。②部分图形的收敛越大（梯形的坡度大），③以后的设计开发的图形就越接近于正矩形，工作就越顺利，否则②～⑤都是大坡度的梯形时就说明需求工程做的不到位，在后续的设计和开发中会不断地发现前期的需求有问题而造成返工。

        注：关于“收敛”的含义

       收敛，指的是将复杂的原始需求，归集成为可以进行标准化作业的过程。标准化的作业内容是不受需求影响的，不论需求是否复杂其内容都是固定的。

2．需求，并非都是来自于客户调研

       构建信息系统的需求是否都是从客户那里获得的呢？这个问题反映出了完成的系统中有多少内容是经过软件工程师（包括咨询、需求、设计、开发、实施等）提案的，这些提案往往包含更多的高级需求、更多的附加价值，需求的来源有多个。

        1）基本需求

        基本需求来自于对客户进行的“调研”，这类需求以功能需求为主，基本上按客户意愿进行设计和开发，内容大部分在需求调研、需求分析阶段内确定。

        2）中级需求

        中级需求不是客户直接提出来的功能需求，而是在需求分析阶段、业务设计阶段通过对客户提出来的业务需求进行转换、优化、补缺、提升的过程中产生的需求，也就是为完善业务而产生的需求。

        3）高级需求

        高级需求主要来自于软件工程师根据本次客户的目标需求、新的设计理念、新技术等而提出，也就是说，高级需求是软件工程师设计出来的需求，例如，“事找人流程设计（架构）”“按照任务设计组件（功能）”“数据的复用（数据）”等。“设计需求”需要软件工程师有足够的知识和能力。

        上述三个需求来源的获取难度顺序为高级需求＞中级需求＞基本需求。

       软件工程师要认识到，需求工程（调研与分析）完成了，并非是需求获取的工作全部完成了，只是由客户直接提出来的需求完成了，而通过设计工程的需求发掘尚未开始。        

        注：高级需求会影响开发成本这里只考虑如何发掘有价值需求的方法，不考虑新需求带来的开发成本问题。

5.2　需求分类

        需求通常分为两大类，即功能性需求和非功能性需求。

5.2.1　功能性需求

       功能性需求是系统必须要提供的业务处理功能，也是软件需求的主体。通常所说的需求前面没有形容词时指的都是功能性需求。

        获取的需求可以分为三类，它们之间存在着转换关系，按照转换的顺序分为： 目标需求、业务需求以及功能需求。

        目标需求：客户提出的信息化的目标、理念、希望、价值。

        业务需求：客户提出的系统要对应业务的内容、过程、规则等。

        功能需求：确定系统必须提供的处理业务需求的功能及功能的具体描述。

5.2.2　非功能性需求

        非功能性需求是指建立一些指标性的条件来判断系统运行情况，而不是针对某个业务处理的具体功能需求，它们被用来判断运行的系统是否可以满足以下的条件：安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性等。

5.2.3　关于售前咨询

        售前咨询的结果中包含着很多对需求分析、业务设计而言非常重要的输入，特别是很多的“目标需求”来源于此，目标需求对后续信息系统整体规划、顶层设计有着非常重要的影响

        1．售前咨询的内容

        在进入到设计工程之前的阶段，与客户的所有交流和沟通的目的都是在获取需求，特别是对大型项目来说，签订合同之前通常会有一个售前咨询阶段，在这个阶段一般软件商会派出经验比较丰富的咨询师（如专家型咨询师）来与客户进行交流，探讨根据客户的需求可以提供什么样的解决方案，这个阶段的咨询具有以下几个特点。

        ●　合同尚未签订，具体信息系统做什么内容尚未确定，能否签约取决于咨询的结果。

        ●　此时客户方面的参与者多为企业高层，如经营者、高级管理者以及信息化主管等。

        ●　客户的需求多为目标需求、业务需求甚至是难度痛点等内容，较少谈及功能需求。

        ●　需求会涉及企业的发展战略、现存的主要问题及公司对信息化的期待等内容。

        ●　交流中谈到的内容可能会比较抽象，需求也多为隐性需求，是否能够成为真实需求需要咨询师去引导、判别、确认等。售前咨询通常谈到的都是相对高端的需求，它们是后续需求分析中“目标需求”的主要来源，是企业经营管理者对信息系统的价值期望（尽管可能是用隐性方式提出的），在后续所谓的“需求调研”阶段中，往往可能就没有机会再去直接听取企业高管的需求了，所以这个部分的内容要作为非常重要的需求记录下来，作为后续需求分析的重要参考素材。

        2．售前咨询与需求工程

        售前咨询的方式非常依赖于咨询师个人的能力和魅力，它并没有特别规范和标准的交付物以及模板，因此没有将咨询工作明确地列入到需求工程中（软件商不同可能划分方法不一样），这两者的重点不同。

        （1）售前咨询：重点是通过售前咨询活动，提出解决方案，协助销售部门签下合同。

        （2）需求工程：重点是进入客户现场，对已经确定的合同内容进行详细的调研。虽然咨询的主要目的是促成签订合同，但是咨询阶段收集到的信息是非常重要的需求工程分析对象，尤其是“目标需求”。

        3．咨询师的作用

        （1）咨询师，代表的是软件企业的最高专业水准，他应该是软件商的名片。

        （2）咨询师是全面阐释软件商的理念与主张的传道士。

        （3）咨询师建立的起点高，则整个项目的起点高，总价值也会高（对软件商与客户双方）。

        （4）咨询师要能够利用储备的知识和经验，为客户的决策者充当顾问、参谋。

        （5）咨询师的工作重点是要与客户项目的决策人进行沟通，获取客户的目的、期望等目标需求。

        4．咨询师的能力要求

        对于从事售前咨询的专家型咨询师来说，对他的要求就比较高了，主要体现在以下几个方面（不限于此）。

        1）沟通能力沟通的对象有客户的决策层，生产、财务等中间管理层，对能力的要求较高，例如，

        ●　理解：是否能够理解高层的谈话要旨、隐含的需求？

        ●　展示：能否充分地展示出软件企业的服务能力、产品能力？

        ●　说服：能否说服客户，例如，导入系统后要在组织或管理制度上做相应的改变？等等。

        2）专业能力对咨询师而言，对他的专业能力要求是综合的。

        ●　是否掌握行业咨询的基本知识？

        ●　是否熟悉客户的主营业务和辅营业务知识？

        ●　是否基本清楚软件行业的最新技术、匹配的案例、解决方案等。

5.3　工程分解

        需求工程的工程分解分为两个阶段，即需求调研阶段和需求分析阶段

5.3.1　工程分解1——需求调研

        需求调研阶段的主要工作有两个：需求调研，资料汇总。

        （1）需求调研：利用问卷、现状构成图、访谈记录、既存表单的方式收集客户的需求。

        （2）资料汇总：将调研过程中收集到的资料进行汇总，形成需求调研资料汇总，作为需求分析阶段的分析依据。

5.3.2　工程分解2——需求分析

        需求分析阶段的主要工作有两个：需求分析，资料汇总。

        （1）需求分析：基于需求调研资料分析客户的需求，最终确认系统需要实现的功能。

        （2）资料汇总：将分析成果资料进行汇总，形成需求规格说明书，作为后续的各个设计阶段的输入。

5.3.3　需求调研与需求分析

        1．需求调研

        目的主要是收集、记录客户对信息化的需求，重点是对内容的“记录”，而不是“分析”或是“设计”，避免因为分析与设计融入了需求分析师个人的见解，需求调研阶段的资料一定要保持其“原始性”（使用需求模板是为了使记录内容标准化、格式化）。

        2．需求分析

        在对需求调研资料的理解基础之上，进行了抽提、归类、梳理，同时根据分析补全了调研时的断点，并且采用比较规范的方式进行了表述，重要的是：需求分析师通过对目标需求、业务需求等高端需求的分析加入了个人的理解，以及对企业信息化提升有价值的意见，所以需求分析的结果与原始记录之间会发生不同，需求分析师的理解代表了软件开发团队的理解，并以此为基础向客户进行确认，最终稿就形成了向下一个设计环节的输入资料。

        所以说，需求分析师的能力会最终影响到信息系统的内容、技术、成本和周期等。

        3．二者的关系

        两者都采用非技术设计用语描述，需求调研采用“客户用语”进行记录，需求分析采用“业务设计用语”表达分析的结果。在工作目的上两者有所不同，例如：需求分析做的业务流程图必须具有业务的完整性，且符合业务流程的标准表达方式；而需求调研收集到的业务流程图可能是片段的、不连续的流水账。需求分析对需求实体的内容进行了抽提、分类，建立了需求体系表；需求调研阶段不要求这个梳理，只进行原始的收集和记录即可（要保留原始状态）。需求分析成果的作用有两个：向前端的客户确认，向后端输出设计依据；需求调研的成果仅仅是向需求分析提供资料。两者最大的区别如下。

        （1）需求调研：着眼于对原始需求的收集、记录。

        （2）需求分析：着眼于从整体上理解、归集、确认，需求分析不是对需求调研的重复。

5.3.4　需求工程资料的应用

        需求工程阶段完成的资料对后续的各个设计阶段的影响

        （1）需求调研：收集、梳理客户的原始需求。

        （2）需求分析：调研资料只提供给需求分析，不能被设计所直接引用（可以参考）。

        （3）概要设计：要完整地对需求分析的结果全面覆盖，给出规划。

        （4）详细设计：原则上是针对概要设计的成果进行细节设计。

        （5）应用设计：对需求分析中关于应用方面的要求给出系统实现的方法。

        （6）技术设计：对需求分析成果中的非功能性需求、技术需求做出响应。

        （7）、（8）开发～测试：不能将需求分析的成果作为开发与测试的依据（可以参考）。

        （X）系统验收：客户对系统的最终验收是依据需求规格说明书进行的。 

5.4　工作分解

5.4.1　需求调研的工作分解

        需求调研并不是按照工作的顺序或是调研内容之间的关系去进行的，因此不存在严格意义上的工作分解，它是按照需求表达形态的不同进行划分的，需求表达的形态分为三个类型。

        （1）图形类：包括表达客户业务现状的图形、用界面表达的需求等。

        （2）文字类：通过问卷、访谈记录形式收集的用文字表达的需求。

        （3）表单类：客户提供的实际报表、单据形式的需求。

        这三种类型的资料相互之间没有必然的关联关系或是顺序，可以同时进行收集。

5.4.2　需求分析的工作分解

        需求调研的结果经过梳理，将非功能性需求分离后剩下的都是功能性需求，可以按照功能性需求的定义将它们分为：目标需求、业务需求和功能需求，这三者存在着目标需求→业务需求→功能需求的转换关系。严格地讲，它们不是三种类型的需求而是需求的三个层次，最终只有成为第三层的功能需求才能在系统中实现。分析阶段的工作分解就是按照这个顺序确定的。

        （1）第一层工作：对目标需求的分析、向业务需求的转换。

        （2）第二层工作：对业务需求的分析、向功能需求的转换。

        （3）第三层工作：对功能需求的分析和确定。

5.5　需求体系的建立

5.5.1　需求体系的内容

        建立相应的需求体系，没有这个需求体系，就是用个人的经验来解决客户的问题，有了这个体系，就可以做到用集体的经验和智慧来解决客户的问题。这里需求体系主要指的是建立“业务需求”。

5.5.2　需求体系的价值

        建立了需求体系可以带来很多的价值，试举几例如下。

        1．体系化的知识积累

        （1）研究与实践的成果可以有条理地进行积累，包括：理念、方法、标准、规范等。

        （2）客户价值的积累，包括：不同业务领域、行业、板块、系统、模块、功能等。

        2．商业规模化的需要

        （1）提升软件企业的价值，可以为客户提供体系化的解决方案。

        （2）抽提、规划、建立新的商业模式，对客户的需求进行快速响应。

        3．降低成本提高效率

        （1）积累的知识可以得到有效的复用、共享，降低成本。

        （2）可以大幅度地缩短开发周期，同时可以帮助减少“需求失真”现象。

        4．规避风险的首要措施

        （1）规避风险的最佳方式是让每个人事先知道该如何做，有了体系支持就可以做到。

        （2）人的能力不足、调研分析时间短的问题，可以用知识库帮助解决。

        5．快速培养人才的捷径作为需求分析师，被要求具有很多的能力，例如“业务能力”“沟通能力”“抽象能力”“表现能力”等，但这太抽象，难以理解，而且非一日之功。建立一个可以提供大多数人直接参考和共享的知识库，可以让需要者“有序可循”，它像一个“业务平台”，可以让大家提供经验、分享知识，并由大家共同维护。

小结

        需求工程可以说对每个从事软件行业的人员来说都是基础知识。因为它的核心内容是：

        （1）如何与他人交流，如何快速地理解他人的想法，如何向他人传递想法等？

        （2）对一个复杂的、不熟悉的研究对象如何快速找到切入点？

        （3）如何将一个不清晰的对象，用简单的语言、图形或是表格的方式表达出来？

        （4）如何将客户用语（知识、经验）表达的需求转换为业务设计用语的表达方式？等等。

      管理信息系统的需求数量多少、需求的附加价值高低，取决于客户对信息化的目的和需求分析师的能力，需求分析师的位置通常是夹在前面的“咨询师”和后面的“业务设计师”之间，当软件企业具有这两个岗位或是该项目配置有这两个岗位时，需求分析师自身能力对项目的影响可以在某种程度上得到控制，如果软件企业没有其他两个岗位或是本项目没有配置这两个岗位，那么需求分析师就决定了这个项目的最高水平（企业管理型项目的最高水平通常是由业务设计师决定的），因此他就必须要掌握一定的咨询和业务设计知识。

        需求工程，以设计输入为要求标准

        需求工程不但是一门“知识”，同时也是一门可以定性定量执行的“技术”，它有模板、有流程、有标准，更重要的是它与后续的设计有着严格的传递与继承关系，由于有了设计的范围、内容、格式等作为需求工程的产出标准，所以需求工程要做的内容就非常具体、规范，作为一门“技术”的需求工程的可操作性大为提升。建立以设计输入为需求工程标准的方法，可以提升设计质量、产品质量以及工作效率。