大话软件工程:需求分析与软件设计(二十二)
将前述所有章节的交付物成果进行汇总,形成一套包括各个阶段的分析与设计资料的规格书,建立起软件工程的各个阶段与交付物的关联关系。
需求调研阶段的成果汇总为需求调研资料汇总,也就是将所有的调研成果汇总成册,主要内容如下(不限于此)。
(1)背景资料:通过从客户的网站、印刷资料、人员交流等方式获得的客户相关资料。
(2)问卷资料:调研前向客户发出的问卷。
(3)现状构成图:客户提供的或是根据客户现状绘制的业务框架图、流程图等。
(4)访谈记录:用文字记录的客户需求(目标/业务/功能需求、难度、痛点等)。
(5)既存表单:收集客户日常用各类报表、单据以及分析资料等(电子、纸质)。
(6)需求4件套:针对部分已知的功能需求做的详细记录。其中,(3)~(6)项为需求分析阶段的正式输入资料。
现状构成图包括业务和管理两个方面的内容
1.现状构成图
记录客户现状的模型主要有两类,即:
(1)业务类(业务架构模型):框架图、分解图和流程图;
(2)管理类(管理架构图)
2.现状构成图一览
对于收集和绘制的现状构成进行整理,形成现状构成图一览
文字记录的资料重点有调研前的问卷和访谈记录两类。
1.需求调研问卷(模板)问卷模板可以采用两种形式,一种是以填写为主,另外一种是以选择为主。根据内容判断采用哪一种
2.访谈记录一览(模板)访谈记录用的模板与记录一览可合为一体,形成访谈记录一览。
1.资料收集
将收集到的原始资料在现场进行分析,并给出关系分析图。
2.既存表单一览
将收集到的既存表单汇总成一览
在现场对既存表单等进行详细记录(采用需求4件套的形式)
需求调研阶段的交付物是需求规格说明书,也就是将所有的调研成果汇总成册,主要的内容如下(不限于此)。
(1)需求规格说明书/解决方案。
(2)功能需求一览。
(3)需求调研资料汇总:需求调研的阶段成果。
(4)需求分析过程资料:目标需求→业务需求→功能需求的转换过程记录。
其中,(1)~(3)项为概要设计阶段的正式输入资料;(4)为参考资料,它的转换结果已经归入到功能需求一览中。
需求工程的结束是以完成需求规格说明书为标志的。需求规格说明书是基于需求调研和分析的成果汇总而成的,它是客户和软件开发者双方之间关于待开发系统的共同认知,它是后续系统的设计、开发以及验收的依据。一般来说,需求规格说明书中要包含对软件和硬件两方面的要求,由于本书的主题是分析与设计,因此只涉及在需求工程中讲到的内容和成果。另外,需求规格说明书对于不同的软件企业有不同形式的模板,但不论是什么样的模板,处于模板核心位置的都是需求工程中介绍到的内容。这部分内容是客户投资信息化系统的核心需求,也是后续设计工程中主要的设计对象,是带来最大客户价值的部分。以下需求规格说明书的框架中主要包括与软件的业务设计、应用设计相关的需求。这个框架仅作为参考,实际使用时需要另行加入其他部分(包括:技术、硬件)的内容。需求规格说明书至少要包含4个核心部分,各部分的重点如下。
第一部分 引言:所有需要在事前声明的内容,如前言、原则、定义、范围等信息。
第二部分 背景:直接来源于客户的主观信息,如背景、现状、目标、期望等信息。
第三部分 需求:对需求的综合描述,这些内容是设计工程的辅助参考信息。
第四部分 功能:对需求分析成果的罗列,它们是设计工程的主要依据信息。
注:需求规格说明书与设计规格书的区别
需求规格说明书是需求工程完成时的交付物,这个阶段只是对需求进行了梳理、汇集、分析,但是并未对需求按照软件设计的标准进行设计。它是设计规格书的输入。设计工程的设计规格书是对需求规格说明书的内容按照软件设计标准进行的设计成果。它是对后续技术设计、开发的输入。
解决方案,重点是针对有“定制”的需求做出的特殊说明,项目整体是定制的对象,也可以是项目中某个部分内容的是定制的。解决方案的重点在于说明:
(1)客户最为关心的内容,如创新、难点、痛点、高价值的功能等。
(2)开发者比其他同行的优越之处。
(3)对客户需求的解决思路、对客户价值的认知、设计思路/理念等。
解决方案与需求规格说明书两者的区别如下。
(1)需求规格说明书是对需求的“规格”级说明,而且是全面详细的。而解决方案是针对咨询结果做出的“概要”级说明,只对客户关心的重点进行说明。
(2)两者形成的时间顺序,通常是先有解决方案(作为原则性的粗稿),在获得客户认可后,再进行深入调研之后,再继续做出需求规格说明书。特殊情况下,也可以是在有了需求规格说明书后,从中抽取部分内容形成解决方案,向客户介绍他们特别关心的内容。
需求分析完成后,最重要的输出之一就是功能需求一览,这个表给出了需要开发的功能需求参考,也是后期在设计、开发时判断工作量、难度、资源以及进度计划的主要参考依据。
进入设计工程后,第一阶段的设计就是概要设计,概要设计阶段的交付物概要设计规格书中包括三层的内容:架构、功能和数据,主要内容包括以下三种。
(1)架构概要规格书:业务架构图(拓扑图、分层图、框架图、分解图、流程图)。
(2)功能概要规格书:功能的分类与分类图、功能的规划与关联图、业务功能一览等。
(3)数据概要规格书:数据规划、编号标准、数据标准、主数据。
1.理念、主线与标准
架构的概要设计包括整体设计的理念、主线,以及各类交付物的标准和规范。理念:设计师对系统的顶层设计的构想、方向。主线:以价值为目标,串联起达成目标的功能。标准:架构模型在架构设计中需要遵循的要求。
2.业务架构图
架构图主要采用5种模型。
3.业务架构图一览
将完成的业务架构图汇总成业务架构图一览
功能概要规格书主要包括两个资料:一是功能关联图,二是业务功能一览。
1.功能关联图
按区、线、点等进行功能规则,绘制功能关联图。
2.业务功能一览
业务功能一览可以根据内容的多少和复杂度,将业务功能全部归为一个表(包括:活动、字典、看板和表单),也可以按照不同的业务功能各成一表。
1)业务功能一览(合成)
合成的业务功能一览
2)业务功能一览(业务功能类别)
按不同业务功能划分的业务功能一览
活动功能一览
字典功能一览
看板功能一览
表单功能一览
1.数据规划图
数据规划主要分为三个粒度:整体、领域和模块
2.数据标准
(1)业务编号的标准:用文字说明编制标准。
(2)业务数据的标准:用文字说明编制标准。
(3)主数据的选择:用文字或表说明选择标准和结果。
详细设计阶段的交付物详细设计规格书的内容包括三层的内容:架构、功能和数据,以及业务用例。
(1)业务流程规格书:业务流程的详细设计(流程5件套)。
(2)业务功能规格书:业务功能的详细设计(业务4件套)。
(3)业务数据规格书:包括数据关系表、数据模型(关联图、勾稽图、数据线)等。
(4)业务用例:对概要、详细和管理设计成果的验证用例。
业务流程的详细设计成果是业务流程规格书(流程5件套)
对于业务功能(活动、字典、看板和表单)的描述是基于需求工程的“需求4件套”进行的详细设计,形成“业务4件套”。
数据的详细设计成果主要有两个:一是数据表关系图,二是数据模型。
1.数据表关系图
2.数据模型
对概要设计、详细设计以及管理设计的成果,用业务用例的方式进行验证。主要模板有两个,一是用例导图,二是用例数据推演表
应用设计阶段的交付物应用设计规格书的内容包括三层的内容:架构、功能和数据,以及应用用例。
(1)架构应用规格书:业务流程机制、业务架构的转换等。
(2)功能应用规格书:对业务组件的设计(组件4件套),业务组件一览。
(3)数据应用规格书:数据复用、数据共享、数据格式转换(文字→数字)。
(4)应用用例:对应用设计成果的验证用例。
架构的应用设计的成果主要分为两类:一是对业务架构图的转换,二是架构层面的各类“机制”图设计。
1.业务架构图的转换
2.架构的机制设计图
架构的机制设计图根据项目的复杂度而定,不是必做的内容
对于业务组件的描述是基于功能的详细设计“业务4件套”进行的应用设计,形成“组件业务4件套”。
数据的应用设计的成果主要根据系统的内容而定,不是必需的,例如可以设计数据的复用机制、数据的共享机制,以及数据的转换机制等内容
对应用设计以及管理设计的成果,用应用用例的方式进行验证。主要模板有两个,一是应用用例导图,二是数据关系图
需求工程,是构建管理信息系统的第一步工作,是对客户的现状和需求进行调研,并按照工程化的方法和标准完整、准确地记录和分析客户的需求,它的成果是进行后续设计工程的基础。
1.定义
需求工程,是指采用工程化的方法和标准,收集、记录和分析客户对信息化的需求,并最终确定系统需要实现的功能以及功能的相关特征和约束。需求工程包含三个主要的部分:需求调研、需求分析、需求管理。
注:关于需求管理
需求管理是需求工程中非常重要的内容,包含对需求的跟踪、控制、变更、版本管理等内容,它是保证系统的内容、质量、进度的重要手段,需求管理的内容更加偏重于软件的过程管理。
2.作用
需求工程的作用归集为一句话就是:收集客户想要做什么,最终确定实际做什么。
对于一个应用软件的开发来说,需求工程成果的质量极大地影响着这个软件的设计结果,是决定成败的主要环节,从客户那里完整地获取、记录、分析与确认需求,并正确地传递给后续的工程是一个需求分析师的必备能力。需求工程的分析成果形成的需求规格说明书不但是后续设计与开发的依据,同时也是客户对完成系统评估、验收的依据。
另外一方面,需求工程的内容也极大地影响着软件开发的成本、技术、周期、资源、质量以及最终客户的满意度等诸多方面。需求工程的成果不但会影响客户最后获得的效果,也会影响到软件开发者的最终利益。
需求工程的核心工作是需求调研和需求分析,最终的主要交付物有两个。
1)需求调研成果(需求调研资料汇总)
从客户现场通过面对面的调研收集到的第一手需求资料,包括用图形、文字和表格等方式记录的原始资料,形成需求调研资料汇总。
2)需求分析成果(需求规格说明书)
基于前述的调研资料进行分析,识别出最终需要进行开发的全部内容,并且通过客户确认,最终形成需求规格说明书,这是后续设计、开发过程的依据。
1.需求的收集与确认
从客户不清晰的原始需求到可以进行编码开发的过程中,对收敛贡献最大的部分是②需求工程,而比较容易进行规范化、标准化作业的是③~⑤的部分。②将①的复杂内容梳理并形成了清晰的需求说明规格书。③将②的成果再进一步抽提、转换成为架构、功能和数据的设计成果。④将③的成果再进一步抽提、转换为组件、机制的构成方式。⑤将④的成果用编码的形式开发成为最终的软件。
从图形的推进变化上可以看出,需求工程②担负着将原始需求①的内容理出头绪并形成一份清晰明了、可以确认的需求规格说明书的任务;而③~⑤的一系列工作,越靠后的部分就越单纯,复杂度降的越低,要做的事就越收敛。②需求工程是开拓者,它担负了最为杂、乱、累的工作,从客户原始需求到编码的5个步骤中对收敛起的作用最大。②部分图形的收敛越大(梯形的坡度大),③以后的设计开发的图形就越接近于正矩形,工作就越顺利,否则②~⑤都是大坡度的梯形时就说明需求工程做的不到位,在后续的设计和开发中会不断地发现前期的需求有问题而造成返工。
注:关于“收敛”的含义
收敛,指的是将复杂的原始需求,归集成为可以进行标准化作业的过程。标准化的作业内容是不受需求影响的,不论需求是否复杂其内容都是固定的。
2.需求,并非都是来自于客户调研
构建信息系统的需求是否都是从客户那里获得的呢?这个问题反映出了完成的系统中有多少内容是经过软件工程师(包括咨询、需求、设计、开发、实施等)提案的,这些提案往往包含更多的高级需求、更多的附加价值,需求的来源有多个。
1)基本需求
基本需求来自于对客户进行的“调研”,这类需求以功能需求为主,基本上按客户意愿进行设计和开发,内容大部分在需求调研、需求分析阶段内确定。
2)中级需求
中级需求不是客户直接提出来的功能需求,而是在需求分析阶段、业务设计阶段通过对客户提出来的业务需求进行转换、优化、补缺、提升的过程中产生的需求,也就是为完善业务而产生的需求。
3)高级需求
高级需求主要来自于软件工程师根据本次客户的目标需求、新的设计理念、新技术等而提出,也就是说,高级需求是软件工程师设计出来的需求,例如,“事找人流程设计(架构)”“按照任务设计组件(功能)”“数据的复用(数据)”等。“设计需求”需要软件工程师有足够的知识和能力。
上述三个需求来源的获取难度顺序为高级需求>中级需求>基本需求。
软件工程师要认识到,需求工程(调研与分析)完成了,并非是需求获取的工作全部完成了,只是由客户直接提出来的需求完成了,而通过设计工程的需求发掘尚未开始。
注:高级需求会影响开发成本这里只考虑如何发掘有价值需求的方法,不考虑新需求带来的开发成本问题。
需求通常分为两大类,即功能性需求和非功能性需求。
功能性需求是系统必须要提供的业务处理功能,也是软件需求的主体。通常所说的需求前面没有形容词时指的都是功能性需求。
获取的需求可以分为三类,它们之间存在着转换关系,按照转换的顺序分为: 目标需求、业务需求以及功能需求。
目标需求:客户提出的信息化的目标、理念、希望、价值。
业务需求:客户提出的系统要对应业务的内容、过程、规则等。
功能需求:确定系统必须提供的处理业务需求的功能及功能的具体描述。
非功能性需求是指建立一些指标性的条件来判断系统运行情况,而不是针对某个业务处理的具体功能需求,它们被用来判断运行的系统是否可以满足以下的条件:安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性等。
售前咨询的结果中包含着很多对需求分析、业务设计而言非常重要的输入,特别是很多的“目标需求”来源于此,目标需求对后续信息系统整体规划、顶层设计有着非常重要的影响
1.售前咨询的内容
在进入到设计工程之前的阶段,与客户的所有交流和沟通的目的都是在获取需求,特别是对大型项目来说,签订合同之前通常会有一个售前咨询阶段,在这个阶段一般软件商会派出经验比较丰富的咨询师(如专家型咨询师)来与客户进行交流,探讨根据客户的需求可以提供什么样的解决方案,这个阶段的咨询具有以下几个特点。
● 合同尚未签订,具体信息系统做什么内容尚未确定,能否签约取决于咨询的结果。
● 此时客户方面的参与者多为企业高层,如经营者、高级管理者以及信息化主管等。
● 客户的需求多为目标需求、业务需求甚至是难度痛点等内容,较少谈及功能需求。
● 需求会涉及企业的发展战略、现存的主要问题及公司对信息化的期待等内容。
● 交流中谈到的内容可能会比较抽象,需求也多为隐性需求,是否能够成为真实需求需要咨询师去引导、判别、确认等。售前咨询通常谈到的都是相对高端的需求,它们是后续需求分析中“目标需求”的主要来源,是企业经营管理者对信息系统的价值期望(尽管可能是用隐性方式提出的),在后续所谓的“需求调研”阶段中,往往可能就没有机会再去直接听取企业高管的需求了,所以这个部分的内容要作为非常重要的需求记录下来,作为后续需求分析的重要参考素材。
2.售前咨询与需求工程
售前咨询的方式非常依赖于咨询师个人的能力和魅力,它并没有特别规范和标准的交付物以及模板,因此没有将咨询工作明确地列入到需求工程中(软件商不同可能划分方法不一样),这两者的重点不同。
(1)售前咨询:重点是通过售前咨询活动,提出解决方案,协助销售部门签下合同。
(2)需求工程:重点是进入客户现场,对已经确定的合同内容进行详细的调研。虽然咨询的主要目的是促成签订合同,但是咨询阶段收集到的信息是非常重要的需求工程分析对象,尤其是“目标需求”。
3.咨询师的作用
(1)咨询师,代表的是软件企业的最高专业水准,他应该是软件商的名片。
(2)咨询师是全面阐释软件商的理念与主张的传道士。
(3)咨询师建立的起点高,则整个项目的起点高,总价值也会高(对软件商与客户双方)。
(4)咨询师要能够利用储备的知识和经验,为客户的决策者充当顾问、参谋。
(5)咨询师的工作重点是要与客户项目的决策人进行沟通,获取客户的目的、期望等目标需求。
4.咨询师的能力要求
对于从事售前咨询的专家型咨询师来说,对他的要求就比较高了,主要体现在以下几个方面(不限于此)。
1)沟通能力沟通的对象有客户的决策层,生产、财务等中间管理层,对能力的要求较高,例如,
● 理解:是否能够理解高层的谈话要旨、隐含的需求?
● 展示:能否充分地展示出软件企业的服务能力、产品能力?
● 说服:能否说服客户,例如,导入系统后要在组织或管理制度上做相应的改变?等等。
2)专业能力对咨询师而言,对他的专业能力要求是综合的。
● 是否掌握行业咨询的基本知识?
● 是否熟悉客户的主营业务和辅营业务知识?
● 是否基本清楚软件行业的最新技术、匹配的案例、解决方案等。
需求工程的工程分解分为两个阶段,即需求调研阶段和需求分析阶段
需求调研阶段的主要工作有两个:需求调研,资料汇总。
(1)需求调研:利用问卷、现状构成图、访谈记录、既存表单的方式收集客户的需求。
(2)资料汇总:将调研过程中收集到的资料进行汇总,形成需求调研资料汇总,作为需求分析阶段的分析依据。
需求分析阶段的主要工作有两个:需求分析,资料汇总。
(1)需求分析:基于需求调研资料分析客户的需求,最终确认系统需要实现的功能。
(2)资料汇总:将分析成果资料进行汇总,形成需求规格说明书,作为后续的各个设计阶段的输入。
1.需求调研
目的主要是收集、记录客户对信息化的需求,重点是对内容的“记录”,而不是“分析”或是“设计”,避免因为分析与设计融入了需求分析师个人的见解,需求调研阶段的资料一定要保持其“原始性”(使用需求模板是为了使记录内容标准化、格式化)。
2.需求分析
在对需求调研资料的理解基础之上,进行了抽提、归类、梳理,同时根据分析补全了调研时的断点,并且采用比较规范的方式进行了表述,重要的是:需求分析师通过对目标需求、业务需求等高端需求的分析加入了个人的理解,以及对企业信息化提升有价值的意见,所以需求分析的结果与原始记录之间会发生不同,需求分析师的理解代表了软件开发团队的理解,并以此为基础向客户进行确认,最终稿就形成了向下一个设计环节的输入资料。
所以说,需求分析师的能力会最终影响到信息系统的内容、技术、成本和周期等。
3.二者的关系
两者都采用非技术设计用语描述,需求调研采用“客户用语”进行记录,需求分析采用“业务设计用语”表达分析的结果。在工作目的上两者有所不同,例如:需求分析做的业务流程图必须具有业务的完整性,且符合业务流程的标准表达方式;而需求调研收集到的业务流程图可能是片段的、不连续的流水账。需求分析对需求实体的内容进行了抽提、分类,建立了需求体系表;需求调研阶段不要求这个梳理,只进行原始的收集和记录即可(要保留原始状态)。需求分析成果的作用有两个:向前端的客户确认,向后端输出设计依据;需求调研的成果仅仅是向需求分析提供资料。两者最大的区别如下。
(1)需求调研:着眼于对原始需求的收集、记录。
(2)需求分析:着眼于从整体上理解、归集、确认,需求分析不是对需求调研的重复。
需求工程阶段完成的资料对后续的各个设计阶段的影响
(1)需求调研:收集、梳理客户的原始需求。
(2)需求分析:调研资料只提供给需求分析,不能被设计所直接引用(可以参考)。
(3)概要设计:要完整地对需求分析的结果全面覆盖,给出规划。
(4)详细设计:原则上是针对概要设计的成果进行细节设计。
(5)应用设计:对需求分析中关于应用方面的要求给出系统实现的方法。
(6)技术设计:对需求分析成果中的非功能性需求、技术需求做出响应。
(7)、(8)开发~测试:不能将需求分析的成果作为开发与测试的依据(可以参考)。
(X)系统验收:客户对系统的最终验收是依据需求规格说明书进行的。
需求调研并不是按照工作的顺序或是调研内容之间的关系去进行的,因此不存在严格意义上的工作分解,它是按照需求表达形态的不同进行划分的,需求表达的形态分为三个类型。
(1)图形类:包括表达客户业务现状的图形、用界面表达的需求等。
(2)文字类:通过问卷、访谈记录形式收集的用文字表达的需求。
(3)表单类:客户提供的实际报表、单据形式的需求。
这三种类型的资料相互之间没有必然的关联关系或是顺序,可以同时进行收集。
需求调研的结果经过梳理,将非功能性需求分离后剩下的都是功能性需求,可以按照功能性需求的定义将它们分为:目标需求、业务需求和功能需求,这三者存在着目标需求→业务需求→功能需求的转换关系。严格地讲,它们不是三种类型的需求而是需求的三个层次,最终只有成为第三层的功能需求才能在系统中实现。分析阶段的工作分解就是按照这个顺序确定的。
(1)第一层工作:对目标需求的分析、向业务需求的转换。
(2)第二层工作:对业务需求的分析、向功能需求的转换。
(3)第三层工作:对功能需求的分析和确定。
建立相应的需求体系,没有这个需求体系,就是用个人的经验来解决客户的问题,有了这个体系,就可以做到用集体的经验和智慧来解决客户的问题。这里需求体系主要指的是建立“业务需求”。
建立了需求体系可以带来很多的价值,试举几例如下。
1.体系化的知识积累
(1)研究与实践的成果可以有条理地进行积累,包括:理念、方法、标准、规范等。
(2)客户价值的积累,包括:不同业务领域、行业、板块、系统、模块、功能等。
2.商业规模化的需要
(1)提升软件企业的价值,可以为客户提供体系化的解决方案。
(2)抽提、规划、建立新的商业模式,对客户的需求进行快速响应。
3.降低成本提高效率
(1)积累的知识可以得到有效的复用、共享,降低成本。
(2)可以大幅度地缩短开发周期,同时可以帮助减少“需求失真”现象。
4.规避风险的首要措施
(1)规避风险的最佳方式是让每个人事先知道该如何做,有了体系支持就可以做到。
(2)人的能力不足、调研分析时间短的问题,可以用知识库帮助解决。
5.快速培养人才的捷径作为需求分析师,被要求具有很多的能力,例如“业务能力”“沟通能力”“抽象能力”“表现能力”等,但这太抽象,难以理解,而且非一日之功。建立一个可以提供大多数人直接参考和共享的知识库,可以让需要者“有序可循”,它像一个“业务平台”,可以让大家提供经验、分享知识,并由大家共同维护。
需求工程可以说对每个从事软件行业的人员来说都是基础知识。因为它的核心内容是:
(1)如何与他人交流,如何快速地理解他人的想法,如何向他人传递想法等?
(2)对一个复杂的、不熟悉的研究对象如何快速找到切入点?
(3)如何将一个不清晰的对象,用简单的语言、图形或是表格的方式表达出来?
(4)如何将客户用语(知识、经验)表达的需求转换为业务设计用语的表达方式?等等。
管理信息系统的需求数量多少、需求的附加价值高低,取决于客户对信息化的目的和需求分析师的能力,需求分析师的位置通常是夹在前面的“咨询师”和后面的“业务设计师”之间,当软件企业具有这两个岗位或是该项目配置有这两个岗位时,需求分析师自身能力对项目的影响可以在某种程度上得到控制,如果软件企业没有其他两个岗位或是本项目没有配置这两个岗位,那么需求分析师就决定了这个项目的最高水平(企业管理型项目的最高水平通常是由业务设计师决定的),因此他就必须要掌握一定的咨询和业务设计知识。
需求工程,以设计输入为要求标准
需求工程不但是一门“知识”,同时也是一门可以定性定量执行的“技术”,它有模板、有流程、有标准,更重要的是它与后续的设计有着严格的传递与继承关系,由于有了设计的范围、内容、格式等作为需求工程的产出标准,所以需求工程要做的内容就非常具体、规范,作为一门“技术”的需求工程的可操作性大为提升。建立以设计输入为需求工程标准的方法,可以提升设计质量、产品质量以及工作效率。
软件需求涉及功能性问题非常广,我们用抽象化理论分析,可以划分各个功能域,用不同的数字代替,软件——S,功能域——A1、A2……An
S={A1、A2、……An}
但是功能域B又存在若干问题P1、P2……Pm组成,并且每个功能对应于子系统中的一个软构件,可以表示为-B={P1、P2、……Pm}
功能G有若干个行为F1、F2、……Fj,每个行为对应于软件构件中的实现方法
G={F1、F2……Fj}
一个软件包含了所有功能的集合,同时包含了实现所以功能的所有方法和算法描述。需求分析是依据用户动机,经过需求问题识别,进行分析、消除分驰和综合,编写用户故事,评审;形成用户需求与设计同步,设计满足用户需求目标。
需求开发方法贯穿这个产品生命周期,利用不同的开发方法论进行挖掘需求,帮助用户找到问题,梳理问题,判断产品实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前进行周密的、全面的思考软件产品功能,用商业化行为解决需求与现实中存在的矛盾,解决用户需求与商业化产品功能融合,解决规范和个性化需求。
二、软件需求开发的目标
1、对实现的软件做一个全面的描述,帮助用户找到问题矛盾解决用户场景痛点,帮助用户在进行产品规划时做到周密,全面产品定位需求
2、了解和描述软件实现所需的全部信息,为产品设计、确认和验证提供一个基准
3、为软件产品管理人员进行软件产品成本评估和编辑软件开发计划书提供保障
需求开发-软件功能需求、软硬接口、非功能性需求、设计约束、反向需求、阅读支持信息。
软件需求分析尽量提供软件实现功能需求的全部信息,使软件设计人员和测试人员不在需要和需求方进行接触,保证需求分析的一致性和完整性。
三、软件功能需求
描述软件功能实现注意——
1、功能需求的完整性和一致性
2、功能描述的无异议和可追踪
3、功能描述清洗和功能可测试
四、软硬接口
1、人机接口
2、硬件接口
3、软件接口
4、通讯接口
五、非功能性需求
1、运行环境
2、时间需求
3、处理容限、精度、异常处理机制等
4、可靠性要求、可维护性、安全性
综合设计-价值设计,作为软件工程-设计工程中的提高部分,除了需要已经基本上掌握了业务设计和应用设计部分的知识以外,还需要站在客户的视角, 时刻思考:怎样用信息化的手段来为客户提供价值?
1.定义
价值设计,是软件设计师利用信息化的手法,为客户带来高质量、高效率的业务处理能力,是从“赋能”的视角为客户设计企业管理信息系统。
前面各个阶段讲述的内容主要以完成“客户功能”为主,本章的重点在满足客户的基本需求之上,探讨如何从“客户价值”的视角进行分析、设计。在为企业进行管理信息系统设计过程中,非技术阶段主要带来的客户价值是由两个部分构成的:业务价值(业务设计)和应用价值(应用设计)。
1)业务价值
业务价值,是基于业务知识、管理理论、实际经验等,并通过需求分析、业务设计对客户业务本身进行分析、梳理、优化、完善(此时不考虑功能需求的实现方法)后获得的。 业务设计的成果是“让客户重新认识企业自身的过去与现在”。
2)应用价值
应用价值,是将业务设计的成果与信息化手段相结合,描绘出未来在“人-机-人”环境下如何提升企业业务的效率与效益。 应用设计的成果是“为客户描绘了未来信息化管理的工作环境和效果”。 可见,两种价值不在同一个阶段上,并且需要不同的知识作为支持:实现业务价值需要有客户的行业专业知识及业务设计知识做支持,实现应用价值必须要有应用设计知识做支持才能做到。
业务价值和应用价值,构成了客户管理信息化价值的最大部分,也就是说,业务设计和应用设计决定了客户信息化价值的大小,该价值的大小又直接影响到了客户的满意度。
2.作用
在企业管理信息化推广的初期,主要是以软件商为本位进行管理信息化推广的,多数的软件商都是从自身开发效率、成本控制的视角出发设计系统,向客户进行系统的说明也主要是从业务处理功能的角度进行的,因为企业虽然有所不同,但是同类的业务处理功能实际上是相近的,时间一长就造成了市场上的管理产品、解决方案趋于同质化。不能支持个性化就违背了企业的经营管理的理念和方式。因此采用传统思维设计出来的信息系统越来越不能够满足客户的需求。 价值设计,本质上就是回归到以客户为主的设计理念上,让分析和设计围绕着为客户可以带来什么价值进行,软件设计师必须要确定这样的概念:功能,是为实现客户价值而提供的系统服务。
1.作业内容
这里总结从需求分析到应用设计的各个阶段中,是如何从不同的视角分析和设计客户价值的。从软件工程上看,要从三个阶段上找出相应的价值
(1)需求获取阶段:重点在收集、分析、理解客户传递出来的价值需求。
(2)业务设计阶段:设计的重点是根据客户的需求,针对既存业务自身存在的问题进行优化、完善,也就是对“业务价值”的实现。
(3)应用设计阶段:重点是将业务价值用信息化的手段展示出来,打造一个信息化的工作环境,让客户感受到与传统工作方式完全不同的变化,也就是对“应用价值”的实现。
来自于需求调研和分析的价值,最终通过设计,反映在架构、功能或是数据层面上。
2.能力要求
价值设计与管理设计相似,都不是业务设计和应用设计的“规定动作”,它是将管理设计的内容也包括在内的更高一层的分析和设计方法,做好价值设计,需要软件设计师具有全面理解信息化管理方式、信息化管理的价值,理解信息化环境会给客户带来什么样的变化的知识和能力。参考能力(不限于此)如下。
(1)具有丰富的客户业务知识、管理知识。
(2)熟悉企业的战略、目标、期望,熟知企业的组织构成、各个角色的作用、需求。
(3)熟知企业管理信息化的理论、方法。
(4)熟知需求分析方法、业务设计和应用设计的方法。
(5)具有一定的技术设计知识(根据内容的复杂程度,可以不需要)。
(6)具有价值设计的知识。
1.理解客户的需求:功能或价值
通常软件的设计基本上是从“功能”的视角推行的,追求功能的意识贯穿软件实现的全过程:寻找功能、设计功能和开发功能。在企业信息化的初期这种方式是正确且有效的,因为需求很直接、简单,直接用功能应对就可以满足客户的需求了。但是在企业信息化大范围普及后,很多企业的信息系统已经推进到了第2次或是第3次的扩建,信息系统的投资者和系统的用户已经从关心有哪些功能转变为:你提供的信息化解决方案与其他提供商有什么不一样? 你的方案可以让企业的经营、管理和业务处理发生什么样的变化?导入了你的系统可以为企业带来什么样的回报(价值)? 这就要求软件设计师认真思考:客户投资信息化的目的是买功能?还是买价值?回答毫无疑问是买价值!当然价值是需要用功能来实现的。系统中的所有功能都是为了实现某个价值而存在的。业务/应用设计起着桥梁的作用,通过业务设计、应用设计、管理设计以及用例设计等方式,向客户说明信息系统完成后带来的“客户价值”;同时向后续的技术设计和开发传递可以实现这些价值的“功能”设计。
2.理解客户的需求:发掘价值
企业管理类的信息系统与图书管理、售票管理等系统在价值发掘方面有很大的不同,后者主要是对“物”进行的管理,它的需求和价值比较明显,容易达成。前者是对“人、事”进行的管理,由于企业存在着诸多的管理制度、多样性的业务、复杂的社会关系、人际关系等,造成了对需求和价值的理解、发掘工作要复杂得多、困难得多。如何针对客户的情况发现价值需求、识别价值作用、设计价值功能并能够完美地使客户价值得以实现,是软件设计师应该追求的目标。
价值设计,站在客户的视角看问题
需求分析阶段的重点是分析和识别价值,需求分析阶段识别出来并得到客户认可的客户价值需求是后续设计阶段客户价值设计的基础依据。
1.通过调研获得需求
在需求调研和需求分析阶段,通过对收集到的需求进行分析获得功能需求是最为基本和普遍的需求获取方法,也可以说是“正向需求的获得方法”。需求获取过程如下。
(1)收集客户需求。
(2)对需求进行梳理,整理出目标需求、业务需求和功能需求。
(3)对需求进行分析(目标需求→业务需求→功能需求),最终获得功能需求。
2.通过价值设计获得需求
从最终的客户价值入手,反过来推演需要什么功能需求,也是一种重要的需求获取手段。它是由软件设计师站在客户的立场从为客户增加价值出发而获得的。这个需求获得的难度大,如果软件设计师没有这个意识或是没有设计的能力,可能这个需求就不存在了。例如软件设计师将系统的设计理念确定为“让系统变得智能化,不需要用户去寻找工作,系统会自动地将工作推送给用户(事找人、待办提醒等)”,为了实现这个设计理念而需要的功能就是价值设计带来的需求。启发软件设计师树立这个设计理念的诱因可能是客户的目标需求、业务需求或是待定需求(抱怨、难度、痛点等)。功能需求的完整性保证了系统的最低满意度(可用);客户价值的多少(业务与应用)保证了系统的最高满意度(好用)。
在需求分析阶段,各个需求分类中都有可以启发软件设计师去思考客户价值的内容,最终完成的系统是否具有很高的客户价值就取决于软件设计师的意识。
1.目标需求中的价值
由决策者、管理者提出的目标需求,要从企业整体的规模上、未来的发展趋势上去理解和分析,这个目标需求可以给企业带来什么样的变化、决策者及管理者期待着从这些变化中获得什么样的回报(价值)。决策者对企业未来的发展提出了如下目标:在未来的n年内,生产产值要达××亿元、利润提升×%,成本降低×%,工作效率达到×%等。软件工程师该如何从上述目标中发掘出具有价值的需求呢?
2.业务需求中的价值
业务需求是从某个部门、某个业务领域的规模上去理解和分析,实现了业务需求会带来什么回报(价值)。例如,管理者对企业管理最为薄弱的成本管理提出了如下需求:要对业务成本进行精细管理、定项追踪、实时监控通报等。软件工程师该如何从上述的业务中发掘出有价值的需求呢?
3.功能需求中的价值
功能是对价值的具体实现,从价值的视角看,容易得出功能的价值来。例如,合同签订,工程师是否可以理解合同签订功能可以为客户带来什么价值?反之,如果没有合同签订,会给企业造成什么损失?结合不同的功能处理内容,链接企业知识库,提供相关知识为正确处理把关等。
4.待定需求中的价值
待定需求中存在的客户价值是不言而喻的,给出如何用信息化手段处理的方法。
业务价值,是通过业务设计的方法对客户业务进行优化、完善可以带来的价值。
业务设计采用什么样的设计理念,就会带来什么样的设计路线和成果,例如,利用信息化的手段,让管理融入到业务中,用业务的标准化操作,代替传统的由人对所有的业务进行“管理”,这样的业务处理方式可以提升工作效率、减少管理成本,同时又不降低管理质量。
1.架构层的价值
通过业务架构的设计带来的客户价值,就是为客户用信息化的方法梳理、优化和完善了企业的业务,这个工作不但是后续所有各个阶段和各层的设计指导,还相当于为企业制作了“体检图”和“作战地图”,为企业今后采用更加科学化的管理方法打下了基础。这些业务架构的“图”具有独立存在的价值,它们不仅是为了后续的设计和软件开发,它们自身具有的实用价值不但不会小于软件系统,而且是软件系统无法替代的,因为 从软件系统界面上是看不到企业内部的业务逻辑的 ,即使是系统上线后,当需要对业务进行进一步的改造时,也应该首先从业务架构图着手分析研究,而不是直接去修改系统,特别是对复杂的大型系统来说更是如此。
1)对企业的体检与体检图在需求阶段,企业的业务和管理形态是“无形”的,因此,要做好企业管理信息化,首先要用现状构成图为企业“画一张像”,让无形的企业业务和管理有了具体的形象,使得客户与软件设计师双方看到了同一个对象,并对这个对象有统一的认知,为后续的优化与完善奠定了基础。利用架构设计的方法对企业进行如下增值工作。
(1)需求调研与分析阶段——现状梳理。
先用构成图将“无形的业务”画出来,通过图形让企业看到自己的“状态”,使相关人理解企业具有的可优化性,这个阶段的成果为下一步的业务优化奠定了基础。
(2)概要/详细设计阶段——业务优化。结合信息化的新知识、新手法,对梳理后的业务进行“流程优化、完善”,让既有的企业业务运行较之以前更加具有科学性、严谨性、可量化的管理等,因此提升了业务价值。
2)经营管理的作战地图
需求阶段完成了现状构成图,业务设计阶段完成了业务架构图的设计,这个图就相当于为企业绘制了“作战地图”,从此企业不再是“摸黑作战”了,因为企业的全部运行状态都被图形化了之后,对于作战目标和路线所有相关人员都知道:需要在什么位置上、对什么对象、进行怎样的管控、以达到怎样的目的等。
2.功能层的价值
在功能层设计时获得的客户价值主要体现在用界面的形式,对业务处理进行标准化、规范化,这个部分的设计有两个重要的价值点,即:管理向标准化转换、对业务进行管控。
1)数据处理的标准化,减少管控
首先借助界面的输入,实现业务的标准化操作,由于用户受到了界面带来的管理规则的约束,只要按照界面的输入就可以基本上正确地输入数据和完成数据的操作,这样就减少了直接的管理行为,提升了工作效率,这就是通过标准化带来的业务价值。
2)让管理措施与业务精准对接
其次,借助界面可以设置精细的管理措施,这些措施与企业的管理规则相关联,可以应对1)中无法通过标准化解决的问题进行逐一地、精准地设计,使得整体系统没有漏洞。可以看出,通过上述设计,就可以确保记录的数据可信、可用
在企业管理信息化的实现过程中,客户价值的核心内容是“效率、效益”,实现这两点主要取决于业务功能的设计。
3.数据层的价值数据层建立的数据标准、业务编号标准,以及主数据等的重要性在于:它们直接地关系到未来企业积累的数据共享、数据复用是否可以实现。
在企业管理信息化的实现过程中,最终的客户价值还是要落在数据上,确保企业数据具有长久生命周期、最大化价值的前提,就是数据标准和标准化的数据。
应用价值,是对业务设计成果加上信息化处理方式的“包装”,从而使得传统业务和管理的处理方式获得前所未有的变化。最终用户是通过应用设计的成果,感受到由信息化带来的价值。
对比业务设计成果和应用设计成果就可以感受到业务价值与应用价值的不同之处,例如,以业务流程的变化来看两种价值的继承与不同。
1.业务价值业务架构设计中优化了业务流程,使得业务的生产过程比原来更加合理,减少了冗余,提升了工作效率,这就是业务设计带来的价值:业务价值。
2.应用价值在应用设计中, 将业务设计优化过的业务流程再按照“事找人”的方式进行设计,从而使得业务流程自动驱动业务处理的推进 ,避免了“人找事”的低效工作,这就是应用设计带来的价值:应用价值。是否可以感受到两种价值的不同以及承接关系呢?
(1)架构层:以“事找人”为主线设计,以“人找事”为主线的设计方法等。
(2)功能层:按照“任务”的理念去设计业务组件(加入管理、知识支持等)。
(3)数据层:如何将“文字型数据”转换为“数字型数据”,提升数据的价值。
价值设计的关键就在于:软件设计师是否有“应用价值”的意识、理念,如果有这样的意识,那么可以让客户感受到信息化带来的价值的方法很多。
在前面已经介绍了在软件工程中的各个阶段、环节中都可以进行客户价值的设计,前面的设计案例总体来说还是属于“功能”层面的价值设计,是从软件设计师的视角进行设计的,相对而言还是比较单纯的价值设计。
对于企业管理信息化类型的系统来说,如果设计到位,信息系统不但可以帮助提升企业的工作效率,还可以为企业提升效益做出相应的贡献。
客户对完成信息系统的满意度取决于系统中包含客户价值的多少,而价值的多少又与软件设计师在设计时对客户价值的意识有着紧密的关联。不论什么样的信息系统,都是通过软件设计师设计出来的,针对同样的业务领域、具有类似功能的系统,为什么客户会有不同的评价呢?理由就是客户感受到的价值不同,价值不同是造成客户对系统评价不同的重要因素。因此,在软件设计师完成了对业务功能的理解、分析、规划、设计之后,一定要再从客户价值的视角再进行一遍审视,从企业的决策层、管理层到执行层,再从目标需求、业务需求到功能需求,检验设计是否有清晰的“客户价值”。前面讲过的架构层、功能层、数据层以及管理设计,这些设计都是有流程、方法、模板/模型等可以参考的,但是价值设计是没有相应的流程、模板作参考依据的,它的存在与否、价值的高低等都取决于软件设计师自身的知识、经验以及他对项目内容的判断等,最为重要的是作为软件设计师是否时刻有为客户提升信息化价值的意识。经过了近二十年的发展,企业管理信息化的活动从最初购买千篇一律的软件功能,进入到了个性化管理的时代,管理信息系统的设计理念与软件设计师的思想也逐步地发生了变化,要求软件设计师:
(1)从“软件功能本位”转为“客户价值本位”。
(2)从“我这里有××产品/功能,你需要吗?”转为“你有什么需求,我来帮你解决”。
(3)从“卖一款软件产品”转为“通过咨询、优化设计,提供综合服务”。
(4)从“开发固化功能的产品”转为“提供通过组合可以实现按需应变”的系统。
对于企业来说,管理信息化的行为越来越不是简单地购买一款软件商产品的问题,管理信息系统是企业运营管理的有机组成部分,所以软件企业,特别是软件设计师一定要跟随时代的变化,从一名功能的设计师转变为企业管理信息化的参谋、顾问、引导者。
价值设计并不“虚”,价值设计可以打开你的思路。
如果从价值的视角出发再做一次需求的话,会有很多的功能需求被提出来,而且一定会得到客户的赞同,从价值出发找到的功能需求能给客户带来意想不到的惊喜,比普通的功能需求带来的客户满意度更高。同时,客户价值的提升,反过来也为软件企业本身带来了价值的提升,形成了良性循环。
并且抽象它们不同的层次和角度。建议用数学语言来抽象事务和问题,因为数学是最好的抽象语言,并且它的本质就是抽象。将复杂的问题分解成可以管理的片断会更容易。将问题或事物分解并模块化这使得解决问题变得容易,分解的越细模块数量也就越多,它的副作用就是使得设计者考虑更多的模块之间耦合度的情况。所谓"需求分析",是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。可以说,在软件工程当中的“需求分析”就是确定要计算机“做什么”,要达到什样的效果。可以说需求分析是做系统之前必做的。
软件设计是把许多事物和问题抽象起来,并且抽象它们不同的层次和角度。建议用数学语言来抽象事务和问题,因为数学是最好的抽象语言,并且它的本质就是抽象。将复杂的问题分解成可以管理的片断会更容易。将问题或事物分解并模块化这使得解决问题变得容易,分解的越细模块数量也就越多,它的副作用就是使得设计者考虑更多的模块之间耦合度的情况。所谓"需求分析",是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。可以说,在软件工程当中的“需求分析”就是确定要计算机“做什么”,要达到什样的效果。可以说需求分析是做系统之前必做的。