# rtc 开发入门的实战项目需求分析文档

说在前面：这篇文章是写给那些真正想动手做点东西的朋友看的。如果你对 rtc 完全没概念，可以先收藏着，等真正想动手的时候再翻出来对照着看。

为什么你需要一个完整的需求分析

我见过太多开发者拿到需求就开始写代码，写到一半发现漏了这个、那个没考虑清楚，最后推倒重来。这种事情发生一次两次是经验，发生的次数多了就变成教训了。

RTC 开发不同于普通的业务系统开发，它涉及实时音视频传输、网络自适应、抗丢包、延迟控制等一系列技术难点。如果不在一开始就把需求理清楚，后面会走很多弯路。这篇文章我想从一个实际项目的角度出发，把需求分析的完整过程过一遍，顺便把一些容易踩坑的地方标出来。

本文以一个在线教育场景为例来展开说明，这个场景足够典型，几乎涵盖了 RTC 开发中最常见的那些问题。

第一步：明确项目背景和目标

做任何项目之前，你首先得回答一个最基本的问题——这个项目到底要解决什么问题？

拿在线教育来说，核心需求通常包含以下几个层面。教学质量层面，老师需要能够清晰地看到每个学生的学习状态，学生需要能够清楚地看到老师的板书和演示内容。互动需求层面，课堂期间要有实时问答功能，小组讨论时需要分屏协作，下课后还要能回看录像。规模预期层面，你是打算先服务几十个学生的小班课，还是直接就要支持几百人的大班课？

这些问题的答案会直接影响到后续的技术选型。比如小班课和大班课在架构上就完全是两个思路，小班课可以用 SFU 模式让每个人都上传一路流，大班课就得用 CDN 或者 MCU 聚合后再分发。

我建议在做需求分析的时候，先找业务方聊透，哪怕多花几天时间也比后面返工强。业务方有时候自己也说不清楚到底要什么，这时候你要多举例子、多追问细节。

第二步：功能需求拆解

功能需求这块，我习惯用一个简单的矩阵来整理。横轴是功能模块，纵轴是优先级，重要且紧急的、紧急但不重要的、重要但不紧急的、不紧急也不重要的，这样分清楚之后，开发节奏会好很多。

下面这个表格列出了一个在线教育项目的基本功能模块，仅供参考：

| 功能模块 | 核心功能 | 优先级 | 备注 |
|————-|————-|———–|———|
| 实时音视频通话 | 1对1视频、小班课、多人会议 | P0 | 延迟要求在 300ms 以内 |
| 屏幕共享 | 共享桌面、共享特定窗口、共享白板 | P0 | 帧率至少 15fps，分辨率 1080p |
| 文字聊天 | 实时消息、弹幕模式、历史消息 | P1 | 需要支持图片和表情 |
| 课堂管理 | 白板标注、举手发言、禁麦、踢人 | P1 | 教师端需要全局控制能力 |
| 录制回放 | 本地录制、云端录制、回放列表 | P2 | 考虑存储成本和回放体验 |
| 考勤签到 | 定时签到、随机签到、签到统计 | P3 | 可以后期迭代 |

插一句：功能优先级这个东西不是一成不变的。如果客户明确说要先跑通核心场景，那有些功能完全可以先不做 MVP 版本，等核心功能稳定了再加。

具体到每个功能点，还需要进一步细化。比如实时音视频通话这个模块，你至少要明确以下细节：

视频方面，需要确定默认分辨率是多少、支持的分辨率范围有哪些、帧率要达到多少、编码格式选什么。音频方面，采样率用 44.1kHz 还是 48kHz，要不要做回声消除、噪声抑制，码率控制在多少合适。网络方面，用户主要分布在哪些地区，有没有跨国需求，能接受的延迟上限是多少。

这些细节听起来很琐碎，但每一个都会影响最终的实现方案。我的经验是，把这些问题全部列出来，逐一找业务方确认，然后形成文档让双方签字确认。后面如果扯皮，这东西就是依据。

第三步：非功能需求同样重要

功能需求是告诉系统「做什么」，非功能需求是告诉系统「做到什么程度」。很多项目在验收的时候扯皮，往往就是因为非功能需求没定义清楚。

性能指标这部分是最容易产生分歧的。举个例子，你跟业务方说延迟要控制在 300ms 以内，业务方可能觉得 300ms 已经很快了，但他没想过网络抖动的时候延迟可能会飙升到 800ms。所以指标要写清楚是平均值、P99 值、还是最大值。

我见过一个项目，业务方要求延迟不超过 200ms，开发团队按平均值 200ms 来做，结果上线后发现 P99 延迟高达 1 秒多，用户体验很差。这就是没把指标定义清楚的后果。

具体来说，RTC 项目常见的性能指标包括：端到端延迟要控制在多少毫秒以内，视频分辨率和帧率的具体数值，音频的采样率和码率，端到端的丢包率容忍度是多少，并发用户数的上限是多少。

稳定性要求也是需要提前沟通清楚的。你需要了解业务方对可用性的期望是多少，是 99.9% 还是 99.99%，这个数字背后对应的故障时间是完全不同的概念。故障恢复时间期望是多长，是分钟级还是小时级。降级策略要怎么做，当网络不好的时候是降低分辨率还是直接切语音。

兼容性需求往往被忽视，但处理不好会很麻烦。你需要明确要支持哪些浏览器，是只支持 Chrome 和 Safari，还是 Firefox 也要覆盖。移动端要支持哪些系统版本，Android 最低到 API Level 多少，iOS 最低到哪个版本。PC 端要支持什么系统，Windows 7 还支不支持。

第四步：技术选型的考量维度

技术选型是需求分析之后最重要的一步，选对了后面少很多麻烦，选错了可能要推倒重来。

关于自建还是使用第三方服务，这个要看公司的具体情况。如果团队有很强的音视频技术背景，时间又比较充裕，可以考虑自研。但如果要在短时间内交付，或者团队在这块积累不够，我建议直接使用成熟的第三方服务。

声网在这个领域做了很多年，SDK 的成熟度和文档的完善程度都挺不错的。他们提供的解决方案覆盖了从 1 对 1 视频到万人直播的各种场景，对于入门来说是个不错的选择。如果选择自研，你需要考虑的事情就多了去了：传输协议是用 QUIC 还是基于 UDP 的私有协议，编解码器选 AV1 还是 H.264，服务器要怎么部署，跨区域同步怎么做。

选型的时候不要只看功能列表，要实际跑一下压测数据。我建议至少要对比三家不同的方案，每家都跑同样的测试场景，然后根据数据做决策。

第五步：把需求文档写成一个检查清单

需求文档写到最后，应该能变成一个检查清单。每个功能点、每个指标，都要能量化验证。

我通常会在文档最后加一个验收标准章节，把所有需求点都列出来，每条后面跟一个验证方法和预期结果。比如视频延迟这一项，验证方法可以写「在双方各开一个终端，使用网络模拟工具注入 20% 丢包，测量端到端延迟」，预期结果写「P99 延迟不超过 800ms」。

这样做的好处是，到了验收阶段大家有据可依，不会出现「我觉得延迟太大」「我觉得还可以」这种扯皮的情况。

最后想说的是，需求分析这件事急不得。你在前面的文档上多花一周时间，可能就避免了后面一个月的返工。但如果需求分析做得太细迟迟不动手，也会错过时间窗口。找到合适的节奏很重要。

祝你开发顺利。