Taobao产品需求说明书规格最全的PRD.docx
《Taobao产品需求说明书规格最全的PRD.docx》由会员分享,可在线阅读,更多相关《Taobao产品需求说明书规格最全的PRD.docx(47页珍藏版)》请在冰豆网上搜索。
Taobao产品需求说明书规格最全的PRD
文件编号
SPI-doc-TIP-PRD
作 者
黑羽
文档版本
V0.6
最后修改日期
2009/1/20
版本号0.6
TOP接入系统(TaobaoIntergrationPlatform)
产品需求说明书
编写人:
黑羽
编写时间:
2009/1/20
修订控制页
编号
文档版本
修订章节
修订原因
修订日期
修订人
1
V0.1
1-7
创建
2008.12.22
黑羽
2
V0.2
5.2.1-5.2.5
根据NCP和平台组会议修改
2008.12.28
黑羽
3
V0.3
5.1–5.2
根据29日周一TOP架构讨论会,划分清TIP的需求优先级、子系统结构而调整
2009.1.5
黑羽
4
V0.4
5.1
消息中心类型添加,API监控调用管理
2009.1.8
黑羽
5
V0.5
1.1,5.1.1,5.1.2
根据会议批注内容补充和完善
2009.1.16
黑羽
6
V0.6
1.1-1.4,5.1.2,5.2.1
修订
2009/1/20
黑羽
7
8
9
10
请与以下部门讨论PRD
序号
OK?
部门
沟通内容
1.
□
运营中心:
商城、集市、二手闲置、门户
⏹协助设定产品的RaodMap
⏹协助设定targetcustomer:
使用者
⏹协助评估:
营销/推广需求
⏹协助设定商业目标
2.
□
运营中心:
网站运营
⏹协助设定产品的RaodMap
⏹协助设定targetcustomer:
使用者
⏹协助评估:
营销/推广需求
⏹协助设定商业目标
3.
□
客户中心:
客服服务部
⏹讨论客服如何支持:
客服需求
⏹协助评估诈欺/数据窜改风险:
欺诈/数据窜改风险、不当使用风险
⏹预测客服成本、工作量
4.
□
客户中心:
网络安全部
⏹评估安全性
5.
□
产品技术中心:
系统分析师虚拟团队
⏹讨论以确定方案的规模评估、推出计划
⏹进行技术可行性分析,提出关键问题的技术解决方案
⏹评估系统规模,数据量,所需资源等
⏹协助评估风险
6.
□
产品技术中心:
项目经理
⏹协助确定产品发布日期
⏹协助确定产品成本
⏹协助评估风险
7.
□
产品技术中心:
用户体验设计之交互设计师
⏹协助制作Demo
⏹协助确定useflow:
用户使用方式
8.
□
财务分析中心:
财务组
⏹请评估财务需求
⏹协助评估风险
9.
□
财务分析部:
数据分析组
⏹协助确定如何度量产品目标
10.
□
行政管理中心:
法务部
⏹协助评估法务问题并检视合作伙伴:
使用者数据需求、法务需求、版权、隐私权等需求
⏹协助评估风险:
诈欺/数据窜改风险、不当使用风险
11.
□
规则委员会
⏹协助评估规则变更的影响
12.
□
支付宝
⏹协助确定接口、合作方式等
13.
□
阿里软件
⏹协助确定接口、合作方式等
1概述
1.1名词说明
介绍本文档中会使用到的专用名词,如:
新名词、产品内实体单位,请尽量使用大众可理解的名词
名称
说明
开放平台
以开放OpenAPI为核心的服务开放系统。
包括开放数据、开放平台和开放的业务方入口。
TOP
全称:
TaobaoOpenPlatform,淘宝开放平台
App
应用,本文中指由第三方开发的,需要调用淘宝TOP来完成业务的应用程序。
通常表现为浏览器端的页面插件,桌面端的应用程序。
ISV
IndependentSoftwareVender,独立软件开发商。
Role
业务方角色,对应于不同的API访问权限和监控策略。
包括:
买家、卖家、高级卖家等
TPS
每秒业务处理量。
1.2产品概述及目标
请以三到五段文字摘要说明您所提出的新服务(包含推出新产品、现有产品重新设计或升级、现有服务推出新功能)及目标;请包括:
1、产品背景说明;
淘宝开放平台是建立大淘宝的关键要素之一。
以围绕淘宝开放数据和业务为核心,把握商业趋势,以第三方开发软件为助力,建立繁荣的商业生态圈。
对于外部数据的调用和监管,是淘宝开放中最重要的环节之一。
同时,在可预见的外部数据调用大规模增长时,淘宝开放平台也必须拥有适应的机制。
这些就是TIP(淘宝接入平台)的商业背景和需求。
2、产品的目标客户;
从TIP系统的使用来说,有外部客户和内部用户
外部用户:
第三方开发者通过开发的App对TIP平台发出数据调用请求。
内部用户:
a)开发者社区。
开发者通过开发者社区系统向TIP平台请求相关App管理接口和开发者管理接口。
b)AdminCenter。
AdminCenter使用方为淘宝小二。
AdminCenter主要用于管理开放平台的开发者、App、API;统计分析TOP数据调用的情况。
1.3产品roadmap
请描述产品发展的各个阶段,可以用图表等多种方式表述。
产品发展阶段
阶段描述
时间
1
●满足外部数据调用的基本(P1)需求
●实现基本的监控、管理功能
●对App和开发者有最基本的管理,支持AdminCenter对单个ISV单个应用手工纳入TIP管理体系。
●AdminCenter有基本的ISV管理界面,和数据统计分析
2009年3月
2
●完善监控与管理。
(完成相关P2需求)。
●完善App和开发者管理,支持对批量的ISV批量应用纳入TIP管理体系。
●建立初步消息通知机制
●AdminCenter完善ISV/App管理界面,数据统计
●支持开发者社区批量接入第三方开发者
2009年6月
3
●App和开发者管理支持第三方草根开发者。
●将沙箱环境使用结合进TIP的相关申请/管理流程
●支持开发者社区对第三方草根开发者的开放。
●AdminCenter完成半自动化的管理,集合对淘宝Hosting程序的相关支持
2009年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.TIPRouter+Gateway
淘宝接入平台网关:
●分发外部程序调用淘宝业务数据的请求。
●监控、记录和限制外部调用请求
●主动通知应用程序信息
1
2.TaobaoIntergrationManager
淘宝平台集成管理器:
●提供管理开发者接口,用于监控和规范他们开发行为,并划分等级。
●提供管理App信息接口,监控和调整App使用状态;与API调用或权限控制
●提供管理API订购状态接口
●区分API使用角色,和其他TIP子系统协作共同限制业务角色的各种权限。
1
3.TIPAdminCenter
淘宝服务调用管理中心:
●小二人工管理和调整开发者,API,APP的后台工具
●展示淘宝各项服务的调用情况的图表报告。
含开发者、API、APP等相关数据。
1
5.2功能详情
5.1.1TIP服务接入
TIP的服务接入需要处理外部业务数据请求、支持应用能够注册和侦听消息,同时还要进行业务数据调用的监控,以及对自身性能的监控。
5.1.1.1业务数据请求
●简要说明
验证外部数据请求合法性,再将请求转发给相关OpenAPI或内部系统。
●业务规则
序号
优先级
需求名称
需求描述
1.
1
验证请求合法性
●验证App身份和状态
⏹验证App是否在TIM中合法注册
⏹验证App状态是否是正常使用状态
●业务方身份合法性
⏹
●验证会话session合法性
⏹本次会话是否真实有效
⏹会话是否过期
⏹传入参数是否有效
●验证App请求是否越权
⏹当前App请求的API与其在TIM中注册的API权限范围是否相符
⏹当前App请求的API与终端用户在TIM中注册的角色权限范围是否相符
●验证调用方是否在黑名单中
⏹App是否在黑名单中
⏹域名或IP地址是否在黑名单中
⏹终端用户是否在黑名单中
2.
四种会话验证机制
根据App在申请时,申请的API权限范围和使用描述,第一期由小二决定App对应下列那一种应用方式。
并和这种方式绑定。
●固定时间SessionKey
当App应用需要在固定时间内运行时,使用这一种方式授权访问时间。
●根据访问延迟Sessionkey
避免用户在短时间内重复登录,影响软件运作和用户体验
●两次调用间隔不超过15分钟时,自动延长15分钟
●15分钟之内,没有有效调用,会话失效
●使用一次失效Sessionkey
单次调用后即失效,如同买家功能中订单确认。
每次确认都需要认证一次。
●通知失效SessionKey
会话一直有效,除非由我们主动终止。
场景:
一个与淘宝对接的ERP系统一直监控订单的状态。
3.
1
业务方身份验证
●当所调用请求需要终端用户登录时,调用相关验证程序来验证用户身份。
相关验证程序,在本期表现为:
⏹弹出的一个域内的浏览器窗口
⏹内含账户名和密码输入框
●保证用户输入账户和密码的安全性
4.
1
转发请求
●将合法API请求转发给相应OpenAPI
5.
1
返回数据的格式
●将OpenAPI返回的数据对象按调用方要求的格式返回
●支持常用的数据格式
⏹XML
⏹JSON
●易于扩展成其他数据格式。
●界面原型
●执行者
应用程序(App)
●前置条件
●后置条件
●主流程
⏹用户在客户端的App中登录
⏹根据App类型生成相应的Session机制
⏹App从客户端发起数据请求
⏹Gateway返回OpenAPI访问结果
5.1.1.2消息中心
●简要说明
由Gateway将相关业务信息,主动通知给业务调用方。
如,续费,订单状态改变、暂停,特殊通知
●业务规则
序号
优先级
需求名称
需求描述
1.
2
提供消息通知机制
Gateway可以通过主动调用App回调接口,传输消息中心注册过的消息类型。
消息中,包括:
●消息类型
●业务数据:
●其余必需数据:
时间戳等
典型应用场景:
一个大商家的自动订单处理系统:
一旦用户的某个订单付款了,Gateway立刻调用自动订单处理系统服务器的回调接口,发出“已付款”类型消息给它,内含:
消息类型:
已付款
业务数据:
订单号,订单相关信息
必需数据:
时间戳
订单处理系统立刻开始进入后续业务——发货流程。
同理,之后,还有“已确认收货”与财务系统的对接,如,划入应收账款等。
2.
2
消息类型
●订单
⏹“等待买家付款”
⏹“价格已修改”
⏹“买家已付款,等待卖家发货”
⏹“卖家已发货,等待买家确认”
⏹“订单成功”
⏹“订单取消”
●商品
⏹上架
⏹下架
⏹售完
⏹库存报警
●服务状态
⏹到期,停止服务
服务恢复正常
3.
2
使用消息接口的限制
由于消息通知机制系统开销成本较高,初期有限制的开放给高级开发者和特殊大商家角色使用。
●对于开发者的限制:
只有4星级以上才可以调用接口
●对于用户的限制:
⏹买家:
高级用户
⏹卖家:
高级卖家
4.
2
提供消息注册接口
●规范App注册侦听某些类型事件(Event)的方法
●规范App提供的回调接口
5.
2
消息类型注册和撤销
使用方为淘宝小二和淘宝自己的其他管理程序
●消息中心需提供注册新事件的接口,规范事件的数据格式和规范。
●消息中心需提供撤销某事件的接口,供取消事件。
●界面原型
●执行者
●前置条件
●后置条件
●主流程
⏹当App注册相关应用侦听时,传入商家号
⏹该商家的订单或者商品变动时,查找需要接受此消息的App列表
⏹由Gateway按列表逐一调用App回调接口
5.1.1.3监控和性能
●简要说明
服务接入过程中,需要实现性能扩展性、子系统独立互不干扰;有效的记录服务接入情况;监控和管理接入使用。
●业务规则
序号
优先级
需求名称
需求描述
1.
1
性能
●扩展性
由于独立网店的推广,和其他业务推广,在可预计将来OpenAPI访问量的增长将会很迅速。
TIPGateway必须具备易于扩展的软硬件结构来适应这种快速增长。
●子系统互不干扰
⏹一个子系统的性能或者状态发生变化时,不会影响其余系统API的正常。
2.
1
日志
●记录OpenAPI调用情况
⏹日志异步记录
⏹至少保留3个月的记录
●记录黑名单、性能监控的相关数据
●提供日志相关接口
⏹提供给AdminCenter使用
⏹提供给开发者社区等其他子系统调用(不建议)
●日志记录内容:
✧当前时间
✧api_key
✧app_path
✧业务方id
✧客户端IP地址
✧app请求的content-type
✧app请求的bodylength
✧service名称(对应的API名称)
✧uri:
包含path和method_name,不包含service_name,如:
/list/getMember;
✧service返回的状态码
✧service返回的content-type
✧service响应时间
✧service返回的bodylength
✧gateway响应状态码
3.
2
黑名单
●设置外部调用的黑名单。
一旦调用方落在黑名单中,将失去数据访问权。
●黑名单的分级
⏹暂时失效:
禁止权限2小时,之后自动从黑名单中消除。
加入和消除时间记录入日志
⏹固定失效:
必须调用解禁接口,才会从黑名单中消除
●提供黑名单的对外接口
⏹供AdminCenter调用
⏹供其他子系统、其他部门调用
4.
1
性能监控
●实时监控(延迟<=5分钟)
⏹每分钟内单个AppKey或终端用户调用频率明显异常时:
◆自动加入黑名单,设为“暂时失效”
◆将相关信息记录入日志
⏹每分钟内部分接口的性能反映异常(错误码)、挂起时
◆自动调用AdminCenter相关接口
◆将相关信息记录入日志
●分时段统计监控
⏹每晚简要分析TIP各模块的状态
⏹相关信息记录入日志
5.
2
流量控制
●能够根据APPkey和角色控制单个API流量和调用次数。
限制形式如下:
⏹总体限制:
单个App在30秒内访问API次数限制
⏹service限制:
单个API在30秒内能被访问的次数限制
⏹按service+uri进行限制:
可以对单个service+uri进行设置,设置特定的service+uri每秒能被一个app访问的次数
⏹按api_key+service_name进行限制:
可以按单个api_key+service_name进行设置,设置特定的api_key对特定的service_name每秒能访问的次数
⏹按api_key+service_name+uri进行限制:
可以对单个api_key+service_name+uri进行设置,设置特定的api_key对特定的service_name和uri每秒能访问的次数
●甚至控制,单个API对不同角色返回不同结果。
(P2)
●应用场景如:
淘宝助理的流量不加以控制,但别的就不行。
淘宝助理可以调用批量接口对当前Sessionkey中用户商品操作,别的APPkey不行。
●界面原型
●执行者
●前置条件
●后置条件
●主流程
5.1.2TaobaoIntergrationManager(淘宝接入管理)
●提供管理开发者接口,用于监控和规范他们开发行为,并划分等级。
●提供管理App信息接口,监控和调整App使用状态;与API调用或权限控制
●提供管理API订购状态接口
●区分API使用角色,和其他TIP子系统协作共同限制业务角色的各种权限。
5.1.2.1开发者管理
●简要说明
提供管理开发者的各种接口,
●业务规则
序号
优先级
需求名称
需求描述
1.
1
需要录入的开发者信息
在开发者数据库中,所需要记录的开发者相关信息
●该开发者的id号
●常规信息:
⏹联系人姓名
⏹公司
⏹通讯地址:
⏹email
●账户信息:
⏹收款人,收款人支付宝帐号
●对应权限表:
见对应调用权限范围
●等级
⏹分成若干级别,供日后运营调用
●统计信息
⏹信用记录
⏹应用列表
⏹所拥有的App汇总统计数据
●历史记录
●其他备注
2.
2
开发者调用权限范围
●记录该开发者可以调用的OpenAPI范围
●应用场景:
小二从AdminCenter中根据开发者的资质来调整他的API访问等级和权限。
●记录开发者可以注册侦听的Gateway事件类型
3.
2
开发者对应等级
●每种开发者所可以访问的API的范围和API调用时的控制策略是不一样的。
●定为5个等级:
1-5星级
●不同级别,拥有默认的调用权限范围
如果之前权限范围中有超出等级对应默认范围,按合集处理。
4.
1
开发者Manager对外接口
只提供接口,由其他子系统调用,
如,由小二在AdminCenter中调用;开发者社区的相关调用等。
●增加开发者接口
●删除开发者接口
●修改开发者接口
●查询开发者接口
●界面原型
无
●执行者
外部调用方
●前置条件
无
●后置条件
无
●主流程
无
5.1.2.2App管理
●简要说明
提供各种App信息的对外接口
●业务规则
序号
优先级
需求名称
需求描述
6.
1
App的数据内容
●应用名称
●必备接入数据:
⏹应用Appkey
⏹应用接入方式:
代码嵌入/Iframe框架嵌入/客户端
⏹应用类型:
旺铺插件/社区插件/NCP插件/独立外部插件
⏹应用是否需要绑定用户Session
●基本信息:
⏹应用的图标
分三种图标大小,20X20,40X40,80X80
⏹应用的简介
⏹应用的详细描述
●应用的回调接口地址(如果是Client插件,则不需要回调地址)
●Appkey所对应的权限范围表
●App对应的状态
●统计信息
⏹当前使用数
⏹所拥有的API调用汇总统计数据
7.
1
AppKey对应的权限范围表
●记录该App可以调用的OpenAPI范围
●记录App可以注册侦听的Gateway事件类型
8.
1
App的状态
●待审核
●审核失败
●上架中(暂留)
正在发布过程中..
●正常使用
●暂停使用
9.
1
AppManager
对外接口
只提供接口,由其他子系统调用,
如,由小二在AdminCenter中调用
●增加App接口
●删除App接口
●修改App接口
●查询App接口
●界面原型
●执行者
●前置条件
●后置条件
●主流程
5.1.2.3API管理
●简要说明
提供各种App信息的对外接口
●业务规则
序号
优先级
需求名称
需求描述
10.
2
OpenAPI对应信息
//TBD
●OpenAPI对应的角色信息
●OpenAPI对应的Sessionkey是否需要绑定,何种类型。
11.
2
消息通知API对应信息
12.
2
可以设置OpenAPI的角色
●具体设置OpenAPI能被哪几种角色可以访问。
●角色列表见:
5.1.2.4
●OpenAPI
●界面原型
●执行者
●前置条件
●后置条件
●主流程
5.1.2.4Role管理
●简要说明
提供各种终端用户角色信息的对外接口
●业务规则
序号
优先级
需求名称
需求描述
13.
2
终端用户角色
●每个角色对应一组OpenAPI权限、注册侦听消息权限
●角色对应的App
●每个App中需要的角色由App来决定。
14.
2
用户角色
买家:
●普通买家:
没有发生卖出交易的用户
●高级买家:
可以使用TIP的消息接口的用户,该类用户数据可以产生消息发送。
卖家:
●普通卖家:
接口使用权限低。