需求分析之道——需求分析要做什么（C系架构设计法，sishuok）

需求分析之道——需求分析要做什么。

需求分析是架构师开始做架构设计的第一步，对架构师来讲非常非常的重要。因为需求分析能够告诉我们，到底我们要做什么，架构设计就是为了去完成这件事情而做的。

接下来，我们就从实战的角度来讲一讲，需求分析的一些方法，都是咱们多年经验的总结，也许听上去或者说大家看上去，没有那么高大上，但是是非常实用的知识，从几10万的小项目到数千万的大项目都可以用得上这些方法。

咱们要做一件事情，首先要紧盯目标，这样你才能够找到自己前进的方向；然后再盯脚下的路，找到具体做事的方法。一步一步，认认真真去做，最终达到这个目标。这里也一样，先来看看需求分析的目标是什么？

一：需求分析的目标：

是尽可能准确、全面、深入的理解业务。

关于这个话题，内容比较多，特别在上一篇《深入理解需求分析的目标》详细讲述了，这里就不再啰嗦了。

二：识别重难点业务

第二个大的任务，就是识别重难点业务。这个可能要求架构师有一定的业务经验，这个也算是架构师的一个基本功。拿到需求过后，架构师要能够快速的识别出里面的一些重难点的业务，足够的业务经验，就能告诉我们，要做这样子的业务，里面有哪些功能是非常重要的，有哪些业务可能是比较难做的，也就是咱们俗称的重难点的业务。

识别出重难点业务有什么样的作用呢？就是接下来，在进行分析设计的时候，我们要重点去考虑这些重点业务、难点业务的实现，如果能够把重难点的业务都解决了，一般来说，常规的、相对普通一些的业务功能，咱们的架构设计，是能够很好的去满足的。

这些重难点业务，很可能会影响到咱们后面的，包括像技术选型、具体的架构设计、架构形式，可能都会受到它的影响。

毕竟，软件只是一个工具，工具嘛，不就是用来干活的吗？软件是用来干什么的呢？就是帮助用户或者客户，实现业务活动的工具。架构设计是干什么的呢？架构设计是为了把软件造好，也可以说它是为了软件服务的，开发和制作软件这个工具。

所以，我们要去识别重难点业务，软件就是来解决这些业务问题的，肯定首先盯的，就是要解决重难点的业务，这些解决了，那些普通业务肯定能解决。是这个道理吧。

咱们的架构设计，就是在考虑，我怎么能够把这个软件做好。因此，对于重难点业务的把握，可能就直接决定了架构设计的成败，咱们一定要非常非常的重视。

这一点对于经验弱一些的架构师，可能就是一个小小的问题了，因为刚开始，他可能不能很快的去识别这些重难点的业务，但这个也没有关系，即使你刚开始没有识别出来，那你就尽量验证的全面一些。比方说，做完你的架构设计了，在做架构验证的时候，你就多挑一些业务来验证你的这个架构设计，这样也能够避免出现一些问题。

三：识别非功能需求，还有质量约束

第三的一个，要去识别非功能需求，还有质量约束。

啥叫非功能需求呢？就是除去咱们的业务功能需求之外的，剩下的这些需求，统称为非功能性需求，通常也是软件质量约束的一部分。

比如说，我们对这个系统提出了一些要求，但不是功能性的，常见的有：性能方面的要求，可靠性方面的要求，可扩展性方面的要求，可维护性方面的要求等等的。当然也还有其他的，比如说安全的要求，备份、恢复的要求等等，这些要求对于架构设计的影响也是非常非常大的。

很多都是架构设计要重点考虑的一些问题，比如说像性能问题，可靠性问题，高并发问题，海量数据的问题，可扩展的问题等。这些对咱们做架构设计都是有非常大的影响的，所以，在做需求分析的时候，就要把这些识别出来。

最后想要强调一点，需求分析对架构师而言，是非常非常重要的。可以这么说，需求分析是架构师做架构设计的起点，需求分析没有做好，后面的全部都是在瞎做。

因为，需求分析会告诉我们：到底要做什么？如果说，连要做什么，我们都不知道，那你想想，如果一片迷茫的情况下，就去做所谓的架构设计，请问这个架构设计为谁做的？做来干什么？

现在有一些所谓的架构师，轻业务而重技术，成天高谈阔论很多新的技术，各种技术大词、名词满天飞，为了技术而技术。但是他忘了架构设计的初心，架构设计的目的是为了软件服务的，是为了更好的去开发和制作软件这个工具，仅此而已，不是为了你去炫耀技术的。

可以毫不客气的说这些人，根本就算不上是真正的架构师，我们可以称之为是伪架构师，或者说是PPT架构师，有那么一句话：“离开业务场景谈架构设计，那就是在耍流氓”。所以说，大家一定要重视起来，业务很重要，需求分析很重要。

为了大家更好的交流架构设计的思想和知识，大家可以加sishuok，拉你进架构设计群，一起共同学习，共同进步。