设计师应具备很多素质（参考：kiss me ），但其主要工作还是将用户需求转化为合理的软件模型！
近来由于整个团队正在强抓团队合作与项目管理，也由于CollegeSystem系统在需求方面有新的资料，大家需重新对先前的设计进行重新审视，将用例图、数据流图以及六个子系统的扇入扇出等进行完善补充。在此次完善过程中有一点问题值得说说。
在教师工作量的计算重新审视与建立数据流图时，我发现先前的很多信息建在了不同的表中，如计算教师工作量时需要用到论文工作量标准、课程工作量标准、实习见习工作量标准、教师职称单位工作量酬金以及教学补助等标准。
一般来讲这些东西建在多少张表都可以，不过此次我了解到其实他们的存储形式（主要是数据表字段类型）很相似，而且它们都是教师工作量计算的标准，并且每个学校的标准不会有太多，众多学校的标准放到一张表中就很合适。这样一来在处理这部分标准数据时就更具有一致性，也减少了模型的复杂度。
在分析校方的教学计划时发现它分为四大模块，分别是公共模块、专业模块、专业方向模块、实践模块。要是按照上述那种“有二是二”的建模方式那这些数据都要放到不同表中了。而在对这四大模块进行建模时再进行分析会发现专业方向同专业选修类似，实践则同专业必修类似，所以将它们一致性建模。
在课表倒入功能建模过程中，才发现原先的课程号需求不大符合实际需求，实际的课程号各个学校是有自己的安排的，而我们的却是自增的，当然此问题可以通过增加课程编码字段来解决，但它也值得咱们思考，教师号、部门号等的实际需求是怎样的等等！
设计者被“需求”了有两层含义，上面几个事情都有所表现，要务必摒弃：
一是脑子里充满了需求，在设计建模时完全照着需求一步步填充，没有经过再加工，没有转化过程。如需求里有一个课程工作量标准，数据模型中就有一张课程工作量标准表；需求里有一个实践课程，数据模型中就有一张实践课程表。
二是设计者被自己想当然的需求给蒙蔽了，妄加判断，进行建模。如CollegeSystem中课程，实际需求是有一个课程编码的，而它会因不同学校而不同，而我们的只有一个课程id，它却是系统递增的，这样一来就得让用户改变现有的数据，而这个问题只要按真实需求来规划下课程id，就是校方要的课程编码了。