需求分析

软件设计的起点是需求，而需求分析的第一步是分层——不是所有需求都有同等的权重，把不同层次的需求混为一谈是很多项目失败的起点。一个实用的分层框架是把需求分为三层：基础需求决定产品的存在意义，刚需决定用户是否买单，亮点需求决定产品能否在竞争中胜出。

三层需求的定义

基础需求是产品的存在前提——不做完这些，产品根本无法成立。一个网盘的"上传和下载文件"是基础需求，一个即时通讯软件的"发送和接收消息"是基础需求。基础需求的特征是"用户不会因为它做得好而赞美你，但会因为它没有而离开你"。它构成产品的下限。

刚需是用户的核心痛点——用户为解决问题而来，问题解决不了用户就走。刚需与基础需求的区别在于：基础需求是"产品类别的要求"（是网盘就必须能传文件），刚需是"目标用户的具体诉求"（网盘用户可能刚需"大文件秒传"或"多设备同步"）。刚需的识别依赖对目标用户的理解——同一类产品，面向企业用户的刚需和面向个人用户的刚需可能完全不同。

亮点需求是差异化竞争力——做了用户不一定主动要求，但体验过之后会显著提升满意度，并成为推荐产品给他人的理由。亮点需求的特征是"不做不扣分，做了加分多"。典型的例子：Chrome 的地址栏即搜索框、微信的"长按翻译"、淘宝的"拍立淘"。亮点需求构成产品的上限。

三者的关系可以这样概括：基础需求保底，刚需成交，亮点需求溢价。

识别与分层的方法

分层的难点在于同一功能对不同用户可能属于不同层次。判断一个需求属于哪一层，有几个实用的测试问题。

"没有它会怎样"测试：没有这个功能，产品还能用吗？完全不能用 → 基础需求。能用但目标用户不会选择 → 刚需。能用且用户仍然选择，只是体验平淡 → 亮点需求。

"用户会不会主动要求"测试：用户会在反馈中主动要求的功能通常是刚需或基础需求的缺失；用户不会主动要求、但体验后给出正面反馈的功能是亮点需求。注意这个测试的方向性——用户主动要求的往往是"显性需求"，而亮点需求常常是隐性需求，需要产品设计者的洞察而非用户调研来发现。

"竞品对比"测试：所有竞品都有的功能 → 基础需求。竞品有但做得都不好、用户怨声载道的功能 → 刚需（这是竞争切入点）。竞品都没有的功能 → 潜在亮点需求（也可能是伪需求，需要验证）。

三层需求与开发策略

需求分层不只是分析工具，它直接影响开发策略和资源配置。

基础需求和刚需必须一次性做完整。基础需求的不完整是致命的——一个"偶尔能上传成功"的网盘不会因为其他功能优秀而被原谅。刚需的半成品同样致命——用户为痛点而来，痛点的解决程度决定了用户的去留。这两层需求的验收标准是"完整可用"而非"最小可行"。

亮点需求必须小步验证。亮点需求的本质是假设——"用户会喜欢这个差异化功能"是一个需要验证的假设。验证成本最低的方式不是完整开发，而是最小验证：先做一个粗糙版本给种子用户体验，收集反馈再决定投入。亮点需求的最大风险不是做不出来，而是做出来没人用——资源浪费在验证失败的假设上。

投入节奏上，基础需求与刚需先行，亮点需求迭代追加。这个顺序保证了每个开发阶段的产品都是完整的——完整但平淡的产品可以存活并积累用户，而残缺但闪亮的产品无法存活。亮点需求应该在产品稳定运行后，以迭代的方式逐个验证、逐个加入。

需求分析在软件设计中的位置

需求分层与设计的关系是：需求决定设计的复杂度和优先级。基础需求和刚需的设计要求是"正确"——架构要为这些核心路径投入最多的测试和验证资源，它们的可靠性要求最高。亮点需求的设计要求是"可实验"——功能开关、灰度发布、A/B 测试的架构支持，让亮点需求可以低成本地上线验证和回退。

这与可维护性形成呼应：基础需求和刚需的代码路径会被长期频繁修改（因为它们是产品的核心），因此这些路径的可维护性投入回报最高。亮点需求的代码路径可能随验证失败而整体废弃，过度设计这些路径是一种浪费。

需求分层最终指向一个朴素的工程纪律：不要用亮点需求的投入去做基础需求，也不要用基础需求的验收标准去卡亮点需求。分层混乱的项目，要么在核心功能上偷工减料（把基础需求当亮点需求做——做了但没做完整），要么在实验功能上过度投入（把亮点需求当刚需做——没验证就全力开发）。识别每个需求属于哪一层，是需求分析的第一课。