第7章 需求分析
需求分析，就是要对需求调研收集到的资料、信息逐个地进行拆分、研究，从大量的不确定“需求”中确定出哪些需求最终要转换为确定的“功能需求”。需求分析的作用非常重要，后续设计的依据主要来自于需求分析的成果，包括：项目的目的、范围、深度等，同时分析的成果构成了需求工程主要交付物需求规格说明书中的核心内容。
7.1 基本概念
7.1.1 定义与作用
1．定义
需求分析，是对收集到的需求进行细致的分析、研判，准确地理解客户的目标、业务等对信息化的需求，最终将这些需求转换为准确的功能需求定义。需求分析就是确定系统必须要做什么的过程。
2．作用
需求分析的结果要确定目标系统的完整、准确、清晰和具体的要求，包括：系统覆盖的业务范围、功能需求、设计原则等。需求分析阶段是分析系统在功能上需要“实现什么”，而不考虑如何去“实现”。需求分析完成后，给出需求规格说明书，这个资料的用途有两个：回答客户的需求、作为后续设计的输入。
（1）对客户：确定了系统需要开发／交付的全部内容，是双方签订／验收合同的依据。
（2）对设计：是规划系统范围、目标、原则等的依据，是具体设计的指导。
7.1.2 内容与能力
1．作业内容
需求分析的主要作业内容是将需求的内容经过归集、过滤、转换、确认等一系列的步骤，最终形成需求规格说明书，这个说明书的主要内容之一就是功能需求一览。
以调研的成果为基础，通过进一步的分析，对需求从高到低进行分层，分析工作包括：
● 分层：将收集到的需求归集为目标需求、业务层需求和功能层需求。
● 转换：将分层后的需求，按照目标需求→业务需求→功能需求顺序进行转换。
● 功能：通过一系列的分析、转换，最终获得功能需求。在分析转换的过程中，清晰客户的目的、目标、价值、期望等，从而确定未来系统的设计理念、设计主线、原则等。
2．能力要求
除去要掌握与需求调研者相同的知识和方法外，需求分析者还需要具有以下的基本能力（不限于此）。
1）建模与分析能力
由于要在分析阶段解决所有尚未清晰的客户需求，特别是客户提出的需求当中包括：目标需求、难点和痛点等类型的需求，它们比较抽象，必须要通过建模、分析的手段才能精准地搞清楚客户的需求是什么，然后在此基础上给出让客户满意的功能需求。
2）专业业务知识需求分类中的第二个层次是业务需求，这个需求不是简单地用功能名称来说明的，而是用比较专业的提法来说明业务场景，例如，需要成本的精细管理、需要业务财务一体化的处理等，只有掌握了比较专业的业务基础知识才能给出解决方案。
3）设计与实现的知识需求分析工作中，常常需要做出一些原型向客户进行说明，这就需要需求分析师具有一定的设计能力和技术实现的基础知识。
7.1.3 思路与理解
在获得了大量的需求之后，下一步要考虑的是：如何梳理需求。面对大量的需求资料，作为需求分析师要理解如下一些基本要点。
1．理解：客户是说不清需求的
永远不要抱怨，客户说不清楚他想要什么、说不清楚业务逻辑等，因为客户中如有某个人可以说得很清楚时，这个企业的规模往往比较小，而说不清的客户通常企业规模比较大、业务复杂、分工细，所以常常会碰到客户存在着“上下之间说不清”“横向之间说不清”的现象，这是正常的。正是因为他们不能用符合信息化标准的方式说清楚，才需要懂得信息化标准的需求分析师来帮助梳理，所以，当需求分析师介入之后还梳理不清楚，这就不是客户的问题了。
2．识别：真假需求
识别出获得需求背后的真实需求，是需求分析工作的重点之一，需求虽然是按照部门采集的，但是每个需求的提供者很大程度是站在自己的岗位上提出的，这些需求在“人-人”环境中是合理的，但是在“人-机-人”环境中是否还是合理的，就需要需求分析师要能够进行识别、判断，是否具有这个能力主要依据的还是需求分析师本人具有多少“行业知识”和“设计知识”，前者从业务视角判断，后者从信息化的视角判断，如果这两个方面的知识都比较弱，就难以判断出需求是否是真实的需求（这就是需求分析师被看作“传声筒”的原因）。
3．需求分析工作的场所
因为对收集到的原始资料进行分析时会发现很多不清楚的内容，例如，流程构成图的缺失部分、访谈内容的真实意图、既存表单的计算逻辑等，需求分析师不清楚的内容可能用户一句话就可以解答，这样的内容不属于分析的对象，大量类似的问题如果在现场与用户直接确认，分析工作的效率将会提升很多。这里再次强调：尽量将需求资料中只有询问用户才能搞清楚的内容在客户现场搞清楚。
7.2 需求的分析
7.2.1 需求的分层
1．需求的分层
对获取的需求按照获取它们的顺序以及需求之间内在的关联关系分为三个层次，即：目标需求、业务需求以及功能需求。
1）第一层：目标需求
（1）提出者：通常是由项目投资人、产品购买者、实际用户的管理者、信息中心负责人等，他们是对系统提出目标性需求的人，也被称为“客户”。
（2）需求内容：说明企业为什么要开发系统，希望做成什么样的系统，信息化目标是什么，通常采用战略、理念、希望、价值等的形式表达。
（3）需求作用：用于指导系统的顶层设计，对业务需求转换的指导等。
2）第二层：业务需求
（1）提出者：包括目标需求的提出者、企业的高层管理者、各个部门的管理者以及普通员工，他们从业务层面提出需求，也被称为“用户”。
（2）需求内容：从客户实际的工作出发说明希望系统可以应对哪些业务、如何对应，通常采用业务术语（场景）来描述业务的内容、过程、规则等。它的来源有2个：
①从目标需求转换而来；
②由提出者根据工作需要直接提出。
（3）需求作用：用于进行业务架构、功能规划、业务优化等。
3）第三层：功能需求
（1）提出者：所有的目标需求和业务需求的提出者、系统的直接用户。
（2）需求内容：给出系统必须提供的业务处理功能，以及对该功能的具体描述。它的来源有2个：
①由业务需求转换而来；
②由用户根据工作需要直接提出。
（3）需求作用：它是后续设计工程输入依据，也是需求工程的主要成果之一。
2．三层需求的转换
可以从上面的定义中看出这三类需求之间是有层次关系的，即：目标需求高于业务需求、业务需求高于功能需求。反过来看也容易理解：功能是为了支持业务，业务是为了落实目标。它们来自于不同层次的提供者，且各自侧重点不同。
（1）目标需求：提出了系统的构建方向、目标，比较抽象，需要转换为对应的业务需求。
（2）业务需求；提出了系统要支持的业务内容，是从业务上相互理解的基础。
（3）功能需求：提出了系统要实现的功能内容，是从功能上相互理解的基础。目标需求和业务需求要想落实到系统中并影响系统的设计，必须采用以下两种方式。
方式一：作为设计的理念，指导系统的规划和架构形式。
方式二：转换为具体的功能需求，可以是业务功能或是管控功能的形式。
①目标需求：提出了“管理智能化”的目标，但是不清楚具体的业务如何处理。
②业务需求：说明了符合目标需求的业务处理方式，是客户希望获得的效果。
③功能需求：对应业务需求给出功能需求，实现这个功能需求就可以满足业务需求。
3．三层需求的区别
1）目标需求与业务需求
（1）目标需求：从高的层次给出了实现管理信息化的希望，方向性强，但需要解读、转换。
（2）业务需求：直接提出了采用信息化手段后可以处理哪些业务。
2）业务需求与功能需求
（1）需求提供者在说不清楚具体的功能时采用“业务需求”的方式说明。
（2）如果清楚地知道要什么功能，则直接采用“功能需求”的方式说明。
注：隐性与显性
相对于直接说明功能的功能需求，目标需求和业务需求是“隐性的功能需求”，从这两个需求中是否能够正确地解读出功能需求，是非常考验需求分析师的能力的。
7.2.2 需求的转换
1．分层的处理
需求调研记录的三种形式（图、文、表）与需求的分层有如下的对应关系，按照它们之间的关系，可以将收集到的原始需求拆分为上述三层需求。
①访谈记录（文字）：内容最为复杂，它同时包含三个层次的需求。
②现状构成（图形）：可以表达业务需求、功能需求，但无法表达目标需求。
③既存表单（表格）：直接表达的是功能需求，可能有业务需求，但没有目标需求。
2．转换的处理
将原始需求拆分为三层需求（目标、业务和功能）后，下面要对不同层的需求采用不同的方法进行分层之间的转换：目标需求→业务需求，业务需求→功能需求。
1）目标需求的转换对目标需求的内容进行深入的理解、分析，并将目标需求的内容与企业的实际业务场景进行关联，从而找出可以支持目标需求落地的业务活动，解读目标需求带来了：
● 对目标需求的理解，这是指导后续的业务优化、系统规划的指针。
● 确定了目标需求转换的业务需求。
2）业务需求的转换业务需求有两个来源：一是从访谈记录等直接获得，二是从目标需求转换而来。但不论哪一种来源，其向功能需求的转换方式是一样的。
● 清晰地描述业务需求，可以用图形、文字等。
● 从描述的业务需求中识别出功能需求。
3）功能需求的确认
功能需求有两个来源：一是从访谈、表单直接获得，二是从业务需求转换而来。不论是哪一种来源，都要对功能需求进行确认。
● 对比各类调研资料，并与客户反复沟通，最终确定所有的需求都是真实的功能需求。
● 将功能需求汇总，形成功能需求一览。
3．转换的判断
在转换过程中，并非所有收到的需求都可以进行转换，以下的情节就不适合转换。
1）目标需求
有些客户提出的高层次需求根据客观的原因不能转为目标需求，只能作为一个后续设计的指导思想、理念，例如：
● 需求太过高大上，超前的需求造成技术难度大、成本过高、开发周期长；
● 客户的整体素质较低，导入高水平的管理系统后没有匹配的高水平管理团队；等等。
2）业务需求
有些需求是客户基于自己常年在“人-人”环境中积累的，但是这些需求不适合于“人-机-人”的处理方式，需要企业决策管理层进行思想、意识方面的改变，例如：
● 很多工作流程、工作岗位是“因人而设”的，采用系统管理后就不需要了；
● 很多管理方式和规则在使用系统管理后，按照标准化流程运行就不需要了；等等。
3）功能需求
采用系统进行工作处理后，原本大量由人工处理的工作就不存在了，因此，客户现实的做法与未来系统的功能也不是一一对应的了，客户所提的功能可能由其他功能替代，或与其他功能功能合并等。
7.2.3 三种需求分析法
1．第一层：目标需求的分析方法
做目标需求的分析，需求分析师要能够做到与企业决策者、高级管理层具有相同的视角，要能够理解他们的思考方式、战略构想、未来的期望等，没有这样的高度、相应的背景知识，就很难从他们提出的需求中找到可以落地的内容，进而找到对应的功能需求。与功能需求相比较，目标需求很多都是用抽象的方式描述的，如理念、目的、策略等。
目标需求是信息系统规划中顶层设计的指导，因此理解目标需求，并能够将目标需求用图形正确地表达出来，让相关人员（客户、业务、技术等）对目标需求达成一致的认知，能够做这样的分析才是最高水平的需求分析师。
2．第二层：业务需求的分析方法
做业务需求的分析，需求分析师要尽可能地掌握客户的业务知识（或借助业务专家的帮助），同时还要非常熟练地掌握业务的表达方式，因为需求分析师有责任清晰地告诉后续的业务设计师：这个业务需求对应的实际业务是什么、业务的构成、业务的逻辑。
业务需求的完美解析和表达，通常都会给信息系统增加亮点和价值，同时它也是需求分析中最能充分地显示需求分析师专业能力的地方。
3．第三层：功能需求的分析方法
对于功能需求的分析，需求分析师要掌握一定的业务设计能力，这样才能够区分业务领域需要什么样的“功能需求”，每个“功能需求”的内容、功能、规则，这个功能需求对应的实际业务处理活动是什么，等等。
7.3 需求分析1——现状构成图
7.3.1 资料梳理
现状构成图主要提供了业务需求和功能需求，由于现状构成图可能来源于客户或是需求分析师在调研现场的随手记录，图中的内容和表达可能不规范，因此要对现状构成图进行梳理，梳理主要是基于业务知识、业务经验，采用逻辑的、系统的手法进行。
节点1：
有活动描述、有对应实体（申请单），仅按照规定调整了名称（名词+动词）。
节点2：
①上没有实体，未来的系统不对应，因此去除“供货商沟通”节点。
节点3：
①上只有实体“合同书”，因此在②上增加了对应的活动“合同签订”。
节点4：
①上没有实体，经过确认，增加了对应的实体“验收单”。同时，参考①的现状图，②采用了标准的流程图画法重新进行绘制，②去掉了无效的步骤同时补全了作为流程的缺失内容。
梳理后的流程图是按照信息化实现方式对现状构成图优化的结果，因此，业务流程图的流转必须要符合流程标准，即有“实体”就必须有产生它的活动，“实体”是该活动处理的结果。以下两种情况都是无效的要去掉：有实体无活动，有活动无实体。最终流程上留下来的只能是：既有活动又有对应的实体。
7.3.2 分析与转换
1．分析与转换
由于图形表达的特殊性，例如，流程是由节点构成的，节点对应的是功能，因此对现状构成的流程图进行梳理后，可以同时获得业务逻辑（流程）和功能需求（节点）。功能需求包括以下两个方面。
（1）输入功能：带有数据输入界面的功能。
（2）打印功能：可以打印输出表单的功能。通过对现状构成图的梳理，获得了业务架构的设计参考资料，以及要素之间的业务逻辑关系，这两者对后续的设计工程都具有非常重要的价值。
2．转换结果记录
将梳理、转换的结果最终形成以下两个资料。
（1）现状构成图一览。
（2）功能需求规格书（也称为需求4件套）。这两个资料之间的关系是：记载在功能需求一览中的所有功能，都必须要编制对应的功能需求规格书。至此，就完成了对需求现状构成图的分析和处理。
7.4 需求分析2——访谈记录
7.4.1 资料梳理
需求主要来源于访谈记录（包括问卷），这类需求是以文字形式记录的，需求分析的主要工作量也是集中在访谈记录。
1．分层需求
包含的3个需求层内容在前面已经介绍过：目标需求、业务需求和功能需求，在下节中分别对这三层的需求进行详细说明。
2．待定需求
后两类收集到的需求由于表面上没有前述分层需求的特征，无法直接归类到分层需求中去，所以暂时归集到“待定需求”分类中，又因为待定需求中内容不同，再将待定需求分为以下两个不同的类型。
（1）类型1：难点、痛点等类型的内容。
（2）类型2：不满、抱怨、吐槽等类型的内容。
7.4.2 分析与转换1——目标需求
1．目标需求的理解
目标需求不能直接给出对应的功能需求，因为目标需求是用目标、理念、思想、价值等抽象化的形式表达的，因此针对目标需求必须首先找到其对应的业务场景，也就是要先将目标需求转换到业务需求上，然后再提供对业务需求的理解，最后去寻找对应的功能需求。
2．目标需求的分析
1）目标需求的内容
目标需求大多来自于企业的高层，目标需求反映了企业的投资信息系统的目的、设想，本案例的企业高层提出的理念（目标需求）。从目标需求的内容上不能直接看出它对应着什么业务需求，更看不出需要采用什么功能做支持，对比业务需求和功能需求，会感受到目标需求的表达方式比较抽象。
2）目标需求的解读
通过与企业领导的沟通，并详细了解企业下一步的发展战略。
3）用示意图表达结果
在理解了上述目标需求后，需求分析师要将自己对目标需求的理解、分析成果表达出来，因为理解的正确与否是需要与客户进行沟通、确认的，其最好的方式就是用图形表达。
示意图是对不清晰、抽象的对象，采用简单、形象的图形表达出其大体的轮廓、意思，示意图不特别强调逻辑的准确性
3．目标需求→业务需求的转换
理解了目标需求的含义，下面寻找支持这些含义的业务场景，这些场景可以用来表达业务需求，它们可以支持目标需求的落地。
7.4.3 分析与转换2——业务需求
1．业务需求的理解
在调研时会发现客户熟悉自己的业务，但是并不清楚自己的需求对应的是什么样的软件功能，所以他们通常采用描述业务处理过程的形式说明自己想要完成什么任务，然后再通过与需求分析师的沟通、分析，最后转换成为功能需求。
业务需求的表达，必须是用客户用语表达，业务需求不能是理念、概念层面的内容，业务需求的内容必须要能够用具体的业务场景来描述或是用图形来表达。业务需求，是客户导入信息系统要解决的具体任务，业务需求是验证系统设计与开发成果的标准，客户验收的不是功能模块的多少，而是业务的需求是否被满足。业务需求的表达方式很多，根据需求分析师的知识背景不同，感受也就不同。
2．业务需求的分析
业务需求有两个来源，一是直接由客户提出来的，二是从目标需求转换而来的。不论是从哪个来源收集到的业务需求，在业务需求的分析阶段，都必须给出清晰的业务处理描述，说明这个业务：
● 业务需求是什么内容、要解决什么业务。
● 采用什么方式或是流程，流程上有哪些节点。
● 业务处理要遵循哪些管理规则。
3．业务需求→功能需求的转换
经过分析，得到了文字、图形或是表格的分析资料后，下一步就是从中识别需要什么功能，将识别出的功能归集后，就获得了“功能需求”。
7.4.4 分析与转换3——功能需求
由于客户不一定理解信息系统的设计与开发工作，因此要对由他们直接提出来的功能需求进行甄别：是否是真实的需求？该需求的可行性？提出的功能需求是否有重叠？在“人-人”环境中需要的功能在进入到“人-机-人”环境中是否还需要？等等。
进入了功能需求阶段，就没有转换作业了，需要的是对已经收集到的功能需求进行最终确认，判断其是否是真实的需求。按照功能的作用，可以将功能需求再分为两大类型：业务功能和系统功能。
1）业务功能
顾名思义，就是直接用来处理客户业务的功能，如合同签订、计划编制、企业基础数据维护等，每个业务功能对应着现实中客户的某个具体的工作。通常不加任何特殊说明时提到的功能指的就是“业务功能”，包括活动、字典、看板和表单4种形式
2）系统功能
业务功能通常是用界面形式表达的，还有一些功能它们不是直接用来处理某个具体的业务工作，而是只有使用信息系统才会出现的功能，是间接地为业务功能提供支持的，例如：
● 如登录、注册、权限、时限等都是系统功能，它们不是用来直接处理业务的，在“人-人”环境中也没有对应的工作，没有信息系统的存在也就没有这些需求了。
● 另外，客户需要业务流程可以实现自动推送信息，实现“事找人”的工作方式，这些属于系统功能。
2．功能需求的确认
最终要对收集到的功能需求进行最后的确认，功能需求有两个来源，一是从业务需求转换而来的，二是直接由客户提出来的。
1）来自业务需求转换的功能需求由于已经过业务需求阶段的分析、转换，不需要再进行确认，直接将确定的功能需求记入到功能需求一览中。
2）来自客户直接提出的功能需求这个部分由于是从需求调研中直接获得的，还没有经过确认，功能需求分析阶段的工作主要是指来自这个部分的内容。
【方法1】用业务逻辑确认。用业务构成图等，从业务逻辑上推演
【方法2】用业务数据确认。由于不是所有的功能都会出现在业务构成图上，还可以通过检查从某个功能上输入的数据是否被引用来判断该功能是否需求，如果找不到使用的地方，就可以判断该功能不需要。
7.4.5 分析与转换4——待定需求
1．待定需求的理解
1）在对收集到的需求资料进行分层时会发现，存在着很多难以判断是否是需求的说明，从描述上看它们与标准的需求说明（目标、业务、功能）有很大的差异，它们的表达方式可以分为两种类型。
（1）类型1——难点痛点：正常说明现实工作中存在的难点、痛点。
（2）类型2——吐槽抱怨：采用吐槽、抱怨的方式讲述工作中存在的问题。
7.5 需求分析3——既存表单
7.5.1 资料梳理
对既存表单的梳理主要是对中间的过渡表单进行确认，这一类的表单是手工作业环境下必须要做的，但是在信息系统中就不需要了。这部分的分析工作必须在现场调研时解决，因为它不是后期可以分析出来的，只能向客户直接询问才能得到，因此，如果在客户现场进行了充分的调研，将收集到的既存表单搞清楚，那么在分析阶段就不需要再进行梳理了。
注：功能需求与实体（表单）的关系
（1）1个业务功能必须对应1个实体。
（2）1个实体可能不止对应1个功能，例如既存表单在做功能设计时，可能需要有两个功能，即：活动功能→用于输入数据，表单功能→用于展示数据。
7.5.2 分析与转换
1．分析与转换梳理后的既存表单，通过在调研现场的梳理和确认，基本上就可以确定它是真实的需求。每个表单都要对应两类功能，即：输入类功能、表单类功能。
● 输入类功能：带有数据输入界面的功能。
● 表单类功能：可以打印输出表单的功能。
2．转换结果记录
● 将识别出的功能需求名称和概述记入功能需求一览中。
● 编写每个功能需求的功能需求规格书（需求4件套）
7.6 需求分析汇总
7.6.1 需求规格说明书
1．需求规格说明书
也有称为“需求分析报告”的，但不论称呼为何，都是对需求工程所做的具体功能、事项、原则的总结。主要包括以下内容：
● 引言：包括项目目的、背景、用语等基础信息。
● 项目概述：对项目自身的说明、包括范围、主要处理对象、与其他系统的关系等。
● 功能需求：本项目具体的功能需求、需求的详细说明等。
● 非功能性需求：对未来系统的性能、安全等的需求等。
● 技术需求：接口、软件、硬件、网络、部署等。
● 各类措施：质量保证、验收标准等。
根据项目的内容、规模以及大小，还会有其他的内容
2．解决方案
对需求调研和分析的成果还有另外一种使用形式，即解决方案。解决方案的目的是对客户进行概要说明，相对于需求规格说明书来说，解决方案包含的范围更加广泛、深度浅一些。解决方案也有其重点强调的内容，例如：
● 项目的目的、导入信息化给企业带来的价值、企业的变化等内容。
● 项目周期、项目计划、项目金额。
● 项目组织、资源构成、管理方法。
● 质量保证、风险控制、保证措施等。两种方式没有严格的区分，根据需要确定是否需要分为两个资料，一般来说，小型的项目只需要前者，大型项目两个都需要，向客户汇报、讨论的资料大都采用解决方案的形式，最终合同签字和验收的依据是需求规格说明书。
重点介绍需求规格说明书——“功能需求”中两个重要的文档，即：功能需求一览和功能需求规格书。这两个文档的内容贯穿了本书所讲的软件工程部分，是后续设计、开发交付的重要指导，也是本书分析与设计方法的主要成果。
7.6.2 功能需求一览
将收集并经过了确认的功能需求进行归集，形成功能需求一览
（1）业务领域：是客户业务的不同板块，也是未来的信息系统划分的基础。
（2）功能名称：这里仅仅是“功能需求”的名称，还不是正式的功能。
（3）功能说明：说明功能需求的目的、作用。
（4）实体信息：“数量”指的是收集到的实体有几份；“名称”是表单或报表的名称。
（5）显示终端：在信息系统实现时对应哪几类的终端。
功能需求一览的内容会随着不同的需求和设计阶段发生变化。
（1）需求分析阶段：功能需求一览经过初步分析，确认为是“功能需求”。
（2）概要设计阶段：业务功能一览通过对业务的分析和设计，正式定为“业务功能”。
（3）应用设计阶段：业务组件一览通过对系统的分析和设计，正式定为“开发对象”。
从（1）到（3），由于不同的设计视角，会一定程度上改变需求分析的结果，或将一个功能拆分为两个（增加），或将两个合并为一个（减少），同时会伴随着名称、定义等的变化。
7.6.3 功能需求规格书（需求4件套）
功能需求规格书记录了功能需求的详细内容，是需求分析工作量最大的一部分。功能的详细需求采用了结构化的记录形式，从4个视角对功能需求进行描述，包括：需求原型、控件定义、规则说明、逻辑图形。将这4个视角的描述方法归纳为4个模板，这4个模板合在一起可以完整地、无歧义地描述一个功能需求的全部属性，这也是“需求4件套”称谓的来源。以下说明中采用“需求4件套”的简称。
1．需求4件套模板4个模板的内容，每一个功能需求就对应一个需求4件套。
1）模板1：需求原型对功能需求进行详细描述的依据有两个来源：
一是根据访谈记录等收集到的客户说明，
二是根据收集到的既存表单。不论是哪一种，这里需要做的事情都是对“需求的记录”，而不是“功能设计”，因此重点都在对字段、字段背后的逻辑、数据算式等的描述。不需要表现按钮、菜单等系统界面的功能。需求原型的形式可以采用以下几种形式绘制，将绘制完成后的原型截图贴附在4件套的模板1上，因为不是设计采用哪种方法都可以。
①既存表单：直接使用既存表单的原件扫描或是截图。
②表格软件：用表格软件绘制简单原型，重点是标出字段的位置。
③专用软件：采用专用的界面设计软件绘制原型。
2）模板2：控件定义
采用表格的形式，对需求原型上的全部字段进行逐一的定义和描述，包括：字段类型、管理规则、计算公式等。在模板上，将记录字段的载体称为“控件”。
3）模板3：规则说明
由于模板2“控件定义”是对每个字段进行的单独说明，对于两个字段之间的关系、本功能需求与其他功能需求的关系，以及其他复杂的需要用大段文字描述的说明，都放在模板3“规则说明”中表述。规则说明是进行文章体说明的地方，所以没有特别的格式要求。
4）模板4：逻辑图形
利用原型、表格，以及文章体的说明仍然难以描述的内容，例如，复杂的业务逻辑、多重的管理方式等，可以采用图形的方式表达，将绘制完成的图形粘贴在模板4上
2．需求4件套的传递与继承
描述功能需求的资料“需求4件套”是对“功能”进行的第一次描述，这个需求4件套在后续不同设计阶段中，要被传递和继承多次
（1）需求工程-需求分析阶段：重点在对功能的需求进行记录→形成“需求4件套”。
（2）设计工程-详细设计阶段：重点在对功能的业务进行设计→形成“业务4件套”。
（3）设计工程-应用设计阶段：重点在对功能的应用进行设计→形成“组件4件套”。它们都是从（1）开始的，最后向技术设计和编码开发提交的是（3）组件4件套。由于“需求4件套”与“业务4件套”的描述方式相同，因此更加详细的记录方法
小结
需求分析的两个主要工作成果是功能需求一览和需求规格说明书，这两个资料基本上决定了这个软件项目的主要内容，依据这些需求可以确定如下的内容（不限于此）。
1．软件设计的需求
从软件的实现过程看，需求分析的成果主要确定了以下的内容。
（1）客户价值：通过分析、客户确认等，确定了客户投资信息化的目的、目标、期望、痛点等内容，这是系统确定设计理念、系统的管控深度的关键判断依据。
（2）业务范围：准确无误地确定了未来信息系统需要覆盖的全部业务内容，包括客户组织维度（集团、公司、部门、岗位）、业务领域的维度（销售、生产、物流、财务等）等。
（3）功能与规模：确定了基本的业务处理形式（业务架构、业务逻辑）、功能需求的内容（所需要的业务功能模块、管控方式等）。
2．软件管理的需求从软件的过程管理上看，需求分析的成果成为下述工作的依据。
（1）开发工期：确定了业务处理的形态、难易度，以及功能需求的数量等，也就基本上确定了可控的开发工期，基于上述内容制定控制用里程碑计划和详细的推进计划。
（2）需用资源：根据内容和计划，可以确定开发所需的各类人才资源的数量，其中也包括各个设计部分需要的资源能力（所掌握的设计知识、经验等）。
（3）项目管理：按照项目管理要求，制定组织方案（计划、资源、风险、质量、验收等）。从上面的内容可以看出，需求分析的作用不仅是后续的设计开发工作的输入，而且也是软件过程管理的输入。
（1）方法按顺序进行转换：目标需求→业务需求→功能需求。
（2）要求采用鱼骨图／思维导图、排比图、示意图等的联合表达分析的过程。
在理解了目标需求的解答方法后，再看业务需求和功能需求就觉得很容易理解了。有一种“居高临下”的感觉。
网友评论