A．系统流程
学生提交缓考申请缓考申请情况学院管理员获取考试信息学校管理员提交学生缓考申请
B．学生登录
学生登录是否是学生是否查看考试缓考申请学院管理员学校管理员是是否通过是否通过否是否学生结束 B．管理员登录
学院管理员登录是否是管理员是查看考试信息否安排监考教师打印考试表结束学校管理员登录是是否是管理员设定考试日期是是否修改考试日期否自动考务是否是否修改考试安排否结束
3.16 有关人员需求和培训需求
本系统有5名参与构建的成员，具备一定的软件开发知识和经验，客户方的管理人员需要具备一定计算机操作知识，并进行简单的培训。当系统出现重大故障课联系开发人员进行维护和改进，可进行长期合作。
3.17 其他需求
暂无其他需求，当后期产生需求变更时刻适当补充。
4. 合格性规定
本系统根据需求方云南大学教务处的需求，完成了考务管理系统的全部功能，拥有自修复功能，较好的安全保护，简单实用的系统界面，适合各类人群，简单易用，明显，简单易懂的功能菜单，能及时提交错误信息 本系统的测试详见《软件测试报告（STR）》
5. 需求可追踪性
A．在所涉及的需求中，多数的需求是固定不变的，下面是有关的每个CSCI的需求到其所涉及的系统需求的可追踪性： 保密性需求：由于人对信息的处理的权限是不想同的，为了更好的管理和保护数据，就得要求不同的人对数据有不同的控制权利，所以此系统需要提供保密性需求来防止意外的事情发生。 计算机软件需求：软件的运行需要计算机操作系统作为依托，同时也要求计算机具有数据的存储能力，因此，要明确此软件要运行的计算机平台，也就需要分析计算机软件对此软件的影响。 故障处理：任何的软件都不可避免会出现错误，故障处理要求我们时刻追踪其运行是否正常。 有关后勤需求：软件完成了以后，还需要有个交付过程，也就需要有后勤需求来完成此过程。
B．下面是有关的CSCI的每个系统到涉及它的CSCI需求的可追踪性：
保密性需求：由于部门或是职称的改变，需要对相关人员的权限进行开放或保密，所以在保密性需求方面要求权限不是依赖部门或职称来决定其权利，而是封装在一个独立的地方，其对外的权限由最高管理员来控制，从而适应未来的可能的保密性需求的改变。 计算机软件需求：由于科技是向前发展的，我们要使软件要跟上硬件的发展，要应对操作系统的影响，也要尽量消除不同数据库管理系统对系软件的影响，未来处理器和存储器容量也可能会有不同程度的改变，因而，我们要尽量减少由于这些硬件的改变对软件的影响。 故障处理：即使有了对未来需求的改变有了一定的适应能力，但不可预知的事情也许会不断的出现，所以，我们不仅要对此系统进行日常维护，还要实时预测将可能会发生的新的故障及提前制定解决方法。 根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向追踪的能力。软件可追踪性依赖于软件开发各个阶段文档和程序的完整性、一致性和可理解性。降低系统的复杂性会提高软件的可追踪性。软件
在测试或维护过程中或程序在执行期间出现问题时，应记录程序事件或有关模块中的全部或部分指令现场，以便分析、追踪产生问题的因果关系。
6.尚未解决的问题
由于我们作为学生实践性开发小组，有很多的想法并不成熟，上述考务安排里的缓考申请和缓考审批功能模块暂时未想到比较合适的方法解决。
7. 注解
考试班级：班级又分为行政班级和教学班级。行政班级指招生时注册的班级，每个行政班级有编号、名称和学生人数。每个行政班同一时间只能考一门课程。教学班概念的产生是因为要考虑某些课程需要合班上课，比如公共政治课可以几个行政班级合在一起授课；
考试场地：每个场地都有编号、名称和容量。每个场地都有场地类型。每个场地都隶属于某个教学区域。每个场地在同一时间内只能考一门课程，并且场地容量应该大于考试人数。
考试课程：每个课程都有自己的编号、名称、开课部门、课程属性（公共课、专业课）、考试方式、考试周。每门课都有考试时间，90分钟或120分钟，90分钟的占用1个时间段，120分钟的占用2个时间段。每门课程可以有拆班上，也可以有多个班级合班上、合班班级往往是同专业或同部门的，但有时也有可能是跨专业跨部门的。
考试时段：在考务问题中涉及到关于时间的概念有学年、学期、周、天、时间段。每周的周一至周五安考务，每天有4个时间段（上午2个、下午2个），每个时间段占2个课时。（大学一般情况下考试是以2节课或2个小时为单位）
缓考：学生因病、家中发生紧急或意外严重事件、需要参加研究生考试等，不能坚持参加正常考试，可以书面形式提出暂缓参加考试另行氮素考试的申请。