02课 - 功能需求：秒杀活动信息是如何管理的？（秒杀系统）
上一讲我们介绍了秒杀业务背景和前端需求是怎么产生的。回想一下，你在秒杀活动的前端页面能看到什么？
有活动场次信息，比如第一场、第二场，以及对应每个活动场次的详情及规则，有商品的名称、价格等基本信息，还有对应的销售情况。
那么，这些信息是怎么在前端页面显示的呢？当然是我们在后台配置好后，通过后端接口提供给前端展现的。
并且，现代网站大多是前后端分离，静态数据如网页的 HTML 文件可以从 CDN（Content Delivery Network，内容分发网络） 中获取，而实时性高的动态数据如活动信息、库存等，通常要从后端接口返回。
为了做好数据的动静分离，让后端服务拥有更好的性能，我们就需要先做好后端及管理后台需求的分析。这一讲咱们还是以小米网的秒杀系统为例展开介绍，其中的一些需求分析经验和思考也适合迁移到其他项目中，记得认真收看哦。
后端需求分析
这部分主要包括需求分析及其接口，还有隐藏需求。
需求分析
后端的需求依赖于前端。 为了分析后端需求，我们需要先了解用户在秒杀活动中的行为
以小米网秒杀系统为例，假如双十一期间的某个上午，米粉想参与双十一促销活动中的手环和耳机的秒杀活动，他需要怎么操作呢？他的这些行为又会产生哪些后端需求呢？
这是整体流程图，我们一起来看看。
首先，他会先打开官网首页，点击首页的秒杀入口，进入秒杀活动页。
第二，当他进入秒杀活动页后，必然要了解活动信息，比如双十一有哪些场次，都有什么优惠，以及自己要买的东西在哪场。为此，我们需要为用户提供一个获取活动信息的接口。
第三，假设手环和耳机都在上午场，为了找到它们，这名米粉会点击场次按钮来了解。那么，这些场次信息就需要我们在后端提供，且最好是能缓存在页面，避免因每次请求而给后端带来压力。
第四，为了避免错过活动，他会点击上午场里手环和耳机的提醒按钮订阅通知。此时，后端需要判断他是否已登录 App。如果是，则生成一条 Push 订阅记录，并返回已订阅人数；如果没有登录，则提示他先登录。
第五，假设现在已经到了上午场活动开始时间，这名米粉开始进入手环的详情页，去了解它的价格、库存、活动信息等，判断要不要购买。
相应地，这个环节当中，就需要我们在后端提供手环的商品信息，特别是它的配送区信息、库存信息、活动信息。其中，库存信息和配送区并不是秒杀系统本身的主要内容，可以简明扼要，而活动信息则是秒杀系统的数据之一，需要提供接口获取该商品是否参与秒杀活动。
最后，假设这个米粉看了促销信息，觉得划算，他就会点击秒杀按钮进行购买。此时，后端需要判断他的登录状态：如果未登录，则跳转登录页；如果已登录，则判断是否参加秒杀活动、是否有库存、是否有资格，满足条件则扣预留库存、加购物车，并返回结果。
这是我们假设一名用户访问前端秒杀活动的行为轨迹，通过它，我们分析出了后端需要哪些需求。
接口清单
根据上面的需求分析，我们不难发现，点击场次信息时是从前端缓存里提取数据，所以不需要后端接口，而其他 4 种行为则需要对应的后端接口以便和前端互动。具体如下：
对应秒杀活动页需求的秒杀活动信息列表接口；
对应提醒按钮需求的 Push 订阅接口；
对应商品详情页需求的商品活动信息接口；
对应秒杀按钮需求的秒杀抢购接口。
这些接口都会传输什么信息呢？
首先来看秒杀活动信息列表接口。
它主要返回每场活动信息，具体有开始时间、结束时间、商品列表；商品列表里的每个商品信息包括商品 ID、商品名称、描述、图片、原价、活动价、库存状态、订阅人数。其中商品 ID 用于唯一标识商品，虽然不展示在页面上，但后续接口请求需要用到。
秒杀活动信息列表接口的最后一个是返回判断用户是否登录的信息，比如，返回用户登录状态为未登录，则会跳转到登录页。
第二，Push 订阅接口，主要是传入商品 ID ，返回已订阅的人数。
第三，商品活动信息接口，主要是传入商品 ID 和配送区，返回商品活动信息和用户是否登录。其中商品活动信息有是否参加秒杀活动、秒杀活动开始时间和结束时间、活动价格多少、是否还有库存、用户是否登录。
最后一个抢购接口，主要是传入商品 ID，返回抢购结果。
隐藏需求
在后端项目中，光实现接口就能满足所有需求了吗？不一定。前面按照前端需求提炼的接口清单属于公开需求，除此之外，还需要一些隐藏需求要满足。
都有哪些呢？
为了获取库存信息，需要对接库存中心；
为了获取商品信息，需要对接商品中心；
为了操作购物车并生成订单，需要对接交易中心；
为了方便做数据统计，需要将秒杀成功的用户 ID 记录下来，以便对接账号中心验证用户账号合法性。
另外，还需要支持灰度测试，以便我们在正式上线前，及早发现测试环境中无法暴露的问题。
最后，为了抗住大流量，还需要做一些维护服务稳定性相关的工作，这个我们会在高可用架构设计模块中重点介绍。
总之，后端的需求不像前端那么直观，有原型图参考。特别是隐藏需求，它比较依赖后端研发人员的经验来分析。
管理后台需求分析
前面我们介绍了后端需求分析，那么后端接口提供的活动信息数据是从哪来的呢？
没错，这些信息都是我们在管理后台配置出来的。例如：在双十一活动上有一批小米生态链产品参与秒杀活动，这需要运营在管理后台配置好活动主题为“双十一秒杀”，配置好场次“上午场”和“下午场”，上午场可能销售小米手环和耳机，下午场销售电动牙刷和台灯。
为了设置管理后台，我们还需要先分析下它的需求。接下来我们就聊聊这个问题。
需求分析
从前端和后端需求分析可知，秒杀系统主要有两类数据：活动场次信息、活动商品信息。另外，配置数据还需要支持灰度测试。
在小米网秒杀系统中，这两类数据的关系是怎样的呢？
一般来说，整个活动会包含 N 个活动场次，每个活动场次包含 M 个活动商品，活动商品包含各种商品信息。
那么，每个商品的信息从哪里来呢？主要有两大来源：
从其他系统中获取，比如名称、描述、图片等商品基本信息，价格、库存等销售信息；
从管理后台中录入，比如商品 ID、活动价格、活动库存、限购策略等。
这些都是管理后台需要用的信息。
另外，一般大型促销专题活动通常是由多场活动组成。比如：双十一大型促销专题活动里可能包含上午场和下午场两场活动，每场活动里有 10 件参与活动的商品。所以，在活动信息编辑功能里，我们还需要三个数据录入功能：活动专题信息录入、活动场次信息录入、商品信息录入。
除了活动信息录入，为了方便操作，系统还需要支持活动信息的查询、修改、删除、灰度测试、上线、下线等功能。
以上就是管理后台的需求分析。
后台页面
需求分析完，接下来就该进行下一步了——根据需求整理出具体的后台页面和接口。
那么，管理后台有哪些页面呢？
从大到小，大致有这三类：
活动专题管理，主要是用于管理所有秒杀活动专题，包括专题列表页和专题编辑页；
活动场次管理功能，用于录入秒杀活动场次信息，并关联到专题上，包括场次列表页和场次编辑页；
商品管理功能，用于管理参与秒杀活动的商品信息，包括商品列表页和商品编辑页。
首先，我们来介绍下第一类——专题管理，它包括专题列表和添加专题这两个页面。
其中，专题列表就是我们每场促销活动的专题信息，具体包括专题编号或ID、专题名称、活动开始时间、结束时间、活动状态、操作选项。我们一起来看下它的原型图。
像这里的 2020 年双十一秒杀、2020 年米粉节就是活动专题，它们的编号分别是 1 和 2。
其中，米粉节的开始时间是 2020.04.01 凌晨 12 点，结束时间是 2020.04.07 23:59；修改时间是 2020.03.31 23:15，表示在这一天这个时间我们对活动做过一次修改；状态是“已结束”。
还有最重要的操作选项，通过它，我们可以对专题信息进行查看、编辑、上下线和删除操作。
那么，这个专题列表里的活动是怎么添加的呢？通过专题管理的另一个按钮“添加专题”来实现。这就是专题管理的另一个页面——专题编辑页。
它主要包括专题输入框、专题 banner 链接输入框、专题开始和结束时间输入框、活动专题文案输入框，还有最后的提交和取消按钮。
这是专题管理，接下来我们介绍下第二类后台页面——场次管理。
这是我设计的一个原型图：
场次管理也包括两个页面，一个是“场次列表”，一个是“添加场次”。
其中，场次列表就是针对一个秒杀活动的场次信息。比如 2020 年双十一秒杀活动，它有两个场次——生态链第一场和生态链第二场。每个场次都有各自的场次 ID、关联专题活动、描述、开始结束时间、状态和操作选项（查看、编辑、上线、下线）。
添加场次，就是把每一场的活动信息都添加上，请看下图。
这一页的信息主要有场次关联的活动专题、开始结束时间、场次描述、限购策略、商品、添加按钮，以及最后的信息提交/取消按钮。
这是活动场次管理，场次之下就是具体的商品管理了，前面提到过，它包括商品列表页和添加商品页。 我们来看这个原型图。
商品列表就是一个个商品，每个商品包含的信息有ID、名称、图片、描述、原价、秒杀价、实际库存、秒杀库存、操作项。
比如，我们这里的商品列表里只有小米手环 4 NFC 版和小米手环4普通版这两款商品。
其中小米手环 4 NFC 版的详细信息有 ID “400002”；名称“小米手环 4 NFC 版”；产品图片；描述“大屏彩显，可刷公交、门禁”；原价“229”；秒杀价“189”；库存“10”；秒杀库存“10”；操作项“查看、编辑、删除”。
实际上，这些商品信息都是通过点击“添加商品”这个按钮录入的。请看下图：
除了多出两个“提交/取消”按钮，其他的信息输入框如商品 ID、描述、图片上传、原价、秒杀价、库存、秒杀库存，都是为了填充商品信息而设置的。
以上就是管理后台的三大页面类型以及具体的页面了。
注意：
提交按钮点击后需要给出提示，成功后跳转到相应列表页，失败则给出具体的失败提示，以便运营同学和研发同学快速定位问题。
各功能列表项中查看操作的页面内容，类似于编辑页面，只是查看页面中内容不可修改。
对于进行中或已结束的场次，查看页面需要展示每个商品的剩余库存，以及秒杀成功的用户名单。
接口清单
当然，对于管理后台来说，前后端分离在技术上是大势所趋。所以，除了页面需求外，为了前后端交互方便，管理后台也有接口需求。从以上后台需求分析中，我们可以整理出后台接口大概如下：
管理后台基本上是增删改查的操作，接口设计最好是符合 RESTFul 风格。查询接口需要支持批量查询和单个查询。
小结
上一讲我们从用户侧分析了前端需求，这一讲我们从运营侧和后端研发侧介绍了秒杀活动信息是如何管理的，具体来说就综合分析了秒杀系统的管理后台、后端接口的需求。不知道你学会了没？
在需求分析的时候，为了考虑全面，我们可以站住不同的角色立场来分析，比如站在用户、产品经理，前后端研发、测试人员、运营人员等的角度来看待。
有时候我们拿到的需求并不是详细的需求文档，可能仅仅是个原型图，这时就需要我们充分与业务方沟通，并将沟通结果整理成可拆解的需求点用文档记录下来，以便后续做详细设计和任务拆解。
另外，我们还需要挖掘出隐藏需求，以免评估工作量的时候有疏漏，导致项目延期。
思考题：前面两讲分别介绍了用户侧、运营侧、研发侧分析功能需求，你抽空也可以想想从 QA 侧如何分析功能需求？
可以把你的想法写到下面的留言区哦。
这一讲就分享到这里了，下一讲我将为你分享非功能需求方面的内容。
