需求工程入门：需求获取与分类

第 4 章 · 软件工程

先看一个常见场景。 老板说：「我们要做个能管订单的系统。」开发问：「谁用？管哪些字段？要不要和仓库对接？要不要报表？」老板说：「你先做嘛，做着再说。」结果做出来：运营说「我们要按门店筛选」、财务说「我们要导出 Excel」、客服说「我们要看客户历史订单」——统统没做，返工一轮又一轮。另一头，需求工程师接到同一句话后，先找运营、财务、客服各聊一轮，搞清楚「谁在什么场景下要做什么」；再画个简单原型给大家点着说「是不是这样」；把「能管订单」拆成「录入、查询、导出、统计」和「响应时间 < 2 秒、支持 100 人同时用」等。开发按这份需求做，一次到位。差别不在谁更卖力，而在有没有先把「需求」搞清楚、获取到、分好类。本章带你入门需求工程：什么是需求、怎么获取（访谈、问卷、观察、原型）、功能需求与非功能需求怎么区分、以及需求分类与优先级怎么定。

一、什么是需求？

需求（Requirement）通常指：系统或产品必须满足的条件或能力，以便解决干系人的问题、达成目标。换句话说：谁（干系人）在什么情况下，需要系统「做什么」或「做到什么程度」；能说清楚、能验证，才算得上一条合格的需求。

需求：源于干系人目标，表述为「做什么 / 做到什么程度」，且应可验证

几个要点：干系人包括用户、客户、业务方、运维、合规等——谁会被这个系统影响、谁有发言权，就要听谁的。「需要」不等于「想要」：有时对方说的是解决方案（「我们要一个按钮」），你要往回挖真正的目标（「其实是想快速完成某操作」），才能避免做错东西。可验证：需求写完后要能判断「做没做到」——要么能测试，要么能验收；模糊的「好用」「快一点」要转化成可衡量的表述（下一章会细讲非功能需求怎么写）。

一句话： 需求是「谁在什么情况下需要系统具备什么能力或满足什么条件」，且要说清楚、能验证。需求工程就是获取、分析、文档化和管理这些需求的过程。

二、需求获取方法：访谈、问卷、观察、原型

需求不会自己跑进文档里，要靠获取（Elicitation）。常见方法有四种，往往组合使用：访谈、问卷、观察、原型。

访谈

面对面或远程深聊，追问「为什么」「在什么场景下」；适合探索性、复杂需求。

问卷

批量收集意见、偏好、频率；适合人数多、问题相对明确时；补充访谈。

观察

到现场看用户怎么干活、卡在哪；发现「嘴上没说但实际在做」的需求。

原型

画界面或交互草图、可点原型，让干系人「点着说」要什么；减少理解偏差。

四种常用需求获取方法：访谈、问卷、观察、原型

访谈（Interview）：和干系人一对一或小范围聊，问「你们现在怎么做的」「最痛的点在哪」「理想情况是怎样的」。适合需求还不清晰、需要深挖时。技巧：多问「为什么」、少引导答案、记下原话再回去整理。
问卷（Survey / Questionnaire）：把问题写成题目，发给一批人填。适合人数多、想快速收集偏好或频率（例如「你每周用几次某功能」）。缺点是不能深挖，往往要和访谈配合：先问卷摸底，再挑典型用户访谈。
观察（Observation）：到用户工作现场看他们实际怎么操作、在哪卡住、有什么变通办法。很多需求用户自己说不出来（习惯成自然），观察能发现「嘴上没说但行为暴露」的需求。适合流程类、操作类系统。
原型（Prototype）：用线框图、可点击的 Mock 或简单可运行界面，让干系人「看着点着说」——「这里我要个筛选」「这个按钮放左边」。原型能把抽象描述变成可见可点的东西，减少「你以为的」和「他想要的」之间的偏差。可先低保真（纸笔、线框），再高保真。

实践中往往组合使用：先访谈摸清大致范围，再用问卷扩大样本，关键流程用观察核实，有争议的界面用原型确认。

三、功能性需求与非功能性需求的初步区分

需求常被分成两大类：功能性需求（Functional Requirements, FR）和非功能性需求（Non-Functional Requirements, NFR）。

功能性需求（FR）

系统「做什么」：功能、行为、输入输出
例：用户能登录、能按条件查询订单、能导出报表
通常可写成「系统应能…」「用户应能…」

非功能性需求（NFR）

系统「做到什么程度」：性能、安全、可用性等
例：页面响应 < 2 秒、支持 100 并发、数据加密存储
约束或质量属性，需可度量、可验证

功能性需求 vs 非功能性需求：做什么 vs 做到什么程度

功能性需求描述的是「系统提供什么功能、用户能完成什么操作」——例如「用户能注册、登录」「能创建和查询订单」「能导出 Excel」。一条好的功能需求应当无歧义、可测试：做完能通过操作或用例验证「做到了」。

非功能性需求描述的是质量、约束或程度——例如性能（响应时间、吞吐量）、安全（认证、加密）、可用性（可用率、恢复时间）、可扩展性、兼容性等。常见陷阱是写得很虚（「系统要快」「要安全」），无法验收。正确做法是尽量量化：例如「列表页加载时间 < 2 秒」「支持 100 用户同时在线」「敏感字段 AES 加密存储」。下一章会专门讲 NFR 的表述与可验证性。

四、需求分类与优先级

需求多了就要分类和排优先级，否则开发不知道先做哪条、产品不知道砍哪条。

分类维度

除了「功能 / 非功能」，还可以按来源或层次分：例如用户需求（用户直接表达的）、业务需求（业务目标、KPI）、系统需求（落到系统上的具体条件）。也可以按模块或史诗分：订单模块、用户模块、报表模块…… 便于规划和分配。下面简表给出常见分类方式：

分类维度	说明
功能 / 非功能	做什么（FR） vs 做到什么程度（NFR）
用户 / 业务 / 系统	用户说的、业务目标、系统级约束
模块或史诗	按功能域或大特性划分，便于排期与分配
Must / Should / Could	MoSCoW：必须有、应该有、可以有（见下）

需求分类的常见维度

优先级

资源有限时，必须决定先做谁、后做谁、谁可以砍。常用方法包括：

MoSCoW：Must have（必须有）、Should have（应该有）、Could have（可以有）、Won't have this time（这次不做）。先保证 Must，再排 Should、Could。
P0 / P1 / P2：数字越小优先级越高。P0 不做不能发布，P1 重要但可延后，P2 锦上添花。
价值 × 紧迫度：价值高且紧急的优先；价值高但不急的排期做；价值低又急的掂量；价值低又不急的可不做。

优先级：MoSCoW 分层（上）；价值 × 紧迫度（下）

优先级要跟干系人一起定，并记录理由，方便以后复盘和应对变更（「当时为什么把这条排前面？」）。

小贴士： 获取需求时，若对方直接说「我们要一个 XX 功能」，不妨多问一句：「你们想用这个功能解决什么问题？现在是怎么做的？」把「方案」还原成「目标」，再一起推合适的方案，能少做很多「做完了发现不是想要的」的冤枉活。

五、小结

需求是系统为满足干系人目标而必须满足的条件或能力，要可验证。需求获取常用四种方法：访谈（深挖）、问卷（批量）、观察（现场）、原型（可视化确认）；实践中多组合使用。功能性需求说「做什么」，非功能性需求说「做到什么程度」；NFR 要尽量量化以便验收。需求分类可按功能/非功能、用户/业务/系统、模块等维度；优先级可用 MoSCoW、P0/P1/P2 或价值×紧迫度，并与干系人对齐、记录理由。下一章我们专门讲功能性需求与非功能性需求的写法与可验证性，把「做到什么程度」说清楚。