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