考试系统之后对需求理解

 

需求是最重要的环节——磨刀不误砍柴工

 

如果把做系统比作砍柴的话，那么需求绝对是一个前期的磨刀环节——重要，不容忽视。

 

需求理解不好，导致原型图，画不准确，然后是类图分析不到位，已经到这个地步了，后期根据类图敲出来的系统又怎么可能会好。所以，需求分析一定要清晰，不能做到面面聚到，但是也要抓住这个系统的灵魂。

 

对于考试系统半年的相处，需求总是那么的赤裸裸：根据给定的题库，配出需要的模板，或者试卷，让学生在指定的考试时间内进行考试，然后进行成绩评定。

正因为这样，我们在考试系统2.0的基础上，开始进行重构。

当时第一开会的时候，达哥就给我们展示了一张，巨大无比的需求图。一下子把我给吓到了。我们的原则是：在2.0的基础上，好的继续保持，旧系统的遗憾，这次重新分析，把功能补全，旧系统的缺陷，一定要摒弃，本着这个原则，一直在进行。

 

考试系统有三个端，学生端，教师端，管理端。我着手的是教师端中的两个模块——模板，试卷。

这篇博客就谈谈对“模板管理”的认识。

 

 

二、需求分析的误区

 

1、走不出旧版本

 

走不出2.0的影子，界面，思维。

 

有什么样的界面，就可以推出对应的逻辑。

看完２.０的界面，我的思维被救版本给束缚住，一时没有走出来，直到系统做完，自己充当用户使用的时候发现，系统的灵活性严重不足。

这个时候才体会到，界面设计是不合理的，不符合“用户正常使用习惯”。正因为那个界面，我的逻辑就开始顺着“界面逻辑”走，没有重新分析模板和考试之间的关系，模板和课程之间的关系，没有比较这三者的关系。

要不是自己做了几天的用户，自己实实在在来操作这个界面，是感受不到自己设计的不合理。通过“用户”给我的体验，重新思考之后发现，界面中的出现的每个实体的摆放位置不同，不同实体之间的依赖关系就不同，有可能决定这个界面需求的灵活性。

 

尽管一直再说，要抛开旧版本的束缚，可是没有理解透需求，还是很难摆脱的掉的。

 

2、缺乏实战经验

 

第一：界面太复杂，没有意识到。

 

这张界面上的东西已经很多了，从概要设计到详细设计，再到再次细化。本身这个界面上的80%的控件都是动态加载出来的，而且每个课程下的章节和题型都不确定，这就意味着，有可能一个课程下有十六个章节，八个题型，那么要是用户进行细化模板的，仅仅是文本框，这个界面上就得加载出150个，考虑不周全，没有想到这个界面在正常使用下是什么情况。

 

第二：不懂用户需要什么

 

用户第一次见到这个界面，还没等我们开口，就抛出一句话，这个界面太复杂，我们不需要，整不了。是啊，在回头看这个界面，简直是惨不忍睹，密麻麻，用户需要的是简洁明了，一看就懂，上手就可以操作的系统。

时刻记住，不是我们做什么，用户用什么，而是站在用户角度：做用户需要什么，我们做什么的系统。

 

 

3、找不着全局

 

分析需求的时候，考虑不周全，同一个模块的增删改查，总是利用不合理，增删改查被孤立。

而我们只是做到了增加就是增加，查询就查询，没有做到，在增加的时候可以查询显示信息，查询的时候，依然可以增加信息。某个信息可以在有关联的界面中都可以被查询，而不是非得到指定页面才可以操作。界面之间的关联性太少。

例如：考试和考生这两块。

只要是我添加了考试，给这个考试建立关联，只要是碰到这个考试的时候，可以查绚到该考试下的考生信息（人数，考试时间，地点等）；在考生管理模块，对于已经攒在的学生，可以知道该考生的信息（考试，学院，班级，联系电话）。当然这些信息都不是来自一个表，正因为我们才要这样组合查询显示，而不是具体查某一块到某一块的领域再去查，要尽可能把相关信息给查出来。

 

 

三、不懂灵活性

 

做完这个系统，自我感觉对“灵活性”有解读了。

代码灵活性：以前就是空白。因为用户中途修改需求，而给我们带来就是改动代码，这样的经历，让我突然明白我的代码是写死了。代码灵活性，现在的看法感觉像是代码的复用率，适应范围。复用率高，适应范围广。

 

敲代码不能保证，只要需求变动，代码完全不动，但是要保证在可控范围内需求发生变化，我们的代码不用修改。我们在敲代码的时候，就得想到“现在需求”可能出现的情况。好比试卷乱序：今年是一套乱，明年就可能是多套乱，这样就需要一个变量来传递信息，根据这个变量的值进行试卷选择，不是单纯的选择一套

 

接口：一些可变因素，编程决定不了的东西，要给用户留接口，不要按照常规处理。变是永远不变的。

既然要乱序，那么切不要以为什么题型都可以乱序？如果根据常规习惯来编程，那么你就错了。什么题型需要乱序，什么题型不需要乱序，这个有可能每年要不一样，所以，在乱序的时候，我们是决定不了的，需要用户决定，这样我们也需要把乱序题型写成变量传递。由用户决定的东西，我们就必须给用户留下界面，根据用户的要求，传递参数进行编程。

 

这是对需求的宏观理解，接下来的几篇文章是对某个需求的不断改进过程。