架构的第一步是什么？很多人会脱口而出：画图、选型、搭框架。但真正在水中游过泳的人才知道，下水之前，最重要的是看清水流的方向。
需求分析，就是这潭水里最容易被忽略的暗礁。
做软件的目的，是满足用户需求。这个答案简单到几乎没有人会质疑。但真正的问题在于：用户需求是什么？你真的清楚吗？
需求分析的必要性，体现在三个层面。
用户需求不是一份问卷调查能够穷尽的。用户说出的话，往往已经带着他所熟悉的技术方案的烙印。举个通俗的例子：用户说"我需要一匹更快的马"，但他的真实需求是"更快到达目的地"。从"马"到"速度"到"到达"，这是三次跳跃，每一次跳跃都是一次需求的重新定义。
架构师如果只听到"马"，那么费尽周折引进千里马，却发现用户真正需要的是一列火车——这种错位，是灾难性的。
用户需求想清楚了，并不代表产品边界就清晰了。任何行业的用户需求满足，必然存在行业分工。我们做什么，合作伙伴做什么，谁负责连接，谁负责交付——这些边界如果不能清晰划定，产品就会像一块无限膨胀的海绵，最终失去形状。
架构设计需要对子系统进行切分，而切分的依据，正是经过归纳与抽象后的用户需求。边界不清的系统，模块之间的耦合必然如同乱麻。
什么是过度设计？尚未发生的事情，你提前为它做足了准备——这就是过度设计。
判断是否过度设计并不容易，它要求对需求未来的演化有精准的预判力。而这种预判力，恰恰来自于扎实的需求分析。脱离需求谈扩展性，是架构师最容易踩进的泥潭：为了一个"也许会用到"的功能，搭起了一套"永远不会被调用"的框架，代码复杂度陡增，维护成本悄然攀升，等到真正需要重构的时候，才发现地基已经锈迹斑斑。
需求分析的过程，必然涉及以下这些内容的思考。
面向的核心用户人群是谁？用户的原始需求是什么，最核心的问题是哪几个？在这个领域里，已经有哪些玩家，上下游有哪些类型的公司？在遇到我们之前，用户是如何解决他们的问题的，我们的替换方案又是什么？
进而，我们的产品创造的价值点是什么？用户最关注的核心指标是什么？用户需求潜在的变化在哪些地方，哪些是变化点，哪些是稳定点？
这里有一个值得细细品味的概念：稳定点与变化点。
稳定点，是系统不变的核心能力。无论用户需求如何演进，有些东西是相对稳定的，它们构成了产品的基石。变化点，则是那些可能随着业务发展而调整的部分，需要我们在架构层面预留扩展的空间。
但这里有一个极其关键的前提：讨论变化点和稳定点时，必须有明确的坐标系。从不同视角出发，稳定点和变化点的判断可能完全不同。
以计算机为例：设计一台计算机，外部设备的多样性是变化点。但如果我们今天是在设计一台显示器，外部设备的多样性就不再是讨论的焦点，变化点和稳定点完全不一样了。所以，所谓变化点，本质上是一次产品边界的确立过程——我做什么，把什么交给合作伙伴，又通过什么接口与合作伙伴配合。
有一种观点认为：需求分析是产品经理的活，架构师只管实现。这种分工听起来合理，但细想之下却经不起推敲。
架构师的核心特色就是，工作内容范围不要设置边界
产品文档是产品经理与用户沟通后的二次加工，是需求的提炼与再包装。无论产品经理多么优秀，原汁原味的用户诉求在传递过程中总会发生损耗。就像一道菜经过层层转手，最后端上桌的味道，已经和厨师最初调制的有所不同。
架构师自己走近用户，去体会用户的述求，这一步不可省略。更重要的是，大部分人并不会仔仔细细阅读他人写的文档。如果团队文档的平均质量不高，阅读者的心态也会受影响——他们可能只扫一眼标题就跳过正文，这进一步加剧了信息传递的失真。
产品经理需要有技术高度。他不必深刻了解技术原理，但必须深刻理解新技术的边界——某项技术能够做什么，不能做什么，顶级产品经理甚至比实现这项技术的开发人员还要清楚。认为产品经理不需要理解技术，是一种普遍存在的误解，但未必符合这个岗位的内在诉求。
产品定义过程需要反复推敲琢磨，并最终成型。这个过程，单靠产品经理是不够的。架构师在技术实现侧的深度参与，能够补全产品经理可能缺乏的技术广度。两者在产品这座桥的两端相向而行，最终必然殊途同归。
产品经理和架构师是一体两面。两者都关心用户需求与产品定义，只是出发角度不同。
方法论层面的总结，往往不如心态层面的提醒来得重要。
除了在心里对需求反复推敲的严谨态度之外，对用户反馈的尊重之心也至关重要。用户说出来的需求，往往是经过他们自己加工后的方案，而非原始诉求。多问几个"为什么"，多推敲几次，把它还原到不带任何技术实现假设的根源需求。
根源需求可能对应非常多的技术方案。用户反馈的每一个"点"，只是他们站在自身立场上给出的解法，而这些解法未必是最优解。架构师的任务，是回到根源，看清本质，然后从技术视角给出更优雅的解答。
但问题在于，有一类需求决策起来非常困难：不做，可能丢失这个客户；做，如果放宽标准，产品的需求就会被无限放大，最终做出一个四不像的东西。厘清这一类边界，需要团队坐下来反复拷问，不断明确响应需求的正确姿势。
根源需求的挖掘，是需求分析中最见功力的部分。用户反馈需求时，通常已经带着他自己熟悉的方案烙印。这种经过二次加工的需求，需要我们一层层剥开伪装，回到最原始的诉求。
一个常见的情形：用户说"需要支持批量导入"。表面上看，这是一个功能需求。但当我们追问"为什么需要批量导入"，答案可能是"每次手动录入太慢"。再追问"为什么慢"，可能发现是"数据量太大"。继续挖掘，根源可能是"现有系统响应速度太慢，操作一次需要等待三十秒"。
你看，从"批量导入"到"系统响应速度"，这是完全不同的两个问题域。找到了根源需求，我们才可能给出真正优雅的解决方案——也许不是做批量导入，而是优化系统的响应时间，让单条录入也足够快。
在理清需求之后，需要对需求进行归纳整理。一方面，将需求归类到不同的子类别中，形成清晰的需求结构；另一方面，形成对变化点和稳定点的基本判断。
这里需要强调的是：产品功能必须是收敛的，必须是可完成的。如果某个子类别的需求呈现出发散而无法收敛的趋势，团队一定要停下来反复推敲。一边是用户不断提出的新需求，一边是产品边界不断被突破，这个矛盾如果不能及时化解，系统就会陷入无休止的泥沼。
需求分析的目标和最终结果，是形成清晰的产品定义。
产品定义，并不等同于产品需求的归类。产品是桥，一端连接用户需求，一端连接先进技术，所以产品定义不可能做到和技术方案完全无关。
产品定义的要素，包括以下几个方面。
定义产品中的元素，以及这些元素的各类操作方式。 如果从技术视角来理解，这就是定义对象和方法。但产品视角下的对象和方法，与技术视角并不完全一一对应——一个技术上的方法，从产品需求角度可能会有多条路径的操作方式来达到相同的目的。
确认产品如何满足用户需求。 用户的使用场景未必全部是产品所能直接满足的，面向特定的行业，可能需要相应的行业解决方案，把产品整合进去。这里需要保持开放的心态，优先寻找合作伙伴来完成这类行业的需求覆盖，而不是试图把一切都纳入产品本身。
考虑市场策略。 产品如何进入市场，和既有市场格局中的其他主流解决方案的关系是什么？我们希望获取的用户，大部分已经有一个既有的产品在满足他们的需求。在考虑如何让客户从既有方案迁移到我们的产品时，产品边界的确定会复杂很多。在一些极其关键的市场，我们有可能会把迁移需求视作产品需求的一部分；但更多的情况下，产品只为市场上的主流方案提供迁移路径，而不是完整的迁移方案。
需求分析，是架构设计的地基。地基不稳，上层建筑再华丽也会摇摇欲坠。
需求分析的核心要点如下：