项目实训---微信小程序选座之需求分析和简单系统设计

6.29

上午整个项目组进行了大致的需求分析，得出了1.0版本的需求分析。

先是小组内进行需求的讨论，然后各组组长和三名组员进行了组间的需求分析，提出并解决了有关审核座位损坏、活动创建源头、签到认定方式等问题。

下午天气恶劣，系统设计讨论推迟进行。

下午对需求进行了添加：增加代人选座功能（考虑到实际，代人选座上限为5），以学号/工号 以及姓名座位代人选座的依据，由此确定删除账号密码登录功能，此功能一是使用少，二是密码作为隐私数据不能作为代人选座的依据、三是密码不具有用户唯一标识性，故在用户第一次登录时，收集用户姓名、学号/工号等相关信息，并以openid和学号/工号作为用户的两个唯一标识（学号/工号只在代人选座时有此功能）

系统设计讨论，初步确定界面大致与猫眼电影app风格相似。首页以活动（和教室）作为索引，包括轮播图、签到、维修等按钮；导航二以教室作为索引，推送教室的活动，包括搜索栏和分类标识；导航三为用户中心，展示用户头型、用户名和用户将参加、已参加、违约情况，通过三个按钮修改下方列表渲染，列表数量定为5个（可点击更多跳转页面查看更多）（以半天作为一个活动时间段，则最紧凑的情况也能说明最近两天半的活动，而此处只是为了显示最近的活动，方便用户查询），对于将举行活动，用户可在规定时间内，通过列表某列的退座按钮进行退座，也可点击列表某列，查看详细的座位表（与选座时的可视化界面一样）；对于违约，每列有申诉按钮，申诉审核形式略（因为实际就不好操作，很涉及用户隐私）。