1 需求描述及分析

需求分析的目的是使产品和开发，对所要实现的功能细节达成一致，这是一个不断沟通协商的过程。

开发人员需要针对需求中没有明确描述的内容，提出自己的思考及意见。

1、需求描述

本章希望在基础服务框架上实现一个聊天服务。

聊天以聊天室的形式出现。

1.1 登陆

用户可以连接到聊天室服务，并申请一个会话id，保存到本地。

用户可以在服务上设置昵称，并与会话id绑定。

1.2创建

用户可以创建一个聊天室，并获取一个聊天室房间号，房间号为6位数字。

1.3 加入

用户可以通过聊天室房间号加入聊天室。

1.4 解散

聊天室创建后保留30分钟，等待用户进入，若30分钟无人进入，则聊天室解散。

30分钟后，聊天室内还有人，所有用户离开聊天室后，聊天室解散。

1.5 消息

聊天室内有人发消息，所有在聊天室内的人都可以收到。

服务端不保存历史消息，不提供聊天内容漫游功能，属于阅后即焚。

暂不支持语音、图片、视频等多媒体消息，仅支持文字消息。

1.6 交互

用户可以从聊天室拉取当前聊天室内的用户列表，以便可以通过@方式提及某个用户。

2、需求分析

产品提供的需求文档，往往只关注他想实现的需求，会再多一些界面展示的UI示意图，其他技术细节需要开发人员自己补充。在需求分析时，需要看到需求中没有明确的一些点，和产品做好充分沟通。

服务架构

本次需求只需要实现一个小的聊天室服务，支持聊天。由于初期使用人数较少（10个以内），所以只考虑实现一个服务即可。暂不考虑分布式部署多台聊天服务的情形。

服务功能比较简单，预估单台服务可承载上限为3000人左右。

登陆

登陆功能适合接入一个统一的登陆平台，这里没有其他服务，仅做简单支持，后期可以独立出一个登陆注册服务。

创建

创建需求只提到可以创建一个聊天室，并没有提到创建上限，一般沟通后可能确定，一个人同一时间，只能创建一个聊天室，但可以随意加入其他聊天室，但同一时间只能进入一个聊天室。因此，客户端需要能够拉取自己相关的聊天室列表，包括自己创建的聊天室，加入过的聊天室（最近10个），当前所在的聊天室。

加入

用户可以通过聊天室ID进入聊天室，因此聊天室ID不能重复分配。因此需要一个单独的模块分配和回收聊天室ID，后期可能独立出一个服务，专门用于管理聊天室ID。

解散

聊天室设置有效期，30分钟应该是可配置值，后期又可能变化。

服务可以每分钟检查所有的聊天室状态，符合需求的，直接解散即可，不需要为聊天室单独设置定时器。用户离开聊天室时，也不需要单独检查，精度要求不高，在每分钟检查时处理即可。

聊天室需要记录创建时间，有效期，以及一个检查可以关闭的函数。

消息

由于需要支持聊天室内的消息广播，一条用户消息，需要发给聊天室的N人，变为N条消息。若每人每秒发一条消息，则每秒广播消息数为N*N条，消息数随人数增加指数级增长。因此，需要控制聊天室人数上限，可以暂定单个聊天室人数上限为50。（注：这个内容产品一般不会考虑到，需要开发人员自己注意，避免后期出现单个聊天室人数太多，消息数暴涨，导致服务卡顿。）

以上为针对产品需求，进行的需求分析，开发经验越丰富，考虑到的细节点越多，大家平时可以注意积累。下一节我们一起做概要设计。