需求工程基础：需求的定义与分类

说实话，做了这么多年系统架构，我见过太多项目翻车，十有八九都是需求没搞明白。你想想看，地基都没打牢，房子能稳吗？今天咱们就来聊聊需求工程最基础的东西——需求到底是什么，怎么分，怎么挖。

需求的定义：别小看这俩字

需求，说白了就是「用户想要什么」和「系统必须做什么」的集合。但这里有个坑——用户说的不一定是他真正要的。我记得有个项目，客户说「我要一个报表系统」，结果聊了三天才发现，他真正需要的是「能自动汇总数据的工具」，而不是花里胡哨的图表。

我个人习惯，拿到任何需求先问三个「为什么」。比如「我要一个搜索功能」——为什么？「因为用户找不到历史订单」——为什么找不到？「因为数据太多没有筛选」——哦，原来你要的是筛选+搜索，不是单纯的搜索框。你看，多问两句，需求就清晰了。

需求的分类：功能 vs 非功能

这个分类是需求工程的基石。我见过不少团队，功能需求写得密密麻麻，非功能需求就写一句「系统要稳定」。结果上线后用户骂「太慢了」，你说这是功能问题还是非功能问题？

功能需求

功能需求就是「系统能做什么」。比如：

• 用户登录
• 商品搜索
• 订单提交
• 数据导出

这些是看得见摸得着的。写功能需求时，我建议用「用户故事」的格式：「作为XXX，我想要XXX，以便XXX」。这样写出来的需求，开发看得懂，测试也方便验证。

非功能需求

非功能需求是「系统做得怎么样」。说白了，就是质量属性。包括：

类别	说明	例子
性能	响应时间、吞吐量	页面加载不超过2秒
可用性	系统正常运行时间	99.9%可用，全年宕机不超过8小时
安全性	数据保护、权限控制	用户密码必须加密存储
可维护性	代码易读、易改	模块间耦合度低于某个阈值
可扩展性	支持未来增长	支持用户量从1万增长到100万

需求获取的常见方法

需求不会自己从天上掉下来，得靠你去挖。我常用的方法有三种，各有各的适用场景。

1. 访谈

访谈是最直接的方法。一对一聊，能挖出很多书面材料里没有的东西。我个人习惯分三步走：

1. 准备提纲——列出核心问题，但别太死板
2. 开放式提问——「你平时最头疼的是什么？」比「你需要报表功能吗？」有效得多
3. 追问细节——「你说数据不准，具体是哪个字段？什么情况下不准？」

嗯，这里要注意：访谈对象要选对。找业务骨干聊，别只找领导。领导说的往往是「愿景」，一线员工说的才是「痛点」。

2. 问卷

问卷适合大规模收集需求。比如你要做一个内部工具，全公司2000人用，一个个访谈不现实。这时候问卷就派上用场了。

设计问卷时，我建议：

• 选择题为主——方便统计分析
• 开放题为辅——留一两个填空，让用户自由发挥
• 控制题量——超过20题，填写率会断崖式下降

3. 观察

这个方法很多人忽略，但我觉得特别有用。你坐在用户旁边，看他怎么操作现有系统，会发现很多他自己都没意识到的习惯。

举个例子：有个项目，用户说「我们想要一个更快的录入界面」。我去现场观察了半天，发现他们录入数据时，80%的时间花在「从纸质单据上找数字」上。真正的问题不是录入速度，而是纸质单据排版太乱。后来我们优化了单据格式，录入效率直接提升了40%。

观察法的要点：

• 别打扰——让用户按平时习惯操作
• 记笔记——记录每个操作的耗时、犹豫点、错误点
• 事后追问——「我刚才看到你在这里停了一下，是遇到什么问题了吗？」

三种方法的对比

方法	优点	缺点	适用场景
访谈	深度高，能挖隐性需求	耗时长，样本少	核心用户、关键业务
问卷	覆盖面广，数据可量化	深度不够，容易有偏差	大规模用户调研
观察	真实客观，发现隐藏问题	成本高，可能影响用户	流程优化、用户体验改进

我个人建议，别只用一种方法。先做问卷摸清全貌，再挑几个典型用户做访谈，最后去现场观察验证。三种方法组合使用，需求才能挖得又深又准。

总结一下

需求工程不是写文档，而是理解人。功能需求解决「做什么」，非功能需求解决「做多好」。获取需求时，别光听用户说什么，要看他怎么做。记住一句话：用户永远是对的，但用户说的需求不一定是对的。

下一章咱们聊聊需求分析的常用工具——用例图、用户故事、需求优先级排序。到时候我会分享一个真实案例，看看怎么把模糊的需求一步步变成可落地的方案。