第一篇：蜘蛛纸牌游戏需求规格说明书
蜘蛛纸牌游戏
需求规格说明书
二、需求规格说明书
1．引言.............................................................................................................................................2
1.1编写目的.............................................................................................................................2 1.2项目背景.............................................................................................................................2 1.3参考资料.............................................................................................................................3 2．任务概述.....................................................................................................................................3
2.1待开发软件的一般描述.....................................................................................................3 2.2 用户特征............................................................................................................................3 2.3运行环境.............................................................................................................................3 3．功能需求.....................................................................................................................................4
3.1功能需求...........................................................................................错误！未定义书签。4．外部接口需求.............................................................................................................................5
4.1用户接口.............................................................................................................................5 4.2硬件接口.............................................................................................................................5 4.3软件接口.............................................................................................................................5 4.4故障处理.............................................................................................................................5 5．性能需求.....................................................................................................................................5
5.1数据精确度.........................................................................................................................5 5.2时间特性.............................................................................................................................6 5.3适应性.................................................................................................................................6 6．软件属性需求.............................................................................................................................6 7．其它需求.....................................................................................................................................8 8．数据描述.....................................................................................................................................8
8.1静态数据.............................................................................................................................8
8.2动态数据.............................................................................................................................8 8.3数据库介绍.........................................................................................................................8 8.4数据词典...........................................................................................错误！未定义书签。
8.5数据采集…….....................................................................................................................9 9.系统模型
9.1逻辑模型……....................................................................................................................9 9.2用例图……........................................................................................................................11
1．引言
1.1编写目的
本需求规格文档的目的是说明蜘蛛纸牌游戏平台最终需要满足的条件和限制，为进一步设计和实现提供依据。本文档将用户的需求用文字的形式固定下来，是与用户沟通的成果，也是用户验收项目时的参考。
本文档将供开发组团队成员查阅和使用，其中包括系统设计人员、编程人员、测试人员。
1.2项目背景
目前蜘蛛纸牌游戏在休闲游戏市场上有着很大份额，给用户提供一个放松娱乐，相互交流学习的平台，也是目前大多数网民娱乐的主要方式。蜘蛛纸牌游戏是真正适合各种年龄群的用户使用的具有寓教于乐意义的游戏。在当今如此盛行网络游戏的时代，教育网游的诞生不能不说是一个绝好的切入点。因此蜘蛛纸牌游戏就更适合于教育网游。与一般传统的角色扮演类游戏相比，蜘蛛纸牌游戏的开发更适合于如今网游的发展趋势，从另一方面更可以使如今的用户远离一些血
腥暴力游戏所带来的危害。益智休闲类游戏不仅满足用户对游戏的需要，也是一种促进智力发展的手段。
1.3参考资料
[1]蜘蛛游戏平台-项目开发计划书
2．任务概述
2.1待开发软件的一般描述
蜘蛛纸牌游戏平台是一款基于c++的游戏平台。此平台的目的在于给用户提供一个放松娱乐，相互交流学习的平台。
2.2 用户特征
本蜘蛛纸牌游戏平台适合于任何年龄段的网民玩家，不受教育水平，工作经验及技术专长的影响，2.3运行环境
1、硬件运行环境
本系统运行于基本的PC系统之上。（硬件配置略）
2、软件运行环境
本系统运行于Linux发行版之上，内核2.6以上、bash环境、glibc 2.6
3．功能需求
(1)打开游戏：
(2)进行游戏：要想赢得一局，必须按降序从 K 到 A 排列纸牌，将所有纸牌从玩牌区移走。在中级和高级中，纸牌的花色还必须相同。在按降序成功排列纸牌后，该列纸牌将从玩牌区飞走。
在不能移动纸牌时，可以单击玩牌区底部的发牌叠，Windows 就会开始新一轮发牌。
不限制您一次仅移动一张牌。如果一串牌花色相同，并且按顺序排列，则可以像对待一张牌一样移动它们。
（3）重启游戏：如果玩家在游戏过程中需要重新玩游戏，可以点击“游戏”菜单里的“开始”，这是游戏就会重新发牌，玩家可以重新体验游戏。
(4)自定义游戏外观：如果玩家对当前的游戏设置不满意，可以选择“游戏”菜单里的“更改外观”游戏，选择备选外观之一。(5)退出游戏：在游戏的任何时候，玩家都可以点击“x”按钮，退出游戏
4．外部接口需求
4.1用户接口
本系统属于终端应用程序，无GUI界面，以命令行方式运行，接收命令行参数。同时以良好的命令行菜单为用户导向
4.2硬件接口
本系统硬件接口为x86，用户只需一台PC机器即可运行。
4.3软件接口
本系统运行需要C标准库，基于GCC4.3编译。
4.4故障处理
正常使用时不应出错，对于用户的输入错误应给出适当的改正提示。若运行时遇到不可恢复的系统错误，必须保证数据库完好无损。
5．性能需求
5.1数据精确度
查询时应保证查全率，所有在相应域中包含查询关键字的记录都应能查到，同时保证查准率。
5.2时间特性
一般操作的响应时间应在0.5秒内
5.3适应性
满足运行环境在允许操作系统之间的安全转换和与其它应用软件的独立运行要求。
6．软件属性需求
6.1可靠性
本系统的最终用户涉及面广，因此，整体系统运行要求稳定，有很强的防错、抗错能力，保证数据报送工作正常进行。
可靠性指标：在连续运行情况下，系统可靠性99.9999%。提供应用服务器集群技术和组件技术支持高可靠性和伸缩性。
6.2可维护性
系统从设计上尽量考虑使得大多数统计系统的建设都能使用本软件搭建而成，量少做二次开发或者不做二次开发，直接通过系统配置搭建系统，从功能上具有通用性，易修改和扩展。软件开发使用组件技术，保证了可维护性高。系统具有开放性，是指统计、分析内容的可修改、可扩展性。例如，经过一定的授权，系统管理人员即可根据将来统计制度变动的需要对统计指标进行增、删等修改，无需经过软件开发技术人员。
6.3兼容性
系统应支持多种操作系统、数据库系统和、WEB服务器系统。
6.4可用性
本系统采用C/S模式，同时，系统采取容错技术，具备数据恢复功能，能够保证用户随时随地操作系统。
6.5可移植性
本系统采用c++编写，能够实现跨平台操作。
6.6可测试性
软件系统具有良好的可测试性，能够在短时间的情况下顺利完成所有测试项目。具体测试项目如下：
代码检查：程序开发人员除了调试外，还应进行重点检查程序代码语法错误。
单元测试：对组成系统的每个组件进行数据结构测试和功能性测试，重点是组件的功能和程序逻辑。
集成测试：将组件组装成子系统后，应再次对组装后的子系统进行功能性测试，重点是组件与组件之间的接口测试。
系统测试：经过测试后的各子系统组装成系统后，还应组织对整个系统进行全面的测试，包括功能、性能以及接口测试。
性能测试：测试系统的操作相应速度以及资源占用效率。压力测试：测试系统的可靠性和伸缩性，以验证系统能承受多大的负载。
6.7易用性
系统应操作简单、易学易用，丰富的联机帮助，人性化的操作界面，界面布局合理，节省操作时间。
7．其它需求
保密性和私密性需求：
网络传递数据经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。
8．数据描述
8.1静态数据
静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据
8.2动态数据
动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间
8.3数据库介绍
用户数据库：玩家个人信息，所有游戏的分数信息
8.4数据采集
是确保数据快速正确地输入系统，本系统选用键盘输入，鼠标输入。
9.1 系统模型
1、用例图
The use case of spider playing card
第二篇：需求规格说明书编写心得
需求规格说明书编写心得
以下是本人总结的《需求规格说明书》编写心得，由于人个水平有限，欢迎大家补充。
1.需求编写依据
合同、招投标文件、调研记录以及项目经理提供的已确定的需求规格说明书（内部）等。
2.主动与项目经理的沟通
反复的沟通，才能深入把握项目的实际需求，获得更多的资讯和资料。
3.项目背景
1)阐述目前遇到了什么样的问题，并充分说明该问题的严重性和紧迫性，若能提供一些数据或运用一些真实、典型的案例，不仅可以充分的说明该问题同时还能表明你对该项目的了解；
2)如何解决该问题；
3)为什么要提出这样一个系统；
4)最后扼要概述该系统的长远战略意义。
这样从逻辑上层层递进，不仅可以让自己的思维严谨起来，也使自己写出来的东西变得专业些。
4.系统总体概述
简单介绍系统的基本情况、特点、展示功能框架及阐述其优势。主要围绕是什么，有什么样的功能特点，能起到什么样的作用。
5.术语与用词
列出与系统有关的在文档中一定会提到的专业术语，没有提到的术语则不需要列出，否则会给读者带来一定的负担。还有要统一表达方式，如“修改”，“编辑”，“用户”，“员工”等等，以避免引发歧义。
另外，需求文档不需要华丽的词语，以客观事实的原则，切忌掺和主观思想，注意用词准确，精简表达其业务就可以。同时还需注意几点：等等、很多等抽象词尽量不使用；我认为、以为等主观词语切忌出现，尽量避免口语化。
6.描述模块
在编写模块时，通常包括模块描述、重要业务及流程、功能需求定义、业务数据字典、原型界面图等。
模块描述
要明确指出建设了哪些功能，帮助用户实现什么、目标、基础等
重要业务及流程
对该业务进行认真分析，得出该功能事项的有效规则，以激发该功能。可以通过画流程图，快速帮助阅读者理解，但一定要注意质量，避免产生误导。
功能需求定义
需求中每个功能点力求写的清楚，一个需求文档下来能清楚统计出功能有多少个，并指明什么用户使用。一般情况下，要先写简单的，权限少的角色。此文档是设计的基础，是系统验收的依据。
数据字典
写出实体类的中英文属性名称、类型和说明（如是否为表主键）。
重要界面原型图
该功能模块的重要原型图。
第三篇：需求规格说明书-参考1
丰台区红十字会需求说明书
面、公文流转功能、个人通讯录功能）；通讯助手（公共通讯录）；个人邮箱（实现OA内部收发邮件等功能）；制度查询（实现可读文件查询-查询功能）；用户管理（增加、修改、删除用户，以及用户权限管理功能）。（2）.办公管理区（传文系统）：
类似于丰台区卫生局VPN传文系统，主要功能：文件收发系统（24个街乡镇红十字会文件的发送、收取、下载管理）。（3）.会务工作专属区：
主要功能：基层上传文件、统计报表、信息投稿等，上传时要记录时间、统计数量。且这些内容可以由管理员设置阅读权限。
3．区红十字会简介、政策法规、会员社区、志愿者之家、在线学习（自救互救知识）、健康快车、教师园地为首页导航栏部分内容。（1）.区红十字会简介：
主要功能包括：单位介绍（组织机构图）；领导班子（领导照片）；科室职能（工作职能及联系方式）；地理位置（区位图、联系电话、地址、公交路线、E-mail）；基层介绍（各街乡镇红十字会联系电话、地址）。（2）.政策法规：
基本上是固定内容，主要内容包括：法律（中华人民共和国红十字会法、红十字标志使用办法、公益捐赠法）；法规（未定）；规章（中国红十字会章程、北京红十字会章程）。（3）.会员社区（是否要增加会员在线注册等功能）：
主要功能：入会条件和审批流程（结构图）；会员职责（文字介绍）；会员活动信息；下载中心（可下载团体会员、个人会员入会表格）。（4）.志愿者之家：
主要功能：发布招募志愿者信息；志愿者条件；加入志愿者申请表格（网上填写，有模版）；志愿者专用标识；交流天地（内容由管理员上传，类型类似于新闻）；批注加入志愿者（个人信息、特点、工作意向；注册，自动统计人数）。（5）.在线学习（自救互救知识）：
北京同方卫康科技有限公司 丰台区红十字会需求说明书
主要功能：在线学习流程介绍（流程图）；在线学习分两种，一种是普及型，普及型的对象是对了解一些自救互救知识有兴趣，但是并不希望拿到证书的人群，因此普及型的在线学习不需要记录成绩，只要统计人数（学习人数还是考试人数？）；另外一种是取证培训，即通过考试以后可以得到证书。取证学习分为1.注册（注册时需要登记本人身份证号码）2.在线学习理论以下几个阶段：○；○3.在线考试（试卷为50道选择知识，学习时间达到要求后可以参加在线考试；○题，从题库中读取，其中一部分为固定要考的题目，另外一部分为每次随即抽取的题目），考试结束后系统立即自动给出分数，并通知是否及格，如果及格，则
4.学员认为视可以进行下一步的学习（视频操作，可下载，不记录学习时间）；○频操作已经学习完毕，可以上网下载准考证表格填写后，携带本人身份证，到红十字会指定地点参加现场操作考试。如果通过现场考试则现场发给证书。（6）.健康快车：
主要功能：丰台红页（图片文字，参考北京市红会）；健康护照（文字与数据对照）；健康、急救知识查询（友情链接相关网站）。（7）.教师园地：
主要功能：下载区；讨论区；短信猫；公告区。4．会长信箱（表格式填写）。主要功能：表格式填写内容，可参考妇幼保健院的院长信箱。
5．红十字文化馆、传播与学习、知识手册、爱心桥、小动物急救站内容形式相似，放入首页另一列导航栏。（1）.红十字文化馆：
主要内容：城市明信片（丰台照片-图片）；宣传展示台（红十字宣传品、纪念品照片-图片）；红十字标识（红十字标志介绍-图片+文字）；红十字会史话（图片+文字）；红十字与奥运（文字资料）；博爱天地（会刊）；人物传记（《南丁.格尔传》）。（2）.传播与学习：
类似于在线学习中的普及型学习，不记名，只记录学习人数，同时题库可以
北京同方卫康科技有限公司 丰台区红十字会需求说明书
生成自测题，考完即可给出成绩。主要功能：会务知识（图片+文字；支持PPT文件；可下载；可随时生成自测题，考完立即出成绩；记录学习人次）；人道法传播（同会务知识）。（3）.知识手册：
全部是文字内容。主要内容：捐献造血干细胞知识；预防艾滋病知识；健康保健知识；无偿献血知识。（4）.爱心桥：
主要内容：网上捐献（捐献表格、联系方式；捐献造血干细胞志愿填表）；捐献遗体（联系方式）。（5）.小动物急救站：
主要内容：图片+文字。6．公告栏。
公告栏为首页漂浮框，主要内容：通知、招聘、招募内容。7．网上调查。
网上调查（对网站管理、急救知识学习情况调查，自动生成结果）。8．友情链接网站：中国红十字会；北京市红十字会；丰台区政府；各区县红十字会。
9．新闻之窗（图片、文字滚动栏）
主要内容：区红十字会工作新闻（图片+文字）。
四、运行需求
操作系统：Windows98 Windows2000 WindowsXP Windows2003 数据库：SqlServer2000 Web服务器：IIS6.0
北京同方卫康科技有限公司
第四篇：返利APP需求规格说明书
安徽木子林科技有限公司 返利APP需求规格说明书 1 用户端
1.1 登录
1.1.1 功能说明
使用帐号（手机号码）和密码登录
1.1.2 注意事项
1.判断账号和密码是否合法，合法的话，直接登录；不合法的话给出对应提示
1.2 注册
1.2.1 功能说明
用户：使用手机号、验证码、邀请码（选填）、密码注册 一级代理：后台确定身份，在大后台设置账号和密码 二级代理：一级代理在其个人中心中进行绑定
1.2.2 注意事项
1：用户注册页面：推荐码可以进行选填，也可以获取系统默认的验证码，一旦输入有效的推荐码则上下级关系绑定
2：一级代理注册：超级管理员为其添加登录账号和密码，并且可以进行修改
3：二级代理注册：二级代理需要一级代理在个人中心处添加，添加成功则代表着关系绑定
4：每个手机号只可以注册一个身份，如果需要切换身份，则需要重新注册账号，同时之前的账号逻辑和账号信息保持不变
5：注册之后需要绑定支付宝，绑定的支付宝在个人中心可以编辑修改
1.3 忘记密码
1.3.1 功能说明
使用手机号、验证码、密码找回密码
1.3.2 注意事项
1：使用手机号和验证码找回密码，无论哪种身份，在APP里面都可以找到密码
1.4 首页
1.4.1 功能说明
首页包含搜索框、banner图、推荐商品
1.4.2 注意事项
安徽木子林科技有限公司 返利APP需求规格说明书
1：搜索框：输入商品名称中的关键字，搜索全平台商品
2：banner图片：可以设置跳转链接，点击进行跳转，同时不限制张数 3：推荐商品：首页推荐商品样式，首页可以利用不同的页面布局或者排版展示推荐商品，可以只是部分商品推荐，也可以是每个分类推荐同时推荐该分类下的个别商品，具体请在原型图阶段确定
4：推荐商品：点击进入到对应的列表页面或者商品详情页面
1.5 商品
1.5.1 功能说明
商品页面主要是展示各个商品列表，包括商品分类和商品详情
1.5.2 注意事项
1：商品分类、商品列表和商品详情中的字段都是从淘宝中获取，关于页面商品分类和商品列表需要重新出，商品详情页面可以使用原生（和淘宝的详情页面一模一样）也可以另外出图（可以自定义布局和样式）
2：点击商品分类可以对商品进行筛选
3：点击商品列表可以查看商品详情，在商品详情页面可以加入购物车、分享、收藏、立即购买
1.6 积分商城
1.6.1 功能说明
在积分商城页面展示后台添加的所有的积分商城商品，用户可以利用账户中的积分进行购买，购买之后按照正常流程进行发货
1.6.2 注意事项
1：积分商城商品列表展示信息包括：商品的缩略图、商品积分价格、商品名称，点击可以查看详情
1.7 购物车
1.7.1 功能说明
购物车内显示用户选中的商品列表
1.7.2 注意事项
1：购物车页面：已加购物车的商品列表，根据加入购物车的时间排列，时间越近越靠前。列表中显示商品缩略图、商品名称、用户选中的商品规格（尺码、分类）、商品价格（根据会员的身份显示，会员显示会员价，代销身份也显示会员价）、购买数量，购买数量可直接加/减，如下图：
2：购物车页面：用户可以直接勾选列表中的商品，在底部合计栏显示所选中商品的价格总和，结算栏显示选中列表商品的个数。点击结算，进入确认订单页面
3：购物车页面-编辑：点击编辑，可删除选中的商品
4：用户将商品加入购物车后，如果后台此时重新编辑了商品信息，则购物车中的信息也要更新
（1）如果用户选中的商品规格被更改，则显示商品状态为已失效，点击商品进入商品详情页面，显示已更新的数据，用户可以选择其他规格商品重新加入购物车，但购物车中仍保留之前的失效商品数据，用户清空失效商品后，失效商安徽木子林科技有限公司 返利APP需求规格说明书 品不再显示
（2）如果已加入购物车的商品在后台被删除，则此商品在购物车中显示的商品状态为已失效，仍显示在购物车列表中；在用户端商品列表中消失，也不再显示在后台商品列表中，只存在数据库中
（3）如果购物车里的商品在后台被下架，则该商品在购物车中的状态为已失效，在用户端商品列表中消失，但仍显示在后台普通商品管理的列表中
（4）已失效商品，点击商品名称/缩略图进入商品详情页面，只更改了规格的商品可以显示商品详情，可以选择其他规格加入购物车/直接购买；已经被删除/下架的商品提示“该商品已被下架或删除”
（5）已失效商品不显示购买数量
（6）点击清空失效商品将删除所有失效商品
1.8 个人中心
1.8.1 功能说明
个人中心包括：个人信息、积分收入、我的推广、我的订单、我的收藏、支付宝设置
1.8.2 注意事项 1.个人信息：
1）个人信息包括个人头像、推荐码、姓名/昵称、性别、手机号，在个人中心首页，点击头像/昵称进入到个人信息编辑页面
（1）个人头像：可编辑，从相册中选择/拍照，图片大小不能超过2M（2）推荐码：系统自动生成，不可更改（3）姓名/昵称：可以更改
（4）性别：可编辑，选择男或者女
（5）手机号：点击手机号进入到手机号修改页面，利用手机号和验证码进行更改，更改成功之后本次不重新登录，下次登录账号使用新手机号登录
（6）点击保存，保存信息同时跳转到个人中心 2.积分收入
1）包括：总收入、即将到账、已到账、可提现和返利订单 2）返利订单包括：即将到账订单、已到账订单、无效订单
3）积分收入来源：作为一级或者二级代理，下级的用户在APP中购买商品，确认收货之后可以获得一定积分，或者本人在APP内购买商品确认收货之后可以获得一定积分
4）积分提现：每个月的20号，用户可以提交提现申请，申请提现的支付宝账号是在注册或者在个人中心编辑设置的，后台收到申请，审核通过之后会把对应的返利打到用户的支付宝账户
3.我的订单：
1）点击我的订单进入我的订单主页面
2）我的订单：订单排列顺序按照订单创建时间排列，最新订单显示在首位
3）我的订单（具体的按照淘宝提供的接口为准）：显示订单编号、订单状态、商品列表（商品缩略图、商品名称、商品价格、商品规格、购买数量）、订单内商品数量、合计金额、订单操作等
安徽木子林科技有限公司 返利APP需求规格说明书 4）订单状态（具体的按照淘宝提供的接口为准）：
待付款、待发货、待收货、待评价、取消订单、退款订单、退货订单 4.我的推广：
1）如果用户身份是一级代理，则该用户可以在我的推广中添加二级代理，添加成功的二级代理有登录账号和登录密码，同时有一个唯一的推荐码
2）在我的推广中，可以查看到我的一级好友和我的二级好友 5.我的提现：
1）提现明细：显示出申请时间、申请的金额、申请的状态、提现账号、提现流水号，点击账号可以查看以弹窗显示 6.收藏宝贝：
1）收藏的商品列表，按时间排列，最新的收藏在首位 2）收藏列表中的商品，可以删除，删除的方式后期确定 3）收藏的商品不显示规格参数
4）收藏的商品被删除/下架，收藏页面显示商品状态为已失效，点击商品名称提示“该商品已被下架或删除”
5）点击清空失效商品将清空所有已失效商品 7.支付宝设置
1）注册时绑定的支付宝账号可以编辑修改 8．系统设置
包括版本检测、退出登录
1）版本检测：默认显示当前版本，点击可以查看是否是最新版本 2）退出登录：点击进入到商城首页
安徽木子林科技有限公司 返利APP需求规格说明书 2 后台
2.1 登录
2.1.1 功能说明 登录使用内置帐号密码登录
2.1.2 注意事项
1.判断账号是否存在，不存在的话文字提示用户“当前账号不存在，请重新输入”
2.判断账号是否合法，不合法的话给出对应提示
3.判断账号密码的一致性，不一致或者有错的话给出提示
2.2 控制台
2.2.1 功能说明 展示统计数据
2.2.2 注意事项
1.控制台：包括总注册人员、一级代理人员、二级代理人员、用户人数等
2.3 用户管理
2.3.1 功能说明
包括一级代理添加、用户管理
2.3.2 注意事项
1：一级代理的添加：添加的主要内容是一级代理的登录账号、登录密码、支付宝信息
2：用户管理：列表显示用户基本信息，并且可以查看对应用户的上下级，比如，用户A的父级，以及用户A的二级和三级
3：用户管理：在用户列表中可以对用户账号删除、禁用并且可以对大代理进行编辑
2.4 积分商城商品管理
2.4.1 功能说明
积分商城商品管理在后台进行积分商城商品管理处添加
2.4.2 注意事项 1.积分商城商品管理：
1）显示商品总数、上架个数、下架个数，显示商品列表，内容包括商品名称、商品价格、上下架、操作，如下图：
2）查询条件：商品名称
3）上下架：点击上架，商品将在用户端-商品区域对应的分类中显示；对已上架的商品点击下架，商品将不在用户端-商品区域对应的分类中显示，只显示在后台
5）操作：添加/编辑/删除：
2.5 订单管理
2.5.1 功能说明
安徽木子林科技有限公司 返利APP需求规格说明书 包括：订单管理（具体的展示数据以淘宝接口为准）
2.5.2 注意事项
1.显示内容包括：总订单、待支付订单、代发货订单、已发货订单、已收货订单、已评价订单、退款订单、已完成订单、退货订单
2.查询订单条件：时间段、订单号、订单状态等
3.订单内容包括：订单编号、下单时间、购买账号、商品名称、规格、单个商品价格、购买数量、订单状态、付款总金额、收货人信息
2.6 财务管理
2.6.1 功能说明
包括：财务管理、提现管理、分销体系设置
2.6.2 注意事项
1.财务管理：收入统计：总收入、已提现等 1）收入统计
可以显示出平台内所有的收入订单，并且可以通过查询条件查询 2.提现管理
显示APP用户提交到所有提现申请，申请的金额可以查看到对应的订单以及订单状态，后台给出审核，如果同意申请，则直接打款至支付宝账号，否则直接拒绝
3：分销体系设置
主要是设置每个等级用户获得返利比例
2.7 广告图管理
2.7.1 功能说明
目前设置在APP首页，如果特殊要求请提出
2.7.2 注意事项
1.banner图显示在用户端首页
3.banner图列表：展示：banner图片、链接、名称和操作等
2.8 系统设置
2.8.1 功能说明
包括：启动图管理、服务协议管理、账号设置
2.8.2 注意事项 1.启动图管理：
1）启动图为用户打开APP，未进入首页时出现的图片 2）上传启动图图片，图片尺寸：480×800，图片类型：png, gif, jpg, jpeg，图片的质量不能大于2M
4、服务协议
服务协议：富文本编辑框 操作：保存 6.账号设置
安徽木子林科技有限公司 返利APP需求规格说明书 1）超级管理员账号为内置账号，只能修改密码 2）帐号列表如下图： 3）操作：添加/编辑/删除
（1）添加/编辑：添加/编辑管理员名称、帐号，输入密码、确认密码，点击确定即可添加/编辑成功
安徽木子林科技有限公司
返利APP需求规格说明书
第五篇：软件需求规格说明书检查单
《软件需求规格说明书》检查单
文档组织与完整性
1.所有对其它需求的内部交叉引用是否正确？
2.需求为设计提供了充足的基础么？
3.是否所有需求的书写详细程度都是一致的、合适的？
4.是否包括了每个需求的实现优先级？
5.是否定义了所有与外部硬件、软件和通讯的接口？
6.是否定义了功能性需求内在的算法？
7.软件规格说明书是否包含了所有已知的业务需求？
8.是否记录了所有可能的错误条件所产生的系统行为？
9.对所有内部和外部接口的描述，是否都符合模板的要求，即包括来源、目的、输入、输出和激发条件？
正确性
10.是否没有需求间的冲突或重复的需求？
11.是否每个需求都是无二义性的？
12.是否每个需求的描述都是简洁、清晰的？
13.是否每个需求都可以用测试或同级评审来进行验证？
14.是否每个需求都在项目的范围内？
15.是否每个需求都没有内容或语法上的错误？
16.是否需求中必需的信息都没有遗漏？如果有的话，是否标记为“待决定”了？
17.在已知的约束条件下，是否可以实现所有的需求？
18.是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性
19.对所有性能目标都作了适当的说明么？
20.对所有安全和防护性的考虑作了适当的说明么？
21.对其它相关的质量属性目标是否明确地文档化和量化，且进行了可接受的权衡也被详细说明了？
可追溯性
22.每个需求的标识都是唯一和正确的么？
23.每个软件功能需求都可追溯到客户需求么？
特殊问题
24.是否所有需求都是名副其实的需求，而不是设计或实现方案？
25.是否确定了对时间要求高的功能并定义了它们的时限标准？
点击咨询 