告诉老默：响应需求变更这个老难题，该解开了！

需求变更是必然的

VUCA时代，变化是不可避免的。试图冻结需求的做法并不能真正地阻止需求变更的发生，大多数尝试冻结需求的活动最终都失败了，因为需求是无法在最初设计到100%，所以一定会在后面发生变更。

为什么很多人想要避免需求变更？因为需求变更对于大多数的SRS来说简直就是噩梦，小的需求变更就有可能引起文档的大幅度调整，究其本源就是文档书写方式本身对需求变更不友好造成的。因此也有一个对应的做法——冻结需求，但是冻结需求并不现实。需求冻结只是个美好的愿望，当发现了需求本身的疏漏的时候，就需要弥补；当外界经营环境发生变化的时候就要作出应对。所以，冻结需求只是一厢情愿的事情。

响应需求变更才是正确的方法——拥抱需求变更。在发生需求变更时做好应对的准备，才是提升企业竞争力的关键所在。因此，想要更好地面对需求变更，要探究需求变更的本质，通过本质来探索发生变更时应该采取哪些策略。UPerform

变更的种类

从变更的角度来看可以分为外部变化和内部变化。

1.外部变化

外部是指市场、业务及实施条件的变更；业务流程、工作流程变更；角色及操作权限的变更等。对外部变更应该采取拥抱变化的态度。

2.内部变化

内部是指BA推翻了之前的设计，或对之前的设计进行变更。

设计不当：由于业务需求分析理解不当，或思维能力局限导致的僵硬设计，导致需求无法持续兼容而导致的变更。此类变更可通过提高业务需求分析能力水平和系统化的分析工具得到改进。

设计缺陷：由业务需求分析设计失误造成的逻辑缺陷，不应该叫需求变更，但对开发者来说，它也是一种变更。因此对于内部变更来说，应该采取尽量避免的方式处理。

从变更的幅度来看，有的是彻底推翻重写，有的是扩展，有的是变更。但是不同的设计也会造成同一个变更影响幅度不同。例如2019年日本改年号为令和，这要求几乎所有的系统都要变更。如果当初设计的时候时间的取值都是来自同一个模块，那么修改就很容易。如果时间模块散落在很多地方，那么修改时影响范围非常大。

无法快速响应变更的原因

不分层：未分层的需求比较僵硬，变更时难免牵一发动全身。

过耦合：采用类似锯齿式的方式书写逻辑，造成每次修改的时候都要重新设计逻辑，容易出现错误。

重复：同样的逻辑写了若干次，导致每次变更时都要到处修订。UPerform

响应需求变更的方法1-抽象:

1.抽象概念

采用抽象的方式可以将相似对象共同的部分提取出来。当增加新的功能时，可以减少对现有设计的影响，并将修改控制在更加明确和有限的范围内，从而降低维护的成本。

2.抽象说明

在抽象层次上做通用的需求设计，当增加类似的新功能或选项时，无须在设计中改变抽象的部分。当变更时，共同的变更只变更抽象层，这样在具体变更时，只变更某个具体的需求。扩展新的时，对原有的处理没有影响。

3.抽象策略

采用抽象思维能帮助我们从众多的业务场景中找到通用结构或者通用逻辑。而应用抽象思维进行设计，可以引导面向对象的编码或者函数式编程以确保代码的可扩展性和可变更性。

对相同事物的抽象：找出事物的相同点，并对其进行抽象。

对相似事物的抽象：找出事物的相似之处，并且对其抽象。

响应需求变更的方法2-分层

1.分层概念

需求过大时，采用分层的方式描述。分层结构的需求勾画，可以减少顶层的变化的可能性。在不同的层次描述不同的内容，从上层往下钻，可以逐渐看到细节。这样当每层修改时，不影响上层。采用分层的方式可以将需求由粗到细地表达，既易于管理也方便阅读，且在变更发生时可以更快速地定位。

2.分层说明

分层法用于解决庞大的需求难以组织的情况。

对于较大体积的需求来说，如果把所有的文档内容按照线性的方式进行组织，会造成查找资料困难，不容易阅读的情况。分层法把庞大的需求分层来处理。最高层只描述需求的主要流程，其中的细节都不进行描述，而放在下沉的层中去。这样通过快速阅读最高层需求就可以理解整体系统的目标和流程。

想要了解某个步骤的细节，则下钻到下一层，阅读对应的文档。第二层中对应的文档中描述需求的细节，如果这一层仍然比较庞大，则可以分解到下一层，如此循环直到最后一层足够的详细。

采用分层法不仅可以将需求进行分层管理和描述，并且可以利用分层对需求进行解耦合，减少需求变更的影响范围。将需求进行分层降低需求的僵硬度，避免进行变更时造成牵一发动全身，避免每次需求变更时每次修改都要重新设计逻辑，降低出现错误的概率，同时避免同样的逻辑写了若干次，导致每次需求变更的时候都要到处修订。

3.分层策略

● 策略1：采用树形目录

一棵树，由枝和叶构成。树形目录是一种常见的文档管理结构，各种电脑系统都在用树形文档结构。多棵树放在一起就构成了森林。森林型文档结构通过将文档以“模块”，“类型”，“角色”等若干个视角进行不同的贯穿，可以很方便地进行文档的规划和阅读，能够更好地解决过去需求文档管理中的各种问题。

就像查字典一样，有人愿意用拼音查字法，有人愿意用部首查字法，有人愿意用笔画查字法。不同的人有不同的习惯。但是不管哪种查字法，都是为了能够更有效地连接到具体的内容的一种手段。

图上的每个有颜色的矩形表示一个需求内容片段以及各种需求分析工具。例如：流程图、原型、决策矩阵、判定矩阵都是上述的需求片段。而对其的编目方式则是需求文档的有效阅读方式的建立过程。这里给出了三个例子：

分模块视图：以模块的方式来组织目录，这种方式也最常见。想要阅读哪个模块的内容就从哪个模块入手。

多角色视图：通常是利用Tag等方式，让不同的角色可以看到自己最关注的内容，比如说，UI设计师关注的是UI的原型；后端工程师注重的是业务逻辑，存储对象；前端工程师则对交互方式比较在意。

项目管理视图：对于Scrum的管理方式来说，可以是以用户故事为单位组织的任务。

还可以增加更多的需求文档管理方式，以便能够更好地让读者快速地找到自己关心的内容。但是需要注意的是，每种视图都有自己的方式连接到需求片段上，可以支持各种快速阅读。除此之外，这个文档管理体系还可以确保文档通过版本管理的方式始终保持最新，能够快速确认文档版本之间的差异。支持新人快速阅读等。

● 策略2：需求文档分层

系统整体的介绍文档应独立出来，这样当新人加入项目的时候可以很容易地接收到项目的主要信息，从而可以快速地加入到项目中。负责某个模块的开发人员可以从主需求文档按照模块分布，快速地定位到自己的负责模块，快速理解需求。

● 策略3：解决共通的依赖

术语和概念：系统中所涉及术语进行定义，集中存放，容易查找。界面布局规定：界面布局的定义的统一规范可以帮助减少不必要的界面设计工作，如果有些界面的布局和标准的一致，只要说明其中的字段即可，而无须多花费一份工时去绘制。

消息定义：系统中会有各种统一的消息定义，在显示的时候只是具体的参数不同。可以将所有的消息统一定义，在需要的时候进行引用。这样可以防止消息显示的时候各自措辞不一致，包括标点符号不统一的情况出现，并且这个也符合各种软件开发框架的特点。UPerform

响应需求变更的方法3-解耦

1.解耦概念

解耦是需求分析能够很好地响应需求变更的一个重要手段。采用解耦合的方法可以在需求发生变化的时候，以较低的成本进行开发、容易阅读的方式向开发团队和业务部门呈现需求的变更。

解耦合的方法是将关注点分离，即将能够引起变化的点分开阐述，突出重点。这样当需求发生变化的时候，影响的范围更受控也更容易调整。这种方式具备以下特点：

增强需求文档的灵活性；

引导开发人员进行同样解耦合的代码设计；

通过高度抽象，提高信息的可复用性。

2.解耦说明

耦合是指两个或两个以上的要素的集合体输入与输出之间存在紧密配合与相互影响，某一方的变动会影响到另一方的变化。在需求分析中，需求耦合主要是指多个功能模块或者逻辑存在“剪不断，理还乱”的交叉，存在很强的牵连性。这种情况会造成变更困难、技术实现难度高。耦合越高，维护成本越高。

通过分离将引起变化的原因进行解耦合，让每个需求的文档片段产生变更的原因最好只有一个。这样当需求变更发生时，只影响对应的片段，而不至于任何微小的变化都会影响到整体，从而降低响应需求变更的成本。

模块之间的耦合程度越低，相互影响就越小，发生异常后产生连锁反应的概率就越低。这样在修改一个模块时，低耦合的系统可以把修改范围尽量控制在最小的范围内。这样对一个模块进行维护时，其他模块的内部程序的正常运行不会受到较大的影响，可以轻松地扩展新功能，也可以轻松地改变现有功能。在扩展新功能时，需要为新功能添加新的文档，不影响现有功能。当改变现有功能时，只需改变功能文档，不影响其他功能。

3.解耦策略

● 策略1：界面解耦

显示界面在不同的终端上有不同的展示方式，比如说PC上屏幕面积大，所以展示详细信息。在手机上屏幕面积小，所以展示的是摘要信息，存在布局不同的情况，导致手机显示和网页显示会明显存在不同。

因此需要我们在进行需求分析时我们应考虑保持显示界面与数据的分离，在后期当界面需求发生改变，只需要改写界面的代码，降低耦合度，同时提高整体项目的易维护性。

● 策略2：适配器解耦

可以采用适配器的方法来进行解耦。适配器模式主要是把一个类的接口更换成所期待的另一种接口。Adapter可以假设为万能插座的意思，比如USB接口也是一种特别常见的Adapter。从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。Adapter不仅不是为了解决还处在开发阶段的问题，同时也是解决正在开展的项目问题。

因此在考虑数据和显示分离时，我们首先应该注意数据接口是否为同一个、是否返回同样格式的数据？具体操作我们可以采用适配器(adapter)的方式，各个显示终端自己根据自己的需要来展示。

适配器我们可以按照下图的方式进行理解：

在使用适配器时，用户的角度看不到被适配者的。用户调用适配器转化出来的目标接口方法，适配器再调用被适配者的相关接口方法，用户收到反馈结果，感觉只是和目标接口进行了交互。我们可以把每个终端当成一个适配器，通过这种方式将数据的操作和显示分离，达到了解耦合的目的达到可以扩展更多的类似设备，为系统提供了更多的扩展性，同时也降低开发成本和运维成本。

同理跨系统API也是一样。当你需要对接若干个类似的平台，但是每个平台之间都有细微差别的时候可以用adapter模式。例如：需要对接多个商户的交易数据，通过适配器将它们的接口适配为统一的接口定义，这样我们可以复用、调用对应的数据，并且在接口变更时不会对其他数据造成影响。