团队作业2——需求分析&原型设计

Posted 2020-09-09 teamworkers

选题：实验室故障报修管理系统

一、需求分析

1.在群里，我们采取群投票的方式，询问同学们对这个系统的要求

同学们普遍认为这几点比较重要

• 站内信，方便交流，有些小问题可以比较迅速地解决
• 匿名报修，这样既保护了个人信息，又能正确地汇报故障信息
• 实时故障信息显示，这有助于同学们少耽误时间去找合适的机子上课
• 个人信息的保存，方便自己对自己之前填写的设备故障信息的更新

至于实名表彰，倒是很少同学喜欢。

2.我们采访了实验室教师，询问对这个系统的详细要求

一般流程：学生：“老师，这台电脑坏了打不开” 老师： “哪一台机子”学生：  “XX号”  然后看见在每个实验室的讲台上有一个故障登记表 ，会在上面写一些基础信息，之后在管理实验室的老师来关门时候会顺便核查一下，尽快做维修处理。

缺点：信息发布不及时；手工汇总故障信息工作量大；若学生填写故障登记表太过简单，再想去联系学生了解详情麻烦；区分故障处理优先级模糊，容易造成简单问题处理拖拉。

要求：电子化，信息发布比较及时；能自动化处理故障报修信息；分类并检出高优先级的故障好安排工作；可以的话，实现简单通信，小问题及时发现，及时解决。

3.NABCD讨论

N：学院采用手工处理实验室故障信息，就如上面所说的缺点，麻烦，且文件众多，查找记录不容易；文件保存期限短，信息储存生存期过于短暂，不方便日后的翻阅。

A：我们采用了数据库储存信息和网页信息公示的方法。学生在这个网站登陆，根据所给的提示框，填写一些必要的设备故障信息，选择高级选项的话，可以更加具体的描述故障信息，方便教师了解设备状况。同学们填写的信息将保存在数据库中。教师查看时，根据优先级，程序将从数据库中调取故障信息，然后显示在网页上，以供教师处理设备故障参考。还有什么不清楚的事情，教师可以发起站内信，询问报修同学具体情况。

B：数据库储存信息不易丢失，且易于备份。网站信息发布流通快，教师能比较迅速地掌握设备使用状况。

C：这次还有另外一个团队也是选择了这个题目。有对比，竞争就激烈了。

D：我们打算征求学院老师的同意，在学院的一台机子上搭建网站，试着运行使用，收集用户的意见，后期再商讨改进方案。

4.电梯演讲

各位领导/投资人/用户/合作伙伴：我们的产品 实验室故障报修系统 是为了解决 教师处理实验室设备故障信息 的痛苦, 他们需要 一个电子化的系统，但是现有的方案并没有很好地解决这些需求，我们有独特的办法 ：数据库储存信息和网页信息公示的方法，数据库储存信息不易丢失，且易于备份。网站信息发布流通快，教师能比较迅速地掌握设备使用状况。不过这次还有另外一个团队也是选择了这个题目。但是有对比，竞争就激烈了。我们打算征求学院老师的同意，在学院的一台机子上搭建网站，试着运行使用，收集用户的意见，后期再商讨改进方案。

二、原型设计

1.角色：管理员、学生、教师

2.不同角色登陆

• 用户登陆（教师）-->主界面（个人中心、故障登记区、教室故障设备查看、维修信息管理、报修单管理、设备管理）；
• 用户登陆（学生）-->主界面（个人中心、故障登记区、教室故障设备查看、报修单管理）；
• 用户登陆（管理员）-->主界面（个人中心、用户管理、实验室管理、设备管理）；

3.相关功能

• 个人中心 -->用户信息（账号管理、站内信、我的报修单）
• 故障登记区-->填写报修信息（报修方式、时间、选择设备、设备编号等）-->报修单管理（显示当前填写一个条目）
• 教室故障设备查看-->查看实验室故障信息（选择教室）
• 维修信息管理-->显示并操作维修完成的设备相关信息（报修时间、选择设备类型、送修时间、经手教师等）
• 报修单管理-->显示并操作报修单信息（报修状态、选择时间、选择教室等）
• 设备管理-->显示并操作设备信息
• 用户管理-->显示并操作用户信息
• 实验室管理-->显示并操作实验室信息

三、编码规范

1.代码风格：简明（该简略的简略，有的必要不要缩写）、易读（每个函数都要有注释）、无二义性（根据用途定义变量名，勿随意起名）。

2.缩进：采用Tab键

3.在复杂的条件表达式中，采用括号清楚地表示逻辑优先级。

4.条件语句中，若只有一句处理语句，换行缩进一个Tab，不加{}。

5.同一行的变量定义应相同，不要把不同的变量定义在同一行上。