1、限定某个学期，比如2005－2006上学期
2、软件学院，计算机教育系统，A教师本学期要开一门课程，比如C语言。
3、学生选课（这一块不准备在程序中实现，就是说目前不准备支持开发学生选课功能，采用用户现有系统，或线下进行，选课系统无开发计划）
4、做为学习类系统，我们不关心几点在哪个教室上课的问题，就是说排课系统无开发计划。
5、将结果形成EXCEL，包括内容字段：院系，年级，学生姓名，学号（唯一标识），选择了哪一个课程。
6、我们主要是想得到某一学期，某一课程，N个教师，M个时段(上课位置)：虚拟班，哪些学生。
比如：东北师大，2016－2017上学期，软件工程这门课程，有两位教师上，命名为A和B，A在周一，三的上午9：00至11：00，命名为X班，周二，周四下午的2：00至4：00 ，命名为Y班，
B在周二和周四的晚上7：30至9：30.命名为Z班，这样相当于映射产生了3个班级。
这些班级和教师的留作业，上成绩，给学分等都是有实际意义的，不能缺失。
我们应该把精力放在必不可以的业务模型上，不应分散精力在选课，排课等管理类系统中，这类系统开发琐碎，推广难度大，一般职业和大学都已经有现成系统，全面推广很难。我们可以只做一个方向，其它东西采用对接开放的心态进行EXCEL层面的对接即可。
7、课程
一般大学，职业等院校，课程有公共课，选修课，必修课，学分 等概念，个人认为是纯粹的教务管理系统，目前云平台不应更多涉猎，对于我们的主线，学习的知识化构建、教学类业务模型要专注。
8、全新的基础数据，命名为基础数据3.0系统，全新开发，构建于空间之中，完成后，其它业务系统对接到3.0版本系统，并提供对旧基础数据的迁移功能。
9、涵盖的范围包括：组织机构，人员，角色，权限，CRM，权限可视范围，帐号，课程计划，任课计划。
10、最大限度的延长基础数据改造的讨论时间，要事无俱细，不能盲目上马，尽力做精做强，不能应付了事。对于已经分析完毕，可以省略的功能一概省略，保持注意力集中，做精一块就一块。
11、第一轮讨论完成基本模型，第二轮讨论细化到缓存和伪代码，第三轮专门讨论如何实现旧系统的迁移工作。
教育软件基础数据概要设计
1、行政区划
省、市、县（区）
2、学校
（1）幼儿园，小学，初中，高中，职业，大学
（2）国家标准中说有：小学，初中，高中，九年一贯制，完全中学等，这个视为学校的一个属性，但并不依赖于这个属性，称为办学类型。
但比如合肥幼儿师专，有高中，有高等师范（两个方向，一个是培养幼儿教师，另一个是培养小学教师），就不能简的在办学类型中找到答案，而教育培养讲究的是连续性，就是各种组合可能随时出现，我们的基础数据要想
全面兼容，就是做两件事，一是以国家标准和规范进行学校属性标注，另一个就是允许各种阶段进行组合。比如合肥的幼儿师专，我们就可以选择国家标准中的大学，但也要按我们思路选择组成部分：高中，大学。
（3）教育部直属、省直属、市直属、普通
这一条也是做为属性标注在学校身上，而不是因为学校直接放在某市下就变成了市直属。比如长春市市实验中学可以录入到净月区中，但属性却是市直属。统计净月区学校中，应统计属性为普通，同时地理位置是净月区的
学校，而不是简单的读取净月区下的学校。其实就描述的是两类事实，一类是区属学校有哪些，市直学校有哪些，二类是按地理位置查看的实际情况，互不干扰，不可混淆。
3、教育管理机构
教育厅，教育局可以随时增加，不再是默认产生于系统中，依赖于行政区划而存在，但同一行政区划下只可以创建一个，比如吉林省下只可以创建吉林省教育厅，长春市下只可以创建长春市教育局，不能在省下创建教育局，
不能在市下创建教育厅。创建的教育厅和教育局，存在天然的递归管理关系，不用再次设置。
4、组织机构
就是一个树型结构，可以随意增加，但在增加部门时可以选择部门的属性，比如：学院、系、专业，这三类分类是默认的字典，当然也可以选择普通。
以东北师大为例，可以创建工商管理学院，人文学院等，创建结点并标注属性为学院，继续创建系，也可以直接在学校下创建系，没有学院，这个是灵活的，没有严格要求，不能在树状结构中靠级别去维护，要依赖于属性。
以合肥幼儿师专为例，可以创建N个系，M个专业，那样N-M之间是有挂接关系的，我们很容易就可以找到有哪些系，哪些系、哪些学院下有哪些专业。
5、班级
小、初、高的班级按目前实施没什么大问题，暂不讨论。
幼儿的班级一般是按小班，中班，大班，学前进行划分的，也建议使用属性标签进行分类。
班级的名称一般是田园A班，田园B班，蜜桃A班，蜜桃B班等，不能按基础教育的命名规则进行，需要人为定义名称。
幼儿园的班级整体变更是经常存在的，比如田园班升级到蜜桃班，那么应提供学生的班级ID整体变更功能。
职业教育的班级：在专业或系下直接挂接班级，不像基础教育一般是直接挂接在学校下边的。一般建议采用入学年份和专业名称生成班级名称，也应提供一个别名功能，方便识别。
大学教育与职业教育视为一致性处理。
6、人员
（1）身份：教师，学生，家长
（2）类别：幼儿园，小学，初中，高中，职业，大学，可以区分是具体哪类人群
7、各系统的使用权限及相应进行的修改工作。
请各组听明白修改的意图后，自行组织讨论汇报要修改的文档。
8、本轮基础数据修改的幅度很大，同时需要完成模型改造，接口文档提供、周边系统修改、系统优化，整合CRM优化等几大类工作。
基础数据修改工作由吴缤牵头，组员有：姜旭、冯丽杰、李怀宇。
9、角色+权限+权限范围
角色划分为系统角色+业务角色两种，目前可以定义系统角色只有市教育局管理员，县区教育局管理员，校管理员，教辅单位管理员四种，这类的特点是设置为此角色后，自定查找相应的组织机构ID，
比如157中学中一名教师A被设置为校管理员，那么他的角色为校管理员，默认的是管理一所学校。系统不支持一个管理员同时管理两所学校。如果真有特殊的需求，可以再定制功能进行补充。
对于业务角色，比如教研员，要求只审核语文科目下第一册，第二册的资源，那么这些东东属于业务概念，要求业务系统自行实现。就是说在基础数据中不能指定A教师是教研员，具体的教研员任命都规划到业务系统范围，比如资源审核功能，或教学业务功能。同时需要回复谁是教研员，还要进一步回答此人是哪科目的，负责哪册，这些是多张表提供支持的，基础数据只提供最基本的A－教研员角色的配置功能，其它的业务信息由业务系统自行提供完成。