Sherfiter's wiki for fun

第 3 章 · 需求工程

软件项目死掉的头号原因不是技术,是「做出来的东西没人要」。需求工程研究的就是怎么把模糊的人类愿望变成清晰、可验证、可实现的规格,并在变更时管住它们。这一章的技能听起来软(访谈、澄清、谈判),做起来全是硬功夫:每一条没写清的需求,都是将来某次返工的种子。

3.1 需求的分层:业务、用户、系统

「需求」一词涵盖三层,混着说会乱:

  • 业务需求(business):为什么做。「降低客服人力成本 30%」;
  • 用户需求(user):用户要能做什么。「客服人员可以一键检索用户历史工单」;
  • 系统需求(system):系统必须具备什么行为/属性。「检索响应时间 ≤ 2 秒,支持关键词与工单状态过滤」。

从上往下是细化,从下往上是追溯(traceability,每条系统需求都能指回它服务的用户场景,砍需求时知道砍的是谁)。工程课常把功能性需求(做什么)和非功能性需求(做到什么程度:性能、安全、可用性)并列,后者最容易被漏——没有人主动说「系统要能扛双十一」,直到扛不住。

3.2 获取:从访谈到原型

需求不会躺在需求文档里等你,它散在用户的脑袋里,而且用户自己也说不清楚。获取手段按深度排:

  • 用户访谈:一对一深聊,重点问「上次你做这件事的完整过程」(具体事件比假设性提问可靠:「你会用这个功能吗」人人答会,做起来另说);
  • 现场观察:去用户干活的地方看,专家的 workaround(贴在屏幕上的便利贴、自己做的 Excel)是最诚实的痛点清单;
  • 原型(prototype):画个假界面(纸笔或 Figma)给用户点,「看到东西」能逼出 90% 访问问不出的反馈。第 2 章的原型思想在需求期的落地。

一个经典陷阱:「用户说的」和「用户要的」不同。福特名言「如果问用户要什么,他们会说更快的马」。需求工程师的价值在于追问动机:要更快的马,是因为要更快地到城另一头 → 那辆车才是解。需求的每一层都要问「为什么」。

3.3 分析与规格:写下来,可验证

需求分析的产出是软件需求规格说明书(SRS),质量标准有四条,每条都能当验收枪使:

  • 无歧义:「系统应快速响应」不合格,「P95 响应 ≤ 2s」合格;
  • 可验证:每条需求都能设计出一个测试判断满足与否(第 8 章的验收测试由此生长);
  • 完整且一致:需求之间不打架(「所有数据必须实时同步」和「系统必须可离线工作」需要澄清);
  • 可追溯:编号、来源、关联的设计与测试用例。

写法上推荐用户故事(Agile 风格)+ 验收标准:

作为一个 客服人员
我想要 一键检索某用户的所有历史工单
以便 快速了解来电者背景
验收:输入手机号,2 秒内显示全部工单(按时间倒序);无记录时给出明确提示

用户故事的三段式逼你写下「谁、要什么、为什么」,验收标准把「完成」定义死,防止「差不多了」式收尾。用例(use case)是更重的替代品(带主流程/扩展流),适合复杂交互场景,两者选一即可,重点是「可验证」而不是格式。

3.4 确认与管理:和变更共处

需求确认(validation)在写完后、开发前做:给真实的用户/干系人评审。比评审会更高保真的是「走查场景」:拿需求逐条演一遍「用户从进门到办完事」的旅程,漏洞当场现形。

需求管理(requirements management)处理现实:需求一定会变。变更是常态(第 1 章的病灶三),管理它的机制:

  • 变更控制:每条变更走「评估影响(工作量、波及模块、风险)→ 决策 → 更新基线」的流程,拒绝「口头改需求」;
  • 基线(baseline):某时刻的需求快照,之后的变更是可追溯的事件,而不是「文档悄悄变了」;
  • 优先级排序:MoSCoW 法(Must/Should/Could/Won't),资源不够时砍的是 C 和 W,而不是全员加班。

3.5 一个真实案例的复盘

课程设计场景:组队做个「宿舍报修系统」。原始需求一句话:「报修,然后修」。按本章方法展开:访谈宿管阿姨(发现她要的是「按宿舍楼筛选和催办」,不是学生以为的「提交就完事」)→ 用户故事 12 条 → MoSCoW 排序(报修和派单是 Must,评分是 Should,积分商城砍到 Won't)→ 每条配验收标准 → 每周按 backlog 交付。同样的开发时长,交付物的差距是「能演示」和「演示时被问倒」的差距。需求阶段的每一小时,省的是开发阶段的十小时(缺陷修复成本的阶段曲线,第 1 章提过)。

常见错误

  • 把「用户想要的功能列表」当需求。没有用户故事和验收标准,列表只是愿望;每条需求要能变成测试。
  • 非功能需求集体失踪。性能、安全、可用性从不主动出现;给 NFR 专门开一节,逐类问一遍。
  • 变更不进流程。微信群里说一句「顺便加个导出 Excel」,两周后没人记得;所有变更走 backlog 评估。
  • 追求一次写全。瀑布式「需求冻结」在多数项目里是幻觉;写「当前最好理解」的版本,靠迭代与变更控制演进。

练习

  1. 动手:给你的课设写 10 条用户故事(三段式 + 验收标准),用 MoSCoW 排序,砍掉两条,写砍的理由。
  2. 动手:找一位「目标用户」(同学扮演也行)做 20 分钟访谈,主题「上次你完成某任务的完整过程」,记录三点:他没说出口的 workaround、他抱怨的环节、他主动提的要求,三者对照。
  3. 手算:某项目 40 条需求,平均每条开发 5 人天。若验收时发现 20% 需求「理解错误」需返工(返工成本 2 倍),总计浪费多少人天?需求评审花 10 人天能消灭一半错误,净收益多少?
  4. 思考:「需求文档要不要写」的两派(瀑布详尽 SRS vs 敏捷 backlog+故事)各自的失效场景是什么?从「团队规模、用户距离、变更频率」三个维度,给出你的分界判断。
豫ICP备2026027944号