大话软件工程：需求分析与软件设计（二十）

        前面完成了业务设计（概要／详细）、应用设计和管理设计，到此为止，非技术层面的设计工作就已经全部结束了，软件设计师（业务、应用、技术），除去前述的主要以逻辑和功能视角进行的设计以外，还应该有一个非常重要的设计视角，即客户价值视角。价值设计，不是软件工程中的一个独立设计体系，但它是软件设计的重要目的，在前面各阶段的设计中已经反复地强调了价值，这里将有关客户价值设计的内容进行汇总，从客户价值的视角出发再重新审视一遍前面做过的设计，软件工程上每个阶段或是每层的设计实际上都是围绕着客户价值进行的。

        综合设计-价值设计，作为软件工程-设计工程中的提高部分，除了需要已经基本上掌握了业务设计和应用设计部分的知识以外，还需要站在客户的视角， 时刻思考：怎样用信息化的手段来为客户提供价值？

        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）从“开发固化功能的产品”转为“提供通过组合可以实现按需应变”的系统。

        对于企业来说，管理信息化的行为越来越不是简单地购买一款软件商产品的问题，管理信息系统是企业运营管理的有机组成部分，所以软件企业，特别是软件设计师一定要跟随时代的变化，从一名功能的设计师转变为企业管理信息化的参谋、顾问、引导者。

        价值设计并不“虚”，价值设计可以打开你的思路。

        如果从价值的视角出发再做一次需求的话，会有很多的功能需求被提出来，而且一定会得到客户的赞同，从价值出发找到的功能需求能给客户带来意想不到的惊喜，比普通的功能需求带来的客户满意度更高。同时，客户价值的提升，反过来也为软件企业本身带来了价值的提升，形成了良性循环。

大数据技术在数据采集方面采用了哪些方法：

1、离线采集：

工具：ETL；

在数据仓库的语境下，ETL基本上就是数据采集的代表，包括数据的提取（Extract)、转换(Transform)和加载(Load)。在转换的过程中，需要针对具体的业务场景对数据进行治理，例如进行非法数据监测与过滤、格式转换与数据规范化、数据替换、保证数据完整性等。

2、实时采集：

工具：Flume/Kafka；

实时采集主要用在考虑流处理的业务场景，比如，用于记录数据源的执行的各种 *** 作活动，比如网络监控的流量管理、金融应用的股票记账和 web 服务器记录的用户访问行为。在流处理场景，数据采集会成为Kafka的消费者，就像一个水坝一般将上游源源不断的数据拦截住，然后根据业务场景做对应的处理（例如去重、去噪、中间计算等），之后再写入到对应的数据存储中。这个过程类似传统的ETL，但它是流式的处理方式，而非定时的批处理Job，些工具均采用分布式架构，能满足每秒数百MB的日志数据采集和传输需求

3、互联网采集：

工具：Crawler, DPI等；

Scribe是Facebook开发的数据(日志)收集系统。又被称为网页蜘蛛，网络机器人，是一种按照一定的规则，自动地抓取万维网信息的程序或者脚本，它支持、音频、视频等文件或附件的采集。

除了网络中包含的内容之外，对于网络流量的采集可以使用DPI或DFI等带宽管理技术进行处理。

4、其他数据采集方法

对于企业生产经营数据上的客户数据，财务数据等保密性要求较高的数据，可以通过与数据技术服务商合作，使用特定系统接口等相关方式采集数据。比如八度云计算的数企BDSaaS，无论是数据采集技术、BI数据分析，还是数据的安全性和保密性，都做得很好。

数据的采集是挖掘数据价值的第一步，当数据量越来越大时，可提取出来的有用数据必然也就更多。只要善用数据化处理平台，便能够保证数据分析结果的有效性，助力企业实现数据驱动~

1．引言 3

11编写目的 3

12项目背景 3

13定义 3

14参考资料 3

2．任务概述 4

21目标 4

22运行环境 4

23条件与限制 4

3．数据描述 5

31静态数据 5

32动态数据 6

33数据库介绍 6

34数据表 6

35数据采集 6

4．功能需求 7

41功能划分 7

42功能描述 7

421采购管理 7

422器具管理 8

423检定管理 8

424台帐管理 9

425维修管理 9

426环境因素管理 9

5．性能需求 10

51数据精确度 10

52时间特性 10

53适应性 10

6．性能需求 10

61用户界面 10

62硬件接口 10

63软件接口 10

64故障处理 10

7．其它需求 11

软件需求 = 业务知识 + 问题列表 + 其他因素。

业务知识：业务事件，业务实体，业务规则。

问题列表：用户在工作中遇到的困难和障碍，也是软件需要解决的问题。

其他因素：设计约束，非功能性需求等。

3111 业务需求

业务需求是系统的高层次目标要求，即系统的建设目标，这种目标通常体现在两个方面：问题和机会。

业务需求的提出通常是高层管理人员，它是团队努力的方向。但如果业务需求过于夸大，可能会导致不必要的资源浪费。

业务需求是在项目立项阶段整理，也就是需求定义的产物。关于业务需求定义的方法，将在“第四章 需求定义最佳实践”中讲解。

3112 用户需求(也叫原始需求)

用户需求是需求捕获的产物，是指用户使用软件需要完成什么任务，怎么完成。通常在业务需求定义的基础上进行调查整理。

用户需求有几个特点：

》零散：用户会提出不同角度，不同层面，不同粒度的需求。

》存在矛盾：由于用户处于企业不同位置，需求具有片面性，不同用户将存在不同观点。

正因如此，我们需要对用户需求进行分析，整理，从而得出更精确的需求说明。

3113 软件需求

软件需求就是用户需求整理后的产物。

业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。

软件需求可以分为功能需求，非功能需求和设计约束三种类型。

3121 功能需求

功能需求的要点在于如何组织。

对于功能需求的组织形式有以下几种：

》层次结构。在传统方法论中，会以系统-子系统-模块-子模块-功能-子功能的层次结构来组织，这也是一种方法。但它更多是一种程序结构，而非需求结构，它很可能会割裂用户的使用场景。

》RUP方法论中的用例方法。

》敏捷方法论中的用户故事。

》特征驱动开发中的Feature。

笔者建议首选用例方法，详细内容将在“第六章 需求分析与建模最佳实践”中介绍。

3122 非功能需求

对于非功能需求最典型的问题有两个：

》信息传递的无效性：在前面的章节也讲到过，许多需求规格说明书中都有“设计原则”这一章，里面写着：高可靠性，高可用性，高扩展性等要求。但没人真正去看它，因为定性描述是没有判断标准的。所以这种就是信息无效传递。将在“第七章 需求描述最佳实践”中说明解决办法。

》忽略了非功能性需求的局部性。有时会看到“所有查询时间都应该小于10秒”。但当用户执行年度查询时，这是不合理的要求，最终也变成摆设。所以要抓住具体的场景来描述。

非功能需求的要点在于保证信息的有效传递和注意其局部性。

3123 设计约束

设计约束包括非技术因素的技术选型，预期的软硬件环境和预期的使用环境三大类型。

在收集设计约束时，不能出现遗漏：

》非技术因素决定的技术选型。

》预期的软硬件环境。在整理需求时，应该将这些预期的软硬件环境描述出来，最有效的方法就是部署图，将在“第六章 需求分析与建模最佳实践”中讲述。

》预期的使用环境。

完整性，正确性，无歧义性，必要性，有优先次序，可行性，可验证性。这7个标准可以分为4组。

3121 完整性

完整性就是没有遗漏。将来在需求变更时“新需求”占比会较少。但在实际需求活动中，完整性是一个难题。完整性的关键在于以下两个方面：

》用户才是验证需求完整性的合适人选。但是用户往往需求都提不完整，如何对完整性进行验证？问题还是在需求组织结构上。很多人在组织需求时，通常是按照程序结构来梳理，这样做的结构就是用户在验证完整性时遇到障碍，无法直观系统的了解系统是否能满足所有需求。要保证需求的完整性，就必须从业务角度来组织各种需求像，让用户验证需求规格说明书中罗列的主题域，业务事件，业务活动，业务步骤，困难与障碍点是否完整。

业务导向的需求层次结构是保障完整性的关键。

》需求完整性存在不同层面。需求是有层次的，企业中高层，中层， *** 作员所了解和掌握的信息是不一样的， 在验证需求完整性时，需要采用分层评审的方式 ，不同层次的人员评审与自己相关的需求层次。

3122 不失真

需求的正确性和无歧义性就是不失真。

》正确性。要使需求正确，一方面要分层次验证，一方面应该找到直接相关人员进行验证，另一方面，为了避免片面性，还要通过用户调查来补充。更多细节将在“第五章 需求捕获最佳实践”中介绍。

》无歧义性。是指在传递过程中不同的人加入不同的理解。因此光靠文档来传递需求是不充分的，沟通和验证活动能尽量缓解歧义问题。

3123 有优先级

需求有时会戴上“高优先级”的面具，实际上只是担心你不实现而已。

所以引导用户从业务角度划分优先级是最关键的。除业务角度外，也要考虑技术角度和项目管理角度。

》从必要性的角度评价优先级

满意/不满意模型是需求必要性评价的有效手段。

3124 技术人员早期参与

需求规格说明书，来源于用户，提供给技术人员，包括开发和测试。所以与技术团队交流，探讨需求规格存在哪些不足，缺少什么信息，是改进需求规格说明书的有效方法。

》可行性，由开发软对重点需求项，及复杂技术解决方案进行验证。

》可验证性，由测试团队验证。

需求工程包括需求开发和需求管理。需求开发是指收集，分析，整理，编写，验证的全过程，重点在于产出高质量的需求规格说明。需求管理是对需求的实现，变化进行追踪的全过程，重点在于确保开发的软件满足需求。

注意，需求定义并不包含在需求工程中，这是因为需求定义通常叫做项目立项，属于项目管理的范畴。将在“第四章 需求定义最佳实践”中介绍。

现代软件工程的思想更偏向于多次循环，需求工程也不例外，通常需求获取，需求分析，编写规约，需求验证至少要经历三次循环。

对于需求获取，需求分析，编写规约，需求验证这四个活动，将在5-8章中详细介绍，这里只对其核心要点和盲区进行说明。

3221 需求获取(需求捕获)

需求捕获是一个主动的过程，而显示中却常常是比较被动的，主要体现在：

》捕获范围不足：只注重用户要实现什么功能，不注重对业务知识的捕获。

》缺乏计划性：捕获过程随意，预先没有对问题，时间，访谈人员进行计划。

》缺乏科学性：捕获过程比较分散，没有做到定向，聚焦，常常把宏观问题和微观问题混在一起。

》捕获对象不明确：很少主动寻找合适的被访谈者，常常是对方主动指定。

》捕获手段不足：通常认为只有用户访谈和调研会是有效手段，但忽略了不同场景下捕获手段的不同组合将有更好的效果。

“第五章 需求捕获最佳实践”中将详细说明需求捕获的策略，方法和工具。

需求捕获活动中，化被动为主动是关键。

3222 需求分析

需求分析是需求工程中的核心任务，但在实践中常被忽视，也就是捕获的需求直接整理到需求规格说明书中。

》需求分析是什么。需求分析是业务分析，因此要从业务线索入手，而非程序结构；需求分析是一种分解活动，将按职责划分成不同的主题域，再分解到业务流程，再分解到用例；需求分析是一种提炼与整合活动，将原始需求整合到业务活动中，将业务活动整合到全局业务流程图中；需求分析是一种规格化活动。将在“第六章需求分析与建模最佳实践”中详解。

需求分析就是向下分解+向上提炼，外加一些规格化。

》内容和形式

建模语言越来越流程，但一定要理解：分析是任务，建模是手段。建模的过程就是分析的过程。尽量团队建模；大胆使用草图，而不是一上来就开rose。

需求分析是目标，需求建模是手段。

3223 编写规约

编写规约就是需求分析结果文档化的过程。软件需求规格说明书的要点在于：分享，更新。

3224 需求验证

需求验证不是签字，细节将在“第八章 需求验证最佳实践”中阐述。

需求管理包括基线管理，变更管理和需求跟踪三个活动。

需求管理可以分为四步：统一明确的需求项划分标准，引入基线管理，引入变更管理，引入需求跟踪。下面将逐一讲解。

3231 统一明确的需求项划分标准。

》颗粒均匀。即衡量需求工作量的单位是相同的，人天，人月，人周都可以，但是需要统一。

》大小合适。

》完整。最低一级的需求项应该覆盖所有开发任务。

“第六章 需求分析与建模最佳实践”中将具体阐述。

划分出大小合适，颗粒均匀的需求项是需求管理的前提。

3232 引入基线管理

基线管理将需求分为两个部分：已经开始开发的需求(baseline)，还没安排开发的需求(backlog)。(一个基线内容就是Scrum里的一个冲刺)

在划分基线时，通常需要完成三件事：

1 确定优先级，确保高优先级，高风险的需求尽早完成。

2 工作量估算，确保每次迭代的安排是紧凑的。

3 未完成项的合并，每次迭代还是可能有些工作未完成，分配下一次基线时就要考虑进去。

具体将在“第九章 需求基线 *** 作事务”中距离说明。

需求优先级与工作量估算是基线管理的关键。

3233 引入变更管理

变更如果简单地转交给开发人员，会使开发团队变成救火队，陷入大量紧急却不重要的工作中 。所以引入变更管理是非常重要的。就需求管理而言，变更管理的重要在于完成业务影响分析，技术影响分析，项目影响分析三方面工作。具体可以参考“第十章 变更管理 *** 作事务”。

》业务影响分析：从业务角度对变更的合理性，优先级，对原有需求的影响进行分析，以便决定是否纳入backlog中。

》技术影响分析：从技术角度对变更的影响范围，工作量进行分析。

》项目影响分析：基于前面的工作量分析，考虑是否对整个项目的进度成本产生较大影响。

变更管理的核心是控制变更的影响，而非消除变更。

3234 引入需求跟踪

需求跟踪是一种高阶管理活动，将辅助大量的工作量，因此在前三个活动还不是很顺畅时，不建议引入需求跟踪。我们将在“第十一章 需求跟踪 *** 作事务”中介绍。

需求分析人员必须掌握的技能包括：倾听，交谈，提问的技巧，分析，协调，观察，写作，组织，建模，人际交往和创造能力。这些能力可以概括为业务知识，技术知识，沟通能力三个方面。

3241 需求分析人员的来源

推荐是以用户背景的人员(甲方需求人员)为核心，以开发人员作为解决方案的选择和技术论证(乙方需求人员)，领域专家作为顾问。

但在现实中，更多还是以乙方需求分析人员为主角，这时就要充分发挥用户背景的需求人员作为业务支持。

3242 各种能力培养的要点

对于沟通能力方面，在“第五章 需求捕获最佳实践”中有很多案例。

SERU模型分为三个阶段：Subject1-3是需求定义阶段，Event和Report4是理清脉络阶段，User case5是细节填充阶段。

》需求定义阶段：就是项目立项阶段。核心目标在于定义项目目标和范围。主要任务就是划分主题域，并标识出每个主题域中的Event(业务事件)和Report(报表)。

》理清脉络阶段：相当于需求捕获，分析和建模的第一阶段。就是将每个Event(业务事件)，每个Report(报表)进行分析，包括事(流程)，物(业务实体)，人(角色)的分析。

》细节填充阶段，相当于需求捕获，分析和建模的第二阶段。

以上就是关于大话软件工程：需求分析与软件设计（二十）全部的内容，包括:大话软件工程：需求分析与软件设计（二十）、需求获取技术有哪些方法、需求分析如何来做等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！