Taobao产品需求说明指导书规格最全的PRD.docx

文件编号
SPI-doc- TIP-PRD
作　　者
黑羽
文档版本
V0.6
最终修改日期
/1/20

版本号0.6

TOP接入系统(Taobao Intergration Platform)
产品需求说明书

编 写 人： 黑羽
编写时间： /1/20

修订控制页
编号
文档版本
修订章节
修订原因
修订日期
修订人
1
V0.1
1-7
创建
.12.22

黑羽

2
V0.2
5.2.1-5.2.5
依据NCP和平台组会议修改
.12.28
黑羽
3
V0.3
5.1 – 5.2
依据29日周一TOP架构讨论会，划分清TIP需求优先级、子系统结构而调整
.1.5
黑羽
4
V0.4
5.1
消息中心类型添加，API监控调用管理
.1.8
黑羽
5
V0.5
1.1, 5.1.1，5.1.2
依据会议批注内容补充和完善
.1.16
黑羽
6
V0.6
1.1-1.4, 5.1.2,5.2.1
修订
/1/20
黑羽
7

8

9

10

目 录
1 概述 5
1.1 名词说明 5
1.2 产品概述及目标 5
1.3 产品roadmap 5
1.4 产品风险 6
2 使用者需求 6
2.1 需求描述 6
3 可选方案 6
4 效益成本分析 7
4.1 效益估计 7
4.2 产品技术中心成本 7
4.3 非产品技术中心支持成本 8
5 功效需求 8
5.1 功效总览 8
5.2 功效详情 10
5.3 整合需求 11
5.4 BETA测试需求 11
6 非功效需求 11
产品营销需求 11
规则变更需求 12
产品服务需求 12
法务需求 12
财务需求 12
帮助需求 13
安全性需求 13
7 上、下线需求 13
7.1 上线时限需求 13
7.2 下线需求（活动类需求必需明确下线时间） 13
8 运行计划 13

请和以下部门讨论PRD
序号
OK？
部门
沟通内容
1.
□
运行中心：
商城、集市、二手闲置、门户
n 帮助设定产品RaodMap
n 帮助设定target customer：使用者
n 帮助评定：营销/推广需求
n 帮助设定商业目标
2.
□
运行中心：网站运行
n 帮助设定产品RaodMap
n 帮助设定target customer：使用者
n 帮助评定：营销/推广需求
n 帮助设定商业目标
3.
□
用户中心：客服服务部
n 讨论客服怎样支持：客服需求
n 帮助评定诈欺/数据窜改风险：欺诈/数据窜改风险、不妥使用风险
n 估计客服成本、工作量
4.
□
用户中心：网络安全部
n 评定安全性
5.
□
产品技术中心：系统分析师 虚拟团体
n 讨论以确定方案规模评定、推出计划
n 进行技术可行性分析，提出关键问题技术处理方案
n 评定系统规模，数据量，所需资源等
n 帮助评定风险
6.
□
产品技术中心：项目经理
n 帮助确定产品公布日期
n 帮助确定产品成本
n 帮助评定风险
7.
□
产品技术中心：用户体验设计之交互设计师
n 帮助制作Demo
n 帮助确定 use flow：用户使用方法
8.
□
财务分析中心：财务组
n 请评定财务需求
n 帮助评定风险
9.
□
财务分析部：数据分析组
n 帮助确定怎样度量产品目标
10.
□
行政管理中心：法务部
n 帮助评定法务问题并检视合作伙伴：使用者数据需求、 法务需求、 版权、隐私权等需求
n 帮助评定风险：诈欺/数据窜改风险、 不妥使用风险
11.
□
规则委员会
n 帮助评定规则变更影响
12.
□
支付宝
n 帮助确定接口、合作方法等
13.
□
阿里软件
n 帮助确定接口、合作方法等

1 概述
1.1 名词说明
介绍本文档中会使用到专用名词，如：新名词、产品内实体单位，请尽可能使用大众可了解名词

名称
说明
开放平台
以开放OpenAPI为关键服务开放系统。包含开放数据、开放平台和开放业务方入口。
TOP
全称 : Taobao Open Platform, 淘宝开放平台
App
应用，本文中指由第三方开发，需要调用淘宝TOP来完成业务应用程序。通常表现为浏览器端页面插件，桌面端应用程序。
ISV
Independent Software Vender， 独立软件开发商。
Role
业务方角色，对应于不一样API访问权限和监控策略。包含：买家、卖家、高级卖家等
TPS
每秒业务处理量。
1.2 产品概述及目标
请以三到五段文字摘要说明您所提出新服务(包含推出新产品、现有产品重新设计或升级、现有服务推出新功效)及目标；请包含：
1、 产品背景说明；
淘宝开放平台是建立大淘宝关键要素之一。以围绕淘宝开放数据和业务为关键，把握商业趋势，以第三方开发软件为助力，建立繁荣商业生态圈。
对于外部数据调用和监管，是淘宝开放中最关键步骤之一。同时，在可预见外部数据调用大规模增加时，淘宝开放平台也必需拥有适应机制。这些就是TIP(淘宝接入平台)商业背景和需求。

2、 产品目标用户；
从TIP系统使用来说，有外部用户和内部用户
外部用户：第三方开发者经过开发App对TIP平台发出数据调用请求。
内部用户：a) 开发者小区。 开发者经过开发者小区系统向TIP平台请求相关App管理接口和开发者管理接口。
b) Admin Center。 AdminCenter使用方为淘宝小二。Admin Center关键用于管理开放平台开发者、App、API；统计分析TOP数据调用情况。
1.3 产品roadmap
请描述产品发展各个阶段，能够用图表等多个方法表述。
产品发展阶段
阶段描述
时间
1
l 满足外部数据调用基础（P1）需求
l 实现基础监控、管理功效
l 对App和开发者有最基础管理，支持Admin Center对单个ISV单个应用手工纳入TIP管理体系。
l Admin Center有基础ISV管理界面，和数据统计分析
3月
2
l 完善监控和管理。（完成相关P2需求）。
l 完善App和开发者管理，支持对批量ISV批量应用纳入TIP管理体系。
l 建立初步消息通知机制
l Admin Center完善ISV/App管理界面，数据统计
l 支持开发者小区批量接入第三方开发者
6月
3
l App和开发者管理支持第三方草根开发者。
l 将沙箱环境使用结合进TIP相关申请/管理步骤
l 支持开发者小区对第三方草根开发者开放。
l Admin Center完成半自动化管理，集合对淘宝Hosting程序相关支持

10月
1.4 产品风险
请描述产品可能存在风险，比如商务谈判风险？外部合作风险？不妥使用风险 等等。
风险等级为高中低。
风险
风险等级
描述
监控策略
改善策略
（// TBD）

2 使用者需求
2.1 需求描述
请说明此产品目标用户、其需求及使用情境。如已做好personas(代表性角色描述)，也请包含于此。
请具体说明此产品关键使用案例—目标用户最想由此产品满足什么需求？最想藉由此产品处理什么问题？—并依据每个不一样使用案例，区分目标用户及其使用时优先级/关键性/频率。
目标用户
需求描述
场景描述
优先级

3 可选方案
列出全部能够选择达成该产品目标方案关键点（关键思绪），给各方案合适评价，并推荐最优方案。
如另有说明可选方案文档，欢迎使用。

方案介绍
优点
缺点
方案1

方案2

方案3

4 效益成本分析
4.1 效益估计
请提供在多种产品环境中效益估计，并标明关键变量及假设，最好能包含现在和过去效益数据。
示例：
指标1
网游每日支付宝成交额
环境
时间

好
中
差
现实状况

产品公布后一周

产品公布后3周

4.2 产品技术中心成本
请列出设计及布署此产品产品技术中心所需资源需求，包含人力成本，软硬件支出等。 （项目经理应提供帮助）
示例：
人力资源
工作内容描述
成本（人日）
备注
产品经理

交互设计师

开发

测试

非人力资源
成本（元）
描述
硬件投入

软件投入

其它

4.3 非产品技术中心支持成本
请预估此产品相关除产品技术部以外支持投入。
比如：需要客服部投入多少资源用于该产品服务，需要运行部投入多少资源运行该产品。
示例：
人力资源
工作内容描述
成本（人日）
备注
客服专员

运行专员

非人力资源
成本（元）
描述
广告位

邮件群发

5 功效需求
请具体说明此产品关键功效及内容(除了使用者所需功效外，也请说明企业内部操作及维护产品所需要功效或工具，比如报表、管理使用者或维护网站内容工具、用户服务工具等等。
5.1 功效总览
请分别列出全部关键功效及内容模块。
提议使用图表来形象叙述本产品各个组成部分关系。
功效总表
名称
描述
优先级
备注
1. TIP Router +Gateway
淘宝接入平台网关：
l 分发外部程序调用淘宝业务数据请求。
l 监控、统计和限制外部调用请求
l 主动通知应用程序信息

1

2. Taobao Intergration Manager
淘宝平台集成管理器：
l 提供管理开发者接口，用于监控和规范她们开发行为，并划分等级。
l 提供管理App信息接口，监控和调整App使用状态；和API调用或权限控制
l 提供管理API订购状态接口
l 区分API使用角色，和其它TIP子系统协作共同限制业务角色多种权限。

1

3. TIP Admin Center
淘宝服务调用管理中心：
l 小二人工管理和调整开发者，API，APP后台工具
l 展示淘宝各项服务调用情况图表汇报。含开发者、API、APP等相关数据。

1

5.2 功效详情
5.1.1 TIP服务接入
TIP服务接入需要处理外部业务数据请求、支持应用能够注册和侦听消息，同时还要进行业务数据调用监控，和对本身性能监控。
5.1.1.1 业务数据请求
l 简明说明
验证外部数据请求正当性，再将请求转发给相关OpenAPI或内部系统。

l 业务规则
App上架步骤参考：
1. ISV资格申请
2. 沙箱测试
3. 小二审核
4. 正常公布

序号
优先级
需求名称
需求描述
1.
1
验证请求正当性
l 验证App身份和状态
n 验证App是否在TIM中正当注册
n 验证App状态是否是正常使用状态
l 业务方身份正当性正当状态包含哪多个
可能考虑：
沙箱阶段
正式使用阶段

n
l 验证会话session正当性
n 此次会话是否真实有效
n 会话是否过期
n 传入参数是否有效
l 验证App请求是否越权
n 目前App请求API和其在TIM中注册API权限范围是否相符
n 目前App请求API和终端用户在TIM中注册角色权限范围是否相符
l 验证调用方是否在黑名单中
n App是否在黑名单中
n 域名或IP地址是否在黑名单中
n 终端用户是否在黑名单中
2.

四种会话验证机制
依据App在申请时，申请API权限范围和使用描述，第一期由小二决定App对应下列那一个应用方法。并和这种方法绑定。

l 固定时间SessionKey
当App应用需要在固定时间内运行时，使用这一个方法授权访问时间。

l 依据访问延迟Sessionkey
避免用户在短时间内反复登录，影响软件运作和用户体验
l 两次调用间隔不超出15分钟时，自动延长15分钟
l 15分钟之内，没有有效调用，会话失效

l 使用一次失效Sessionkey
单次调用后即失效，如同买家功效中订单确定。每次确定全部需要认证一次。

l 通知失效SessionKey
会话一直有效，除非由我们主动终止。场景：一个和淘宝对接ERP系统一直监控订单状态。

3.
1
业务方身份验证
l 当所调用请求需要终端用户登录时，调用相关验证程序来验证用户身份。相关验证程序，在本期表现为：
n 弹出一个域内浏览器窗口
n 内含账户名和密码输入框
l 确保用户输入账户和密码安全性
4.
1
转发请求
l 将正当API请求转发给对应OpenAPI
5.
1
返回数据格式
l 将OpenAPI返回数据对象按调用方要求格式返回
l 支持常见数据格式
n XML
n JSON
l 易于扩展成其它数据格式。

l 界面原型

l 实施者
应用程序(App)
l 前置条件

l 后置条件

l 主步骤
n 用户在用户端App中登录
n 依据App类型生成对应Session机制
n App从用户端提议数据请求
n Gateway返回OpenAPI访问结果

5.1.1.2 消息中心
l 简明说明
由Gateway将相关业务信息，主动通知给业务调用方。如，续费，订单状态改变、暂停，特殊通知
l 业务规则

序号
优先级
需求名称
需求描述
1.
2
提供消息通知机制
Gateway能够经过主动调用App回调接口，传输消息中心注册过消息类型。
消息中，包含：
l 消息类型
l 业务数据：
l 其它必需数据：时间戳等
经典应用场景：
一个大商家自动订单处理系统：
一旦用户某个订单付款了，Gateway立即调用自动订单处理系统服务器回调接口，发出“已付款”类型消息给它，内含：
消息类型：已付款
业务数据：订单号，订单相关信息
必需数据：时间戳
订单处理系统立即开始进入后续业务——发货步骤。
同理，以后，还有“已确定收货”和财务系统对接，如，划入应收账款等。
2.
2
消息类型
l 订单
n “等候买家付款”
n “价格已修改”
n “买家已付款，等候卖家发货”
n “卖家已发货，等候买家确定”
n “订单成功”
n “订单取消”
l 商品
n 上架
n 下架
n 售完
n 库存报警
l 服务状态
n 到期，停止服务
服务恢复正常
3.
2
使用消息接口限制
因为消息通知机制系统开销成本较高，早期有限制开放给高级开发者和特殊大商家角色使用。

l 对于开发者限制：
只有4星级以上才能够调用接口
l 对于用户限制：
n 买家：高级用户
n 卖家：高级卖家
4.
2
提供消息注册接口
l 规范App注册侦听一些类型事件(Event)方法
l 规范App提供回调接口
5.
2
消息类型注册和撤销
使用方为淘宝小二和淘宝自己其它管理程序
l 消息中心需提供注册新事件接口，规范事件数据格式和规范。
l 消息中心需提供撤销某事件接口，供取消事件。

l 界面原型

l 实施者

l 前置条件

l 后置条件

l 主步骤
n 当App注册相关应用侦听时，传入商家号
n 该商家订单或商品变动时，查找需要接收此消息App列表
n 由Gateway按列表逐一调用App回调接口

5.1.1.3 监控和性能
l 简明说明
服务接入过程中，需要实现性能扩展性、子系统独立互不干扰；有效统计服务接入情况；监控和管理接入使用。
l 业务规则

序号
优先级
需求名称
需求描述
1.
1
性能
l 扩展性
因为独立网店推广，和其它业务推广，在可估计未来OpenAPI访问量增加将会很快速。
TIP Gateway必需含有易于扩展软硬件结构来适应这种快速增加。
l 子系统互不干扰
n 一个子系统性能或状态发生改变时，不会影响其它系统API正常。

2.
1
日志
l 统计OpenAPI调用情况
n 日志异步统计
n 最少保留3个月统计
l 统计黑名单、性能监控相关数据
l 提供日志相关接口
n 提供给Admin Center使用
n 提供给开发者小区等其它子系统调用（不提议）
l 日志统计内容：
² 目前时间
² api_key
² app_path
² 业务方id
² 用户端IP地址
² app请求content-type
² app请求body length
² service名称 (对应API名称)
² uri：包含path和method_name，不包含service_name，如：/list/getMember；由凤先评定

² service返回状态码
² service返回content-type
² service响应时间
² service返回body length
² gateway响应状态码

3.
2
黑名单
l 设置外部调用黑名单。一旦调用方落在黑名单中，将失去数据访问权。
l 黑名单分级
n 临时失效：
严禁权限2小时，以后自动从黑名单中消除。
加入和消除时间统计入日志
n 固定失效：必需调用解禁接口，才会从黑名单中消除
l 提供黑名单对外接口
n 供Admin Center调用
n 供其它子系统、其它部门调用
4.
1
性能监控
l 实时监控(延迟<=5分钟)
n 每分钟内单个AppKey或终端用户调用频率显著异常时：
u 自动加入黑名单，设为“临时失效”
u 将相关信息统计入日志
n 每分钟内部分接口性能反应异常（错误码）、挂起时
u 自动调用Admin Center相关接口
u 将相关信息统计入日志
l 分时段统计监控
n 每晚简明分析TIP各模块状态
n 相关信息统计入日志
5.
2
流量控制
l 能够依据APP key和角色控制单个API流量和调用次数。限制形式以下：
n 总体限制：
单个App在30秒内访问API次数限制
n service限制：
单个API在30秒内能被访问次数限制
n 按service+uri进行限制：
能够对单个service+uri进行设置，设置特定service+uri每秒能被一个app访问次数
n 按api_key+service_name进行限制：
能够按单个api_key+service_name进行设置，设置特定api_key对特定service_name每秒能访问次数
n 按api_key+service_name+uri进行限制：
能够对单个api_key+service_name+uri进行设置，设置特定api_key对特定service_name和uri每秒能访问次数

l 甚至控制，单个API对不一样角色返回不一样结果。（P2）
l 应用场景如：淘宝助理流量不加以控制，但别就不行。淘宝助理能够调用批量接口对目前Sessionkey中用户商品操作，别APP key不行。

l 界面原型

l 实施者

l 前置条件

l 后置条件

l 主步骤

5.1.2 Taobao Intergration Manager (淘宝接入管理)
l 提供管理开发者接口，用于监控和规范她们开发行为，并划分等级。
l 提供管理App信息接口，监控和调整App使用状态；和API调用或权限控制
l 提供管理API订购状态接口
l 区分API使用角色，和其它TIP子系统协作共同限制业务角色多种权限。

5.1.2.1 开发者 管理
l 简明说明
提供管理开发者多种接口，
l 业务规则

序号
优先级
需求名称
需求描述
1.
1
需要录入开发者信息
在开发者数据库中，所需要统计开发者相关信息
l 该开发者id号
l 常规信息：
n 联络人姓名
n 企业
n 通讯地址：
n email
l 账户信息：
n 收款人，收款人支付宝帐号
l 对应权限表：
见对应调用权限范围
l 等级
n 分成若干等级，供以后运行调用
l 统计信息
n 信用统计
n 应用列表
n 所拥有App汇总统计数据
l 历史统计
l 其它备注

2.
2
开发者 调用权限范围
l 统计该开发者能够调用OpenAPI范围
l 应用场景： 小二从AdminCenter中依据开发者资质来调整她API访问等级和权限。
l 统计开发者能够注册侦听Gateway事件类型
3.
2
开发者对应等级
l 每种开发者所能够访问API范围和API调用时控制策略是不一样。
l 定为5个等级：1-5星级
l 不一样等级，拥有默认调用权限范围
假如之前权限范围中有超出 等级对应默认范围，按合集处理。

4.
1
开发者 Manager对外接口
只提供接口，由其它子系统调用，
如，由小二在AdminCenter中调用；开发者小区相关调用等。
l 增加开发者接口
l 删除开发者接口
l 修改开发者接口
l 查询开发者接口

l 界面原型
无

l 实施者
外部调用方
l 前置条件
无
l 后置条件
无
l 主步骤
无

5.1.2.2 App 管理
l 简明说明
提供多种App信息对外接口
l 业务规则
序号
优先级
需求名称
需求描述
6.
1
App数据内容
l 应用名称
l 必备接入数据：
n 应用Appkey
n 应用接入方法：代码嵌入/Iframe框架嵌入/用户端
n 应用类型：旺铺插件/小区插件/NCP插件/独立外部插件
n 应用是否需要绑定用户Session
l 基础信息：
n 应用图标
分三种图标大小，20X20， 40X40，80X80
n 应用介绍
n 应用具体描述
l 应用回调接口地址（假如是Client插件，则不需要回调地址）
l App key所对应权限范围表
l App对应状态
l 统计信息
n 目前使用数
n 所拥有API调用汇总统计数据

7.
1
App Key对应权限范围表
l 统计该App能够调用OpenAPI范围
l 统计App能够注册侦听Gateway事件类型
8.
1
App状态
l 待审核
l 审核失败
l 上架中(暂留)
正在公布过程中..
l 正常使用
l 暂停使用
9.
1
App Manager
对外接口
只提供接口，由其它子系统调用，
如，由小二在AdminCenter中调用
l 增加App接口
l 删除App接口
l 修改App接口
l 查询App接口

l 界面原型

l 实施者

l 前置条件

l 后置条件

l 主步骤

5.1.2.3 API 管理
l 简明说明
提供多种App信息对外接口
l 业务规则
序号
优先级
需求名称
需求描述
10.
2
OpenAPI对应信息OpenAPi对应角色信息。
OpenAPI所对应sessionkey是否需要绑定，和何种类型。

//TBD
l OpenAPI对应角色信息
l OpenAPI对应Sessionkey是否需要绑定，何种类型。
11.
2
消息通知API对应信息

12.
2
能够设置OpenAPI角色
l 具体设置OpenAPI能被哪多个角色能够访问。
l 角色列表见：Error! Reference source not found.
l OpenAPI

l 界面原型

l 实施者

l 前置条件

l 后置条件

l 主步骤

5.1.2.4 Role 管理
l 简明说明
提供多种终端用户角色信息对外接口
l 业务规则
序号
优先级
需求名称
需求描述
13.
2
终端用户角色
l 每个角色对应一组OpenAPI权限、注册侦听消息权限
l 角色对应App
l 每个App中需要角色由App来决定。
14.
2
用户角色需要细化到每个接口上。

买家：
l 一般买家：没有发生卖出交易用户
l 高级买家：能够使用TIP消息接口用户，该类用户数据能够产生消息发送。

卖家：
l 一般卖家：
接口使用权限低。
l 旺铺卖家：
含有API大部分使用权限，但在产品公布等接口上不含有权限
l 商城卖家和外部网店卖家：
含有API全部使用权限
l 高级卖家：
除了含有API使用权限外，还能够使用TIP消息接口。

淘客：
l 能够渠道
15.
2
用户角色绑定
l 在开发者小区提供专门角色权限申请页面
l 在AdminCenter中提供“角色权限”勾选范围

l 界面原型

l 实施者

l 前置条件

l 后置条件

l 主步骤

3.2
5.2.1 AdminCenter
5.2.1.1 管理开发者部分
统计需求：
1
开发者调用统计
以图表形式表现以下数据
l 总调用数、频率日线图
l 调用各个接口次数、图表
l 全部App数量统计、
l 全部开发者分类统计

管理需求：
序号
优先级
需求名称
需求描述
5.
2
待审核开发者
1、 列表显示字段有：开发者类别、联络姓名、电子邮件地址、网址、联络电话、已经过角色。
2、 可做操作有：经过、拒绝
a) 经过后则待审用户自动进入下一个角色待审列表中。
b) 拒绝则需要输入拒绝理由。
审核机制采取一票否决制。
6.
2
已经过开发者
1、 列表显示字段有：开发者类别、联络姓名、电子邮件地址、网址、联络电话，开发者注册应用（点击后能够查看应用具体资料）。
可做操作有：删除
7.
2
删除开发者
1、 被删除开发者如没有注册应用，则输入完删除理由后从列表中消失。
被删除开发者如有注册应用，输入删除理由后，该开发者所属应用也全部被删除，已使用该应用模块也对应被删除。

序号
优先级
需求名称
需求描述
8.
2
开发者列表
1、 以表格方法列出全部开发者。
2、 显示字段为开发者类别/姓名/电邮/应用数目（已经过/未经过）
（//TBD）

l 界面原型

l 实施者
开发者
l 前置条件
登录进入开发者小区，进入管理中心
l 后置条件
无
l 主步骤

5.2.1.2 管理App部分
l 简明说明
数据中心，存放App（应用）和开发者相关信息校验App对应角色
。
l 业务规则
统计需求
1
App应用统计
以图表形式表现以下数据
l 注册数统计
l App单个调用数统计、列表
l 分类统计
l 趋势统计

序号
优先级
需求名称
需求描述
1.
1
添加新应用
1、 需要填写字段为：
l 应用名称
l 必备接入数据：
n 应用Appkey
n 应用接入方法：代码嵌入/Iframe框架嵌入/用户端
n 应用类型：旺铺插件/小区插件/NCP插件/独立外部插件
n 应用是否需要绑定用户Session
l 基础信息：
n 应用图标
分三种图标大小，20X20， 40X40，80X80
n 应用介绍
n 应用具体描述
l 应用回调接口地址（假如是Client插件，则不需要回调地址）

2、 提交后提醒信息中给出api_key，并再次判定用户是否有站点，如无站点提醒同注册开发者时相同。
注册成功后，该应用信息进入调试状态。
2.
1
应用具体资料页
显示应用具体信息，显示内容为添加应用时填写内容和被使用次数、评论。

序号
优先级
需求名称
需求描述
1.

2.
2
修改应用
1、 已上线应用可修改
a) 可修改全部字段
b) 修改后，用户能够选择公布到调试环境或是公布到正式环境，公布到调试环境线上应用，在调试环境中能够添加和使用，并不替换线上应用。
c) 选择公布到正式环境后修改后信息进入审核系统，并不替换线上应用信息。
2、 审核中新应用修改不许可修改。
修改经过后应用对老模块升级。

3.
2
下线应用
1、 已上线应用开发者能够修改为下线状态，审核步骤如同修改
3、 被同意下线应用将从列表中消失，且不能被添加，但原添加模块可继续使用。
4.
2
删除应用
1、 删除上线状态应用：提出申请后进入审核步骤，审核经过后通常使用到该应用模块一并被删除。
5.
2
下线应用
2、 已上线应用开发者能够修改为下线状态，审核步骤如同修改
4、 被同意下线应用将从列表中消失，且不能被添加，但原添加模块可继续使用。
6.
2
下线应用
3、 已上线应用开发者能够修改为下线状态，审核步骤如同修改
5、 被同意下线应用将从列表中消失，且不能被添加，但原添加模块可继续使用。

序号
优先级
需求名称
需求描述
9.
2
应用列表
1、 应用列表依据应用状态分为以下多个tab：已公布、调试中、审核中、被拒绝、下线、删除。
2、 已公布状态应用为已经经过审核，线上正在使用中应用。
a) 显示字段为：icon、名称、上线时间、类别、类型、被使用次数、查看评论。
b) 点击icon或名称能够查看应用具体资料。
c) 可做操作有：修改、删除。
3、 调试中应用为调试环境下才能添加和使用应用，线上环境并不能看到和被添加。
a) 显示字段为：icon、名称、提交时间、类别、类型。
b) 点击icon或名称能够查看应用具体资料。
c) 可做操作有：修改、公布、删除。
4、 审核中状态应用为新应用或修改后提交审核应用，现在处于开发环境中。
a) 显示字段为：icon、名称、提交审核时间、类别、类型、状态（新应用还是老应用修改后待审）。
b) 点击icon或名称能够查看应用具体资料。
c) 可做操作有：修改、删除。
d)
5、 被拒绝状态应用为新应用或修改后提交审核应用被淘宝审核人员拒绝应用。
a) 显示字段为：icon、名称、被拒绝时间、类别、类型、状态（新应用还是老应用修改后待审）、查看拒绝理由
b) 点击icon或名称能够查看应用具体资料。
c) 新应用被拒绝后可做操作有：修改、删除。点击修改后步骤同添加新应用；点击删除后，该应用信息从列表中消失。
d) 老应用修改被拒绝后无可作操作。
6、 下线状态应用为老应用被开发者或淘宝审核者作出下线操作应用，该类应用将不会在列表中出现，且不能被添加，但已使用中不受影响。
a) 显示字段为：icon、名称、上线时间、下线时间、类别、类型、被使用次数、查看评论。
b) 点击icon或名称能够查看应用具体资料。
c) 可做操作有：修改、删除。
7、 删除状态应用为被删除老应用，包含开发者自己删除和淘宝审核删除。
a) 显示字段为：icon、名称、上线时间、删除时间、类别、类型、被使用次数、查看评论、删除理由、删除者角色。
b) 点击icon或名称能够查看应用具体资料。
无任何可做操作，仅仅是一个信息统计。
10.

l 界面原型

l 实施者

l 前置条件

l 后置条件

主步骤

5.2.1.3 管理API部分
l 简明说明

l 业务规则

序号
优先级
需求名称
需求描述
16.
1
OpenAPI各项指标统计
l API接口调用次数统计
l 所耗性能
l 被调用APP数目
17.
2
单个OpenAPI信息
l 名称
l 状态
l 所属角色权限
18.
1
OpenAPI列表
l 列出目前全部OpenAPI
l 信息：
n 名称
n 状态

19.
2
暂停服务
暂停服务包含整体OpenAPI暂停和选定API接口暂停。
n 总体限制：暂停单个App访问API
n service限制： 单个API在30秒内能被访问API
n 按service+uri进行限制：
能够对单个service+uri进行设置，限制访问
n 按api_key+service_name进行限制：
能够按单个api_key+service_name进行设置，设置特定api_key对特定service_name限制访问
l 按api_key+service_name+uri进行限制：
20.
2
更改OpenAPI对应角色
l 更改对应角色权限。

l 界面原型

l 实施者

l 前置条件

l 后置条件

l 主步骤

5.3 整合需求
请具体说明此产品可和其它产品或企业整合需求。
(具体功效应在「功效详情」中说明)
产品/合作企业
描述
基础需求
优先级

5.4 BETA测试需求
请说明是否需要BETA测试，BETA测试要求及期望达成目标。
6 非功效需求
产品营销需求
假如此产品有推广需求和推广资源，请说明使用推广方法、目标受众和是否有限制或特殊要求？ (网站运行部应提供关键内容。
范例：
推广方法
受众
描述说明
站内信通知
卖家

规则变更需求
本产品可能包含到对淘宝规则变更。（(规则委员会应提供关键内容。
产品服务需求
产品上线是否需要客服帮助？此产品计划服务优先级和关键性怎样？当此产品上线后，你想要从客服中得到什么信息？(比如，相关此产品，请依据产品相关数据进行推断，客服每七天处理多少客诉？花多少时间回复e-mail？会员常问问题是什么？) 客服应怎样支持？对客服有何影响？客服最常碰到什么情况？应怎样回应？此产品还未上线前或上线时，客服可或不可和用户沟通，沟通什么？(请和用户服务部和技术支持讨论确定)
范例：服务类型
是否为
新服务
估计服务事件
估计频率
场景描述
服务处理方案
　□
评价被删除 咨询
1000个/天

1、为缓解服务压力，项目采取逐步推进方法，先自动删除 99%以上概率为信用炒作评价，然后逐步降低概率；
2、面对咨询，为客服提供以下功效：
1）后台评价单向删除；
2）后台评价双向删除
3、在知识库、帮助中心添加相关内容；
4、在客服中组织培训；

法务需求
请具体说明和隐私权、知识产权、专利权、商标、服务条款(TOS)、版权、协议责任、用户沟通等相关之法务议题或需求。(法务应提供帮助)
财务需求
此产品是否有特殊会计财务需求，如有请具体说明。(财务部应提供帮助)
帮助需求