第4章功能需求规格说明书

第4章：功能需求规格说明书——功能列表、优先级划分、验收标准定义

好，咱们接着聊。上一章我们把需求调研清楚了，一堆原始需求摆在那。接下来要做什么？

你得把这些「人话」翻译成「技术语言」。说白了，就是写一份功能需求规格说明书。

这份文档，是整个项目的「宪法」。后面所有的设计、开发、测试，都得围着它转。我见过太多项目，前期需求文档写得稀里糊涂，结果开发到一半，产品经理和程序员吵得不可开交。嗯，咱们今天就把这事彻底理清楚。

4.1 功能列表：把需求「拆碎」

功能列表不是简单地把需求抄一遍。你得把每个需求拆成原子级的功能点。

举个例子，用户说「我要能检测图片里的行人」。这听起来是一个需求，但拆开来看，它包含：

图片输入功能（支持jpg、png格式）
行人检测算法调用
检测结果可视化（画框）
结果导出（JSON格式）

我个人习惯用编号系统来管理功能列表。比如：

功能编号	功能名称	功能描述	所属模块
F-001	图片上传	支持用户上传单张或多张图片，格式限jpg/png，单张不超过10MB	数据输入
F-002	行人检测	调用YOLOv8模型对输入图片进行行人检测，输出检测框坐标和置信度	算法引擎
F-003	结果展示	在原图上绘制检测框，并显示置信度数值，支持缩放查看	可视化
F-004	结果导出	将检测结果导出为JSON文件，包含图片名、检测框坐标、置信度	数据输出

我的经验：功能编号一定要留有余量。比如F-001到F-100留给核心功能，F-101到F-200留给扩展功能。我曾经因为编号没留够，后期加功能时搞得一团糟。

4.2 优先级划分：别什么都想做

你想想看，资源永远是有限的。时间、人力、算力，都是成本。所以我们必须给功能排个优先级。

我常用的方法是MoSCoW法则：

M - Must have（必须有）：没有这个功能，项目就转不起来。比如行人检测的核心算法。
S - Should have（应该有）：很重要，但可以稍微晚点做。比如结果导出功能。
C - Could have（可以有）：锦上添花，有时间就做。比如支持批量处理。
W - Won't have（这次不做）：明确告诉客户，这次版本不包含。比如视频流实时检测。

为什么要这么分？因为客户总想把所有功能都塞进第一个版本。我曾经遇到一个客户，要求第一个版本就支持100种物体检测、实时视频流、还要做数据统计看板。我直接拿出MoSCoW法则，跟他一项项过，最后砍掉了60%的功能，项目才按时交付。

避坑指南：千万不要把「Won't have」的功能偷偷塞进「Could have」里。这会给团队造成错觉，以为这些功能早晚要做。明确说「这次不做」，反而能让客户更信任你。

4.3 验收标准定义：怎么才算「做好了」？

这是最容易被忽略的一环。很多团队写完功能列表，就开始编码了。结果到了测试阶段，产品经理说「这个框画得不够准」，程序员说「我觉得挺准的啊」。为什么？因为没有量化标准。

验收标准，说白了就是「你说它好了，它才算好」的客观依据。我一般会从三个维度来定义：

4.3.1 功能正确性

功能本身跑通了没有？比如：

上传一张包含行人的图片，系统能在3秒内返回检测结果
检测框能准确框住行人，框的坐标误差不超过5个像素
置信度显示保留两位小数

4.3.2 性能指标

跑得快不快？资源吃得多不多？比如：

单张图片推理时间 ≤ 500ms（GPU环境下）
CPU占用率 ≤ 30%
内存占用 ≤ 2GB

4.3.3 异常处理

出错了怎么办？比如：

上传非图片格式文件时，系统提示「仅支持jpg/png格式」
图片超过10MB时，系统提示「图片过大，请压缩后上传」
模型推理失败时，系统返回错误码并记录日志

我建议把验收标准直接写在功能列表旁边，做成一个表格：

功能编号	功能名称	优先级	验收标准
F-001	图片上传	M	1. 支持jpg/png格式 2. 单张≤10MB 3. 上传进度条显示 4. 格式错误时弹出提示
F-002	行人检测	M	1. 推理时间≤500ms 2. 检测框坐标误差≤5px 3. 置信度≥0.5时显示框 4. 支持同时检测10人以上
F-003	结果展示	S	1. 框线颜色为红色 2. 置信度显示在框上方 3. 支持鼠标悬停查看坐标

    核心要点：验收标准必须是可测试的。不要写「界面要好看」，要写「按钮颜色为#1890FF，圆角4px」。不要写「检测要准确」，要写「在测试集上mAP≥0.85」。

4.4 一个完整的例子

咱们拿「行人检测」这个功能，完整走一遍流程：

功能编号：F-002
功能名称：行人检测
优先级：Must have
所属模块：算法引擎

功能描述：
调用YOLOv8模型对输入图片进行行人检测，输出检测框坐标和置信度。

验收标准：
1. 功能正确性
   - 输入一张包含行人的图片，系统返回检测结果
   - 检测框坐标格式为 [x1, y1, x2, y2]，单位像素
   - 置信度范围 0.0 ~ 1.0，保留两位小数

2. 性能指标
   - 单张图片推理时间 ≤ 500ms（NVIDIA T4 GPU）
   - 模型加载时间 ≤ 5秒
   - 支持批量处理，最多同时处理16张图片

3. 异常处理
   - 图片为空时，返回错误码 1001
   - 模型加载失败时，返回错误码 2001
   - 推理超时（>2秒）时，返回错误码 3001

4. 边界条件
   - 图片中无行人时，返回空列表
   - 图片中有超过50人时，只返回置信度最高的50个结果
   - 图片分辨率超过4096x4096时，自动缩放到2048x2048再处理

你看，这样写出来，开发人员知道要做什么，测试人员知道要测什么，产品经理也知道怎么验收。大家心里都有底。

我的习惯：验收标准写完后，我会让测试团队先「预审」一遍。他们最擅长挑刺，能发现很多我没想到的边界情况。比如上面那个「超过50人只返回50个结果」，就是测试同事提醒我的。

4.5 小结

功能需求规格说明书，不是写给别人看的，是写给自己团队用的。它要足够细、足够准、足够可执行。

记住三个关键词：拆碎、排级、量化。把需求拆成原子功能，用MoSCoW法则排优先级，用可测试的标准定义验收条件。

做到这三点，你的项目至少成功了一半。剩下的，就是按部就班地编码和测试了。

下一章，咱们聊聊技术选型。选对了框架和工具，开发效率能翻倍。选错了...嗯，我踩过的坑到时候跟你细说。

📚 课程目录