1 引言
1.1 编写目的
本文档是武汉大学计算机学院17级大型软件设计课程小组今天吃啥APP项目的初步需求,主要面向开发人员、管理人员、测试人员和用户,使之能够更好的理解系统功能。本说明书不仅是整个软件开发的依据,也对以后的维护性工作起着指导性的作用,同时也是设计说明书和测试计划的编写依据。
预期读者:开发人员、管理人员、用户代表、测试人员等。
1.2项目背景
每日有三问:早饭吃什么 午饭吃什么 晚饭吃什么
今天吃什么往往是困扰许多人的一个难题。即使是已经大三的我们,也常常陷入不知道吃什么的困境之中。由于武大校园面积大、校园内食堂与附近餐饮店铺众多,我们每天在决定吃什么的时候,可选择的店铺不在少数。然而由于不同食堂窗口、商家提供的菜品质量、口味不同等原因,许多学生在进行选择时会出现选择犹豫症,尝试新的窗口怕踩雷,而总在一个窗口时间久了却又觉得厌烦。
因此,我们想到了开发一款可以每天为你规划一日三餐的APP,可以根据用户以往的习惯、身体状况、天气状况为用户指定食谱,同时还结合了市面上美食APP的一些功能,让用户可以自行寻找感兴趣的食堂窗口或商家。
a. 待开发的软件系统名称:
b. 本项目提出者:武汉大学计科青鸟开发小组
c. 开发者:武汉大学计科青鸟开发小组
d. 用户:武汉大学信部学生
1.3 定义
【术语 1】:数据流图
数据流图(Data Flow Diagram,简称DFD),是结构化(Structured)方法中用于表示系统逻辑模型的一种工具,它描述系统由哪几部分组成,各部分之间有什么联系等,它以图形的方式描绘数据在系统中流动和处理的过程。
【术语2】:数据字典
数据字典(DD)是对DFD中包含的所有元素的定义的集合,与DFD结合描述系统的逻辑模型。
1.4参考资料
[1]《软件工程导论》作者:张海藩 出版社:清华大学出版社
[2] 计算机软件产品开发文件编制指南GB8567-88.
2任务概述
2.1目标
由于时间交为紧迫,本APP暂时将目标用户定为武大信部学生,将推荐范围暂定为信部周边食堂及商家。
相应的需求有:
-
用户注册与登录,修改个人信息等。
-
首次登陆时用户可以根据系统提示设置自己的喜好或直接跳过,后续也可进行更改。
-
每天自动为用户生成一日三餐的推荐,并且注明相应信息。若用户不满意可以选择换一换,并且用户可以对推荐菜品进行反馈。
-
提供探索功能,其中包括系统中所有食堂及商家,用户可自行筛选和搜索,类似美团中的搜索功能.
另外,该系统还需要保证数据的安全性、完整性和准确性,提供良好的交互界面,保证系统的流畅运行。框架的设计具有一定的可塑性和灵活性,便于系统后续维护。
2.2运行环境
支持环境:Android ?及以上。
数据库:MYSQL。
开发平台:Android Stdio。
编程语言:JAVA。
2.3假定和约束
(1)本系统必须在本学期结束前完成,因开发时间较为紧迫,可以使用小组成员熟悉的编程语言和现有知识进行开发。
(2)用户要按照操作规程运行本系统,不得进行恶意破坏性操作。
(3)建议该系统最短寿命为5年。
3 数据需求
3.1静态数据
(1)用户信息表
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
UID | Varchar | 20 | 是 | 是 | 用户ID |
Phone | Varchar | 11 | 否 | 是 | 手机号 |
Password | Varchar | 20 | 否 | 是 | 密码 |
Feature | Int | 否 | 否 | 特征值 |
(2)菜品信息表
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
DID | Varchar | 20 | 是 | 是 | 菜品编号 |
ImagePath | Varchar | 50 | 否 | 否 | 图片存放路径 |
Feature | Int | 50 | 否 | 否 | 特征值 |
Season | Int | 否 | 否 | 季节属性 | |
AID | Varchar | 20 | 否 | 否 | 所在商家编号 |
Remark | Float | 否 | 否 | 评价值 |
(3)商家信息表
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
AID | Varchar | 20 | 是 | 是 | 商家编号 |
Name | Varvhar | 50 | 否 | 否 | 商家名 |
Address | Varchar | 50 | 否 | 否 | 商家地址 |
(4)用户信息反馈表
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
UID | Varchar | 20 | 是 | 是 | 用户编号 |
DID | Varchar | 20 | 是 | 是 | 菜品编号 |
Time | Date | 否 | 是 | 最后一次用餐时间 | |
Count | Int | 否 | 是 | 一周内用餐次数 | |
Comment | Int | 否 | 否 | 评价值(单次) |
3.2动态数据
对按钮的点击;搜索关键字、筛选条件;美食项、用户项相应记录修改。
3.3 E-R图
4 功能需求
4.1 功能划分
系统中有用户和管理员两种身份,系统的功能可以划分为如下几个部分:
用户端:
- 用户注册和登录:初次登陆时,用户可以根据系统引导对个人喜好进行设置,也可直接跳过,后续可以修改。
- 每日推荐:每天根据用户喜好、当天天气和用户身体状况等消息为用户制订一日三餐的计划,并且显示详细信息。并且用户可对于每日推荐进行反馈,让算法能够更好的为用户量身定制一日三餐。
- 探索:此处用户可以根据距离、地区、评价、关键字等进行搜索和筛选,自行探索周边美食。
- 个人中心:此处用户可以修改个人信息,进行账号管理等操作。
管理员端:
- 对美食信息进行管理,可以添加、修改、删除美食信息。
- 对用户信息进行管理,审核用户评价等。
5 性能需求
5.1 数据精确度
- 保证每日三餐推荐的更新频率,同时最大程度的符合用户口味。
- 用户进行查询时要保证所有符合条件的美食都要能找到,同时还要保证所查找到的都是准确的、符合用户筛选条件的。
- 确保数据的实时性,即菜品价格、商家位置等真实可靠。
5.2 时间特性
用户登录后进行任何操作时,系统都应该及时进行反应,响应时间不超过3秒钟。另外系统能够监测出各种非正常情况,如网络连接失败、无法连接服务器等,此时给出用户相应的提出,避免出现长时间等待后无响应。服务器如非特殊原因应保持24小时开通。
5.3适应性
本系统应能在Android 及以上操作系统平台上良好运行,对于不同版本Android系统有良好的兼容性。
5.4开放性和可扩展性
- 系统开发过程中应充分考虑以后的可扩展性。商家和食堂的接入范围后续会逐渐加大,面向的用户范围也会增加,每日推荐的准确性和用户查询的需求也会不断更新和完善。所有的这些都要求系统提供足够的手段进行功能的调整和扩充。
- 要实现可扩充性,应通过系统的开放性来完成,即系统应是一个开放的系统,只要符合一定的规范,可以简单地加入或减少系统的模块,通过软件的修补、替换操作来完成系统的升级和换代。
5.5易用性和易维护性
- 系统能够提供良好的用户接口,实现易用的用户界面,尽量选择用户熟悉的术语和操作,并针对用户可能出现的使用问题提供相应的在线帮助,缩短用户对系统熟悉的时间。
- 系统应提供方便的方式供系统维护人员进行数据的备份,日常的安全管理以及系统意外崩溃时数据的恢复等操作。
6 运行需求
6.1用户界面
界面划分:主题明确,排版简洁舒适,图片资料清晰,栏目、菜单设置和布局合理,传递的信息准确及时,字号大小合适、前后一致、美观大方。整体配色和谐自然,不会引起视觉疲劳。 界面划分:分为推荐、探索、我的三个界面。推荐界面为今日一日三餐的推荐,其中显示菜品图片、商家位置、菜品价格、菜品评价等信息。探索界面中可进行筛选搜索,自行探索周边美食。我的界面中可修改个人信息,进行账号管理等操作。
6.2故障处理
- 在用户的输入有错误的情况下,对于用户的输入错误应给出适当的改正提示;
- 为了防止客户端与服务器实现交互过程中造成数据丢失,在网络运输方面采用 http 协议, 实现 TCP 连接,当一定时间内没有得到响应则进行重发等操作。网络传输方面,可考虑建一条成本较低的后备网络,以保证主网断路时数据的通信;硬件方面,要选择较可靠、稳定的服务器机种,保证系统运行时的可靠性。
7 其他需求
安全性:系统有严格的权限管理,逻辑分析以及检测数据完整性的功能。系统要能够防止各类误操作以及潜在的逻辑死角可能造成的数据丢失、破坏。能够针对系统运行出现的异常,跟踪调查出现异常的情况,了解操作意图,有针对性地解决问题。