在本文中将分析一个用于新生开学分配寝室的“宿舍秒杀”系统。从用户故事开始探索需求,进而分析得到系统的主要功能和非功能性需求。最后,根据需求分析设计数据库,数据库的设计原则是尽可能的方便之后的需求拓展和修改。
用户故事一般是产品经理初次描述给自己和开发人员看的,然后产品负责人要依据用户故事设计原型,原型在客户那里通过后,然后再在用户故事里面添加附件。用户故事不会一开始就很清晰,甚至可能不会有特专业术语。
学生
,我想要在系统里登录,并获取验证码
,以便于登录到自己的账号中进行宿舍选取
。学生
,我想要查询剩余宿舍的信息
,以便于及时选择或更换寝室志愿
。学生
,我想要查询宿舍的基本信息(楼号、寝室人数、是否为上下铺、寝室朝向)
,以便于选择自己志愿的寝室
。学生
,我想要核对我的个人信息
,以便于在分寝室的时候不会出现错误
。学生
,我想要可以组队抢寝室
,以便于在分寝室的时候不会出现错误
。学生
,我想要可以创建组队
或加入队伍
,以便于进行组队抢宿舍
。学生
,我想要在系统里预先选择要抢的宿舍,到点提交
,以便于在第一时间抢宿舍
。学生
,我想要查看寝室的选取结果(包括分到的寝室号,室友的相关信息)
,以便于及时联系到室友
。寝管
,我想要修改每个寝室的床位信息
,以便于管理寝室信息
。寝管
,我想要按照寝室顺序导出名单
,以便于在报到时让领钥匙的同学签字
。寝管
,我想要查询并修改床位的可用状态
,以便于对损坏的床位进行申请报修
。管理员
,我想要学生核对他们的个人信息
,以便于在分寝室的时候不会出现错误
。管理员
,我想要对学生设置标签
,以便于后期规定按照某一标签(如班级、专业)进行分寝室
。管理员
,我想要系统支持2000人左右的同时访问
,以便于满足学生可以在一个时间点同时抢寝室
。管理员
,我想要防止有同学使用脚本去抢寝室
,以便于保证系统的安全性
。考虑到后期需求可能会发生变动,因此在数据库设计的时候最大程度降低了表与表之间的关联程度。数据库中有两个核心主体——bed
(床位信息)、student
(学生信息)。
dorm
(宿舍信息)、house
(宿舍楼信息)、bed_type
(床铺类型信息)。class
(班级信息)、major
(专业信息)、stu_contact_info
(学生联络信息表)。其中年级信息作为一个属性考虑在班级信息内。对于学生和床位的关系,单独建立了一个关联表rel_bed_stu
。该表使用“学号+时间戳”的方式作为主键,记录学生床位的分配信息。除此之外,还设计了config
表储存系统相关配置信息,admin
表储存管理员相关信息。