第二章 需求来源与分类

大家好，我是老张。今天咱们聊聊需求到底从哪来，又该怎么分门别类。说实话，我见过太多项目栽在需求混乱上——开发说「产品给的需求不明确」，产品说「用户自己都说不清楚要什么」。其实啊，只要把需求的来源和分类理清楚，很多问题就能提前规避。

2.1 需求的四大来源

我个人习惯把需求来源分成四类。你想想看，一个软件系统要落地，总得有人提要求吧？这些要求从哪冒出来的？

• 用户直接反馈：最直观的来源。用户说「这个按钮太小了」「导出速度太慢」，这些都是原始需求。
• 业务方/产品经理：他们代表公司或客户，提的是「我们要支持多语言」「需要对接第三方支付」。这类需求通常有商业背景。
• 竞品分析与市场调研：看对手做了什么，或者行业趋势是什么。比如「友商已经支持扫码登录了，我们得跟上」。
• 技术演进与合规要求：数据库要升级、安全法规要遵守、性能指标要达标。这类需求往往是被动的，但躲不掉。

2.2 需求的五大分类

需求分好类，后续的优先级排序、工作量评估才能落地。我一般把需求分成五类，咱们一个一个说。

2.2.1 用户需求

用户需求是「用户用自己的话描述想要什么」。比如「我想一键导出所有订单」「我希望登录后能看到上次浏览的商品」。这类需求的特点是：口语化、场景化、不完整。

举个例子：用户说「我想在手机上也能看报表」。这背后其实藏着好几个需求：响应式布局、数据压缩传输、离线缓存……用户不会说这些，但你要能拆解出来。

2.2.2 业务需求

业务需求是「公司或客户为了实现商业目标而提出的要求」。比如「新用户注册转化率提升20%」「订单处理时效缩短到30分钟以内」。这类需求通常有明确的KPI。

我记得有一次做物流系统，业务方提了个需求：「司机到达后必须扫码确认」。表面看是个功能，实际是为了解决「虚假签收」的问题——这是业务目标驱动的需求。

2.2.3 功能需求

功能需求是「系统具体要做什么」。它是用户需求和业务需求的落地。比如：

• 用户需求：「我想知道订单到哪了」 → 功能需求：提供订单物流轨迹查询接口
• 业务需求：「减少客服咨询量」 → 功能需求：增加自助查询页面，展示常见问题

写功能需求时，我建议用「用户故事」的格式：作为[角色]，我希望[功能]，以便[价值]。这样开发一看就懂。

2.2.4 非功能需求

非功能需求是「系统做得怎么样」。它不直接描述功能，但决定了系统的质量。常见的包括：

2.2.5 需求优先级划分

需求永远做不完，所以得排优先级。我常用的方法是 MoSCoW 法则：

• M（Must have）：必须有，没有就不能上线。比如支付功能、登录注册。
• S（Should have）：应该有，但可以延后。比如消息推送、个性化推荐。
• C（Could have）：可以有，但优先级低。比如换肤功能、节日特效。
• W（Won't have）：这次不做，以后再说。比如多语言支持、国际化。

另外，我还会结合 价值 vs 成本 矩阵来辅助判断。高价值低成本的需求优先做，低价值高成本的直接砍掉。

2.3 需求分类的实战案例

拿我最近做的一个「在线考试系统」来举例。需求来源是教务老师和学生：

• 用户需求：学生说「我想知道答完题后能不能改答案」；老师说「我要能批量导入学生名单」。
• 业务需求：学校要求「考试期间系统不能中断超过5分钟」「成绩数据必须保留3年」。
• 功能需求：实现答题卡回退功能、Excel批量导入接口、成绩归档模块。
• 非功能需求：并发支持500人同时考试、页面响应时间<1秒、数据每日自动备份。
• 优先级：M（答题、交卷、计分）→ S（成绩排名、错题分析）→ C（考试倒计时动画）→ W（多语言界面）。

你看，这么一梳理，整个项目的需求就清晰了。开发拿到需求文档，直接就能估算工作量。产品也知道哪些功能可以砍、哪些必须保。

2.4 需求分类的常见误区

最后说几个我踩过的坑：

1. 把用户需求直接当功能需求：用户说「我要一个搜索框」，但你可能需要的是「全文检索+分词+高亮」。别照搬，要分析。
2. 忽略非功能需求：功能做得再好，系统一用就卡，等于白做。非功能需求是系统的「地基」。
3. 优先级全凭感觉：没有数据支撑的优先级排序，最后都会变成「谁嗓门大听谁的」。用MoSCoW法则，至少有个框架。

好了，第二章就聊到这。需求来源和分类是需求分析的起点，也是后续所有工作的基础。下一章咱们讲讲怎么把需求写清楚——需求文档的规范与模板。