
项目编号:HDLH0001
项目名称: 合达联行“乐盒”项目
密 级:公开
版本信息: V1.0
创 建 人:
创建日期:2014年9月10日
审 核 者:
批 准 人:
批准日期:
编辑软件:Microsoft Word 2007/2010中文版
文件状态: √草稿
「」正式发布
「」正在修改
上海正善信息科技有限公司
<版权所有>
文档修订记录
| 版本编号或者更改记录编号 | *变化 状态 | 简要说明(变更内容和变更范围) | 日期 | 变更人 | 批准日期 | 批准人 |
文档审批信息
| 序号 | 审批人 | 角色 | 审批日期 | 签字 | 备注 |
1引言
1.1编写目的
说明:编写这份需求规格说明书的目的。
1.2背景范围
说明:
软件名称:乐盒手机APP
a.待开发的软件系统的名称;
任务提出者:成都合达联行物业服务有限责任公司
开发者:上海正善信息科技有限责任公司
b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
c.该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3术语定义
列出本文件中用到的专门术语的定义和外文的首字母组词的原词组。
1.4参考资料
列出用得着的参考资料,如:
本项目的经核准的计划任务书和合同、上级机关的批文;
属于本项目的其他已发表的文件;
本文件中各处引用的文件、资料,包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
1.5读者范围
指出预期读者。
2调研情况介绍
可采用表格形式简明地描述调研过程,如下表:
| 序号 | 调研对象 | 调研时间 | 调研内容 | 调研人 | 调研方式 | 调研输出结果 |
3需求范围
说明本需求规格说明书是否包含了立项阶段所涉及的所有功能。
如果是合同项目是否包括合同所有需求,及合同以外扩展的需求。
4总体需求
4.1系统组成
说明整个系统的组成和系统运行机理;概述每个子系统的功能,并说明子系统之间的关系。
/**添加**/
系统由java后台,android手机APP,ios手机APP组成。
Java后台为手机app提供数据交互接口,为用户添加数据提供界面。
Android手机app为android手机用户提供数据浏览,数据交互界面。
Ios手机app为ios手机用户提供数据浏览,数据交互界面。
4.2系统的逻辑岗位及职责
不同的单位实际的岗位名称和职责可能不相同,在做需求分析的时候需要加以抽象形成逻辑工作岗位并对每个岗位的职责加以描述。
/**修改**/
系统管理员:对后台数据进行添加修改操作,对一般用户进行删除操作,对一般的管理员进行添加修改操作。
一般管理员:对后台数据进行添加修改,删除。
一般用户:通过手机app,可以浏览数据,与后台进行数据交互。
4.3系统业务流程
在逻辑工作岗位及职责确定之后,需要进一步归纳用户的业务情况。每一项业务都由一个或者多个岗位的人按照一定顺序来完成,可以采用业务流程图来描述每一项业务。
/**修改**/
后台流程图:
app流程图:
5功能需求
5.1需求清单
采用列表形式列举产品的所有需求,每个需求均需标识,并需要确定每个功能的优先级,如可能还应估计每个功能项所需开发时间(包括设计和编码时间)。
标识号采用层次化命名。需求优先级建议分为1、2、3级,其中1级为最高级,表示必须实现的功能。
功能清单可以采用下面的表格表示:
后台管理:
| 标识号 | 需求名称 | 需求说明 | 优先级别 | 备注 |
| 1 | 订单管理 | 1.订单的处理,订单的删除,记录订单处理人,查看订单详情。 | 2 | |
| 2 | 去哪儿玩 | 1.添加攻略的名称,时间,详情。包括上传攻略的图片。 | 1 | |
| 3 | 吃什么 | 同去哪儿玩 | ||
| 4 | 商家管理 | 1.商家的添加,删除,查看详情,修改。 | 1 | 包括玻璃房子,玫瑰园,宜必思。 |
| 5 | 人员管理 | 1.添加管理员,删除管理员,修改管理员。 2.删除注册用户。 | 1 | |
| 6 | 活动管理 | 1.添加,删除,查看,修改活动信息。包括上传活动图。 | 1 | |
| 7 | 操作管理 | 1.操作的查询和查看 | 2 | |
| 8 | 推荐管理 | 1.推荐的查看与删除 | 1 | |
| 9 | App升级管理 | 1.版本的添加和apk的上传。 | 1 | |
| 10 | 特推商家管理 | 1.添加,修改,删除后台特推商家。 | 1 | |
| 11 | 商品管理 | 1.商品的添加,修改,删除 | 1 |
| 标识号 | 需求名称 | 需求说明 | 优先级别 | 备注 |
| 1 | 首页 | 1.读取推荐信息并在滑动栏展示。 2.读取后台特推商家并展示 | 1 | 参考原型设计main_page |
| 2 | 推荐点击 | 1.进入到各自的详情界面。2.推荐内容包括果蔬,活动,去哪儿玩,吃什么。 | 1 | |
| 3 | 点击去哪儿玩 | 1.进入去哪儿玩列表界面,按时间先后顺序排列。 2.根据长假,短假,周末和好评图,发布时间进行过滤排序。 3.列表显示第一张图片,标题,评分,假期类型。 4.点击搜索,搜索去哪儿玩的标题,模糊搜索。 | 1 | 参考原型设计activity_news_page |
| 4 | 点击去哪儿玩列表 | 1.进入去哪儿玩详情界面。 2.点击右上角分享,分享到微信。 3.内容下方的评分,不用登录,可以直接评分。同一个用户可以多次评分。 | 1 | 参考原型设计activity_news_details_page |
| 5 | 点击吃什么 | 1.进入到吃什么列表。 | 1 | 同去哪儿玩列表 |
| 6 | 点击吃什么列表 | 1.进入到吃什么详情 | 1 | 同吃什么详情。 |
| 7 | 点击购物信息 | 1. 进入到购物信息列表 2.点击搜索,根据的标题模糊搜索。 3.列表显示第一张图片,开始时间,结束时间,名称以及店名。 | 1 | 参考原型设计community_news_activity |
| 8 | 点击购物信息列表 | 1.进入到购物信息详情 2.详情界面显示名称,开始时间结束时间,商家名称,活动的列表。 3.活动的列表显示图片,商家名称,商家的描述,活动的内容。 | 1 | 参考原型设计news_details_page |
| 9 | 点击果蔬 | 1.进入到果蔬的列表 2.列表显示第一张图片,商品名称,商品描述,剩余时间,市场价,当前价。 | 1 | 参考原型设计 tuangou_page |
| 10 | 点击果蔬列表 | 1.进入到果蔬详情 2.上面滑动栏,显示商品的图片。 3.点击立即抢购,添加商品抢购界面,(2.0版本不作要求) 4.点击咨询,拨打咨询电话。 5.购买人数可以修改。 | 1 | 参考原型设计tuangou_details_page |
| 11 | 点击品味生活 | 1.进入到品味生活列表 2.列表分为预告和报道两个类别。预告指将要发生的活动,活动完成之后由管理员删除预告活动,并写报道。报道是指已经完成的活动。 3.品味生活放十个类别, 4.列表内容显示图片,名称,描述,时间,类别。 | 1 | 参考原型设计 pingweishenghuo_list_page |
| 12 | 点击品味生活列表 | 1.点击列表,进入到品味生活详情 2.界面最上面的title显示分类的名称, 3.显示赞的个数,并可以多次点击赞。点选赞不用登录。 4.分享到微信。 5.先显示图片,再显示文字。 | 1 | 参考原型设计 pwsh_details_page |
| 13 | 点击房产经纪 | 1.点击房产经纪进入到房产经纪列表。 2.房产列表过滤条件包括地点和房产类型。 3.输入搜索条件,模糊搜索房产信息。 4.列表显示房产照片,房子名称,房子地理位置,面积,房子属性。 | 1 | 参考原型设计house_list_page |
| 14 | 点击房产经纪列表 | 1.点击房产经纪列表,进入到房产经纪详情。 2.显示房子的详细信息。 3.点击拨打电话,直接拨打房产经纪电话。 4.分享到微信 5.房产信息全部都能够修改。 | 1 | 参考原型设计house_details_page |
| 15 | 特推商家 | 1.点击特推商家,进入到特推商家详情。 2.商家详情显示商家名称,商家图片,地理位置,联系方式。 3.分享到微信。 4.点击产品列表,显示产品列表信息。 | 1 | 参考原型设计shoppoing_details_page |
| 16 | 玻璃房子 | 1.点击玻璃房子,进入到玻璃房子详情。 2.玻璃房子 | ||
| 17 | 锦瑞坊 | 参考玻璃房子 | ||
| 18 | 玫瑰园 | 参考玻璃房子 | ||
| 19 | 锦瑞坊 | 参考玻璃房子 |
| 20 | 宜必思 | 参考玻璃房子 | ||
| 21 | 运动中心 | 参考玻璃房子 |
编写需求规范之前应该先制定与当前开发的项目/产品相适用的模板,然后根据这个模板来对需求清单中的所有功能进行描述。可以包含下列内容:
5.2.1需求综合说明
包含下列内容:
(1)使用者的逻辑岗位。
(2)业务背景。即使用者在什么情况下使用该功能。
(3)业务规则。比如算法
(4)后续描述中用到的术语解释
/**修改**/
后台分为管理员和普通管理员角色。
App端是普通的注册用户。
App用户查看社区的活动,打折信息,参加线下活动报名,购买果蔬。
5.2.2需求详细定义
本部分的描述步骤如下:
(1)分析当前需求需要的用户界面。一些功能可能需要多个用户界面;还有一些需求虽然都在一个用户界面中,但界面过于复杂,象这种情况需要拆分为几部分,每部分单独描述。建议给每个界面(或者界面的一部分)按照一定规则编号。
(2)针对每个用户界面需要说明下列内容:
a)界面完成功能简介
b)界面数据描述。对界面中的所有数据项详细定义,一般需要包含下列内容:数据项 名称、数据项说明、数据类型及规则、数据来源、缺省值等。
c)界面操作描述。对界面中所有可能的用户操作详细定义,一般需要包含下列内容:操作项名称、操作过程描述、操作过程中隐含的系统处理、操作的条件(即什么情况下该操作失效)等。
此部分分为两部分描述:后台管理和app端呈现。
6系统接口描述
6.1用户界面
描述需要的用户界面的逻辑特征。
后台界面:1.简洁,以后台的信息操作管理为主。颜色以深蓝为主。
2.左边显示操作栏,右边显示操作内容。
3.操作为标准的操作链接,按钮为标准矩形按钮,有确定和取消。
4.错误信息显示以弹出对话框的形式。
6.2硬件接口
6.3软件接口
| 软件接口名称 | 外部组件名称 | 版本号 | 接口描述 |
| 推荐接口 | 用于首页推荐系统 | ||
| 特推商家 |
| 通信接口名称 | 协议或方式 | 安全要求 | 传输速率要求 | 同步通信描述 |
| Web浏览器 | HTTP/1.0 | 1M | ||
7.1性能需求
需要对软件静态和动态两个方面的性能作出定量规定。
可能包含如下内容:
●所支持的并发用户数。
●容错要求, 如异常操作后应如何处理,如编制预算过程中突然中断时应能自动恢复或保护上一次编制状态。
●数据的处理能力要求,如可处理的文件和记录数,表及文件的大小规模, 数据增长情况。
●对数据存储的空间的要求。
●正常或极端情况下,对用户操作响应速度的要求。
7.2安全性要求
7.3对软硬件环境的要求
| 硬件环境 | ||
| CPU | ||
| 内存 | ||
| 硬盘 | ||
| 网络 | ||
| …… | ||
| 软件环境 | ||
| 操作系统 | ||
| 数据库 | ||
| 相关软件 | ||
| …… | ||
如:美化界面等;
8附录1
8.1原型
8.2采用建模工具所形成的模型文件
在需求分析阶段经常用到一些模型来辅助说明,如果采用结构化分析技术,通常使用数据流程图、实体联系图;而采用面向对象的分析技术,通常使用实例图、顺序图、协作图和状态图。
8.3调研相关资料和文件
如调研报告、会议记录以及调研过程中获取的用户原始资料等。
8.4需求分析过程中制定的相关规范或模板
如原型风格说明、功能规范模板、用户调研规范等。
9附录2:需求确认表
本需求文档建立在双方对需求的共同理解基础之上,是后续的开发的依据,是用户验收的依据。经甲乙双方确认签字后,最终确定。如果需求发生变化,请提出正式书面要求,并且双方协商成本、资源和进度等。
| 需求确认 | |
| 客户代表签字 | 签字: 日期: |
| 项目经理签字 | 签字: 日期: |
