软件需求分析案例

1、高校课程调度系统软件需求规格说明书a. 引言a. 1 目的高校教务管理工作是高等教育中的一个极为重要的环节, 是整个院校管理的核心和基础。面对种类繁多的数据和报表，面对手工处理方式已经很难跟上现代化管理的步伐。随着计算机及通讯技术的飞速发展，高等教育对教务管理工作提出了更高的要求。尽快改变传统的管理模式，运用现代化手段进行科学管理，已经成为整个教育系统亟待解决的课题之一。根据全国高校教学管理软件市场的需求，开发完成教学管理系统尤其是课程调度管理系统迫在眉睫，为计算机管理课程调度工作提供全面的解决方案。a. 2 预期的读者和阅读建议本需求分析说明书适用于该项目客户、业务或需求分析人员，用户文档编

2、写者，项目管理人员，项目产品开发人员，产品测试人员，技术支持人员。a. 3 产品的范围高校课程调度系统，是一个集先进的关系和文档数据库技术、多媒体技术于一身的课程调度管理系统的解决方案。本系统结构清晰、自动化程度高、运行速度快、用户界面友好、课程调度工作味道浓厚、使用灵活方便，可大大提高高校教务管理部门的工作效率，规范各类课程调度管理工作的业务流程。本系统适合各类高等院校的各级教学、教辅管理部门使用（包括：教育处、教研科、教务科、基础课程科等），也适用于各类中专及职业技术学校。a. 4 参考文献、湖南省教委关于普通高等学校教学管理制度和学生学籍管理有关问题的暂行规定、计算机系统导论、数据库原理

3、与方法、SoftWare Requirement b.综合描述b. 1产品的前景各级教学管理部门作为各个高等学府的一个重要职能部门，管理、制定、执行与学校头等大事教学工作有关的各项工作及政策。 其中，教学计划的实施是一个重要的环节。 每学期管理人员 都要制定、整理教学计划，根据教学计划下达教学任务书，然后根据教学任务书编排课程表。 在这 些课程调度工作中，既有大量繁琐的数据整理工作，也有严谨思维的脑力劳动。止匕外， 还有种类繁 多的数据和报表。为了提高教学管理部门的工作效率，其管理工作的计算机化已刻不容缓。通过大量的调查研究发现，目前，教学管理部门的管理模式存在以下主要问题：业务流程不规范数据

4、资料分散、重复、易遗漏数据信息不全面数据查询困难统计、排课工作耗时、费力、不准确等针对目前存在的各种问题，使我们意识到，必需通过计算机管理辅助教学管理部门日常工作， 优化管理模式，才能达到业务流程规范化、业务数值化、资料数据库化以及决策模拟化的管理水准。 为此，研制和开发高校课程调度系统已刻不容缓，具有广泛的使用和推广前景。b. 2产品的功能功能表述图:课表生成高校课程调度系统b. 4运行环境硬件平台：Pentium以上PQ内存16M及以上；VGAJt以上显小器；Microsoft 鼠标或其它兼容鼠标；Windows支持的各种打印机。操作系统：Windows Win98/XP/2000数据库系

5、统：SQL Server 等常用数据库b. 5 设计和实现上的限制所使用的设计符号表示必须符合高等学校教学管理的规范。b.6假设和依赖本软件在开发的过程中，分为技术实现与软件工程两大部分，两部分都有侧重点，若技术支持出现故障或疑难问题无法解决、程序开发出现偏差，会延误工程进度，影响工程的按期完工。若软件工程陈述出现问题，部分描述含混不清，则会影响系统的完整性与可继承性。在管理方面，如管理者没有预见性，对出向的问题无法采用可行的解决手段，都会影响开发模块之间的互动，从而影响工程的顺利开展，导致工程无法按期完工。c. 外部接口需求c. 1 用户界面根据高校课程调度系统的特点，用户界面采用桌面应用程

6、序方式实现。c.2硬件接口硬件环境是高校课程调度系统运行的物质基础，它必须有较高的性能，必须是稳定可靠的，同时还应该是可以扩充的。c.3软件接口计算机信息系统之间的信息交换，除了有硬件要求之外，还必须遵守共同的软件接口标准。高校课程调度系统必须能够提供数据转换接口。高校课程调度系统的软件接口由 WINDOWS作系统(Windows98/Windwos 2000/Windows XP)、 SQL Server 组成。c.4通信接口本产品的没有特殊的通讯接口，通讯接口由所使用的PC机决定d. 系统特性d. 1 排课管理1说明和优先级排课的优先级为高。要求将学校的课表按教学任务无冲突的排好，并尽量满

7、足课元组提出的特殊请求（如：教室请求、排课时间请求等）。但是，不保证是最优方案。2激励/响应序列读取教学计划生成教学任务，进行排课预处理。输入或修改教学任务，进行排课预处理。输入任课教师和上课班级的特殊时间请求，分配上课时间。输入开设课程的特殊教室请求，分配上课教室。3功能需求管理排课时间片：管理影响排课的各种时间片，包括本学期排课周数、每周排课天数、每天排课节数、排课开始节次、班级可用时间、任课教师可用时间、排课时间模式等排课预处理：读取教学任务及排课时间片，进行数据处理，优先为在教学任务中提出特殊请求的课元组分配时间教室分配：为排课预处理后的课元组分配教室，优先为在教学任务中提出特殊请求的

8、课元组分配教室修订、检验课表：对在排课处理里中发生的冲突（时间冲突、教室冲突）进行修订，校正至没有冲突及空缺。生成课表d.2按分类打印课表管理1说明和优先级按分类打印课表的优先级为中。要求将排好的课表按各种用户的要求分类打印，满足不同的用途。2激励/响应序列输入院系、专业、班级，打印总课表。输入任课教师姓名，打印教师课表。输入教室编号，打印教室课表。3功能需求打印总课表：打印学校的总课表，内容包括所在院系、所在专业的所有班级的上课课程、任课教师、上课时间、上课的教室。打印教师课表：打印每位任课教师的个人课表，内容包括教师所上的课程、上课班级、上课时间和上课的教室。打印教室课表：打印每间教室的教

9、室课表，内容包括教室使用的时间、所上的课程和上课班级。d.3课表查询1说明和优先级课表查查询的优先级为低。只要能够在系统中查询、能拷贝课表数据、能在网上查询。2功能需求课表查询：使用本系统按不同的条件查询课表（如：按班级、课程、教师、教室等） 课表数据拷贝：将生成的课表文件拷贝到其他安装该系统的计算机上进行查询生成课表网页：在生成课表的同时生成按教师分类的课表网页，供用户及其他人员（院系 领导、学生）查询课表。e.其它非功能需求e.1性能需求高校课程调度系统性能需求见下表:精度在进行向数据库文件提取数据时，要求数据记录定位准确， 在往数据库文件数组中添加数时，要求输入数准确。时间特性a.响应时

10、间应在人的感觉和视完事件范围内；b.更新处理时间，随着系统的版本升级，课程调度系统将相应的 进行更新。灵活性当需求发生某些变化时，课程调度系统软件操作方式、数据结构、 运行环境基本不会发生变化，变化只是将对应的数据库文件内的记 录改变，或将筛选条件改变即可。数据管理能力本系统数据库的管理能力取决于SQL server对数据的管理能力，Microsoft SQLServer丘-个较成熟的大型数据库系统，能满足本 系统的要求。故障处理故障几率小，排除简单（只需拷贝动态库文件，不需重新安装）。e.2安全性需求保证应用系统信息安全。防止内部机密或敏感信息的泄漏以及外部不良信息的侵入。提供必要的冗余和备

11、份措施。当系统发生故障时能够立即恢复，保证系统可靠运行；系统 备份、数据库备份：定时后备，快速恢复。e.3软件质量属性可靠性：由于软件失效引起排课出错的概率应不超过 5%。健壮性：所有的排课参数都要指定一个缺省值，当输入数据丢失或无效时，就使用缺省值 数据。可用性：在文件菜单中的所有功能都必须定义快捷键，该快捷键是由Alt键和其它键组合实现的。e.4业务规则只有在输入了教学计划之后，才能在新建教学任务时读取教学计划。只有在输入了教学任务之后，才能进行排课。只有在设置了时间片之后，才能进行排课。排课时，要同时安排任课教师和上课教室。使一周的课程尽量均匀分布到每天，不能有班级出现有一天或半天完全没

12、有课。e.5用户文档编号：1高校课程调度系统软件需求规格说明书编号：2系统分析模型编号：3数据字典编号：4风险管理计划编号：5概念测试用例编号：6变更控制的过程顶层图：0层图:教务管理口贝”教室管理员教学楼信息教室名称系统分析模型课务管理员完全课表教学任务课务管理员任课教师教室类型容纳人数教学任务信完全课分一基础” 1数据 下达教学任务可用时间任遽教师教学任务时间片约束时理 3课管 排间排课时间信息个人课表完全课表上课节次 日上课节都教学任务时间约束生成课表系统数据字典院 系 =院系编号 院系名院系编号=*2位正整数，并能唯一标识每个院系或单位*院系名 =*小于13位字符（包括中文、字母、数字

13、）*教 师 =教师编号 教师姓名 出生年 性别教师编号=*6位数字，头2位数字为该教师所在系号,并能唯一标识每个教师；若用户学校以教研室为单位管理, 头 4位应是教研室编号*教师姓名=*小于9位字符（包括中文、字母、数字）*出生年 =*4位数字*性别=“男”| "女”课程=课程编号 课程名称课程编号=*小于11位字符，头2位是课程开课系的编号，并能唯一标识每门课程*课程名称=*小于21位字符（包括中文、字母、数字）*专 业 =专业编号 专业名称专业编号=*小于5位字符，头2位为该专业所属的系号，并能唯一标识每个专业*专业名称=*小于13位字符（包括中文、字母、数字）*教学楼 =教学楼

14、编号 教学楼名称教学楼编号 =*4位数字，第1位是校区码，并能唯一标识每个教学楼*教学楼名称 =*小于17位字符（包括中文、字母、数字）*教室=教学楼编号 教室名称 容纳人数 教室类型教室名称=*小于7位个字符，（包括中文、字母、数字）*容纳人数=*3位正整数*教室类型“ -1 ” |“ 0” | “ 1” |“ 2” | “ 3” |“ 4” | “ 5” | “ 6” |“ 7” | “ 8” |“ 9” * -1 表示不分教室；0 表示一般的上课教室；1和 2均表示制图室；3 9为自定义小于5位字符*学生班级二班级编号 年级 班名 人数 固定教学楼 固定教室编号二*4 位字符, 是该班所

15、在专业的编号年级二“ 1” | “ 2” | “ 3” | “ 4” 班名=标识符标识符序号数 固定教学楼 固定教室 教学计划序号* 小于7位字符*2 位字符，允许为空*3 位数字 *小于13位字符（包括中文、字母、数字），允许为空*小于7位字符（包括中文、字母、数字），允许为空*=编号+年级+学期+课程编号+课程名称+学时+学分+周学时+是否必修+是否考试+起周次+末周次*心了心了心了周是期 时 分 学时“ 1” | “ 2” | “ 3” *3位正整数*2 位正整数, 1位小数*2 位正整数, 1位小数 “ 0” |“选修为 2,1 ” | “ 2” 是否考试必修为 1, 限选为 0* 1

16、” 周次周次教学任务班数*2 位正整数，允许为空允许为空*2 位正整数，允许为空允许为空课程编号课程名称学时周学时是否必修是否考试主讲助课上课班级合班数人数起周次末周次连上节数时间要求排课模式教室类型教学楼教室*2 位正整数*考查为 1, 考试为 0*0” | “连上节数=“1”|“2”|“3”|“4”|“5”|“6”|“7”|"8”* 0 4 表示该课每次上课的节数, 0 也表示连上2 节；5 表示上午2节，下午4节；6 表示排2个下午；7 表示1天；8 表示1个上午2节，2个下午* 连上节数是5-8 时周学时对排课不起作用*排课模式=“1”|“2”|“3”|“4”|“5”|“6”

17、|"7”* 0 表示上、下午排课；1表示单周上午、双周下午排课；2表示双周上午、单周下午排课；3表示上、下午排课，并均匀分布课时；4表示下午、晚上排课，并均匀分布课时；5表示下午排课；6表示晚上排课；7表示上、下午、晚上均排课*联合课码=*小于6位字符，在一种联合课中，主行课的联合课码是正整数，并行课的联合课码是该数的负数*讲课课程=课程编号 课程名称 容纳数 固定教学楼 固定教室 教室类型容纳数 =*2位正整数，表示该课每个时间片可容纳课元组的数目*风险管理计划有关概念：风险(Risk)是在规定的费用、进度和技术的约束条件下不能实现整个项目目标的可能性的一种度量。风险包括两个方面：

18、(1) 不能实现具体目标的概率；(2) 因不能实现该目标所导致的后果/ 影响。风险事件(Risk event )即可能导致某个项目或系统发生问题，需要作为采办项目要素加以评估以确定风险水平的事件。风险事件的定义应使人们易于理解其潜在影响和致因。可能会有一系列潜在的风险事件，这需要有关专家进行筛选、考察和评估。风险的概率和后果之间的关系比较复杂。为避免评估结论含糊不清，与某个事件有关的风险应以概率和后果这两个参量表征。作为评估的一部分需要含有支持数据和评估理由的背景材料。风险管理(Risk management)是指控制风险的行动或实践。它包括进行风险规划、评估风 险域，拟定风险处理备选方案，监

19、控风险变化情况和记录所有风险管理情况。风险规划(Risk Planning )是指研究一套有组织的、全面的和相互作用的策略和方法并将其形成文件的过程，这套策略和方法用于辨识和跟踪风险域；拟定风险缓解方案；进行持续的风险评估，从而确定风险变化情况并配置充足的资源。风险评估(Risk assessment)指对项目各个方面的风险和关键性技术过程的风险进行辨识和分析的过程，以增加满足性能、进度和费用目标的可能性。风险辨识指对项目各个方面和各个关键性技术过程进行调查研究，从而辩识并记录有关风险的过程。风险分析是指调查研究已辨识出的风险域或过程以进一步细化风险描述，隔离风险的原因和确定风险影响的过程。它

20、包括风险等级评定和优先次序排序，风险事件的等级和排序是根据风险发生的概率、后果的严酷度以及与其他风险域或技术过程的相互关系来确定的。风险处理(Risk handling )是指对风险进行辩识、评价、选定并实施应对方案的过程，目的是在给定项目约束条件和目标下使风险保持在可接受水平上。它包括详细说明应当做些什么，应于何时完成，由谁负责，以及有关的费用和进度等具体问题。要从这些应对方案中选取最恰当的策略。风险处理是一个包罗万象的术语，而风险缓解和风险控制则是它的子集。风险监控(Risk monitoring )是指在整个采办过程中，按既定的衡量标准对风险处理活动的效果进行系统跟踪和评价的过程，必要时

21、还要进一步研究风险处理备选方案。它还反馈信息给风险规划、风险评估和风险处理等其它的风险管理活动。风险文档(Risk documentation )是指记录、维护和报告风险的评估、处理分析方案以及监 控结果的文件，包括所有的计划、给项目经理和决策者的报告以及项目管理办公室的内部报表。风险管理的组织结构执行风险管理功能的主要是项目开发人员。开发人员由项目经理负责，他是风险管理的最终 负责人。风险管理既是整个项目管理的一个有机组成部分， 也是项目管理的一种有力手段和方法。 它的任务是要弄清费用风险、进度风险和性能风险的相互关系。其目的是使参与项目工作的一切人 员都能建立风险意识，在设计、研制和部署系

22、统时考虑风险问题。本系统风险管理的组织形式，为在集中式风险管理，项目经理要组建一个专门的风险管理组， 来负责风险管理的所有工作，如编写计划、进行评估、评价风险处理备选方案和监控风险管理工作 的进展情况等。项目经理是进行规划、分配资源和执行风险管理的最终负责人，因此要求项目经理检查和参与风险管理过程。项目经理必须最佳地使用可用资源，即人力、组织和资金。风险管理是一项团队功能。这是因为风险的广泛性和风险处理计划要影响到项目的其他计划和 行动。总的来说，风险评估、风险处理和风险监控对所有的项目活动和组织都有影响。任何企 图实施积极主动向前看的风险管理计划，而没有项目经理参与，都将导致混乱、迷失方向和

23、资 源浪费。人员工作职责项目经理风险管理的计划、组织、领导和控制；报告项目风险和建议缓解措施。风险管理协调员制定和维护风险管理计划；提供风险管理培训；定义项目使用的风险报告的范围；建立和维护风险管理信息系统；准备风险管理报告；向项目经理提出有关使用独立风险评估员的建议。独立风险评估员对项目经理指定的关键风险域进行独立风险评估;报告这些评估的结果给项目经理；和风险管理协调员共同工作。风险管理工作步骤如下: 在项目计划和项目进度（如果适用）中，标识出风险。 根据项目定义的软件过程，建立补救措施计划文档。此计划将贯穿整个项目软件生命周期。补救措施计划应包括以下方面的工作： 可选项识别、可选项影响度评

24、估、可选项的技术可行 性，和可选项使用时机的决定标准。 为每一风险定义出可供选择的补救措施，如果有可能，也要列出这些补救措施的选择标准。 软件计划的最初版本和主要的修订版，要经过同行评审后才可发行。 管理并控制软件计划。 在有选择的项目里程碑处、在指定的风险检查阶段点、和在对软件项目有影响的计划重大变 更过程中，都应对风险进行跟踪、再评估，和重新计划。 检讨并修正风险级别。 利用风险监控所获得的信息，进一步精化风险评估和软件计划。风险检查表：提示：请使用者根据机构和项目的实际情况完善本检查表商业风险风险类型检查项政治 法律 市场政府或者其它机构对本项目的开发有限制吗？有不可预测的市场动荡吗？有

25、不利于我方的官司要打吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？竞争对手有不正当的竞争行为吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？是否在开发很少有人真正需要却自以为很好的产品？是否在开发可能亏本的产品？客户客户的需求是否含糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。子承包商 供应商与子承包商、供应商签订的合同公正吗？双方互利吗？子承包商、供

26、应商的信誉好吗？子承包商、供应商有可能倒闭吗？子承包商、供应商能及时交付质量合格的产品（或部件）吗？子承包商、供应商有能力做好售后服务吗？管理风险风险类型检查项项目计划对项目的规模、难度估计是否比较正确？人力资源（开发人员、管理人员）够用吗？合格吗？项目所需的软件、硬件能按时到位吗？项目的经费够用吗？进度安排是否过于紧张？有合理的缓冲时间吗？进度表中是否遗忘了一些重要的（必要的）任务？进度安排是否考虑了关键路径？是否可能出现某一项工作延误导致其它一连串的工作也被延误？任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？项

27、目团队项目成员团结吗？是否存在矛盾？是否绝大部分的项目成员对工作认真负责？绝大部分的项目成员有工作热情吗？团队之中有“害群之马”吗？技术开发队伍中有临时工吗？本项目开发过程中是否会有核心人员辞职、调动？是否能保证“人员流动基本不会影响工作的连续性”？项目经理是否忙于行政事务而无暇顾及项目的开发工作？上级领导 行政部门 合作部门本项目是否得到上级领导的重视？上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？行政部门的办事效率是否比较底，以至于拖项目的后腿？行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？机构是否能全面、公正地考

28、核员工的工作业绩？机构是否有较好的奖励和惩罚措施？本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？技术风险风险类型检查项需求开发 需求管理需求开发人员懂得如何获取用户需求吗？效率高吗？需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？需求开发人员能否与客户对有争议的需求达成共识？需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？综合技术开发能力包括设计编程、测试等开发人员是否有开发相似产品的经验？待开发的产品是否要与未曾证实的软硬件相连接？对开发人员而言，本项目的技术难度高吗？开发人员是否已经掌握了本项目

29、的关键技术？如果某项技术尚未实践过，开发人员能否在预定时间内掌握？开发小组是否采用比较有效的分析、设计、编程、测试工具？分析与设计工作是否过于简单、草率，从而让程序员边做边改？开发小组采用统一的编程规范吗？开发人员对测试工作重视吗？能保证测试的客观性吗？项目有独立的测试人员吗？懂得如何进行高效率地测试吗？是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？开发人员重视质量吗？是否会在进度延误时降低质量要求？已识别的风险:风险管理报告风险编号1风险识别人项目经理风险名称风险识别日期风险描述开发人员不够，造成开发时间增加风险可

30、能性0.5风险影响8风险危害值4.0风险处理人风险减缓措施1 .聘请有开发类似系统的开发人员参与系统开发2 .聘请资深程序员作为技术指导3 .规划开发进程，设定标志性任务，一旦发现超过规定时间未完成任务，考虑增加 人手跟踪记录(1)记录何人在何时做了什么事情(2)记录当前风险状态(正在处理，已经解决，不作处理)风险编号2风险识别人项目经理风险名称风险识别日期风险描述用户需求不断扩大，造成开发难以进行风险可能性0.8风险影响8风险危害值6.4风险处理人风险减缓措施1 .在早期多收集用户需求2 .与用户代表一起召开会议以确定开发需求3 .开发一个包括核心功能的用户界面原型。让用户代表来评审此原型跟

31、踪记录(1)记录何人在何时做了什么事情(2)记录当前风险状态(正在处理，已经解决，不作处理)风险编号3风险识别人项目经理风险名称风险识别日期风险描述程序员语言开发环境不同，协调工作困难风险可能性0.8风险影响5风险危害值4.0风险处理人风险减缓措施1 .尽量要求程序员使用同一种语言作为开发语言2 .建议使用Borland C+作为开发环境跟踪记录(1)记录何人在何时做了什么事情(2)记录当前风险状态(正在处理，已经解决，不作处理)风险编号4风险识别人项目经理风险名称风险识别日期风险描述用户提出的需求表达不清楚，造成系统无法满足用户业务需求风险可能性0.2风险影响9风险危害值1.8风险处理人风险

32、减缓措施1 .开发人员参与用户日常办公，熟悉业务过程2 .定期与用户召开会议，确定用户的真正需求跟踪记录(1)记录何人在何时做了什么事情(2)记录当前风险状态(正在处理，已经解决，不作处理)概念测试用例用例11 .业务需求“高校课程调度系统”根据教学计划只拟定现有班级的教学任务。2 .使用实例课务管理员输入教学任务相应班级的编号， 系统通过与基础数据库进行比对，接受或拒绝该班级的 教学任务。3 .功能需求如果请求排课资源，只有输入基础数据库中已存在的班级的教学任务，系统才接受该教学任务。4 .对话图用例41 .业务需求“高校课程调度系统”根据教学计划中的课程为班级制定教学任务。2 .使用实例接

33、受或拒绝该门课系统才接受该教学任课务管理员输入教学任务的课程编号和名称，系统通过与基础数据库进行比对, 程的教学任务。存在的课程3 .功能需求如果请求排课资源下达教学任务，只有输入基础数据库中已存在的课程编号 务。否则，生成新的课程信息，重新制定教学任务。4.对话图接受该课程的任务1 .业务需求“高校课程调度系统”排课时为课元组分配固定教室，教室不能冲突。2 .使用实例排课预处理后，进行教室分配。系统优先分配相应类型和容纳人数的教室给提出了教室请求的课元组。请求发生冲突时，系统根据请求班级的年级分配或拒绝分配教室。3 .功能需求如果请求教室资源，当请求的教室空闲，系统将教室分配给请求的班级所开

34、课程；当教室已被占用, 该班级将与已占用教室的班级比较所在年级，如果所在年级高则将此教室重新分配给它。4 .对话图1 .业务需求“高校课程调度系统”排课时为课元组分配上课时间，时间不能冲突。2 .使用实例预处理排课数据，进行时间分配。系统根据课元组提出的请求优先分配或拒绝分配上课时间。3 .功能需求当时间如果请求排课时间片，只有请求的时间片有空闲，系统才将时间分配给提出请求的课元组, 片完全被占用，则手工修改排课时间。4 .对话图取消读取课元组请求的5.测试用M路径课时间,分配排课胖间片空请求排课时间取消读取课元组请求的 1排课时间，吁同樨镌排课时间被占用变更控制的过程角色和责任建立变更控制委员会，组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪 些，放弃哪些，并设置实现的优先顺序，制定目标版本。角色人员责任变更控制委员会主席开发小组负责人在CCBS见不的情况卜口 以独自作出决定CCB全体开发小组人员决定米纳或拒绝针对本系统所 建议的变更请求评估者开发小组负责人分析变更对本项目带来的影响修改者全体开发小组人员对已认可的变更请求按时更新建议者全体开发小组人员 用户代表提交变更请求验证者开发小组负责人 用户代表确认更改是否止确执行变更注意事项1）没有明确的授