6组 需求分析报告
微信小程序项目
需求分析说明书
1引言
1.1选题背景
该项目适用于生活于福州大学旗山校区的师生职工人员乃至从外来到福州大学旗山校区的人员，用于满足用户对于福州大学旗山校区紫荆园、玫瑰园食堂饮食的各方面知识需求，为用户的饮食提供一定的功能与选择。本项目启动于2022年10月22号，由“软件工程不摆烂小组”进行分析开发以及后续的一系列工作。
1.2说明书目的
该为了能够切实开发出真正可以满足用户需要的小程序，最需要我们实现的是明确了解用户需求。如果说可行性分析是要决定去做还是不做，那么需求分析就是回答系统必须做什么这个问题。需求分析是一个非常重要的过程，它完成的好坏直接影响了后续软件开发的质量。
因此编写此需求分析说明书是因为项目庞大周期漫长，为了使用户以及团队开发人员都能对所开发的系统有一致性的完整性的理解。通过阅读此文档，团队开发人员能够迅速了解项目的具体需求与实现，同时，用户也可通过此文档简单高效地了解系统。
1.3面向用户
本项目适用于福州大学旗山校区中的人群，特别是有堂食习惯人群，准确来讲，本项目面向的人群分为：
核心用户：苦恼与今日就餐选项的人群；
想要尝试好评如潮菜品的人群；
想要将喜爱菜品分享出去的人群；
一般用户：长期单一店家或食堂就餐但想要尝新的人群；
偶尔堂食且不打算随便应付的人群；
坚持尝鲜同时想要避雷的人群；
潜在用户：对未尝试菜品拥有热情但担心失望的人群；
有外卖习惯但有尝试堂食欲望的人群；
而用户属性可以分为：1 人物属性（身高、体重） 2 消费属性（餐饮消费）3 居住属性。
用户画像（例）：
用户一：张寒，男，21岁，大二，居住于生活三区，习惯于在玫瑰园一楼就餐，偶尔点外卖，吃腻了常吃的店家时会苦恼于是否选择尝鲜，没有忌口，但不习惯吃没吃过的店家。
用户二：王涛，男，20岁，大二，居住于生活三区，习惯堂食，但拥有选择困难，时常苦恼于就餐的选择，喜欢尝试朋友推荐的认为好的店家，但还没找到最青睐的店家。
用户三：李依，女，20岁，大二，居住于生活一区，生活较为繁忙，时常点外卖，或者在京元、朝阳等食堂就餐，但酷爱吃面，想要吃遍每一家好吃的面店，对于没尝试过的食堂拥有兴趣。
1.4参考资料
《构建之法之现代软件工程第三版》、《软件工程——实践者的研究方法》等
1.5 logo设计
2 需求分析和产品分析
2.1 需求分析（NABCD模型）
1. Need
这款小程序的目标用户是福大（旗山校区）全体师生，大多数福大学子在饭点都会面临不知道吃什么的问题。学校里的一些食堂窗口与外卖平台并没有合作关系。而且，一些商家只与某个外卖平台合作，那么只使用另一外卖平台的同学对这些商家的了解程度较低，止于听过名字而不知它的菜品的程度。综上，大量同学对食堂里的店面和菜品存在了解需求，这个美食推荐小程序可以帮助大家快速解决点餐的问题并且能吃到符合自己口味的美食，是选择困难人群的福音。
2. Approach
收集紫荆园食堂和玫瑰园食堂的所有门店的菜单放入小程序，然后根据个人喜好和食客评价标签进行菜品推荐。在用户完全不知道吃什么的时候，小程序可以根据用户选择的标签随机推荐菜品，小程序还可以完全随机推荐菜品。
3.Benefit
帮助福大师生了解食堂菜品并推荐与自己口味最契合的美食，告别选择困难，让用户能有更舒适的用餐体验。
4.Competitors
同类竞品有大众点评、饿了么等APP，这些APP首页都有美食入口，且提供了比较丰富的美食筛选，提供了餐厅的招牌菜单，并且包含丰富的图片、描述、评论等等，功能很完整。但是大众点评推荐的福大食堂美食寥寥无几，饿了么平台上缺少很多福大食堂中的门店。我们的产品优势就在于我们的目标受众是福大全体师生，针对性强，推荐的美食聚焦于紫荆园和玫瑰园这两个食堂，专注解决在食堂吃饭问题，将解决该问题做到极致。
5.Delivery
发布小程序后，可通过线上线下相结合的方式进行推广。第一，可以通过微博、微信、QQ、短视频平台等软件进行分享，还可以尝试开通一个微信公众号进行推广。第二，张贴广告。
2.2 竞品分析
1 市场分析
这款小程序的目标用户是福大（旗山校区）全体师生，大多数福大学子在饭点都会面临不知道吃什么的问题。根据大家师生的使用情况，主要使用一些其中在一些点餐APP上例如饿了么、美团。可是，这些没有与食堂所有餐厅进行合作，并不知道一些食堂商家存在。而对于那些想去本身就有去食堂的习惯的同学或者是经常对外卖的同学来说，我们这款小程序能为这些同学提供足不出户便能知道食堂商家的情况。
2 环境现状
民以食为天。福大（旗上校区）全体师生大致有本科生两万多，加上研究生接近三万人。在福大（旗山校区）全体师生都要每天面对每天吃什么而烦恼，所以我们这个小程序帮助大家能提供一个选择的方向。
3思维导图和燃尽图
3.1 思维导图（负责人：陈雅勤）
3.2 功能结构图（负责人：崔佳雪）
3.3 燃尽图（负责人：王家炜）
4 UML图
4.1 组员各自负责的UML图
整体系统用例图1(用户)
负责人：陈雅勤
描述：授权用户对【吃点福大】小程序的大致使用
该部分面临的问题：授权用户如何使用该系统
解决的问题：让授权用户清晰 get 到对该系统的使用
整体系统用例图2（维护人员）
负责人：陈雅勤
描述：运维对【吃点福大】小程序进行维护
该部分面临的问题：运维同学如何使用该系统以及系统异常情况的处理
解决的问题：由运维同学负责查看后台日志信息，更改配置文件等等方式达到维护目 的
就餐前的状态图
负责人：李雅萍
描述：就餐前用户点击进入小程序界面，经统计评价得到的热门餐厅和菜系
面临的问题：用户不知道吃什么，热门推荐可能无法兼顾每个人的口味
解决的问题：多种推荐机制，有热门窗口直接推荐和可以进入今日吃什么随机生成进行 推荐以及根据用户的口味自动生成推荐的三个菜品。可以通过查看菜品详情来获得菜品 的星级
就餐后的状态图
负责人：李雅萍
描述：就餐后用户登录小程序对菜品进行评价和反馈
面临的问题：无法清楚用户是否是恶意评价和反馈
解决的问题：利用窗口保护机制对用户反馈评星进行评价其可靠性
评价控制的活动图
负责人：李雅萍
描述：每个人每天的评论数量是有限制的
面临的问题：防止用户短时间内多次刷评论
解决的问题：记录用户每天的评论数量，超过单个用户最多评论数量则评价失败
菜品加入我的喜欢活动图
负责人：李雅萍
描述：用户对菜品喜欢，进行加入我的喜欢操作
面临的问题：是否会误触把不喜欢的菜品加入【我的喜欢】
解决的问题：在【我的喜欢】中更加直观看见喜欢的菜品
云图标签推荐的活动图
负责人：李雅萍
描述：用户根据云图标签获得菜品推荐
面临的问题：部分菜品与推荐的标签可能存在不符合的情况
解决的问题：应用了用户反馈机制，后台通过用户反馈信息修改菜品标签解 决标签 与菜品不符问题
我的页面活动图
负责人：李雅萍
描述：用户在我的页面可以实现的操作，进行用户反馈，查看我的喜欢和我 的收藏
面临的问题：用户怎么知道自己是否反馈成功
解决的问题：回复用户该反馈是否采纳
用户详情页面的活动图
负责人：李雅萍
描述：用户根据自己的喜好选择标签设置偏好和忌口
面临的问题：标签不够全面，用户不知道从哪里进去该界面
解决的问题：应用了用户反馈机制，用过用户反馈的信息添加缺少的标签，进行提 示
今日吃什么活动图
负责人：李雅萍
描述：随机为用户推荐今日吃什么
面临的问题：随机推荐有可能是用户不喜欢的菜品
解决的问题：用户选择困难症，不知道去哪吃，吃什么
店家保护机制触发的活动图
负责人：崔佳雪
描述：【店家保护】的触发
该部分面临的问题：如何防止大批恶意用户刷评价
解决的问题：我们引入【店家保护】的概念，当触发异常条件，便执行该模块
店家保护机制的活动图
负责人：崔佳雪
描述：【店家保护】主要是针对恶意用户的
该部分面临的问题：大批恶意用户刷评价
解决的问题：开启【店家保护】机制，当系统检测到某店家的评价在短期内大量增加，将该店家判定为异常店家，开启保护，再次收到相同评价，直接返回评价失败
推荐三道菜的活动流程图
负责人：崔佳雪
描述：根据标签快速筛选出大多用户【点赞】过的菜品
该部分面临的问题：用户选择好标签后，如何把点赞度高的菜品推荐给用户
解决的问题：把每条标签下各个菜品的点赞数查出来，从点赞数高于一定值的菜品中随机抽出三道菜品显示在【推荐三道菜】页面
原型图（部分1）
负责人：陈孟琪
描述：用户使用界面
面临问题：设计风格，还有如何去让前端和后端建立链接
解决问题：能大致明确所实现出来的页面
原型图（部分2）
负责人：林灿坤
描述：用户使用界面
面临问题：设计风格，还有如何去让前端和后端建立链接
解决问题：能大致明确所实现出来的页面
E-R图
负责人：王家炜
描述：展现实体之间的关系，以及实体的属性
该部分面临的问题：实体较多，关系难以理清。还有实现的难度很难预估
解决的问题：理清了实体间的关系
实体类图
负责人：黄智勇
描述：实体类的设计与实体间的关系
该部分面临的问题：怎么对现实世界做出抽象并且与库表建立联系
解决的问题：明白所建立的对象的关系
5 功能描述和功能验收标准
5.1 功能描述
该小程序能现实通过对菜品的关键字的搜索而现实对菜品的查找和对通过食堂的筛选进行对食堂商家进行查找和认识，能让大家进一步减小对“吃什么怎么吃”的困扰。
通过对菜品的评分，能快速分享给大家这道菜是否好吃，也能通过“喜欢”和“收藏” 快速找到自己所喜欢的菜品和店家。
5.2 功能验收标准
能实现对菜品、食堂、店家收纳数据后能对的菜品搜索功能和店家的筛选功能，收集对用户对菜品数据的评分，来实现热门菜系的推荐。用户能通过标签的选择让程序推荐出随机的三道菜，和通过“喜欢”和“收藏”快速找到自己所喜欢的菜品和店家，还有对该程序进行即使反馈。
