选题：实验室故障报修管理系统
一、需求分析
1.在群里，我们采取群投票的方式，询问同学们对这个系统的要求
同学们普遍认为这几点比较重要
- 站内信，方便交流，有些小问题可以比较迅速地解决
- 匿名报修，这样既保护了个人信息，又能正确地汇报故障信息
- 实时故障信息显示，这有助于同学们少耽误时间去找合适的机子上课
- 个人信息的保存，方便自己对自己之前填写的设备故障信息的更新
至于实名表彰，倒是很少同学喜欢。
2.我们采访了实验室教师，询问对这个系统的详细要求
一般流程：学生：“老师，这台电脑坏了打不开” 老师： “哪一台机子”学生： “XX号” 然后看见在每个实验室的讲台上有一个故障登记表 ，会在上面写一些基础信息，之后在管理实验室的老师来关门时候会顺便核查一下，尽快做维修处理。
缺点：信息发布不及时；手工汇总故障信息工作量大；若学生填写故障登记表太过简单，再想去联系学生了解详情麻烦；区分故障处理优先级模糊，容易造成简单问题处理拖拉。
要求：电子化，信息发布比较及时；能自动化处理故障报修信息；分类并检出高优先级的故障好安排工作；可以的话，实现简单通信，小问题及时发现，及时解决。
3.NABCD讨论
N：学院采用手工处理实验室故障信息，就如上面所说的缺点，麻烦，且文件众多，查找记录不容易；文件保存期限短，信息储存生存期过于短暂，不方便日后的翻阅。
A：我们采用了数据库储存信息和网页信息公示的方法。学生在这个网站登陆，根据所给的提示框，填写一些必要的设备故障信息，选择高级选项的话，可以更加具体的描述故障信息，方便教师了解设备状况。同学们填写的信息将保存在数据库中。教师查看时，根据优先级，程序将从数据库中调取故障信息，然后显示在网页上，以供教师处理设备故障参考。还有什么不清楚的事情，教师可以发起站内信，询问报修同学具体情况。
B：数据库储存信息不易丢失，且易于备份。网站信息发布流通快，教师能比较迅速地掌握设备使用状况。
C：这次还有另外一个团队也是选择了这个题目。有对比，竞争就激烈了。
D：我们打算征求学院老师的同意，在学院的一台机子上搭建网站，试着运行使用，收集用户的意见，后期再商讨改进方案。
4.电梯演讲
各位领导/投资人/用户/合作伙伴：我们的产品 实验室故障报修系统 是为了解决 教师处理实验室设备故障信息 的痛苦, 他们需要 一个电子化的系统，但是现有的方案并没有很好地解决这些需求，我们有独特的办法 ：数据库储存信息和网页信息公示的方法，数据库储存信息不易丢失，且易于备份。网站信息发布流通快，教师能比较迅速地掌握设备使用状况。不过这次还有另外一个团队也是选择了这个题目。但是有对比，竞争就激烈了。我们打算征求学院老师的同意，在学院的一台机子上搭建网站，试着运行使用，收集用户的意见，后期再商讨改进方案。
二、原型设计
1.角色：管理员、学生、教师
2.不同角色登陆
- 用户登陆（教师）-->主界面（个人中心、故障登记区、教室故障设备查看、维修信息管理、报修单管理、设备管理）；
- 用户登陆（学生）-->主界面（个人中心、故障登记区、教室故障设备查看、报修单管理）；
- 用户登陆（管理员）-->主界面（个人中心、用户管理、实验室管理、设备管理）；
3.相关功能
- 个人中心 -->用户信息（账号管理、站内信、我的报修单）
- 故障登记区-->填写报修信息（报修方式、时间、选择设备、设备编号等）-->报修单管理（显示当前填写一个条目）
- 教室故障设备查看-->查看实验室故障信息（选择教室）
- 维修信息管理-->显示并操作维修完成的设备相关信息（报修时间、选择设备类型、送修时间、经手教师等）
- 报修单管理-->显示并操作报修单信息（报修状态、选择时间、选择教室等）
- 设备管理-->显示并操作设备信息
- 用户管理-->显示并操作用户信息
- 实验室管理-->显示并操作实验室信息
三、编码规范
1.代码风格：简明（该简略的简略，有的必要不要缩写）、易读（每个函数都要有注释）、无二义性（根据用途定义变量名，勿随意起名）。
2.缩进：采用Tab键
3.在复杂的条件表达式中，采用括号清楚地表示逻辑优先级。
4.条件语句中，若只有一句处理语句，换行缩进一个Tab，不加{}。
5.同一行的变量定义应相同，不要把不同的变量定义在同一行上。