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












