软件需求分析案例资料

《软件需求分析案例资料》由会员分享，可在线阅读，更多相关《软件需求分析案例资料（33页珍藏版）》请在装配图网上搜索。

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

2、目管理人员，项目产品开发人员，产品测试人员,技术支持人员。a. 3产品的范畴高校课程调度系统,是一种集先进的关系和文档数据库技术、多媒体技术于一身的课程调度管理系统的解决方案。 本系统构造清晰、自动化限度高、运营速度快、顾客界面和谐、课程调度工作味道浓厚、使用灵活以便,可大大提高高校教务管理部门的工作效率，规范各类课程调度管理工作的业务流程。本系统适合各类高等院校的各级教学、教辅管理部门使用（涉及：教育处、教研科、教务科、基本课程科等),也合用于各类中专及职业技术学校。a. 4参照文献一般高等学校本科专业设立规定、教育部有关高等学校学籍方面某些名称的提法、湖南省教委有关一般高等学校教学管理制度

3、和学生学籍管理有关问题的暂行规定、教学一览、课程编号一览、软件工程、 计算机系统导论、 数据库原理与措施、 Sftre eireent .综合描述b. 产品的前景各级教学管理部门作为各个高等学府的一种重要职能部门，管理、制定、执行与学校头等大事教学工作有关的各项工作及政策。其中,教学筹划的实行是一种重要的环节。每学期管理人员都要制定、整顿教学筹划,根据教学筹划下达教学任务书,然后根据教学任务书编排课程表。在这些课程调度工作中，既有大量繁琐的数据整顿工作，也有严谨思维的脑力劳动。此外，尚有种类繁多的数据和报表。为了提高教学管理部门的工作效率,其管理工作的计算机化已刻不容缓。通过大量的调查研究发现

4、,目前,教学管理部门的管理模式存在如下重要问题: 业务流程不规范数据资料分散、反复、易漏掉 数据信息不全面数据查询困难 记录、排课工作耗时、费力、不精确等 针对目前存在的多种问题,使我们意识到,必需通过计算机管理辅助教学管理部门平常工作,优化管理模式,才干达到业务流程规范化、业务数值化、资料数据库化以及决策模拟化的管理水准。为此,研制和开发高校课程调度系统已刻不容缓,具有广泛的使用和推广前景。b. 2产品的功能功能表述图：高校课程调度系统教务管理教学管理教学筹划管理教学任务管理基本数据库院系数据教师数据课程数据专业数据学生班级数据教室数据课程调度管理排课管理时间片管理排课预解决教室分派查询修订

5、课表检查课表课表生成课表数据拷贝课表打印生成课表网页 b. 顾客类和特性“高校课程调度系统”的顾客类课务管理员课务管理员管理着全校的教学任务以及排课工作。她们是排课管理的唯一使用者,将解决来自教务管理员的时间约束并提供完全课表；向教室管理员祈求排课可用教室并提供教室的课表清单;获取任课教师的任课课程和可用时间并提供教师的个人课表。教务管理员教务管理员是教务科科长甚至教育到处长。她们使用系统是为了获得符合学校教学管理、安排的完全课表,进行宏观管理、保证教学工作正常开展。教务管理员提供学校统一的时间规定。教务管理员需要在生成的课表中得到一系列课表，涉及总课表,班级、教师、教室课表，并进行修订。教室

6、管理员教室管理员将使用系统来查询所管辖教室的课表。教室管理员提供上课可用的教室类型、教室数量、以及教室的名称和容纳人数。教室管理员需要在生成的课表中查找每间教室的使用时间以及班级。任课教师任课教师将使用系统来查询个人的上课课表。任课教师提供自己本学期可上的课程和可用的排学时间做为教学任务的一部分。任课教师需要在生成的课表中查找自己上课的课程、班级、时间以及教室。b. 4运营环境硬件平台：entim以上P;内存16M及以上；G及以上显示屏;cosoft鼠标或其他兼容鼠标；indows支持的多种打印机。操作系统: WindowsWin98/XP数据库系统:SQL Seve等常用数据库b. 5设计和

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

8、质基本,它必须有较高的性能，必须是稳定可靠的，同步还应当是可以扩大的。.3软件接口计算机信息系统之间的信息互换，除了有硬件规定之外,还必须遵守共同的软件接口原则。高校课程调度系统必须可以提供数据转换接口。高校课程调度系统的软件接口由WINDOWS操作系统（idws 8/Widwo /Winows XP)、QLServe构成。.4通信接口本产品的没有特殊的通讯接口，通讯接口由所使用的P机决定。.系统特性d. 1排课管理1阐明和优先级排课的优先级为高。规定将学校的课表按教学任务无冲突的排好,并尽量满足课元组提出的特殊祈求（如：教室祈求、排学时间祈求等）。但是,不保证是最优方案。2鼓励/响应序列读取

9、教学筹划生成教学任务,进行排课预解决。输入或修改教学任务，进行排课预解决。输入任课教师和上课班级的特殊时间祈求,分派上学时间。输入开设课程的特殊教室祈求,分派上课教室。功能需求l 管理排学时间片:管理影响排课的多种时间片，涉及本学期排课周数、每周排课天数、每天排课节数、排课开始节次、班级可用时间、任课教师可用时间、排学时间模式等l 排课预解决：读取教学任务及排学时间片,进行数据解决,优先为在教学任务中提出特殊祈求的课元组分派时间l 教室分派:为排课预解决后的课元组分派教室,优先为在教学任务中提出特殊祈求的课元组分派教室l 修订、检查课表:对在排课解决里中发生的冲突（时间冲突、教室冲突)进行修订

10、，校正至没有冲突及空缺。l 生成课表d2按分类打印课表管理1.阐明和优先级按分类打印课表的优先级为中。规定将排好的课表按多种顾客的规定分类打印,满足不同的用途。2.鼓励/响应序列输入院系、专业、班级,打印总课表。输入任课教师姓名，打印教师课表。输入教室编号,打印教室课表。3功能需求l 打印总课表：打印学校的总课表,内容涉及所在院系、所在专业的所有班级的上课课程、任课教师、上学时间、上课的教室。l 打印教师课表：打印每位任课教师的个人课表，内容涉及教师所上的课程、上课班级、上学时间和上课的教室。l 打印教室课表：打印每间教室的教室课表，内容涉及教室使用的时间、所上的课程和上课班级。d.3课表查询

11、1.阐明和优先级课表查查询的优先级为低。只要可以在系统中查询、能拷贝课表数据、能在网上查询。2.功能需求l 课表查询:使用本系统按不同的条件查询课表（如：按班级、课程、教师、教室等)l 课表数据拷贝:将生成的课表文献拷贝到其她安装该系统的计算机上进行查询l 生成课表网页：在生成课表的同步生成按教师分类的课表网页,供顾客及其她人员（院系领导、学生）查询课表。e其他非功能需求e.1性能需求高校课程调度系统性能需求见下表:精度在进行向数据库文献提取数据时，规定数据记录定位精确，在往数据库文献数组中添加数时,规定输入数精确。时间特性a. 响应时间应在人的感觉和视觉事件范畴内;b. 更新解决时间，随着系

12、统的版本升级，课程调度系统将相应的进行更新。灵活性当需求发生某些变化时，课程调度系统软件操作方式、数据构造、运营环境基本不会发生变化，变化只是将相应的数据库文献内的记录变化，或将筛选条件变化即可。数据管理能力本系统数据库的管理能力取决于L erver对数据的管理能力，Microof QSerer是一种较成熟的大型数据库系统，能满足本系统的规定。故障解决故障几率小,排除简朴（只需拷贝动态库文献，不需重新安装)。.2安全性需求l 保证应用系统信息安全。l 避免内部机密或敏感信息的泄漏以及外部不良信息的侵入。l 提供必要的冗余和备份措施。当系统发生故障时可以立即恢复，保证系统可靠运营；系统备份、数据

13、库备份：定期后备，迅速恢复。e.软件质量属性l 可靠性：由于软件失效引起排课出错的概率应不超过 。l 强健性：所有的排课参数都要指定一种缺省值,当输入数据丢失或无效时，就使用缺省值数据。l 可用性：在文献菜单中的所有功能都必须定义快捷键，该快捷键是由Alt键和其他键组合实现的。e.4业务规则l 只有在输入了教学筹划之后,才干在新建教学任务时读取教学筹划。l 只有在输入了教学任务之后,才干进行排课。l 只有在设立了时间片之后，才干进行排课。l 排学时,要同步安排任课教师和上课教室。l 使一周的课程尽量均匀分布到每天，不能有班级浮既有一天或半天完全没有课。e.5顾客文档编号:1高校课程调度系统软件

14、需求规格阐明书编号：2系统分析模型编号:3数据字典编号：风险管理筹划编号：5概念测试用例编号：6变更控制的过程系统分析模型顶层图：高校课程调度系统教室管理员教室信息教室课表教务管理员时间片约束完全课表任课教师任课课程可用时间个人课表课务管理员教学任务完全课表0层图：任课教师任课课程可用时间时间片约束3排学时间管理教务管理员上课周、天数日上课节数上课节次班级时间排学时间信息教室信息2提供教室信息教室管理员教室名称容纳人数教室类型教学楼信息教室数据4排课解决5生成课表数据合成时间约束教室信息教学任务完全课表完全课表个人课表教室课表教学任务1下达教学任务课务管理员教学筹划基本数据开课班级教学任务信息

15、课程信息系统数据字典院 系= 院系编号 院系名院系编号*2位正整数，并能唯一标记每个院系或单位*院 系名= 不不小于13位字符(涉及中文、字母、数字)*教 师 教师编号教师姓名出生年 性别教师编号 *6位数字,头2位数字为该教师所在系号，并能唯一标记每个教师；若顾客学校以教研室为单位管理,头位应是教研室编号教师姓名 *不不小于位字符(涉及中文、字母、数字)出 生 年 *位数字*性 别 “男“ “女”课 程 课程编号课程名称课程编号*不不小于1位字符，头位是课程开课系的编号, 并能唯一标记每门课程课程名称 *不不小于2位字符（涉及中文、字母、数字）*专 业 专业编号+ 专业名称专业编号 不不小于

16、5位字符， 头2位为该专业所属的系号, 并能唯一标记每个专业* 专业名称=*不不小于位字符（涉及中文、字母、数字)*教 学 楼= 教学楼编号+教学楼名称教学楼编号= 4位数字，第位是校区码,并能唯一标记每个教学楼*教学楼名称*不不小于17位字符(涉及中文、字母、数字)*教室= 教学楼编号 教室名称 容纳人数+ 教室类型教室名称*不不小于7位个字符,(涉及中文、字母、数字)容纳人数 *3位正整数*教室类型“-”|“0”|“”|“2”|“3”|“”“5”“6”|“7”|“8”|“” * -1表达不分教室；0表达一般的上课教室;1和均表达制图室；3为自定义不不小于5位字符学生班级=班级编号+ 年级+

17、 班名 人数 固定教学楼+ 固定教室编 号= 4位字符, 是该班所在专业的编号*年 级 “1”|“2”|“”|“4”班 名= 标记符序号 标记符 不不小于7位字符* 序 号= *2位字符，容许为空*人 数 *位数字*固定教学楼= 不不小于13位字符(涉及中文、字母、数字），容许为空*固定教室 *不不小于7位字符(涉及中文、字母、数字),容许为空*教学筹划 编号+年级+学期+ 课程编号+课程名称+ 学时学分+周学时+ 与否必修+与否考试 起周次+ 末周次学 期= “”|“”“3”学 时 *3位正整数*学 分=*2位正整数, 1位小数*周 学 时= 2位正整数， 位小数*与否必修 “0”“1”|“

18、2”* 选修为, 必修为,限选为0*与否考试=“0”|“1”*考察为1, 考试为0*起 周 次 *2位正整数,容许为空末 周 次= 2位正整数,容许为空*教学任务课程编号+ 课程名称 学时周学时+ 与否必修+ 与否考试+主讲 助课 上课班级 合班数 人数 起周次 末周次+ 连上节数时间规定+ 排课模式+教室类型 教学楼 教室合 班 数= *2位正整数*连上节数 “”“2”|“”|“4”|“5”|“6”“7”|“8”*04表达该课每次上课的节数, 0 也表达连上 2 节; 表达上午2节,下午节; 表达排2个下午; 7 表达1天； 表达个上午节，个下午* 连上节数是-8时周学时对排课不起作用*排课

19、模式“1”|“2”“3”“4”|“”|“6”“7”* 表达上、下午排课;表达单周上午、双周下午排课;2表达双周上午、单周下午排课;3表达上、下午排课,并均匀分布学时;4表达下午、晚上排课，并均匀分布学时；5表达下午排课；表达晚上排课；7表达上、下午、晚上均排课*联合课码=不不小于6位字符,在一种联合课中, 主行课的联合课码是正整数， 并行课的联合课码是该数的负数*授课课程 = 课程编号+课程名称+ 容纳数 固定教学楼+固定教室 教室类型容 纳 数 *2位正整数, 表达该课每个时间片可容纳课元组的数目风险管理筹划有关概念：风险（Rik）是在规定的费用、进度和技术的约束条件下不能实现整个项目目的的

20、也许性的一种度量。风险涉及两个方面:(）不能实现具体目的的概率；(）因不能实现该目的所导致的后果/影响。 风险事件(Rsevnt)即也许导致某个项目或系统发生问题,需要作为采办项目要素加以评估以拟定风险水平的事件。风险事件的定义应使人们易于理解其潜在影响和致因。也许会有一系列潜在的风险事件,这需要有关专家进行筛选、考察和评估。风险的概率和后果之间的关系比较复杂。为避免评估结论模糊不清，与某个事件有关的风险应以概率和后果这两个参量表征。作为评估的一部分需要具有支持数据和评估理由的背景材料。风险管理（ Riskmanagemen）是指控制风险的行动或实践。它涉及进行风险规划、评估风险域,拟定风险解

21、决备选方案，监控风险变化状况和记录所有风险管理状况。风险规划(RikPlnnig）是指研究一套有组织的、全面的和互相作用的方略和措施并将其形成文献的过程，这套方略和措施用于辨识和跟踪风险域;拟定风险缓和方案;进行持续的风险评估，从而拟定风险变化状况并配备充足的资源。风险评估（isk sssn)指对项目各个方面的风险和核心性技术过程的风险进行辨识和分析的过程,以增长满足性能、进度和费用目的的也许性。风险辨识指对项目各个方面和各个核心性技术过程进行调查研究,从而辩识并记录有关风险的过程。风险分析是指调查研究已辨识出的风险域或过程以进一步细化风险描述,隔离风险的因素和拟定风险影响的过程。它涉及风险级

22、别评估和优先顺序排序，风险事件的级别和排序是根据风险发生的概率、后果的严酷度以及与其她风险域或技术过程的互相关系来拟定的。风险解决（Rik hanling）是指对风险进行辩识、评价、选定并实行应对方案的过程,目的是在给定项目约束条件和目的下使风险保持在可接受水平上。它涉及具体阐明应当做些什么,应于何时完毕，由谁负责,以及有关的费用和进度等具体问题。要从这些应对方案中选用最恰当的方略。风险解决是一种包罗万象的术语,而风险缓和和风险控制则是它的子集。 风险监控（Risk moitoing）是指在整个采办过程中，按既定的衡量原则对风险解决活动的效果进行系统跟踪和评价的过程,必要时还要进一步研究风险解

23、决备选方案。它还反馈信息给风险规划、风险评估和风险解决等其他的风险管理活动。 风险文档(Risk ocumntao)是指记录、维护和报告风险的评估、解决分析方案以及监控成果的文献，涉及所有的筹划、给项目经理和决策者的报告以及项目管理办公室的内部报表。 风险管理的组织构造 执行风险管理功能的重要是项目开发人员。开发人员由项目经理负责，她是风险管理的最后负责人。 风险管理既是整个项目管理的一种有机构成部分,也是项目管理的一种有力手段和措施。它的任务是要弄清费用风险、进度风险和性能风险的互相关系。其目的是使参与项目工作的一切人员都能建立风险意识，在设计、研制和部署系统时考虑风险问题。本系统风险管理的

24、组织形式，为在集中式风险管理,项目经理要组建一种专门的风险管理组，来负责风险管理的所有工作,如编写筹划、进行评估、评价风险解决备选方案和监控风险管理工作的进展状况等。l 项目经理是进行规划、分派资源和执行风险管理的最后负责人，因此规定项目经理检查和参与风险管理过程。l 项目经理必须最佳地使用可用资源,即人力、组织和资金。l 风险管理是一项团队功能。这是由于风险的广泛性和风险解决筹划要影响到项目的其她筹划和行动。总的来说，风险评估、风险解决和风险监控对所有的项目活动和组织均有影响。任何企图实行积极积极向前看的风险管理筹划,而没有项目经理参与,都将导致混乱、迷失方向和资源挥霍。人 员 工作职责项目

25、经理 风险管理的筹划、组织、领导和控制; 报告项目风险和建议缓和措施。风险管理协调员制定和维护风险管理筹划； 提供风险管理培训; 定义项目使用的风险报告的范畴; 建立和维护风险管理信息系统; 准备风险管理报告； 向项目经理提出有关使用独立风险评估员的建议。 独立风险 评估员 对项目经理指定的核心风险域进行独立风险评估； 报告这些评估的成果给项目经理； 和风险管理协调员共同工作。 风险管理工作环节如下: 在项目筹划和项目进度（如果合用）中，标记出风险。 根据项目定义的软件过程,建立补救措施筹划文档。此筹划将贯穿整个项目软件生命周期。补救措施筹划应涉及如下方面的工作:可选项辨认、可选项影响度评估、

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

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

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

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

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

31、某项技术尚未实践过,开发人员能否在预定期间内掌握?开发小组与否采用比较有效的分析、设计、编程、测试工具?分析与设计工作与否过于简朴、草率，从而让程序员边做边改？开发小组采用统一的编程规范吗?开发人员对测试工作注重吗?能保证测试的客观性吗？项目有独立的测试人员吗？懂得如何进行高效率地测试吗？与否对所有重要的工作成果进行了同行评审(正式评审或迅速检查）？开发人员懂得版本控制、变更控制吗？可以按照配备管理规范执行吗？开发人员注重质量吗？与否会在进度延误时减少质量规定?已辨认的风险：风险管理报告风险编号1风险辨认人项目经理风险名称风险辨认日期风险描述开发人员不够，导致开发时间增长风险也许性0.5风险影

32、响风险危害值4.0风险解决人风险减缓措施1. 聘任有开发类似系统的开发人员参与系统开发2. 聘任资深程序员作为技术指引3. 规划开发进程，设定标志性任务，一旦发现超过规定期间未完毕任务,考虑增长人手跟踪记录（)记录何人在何时做了什么事情（2）记录目前风险状态(正在解决，已经解决，不作解决)风险编号风险辨认人项目经理风险名称风险辨认日期风险描述顾客需求不断扩大，导致开发难以进行风险也许性0.8风险影响8风险危害值6.4风险解决人风险减缓措施1. 在初期多收集顾客需求2. 与顾客代表一起召开会议以拟定开发需求3. 开发一种涉及核心功能的顾客界面原型。让顾客代表来评审此原型 跟踪记录（)记录何人在何

33、时做了什么事情（2）记录目前风险状态（正在解决，已经解决,不作解决）风险编号3风险辨认人项目经理风险名称风险辨认日期风险描述程序员语言开发环境不同，协调工作困难风险也许性0.8风险影响5风险危害值4.0风险解决人风险减缓措施1. 尽量规定程序员使用同一种语言作为开发语言2. 建议使用Boranc+ 作为开发环境跟踪记录()记录何人在何时做了什么事情（)记录目前风险状态（正在解决，已经解决,不作解决)风险编号4风险辨认人项目经理风险名称风险辨认日期风险描述顾客提出的需求体现不清晰,导致系统无法满足顾客业务需求风险也许性.2风险影响9风险危害值1.风险解决人风险减缓措施1. 开发人员参与顾客平常办

34、公，熟悉业务过程2. 定期与顾客召开会议，拟定顾客的真正需求跟踪记录(1)记录何人在何时做了什么事情(2)记录目前风险状态（正在解决，已经解决，不作解决)概念测试用例用例11 业务需求“高校课程调度系统”根据教学筹划只拟定既有班级的教学任务。2 使用实例课务管理员输入教学任务相应班级的编号,系统通过与基本数据库进行比对，接受或回绝该班级的教学任务。3 功能需求如果祈求排课资源,只有输入基本数据库中已存在的班级的教学任务,系统才接受该教学任务。4 对话图祈求排课资源 班级信息 输入新的班级信息 接受该班级教学任务取消输入班级编号，基本数据库存在该班级输入新的班级存在的班级取消输入班级编号，基本数

35、据库不存在该班级5 测试用例途径用例21. 业务需求“高校课程调度系统”根据教学筹划中的课程为班级制定教学任务。2. 使用实例课务管理员输入教学任务的课程编号和名称,系统通过与基本数据库进行比对，接受或回绝该门课程的教学任务。3. 功能需求如果祈求排课资源下达教学任务，只有输入基本数据库中已存在的课程编号，系统才接受该教学任务。否则，生成新的课程信息,重新制定教学任务。4. 对话图祈求排课资源 课程信息 按输入的编号和名称生成新的课程信息 接受该课程的任务取消输入课程编号、名称，基本数据库存在该编号新的课程信息存在的课程取消输入课程编号、名称，基本数据库不存在编号和名称输入课程编号、名称，基本

36、数据库存在名称，不存在编号 按输入的名称生成新的课程信息取消新的课程信息5. 测试用例途径用例31. 业务需求“高校课程调度系统”排学时为课元组分派固定教室,教室不能冲突。2. 使用实例排课预解决后,进行教室分派。系统优先分派相应类型和容纳人数的教室给提出了教室祈求的课元组。祈求发生冲突时,系统根据祈求班级的年级分派或回绝分派教室。3. 功能需求如果祈求教室资源，当祈求的教室空闲，系统将教室分派给祈求的班级所开课程;当教室已被占用,该班级将与已占用教室的班级比较所在年级,如果所在年级高则将此教室重新分派给它。4. 对话图祈求教室资源 与已占用教室的班级比较所在年级 取消所在年级高读取课元组祈求

37、的教室类型及容纳人数，无空闲教室读取课元组祈求的教室类型及容纳人数，有教室空闲 分派教室信息取消5. 测试用例途径用例41. 业务需求“高校课程调度系统”排学时为课元组分派上学时间,时间不能冲突。2. 使用实例预解决排课数据,进行时间分派。系统根据课元组提出的祈求优先分派或回绝分派上学时间。3. 功能需求如果祈求排学时间片，只有祈求的时间片有空闲，系统才将时间分派给提出祈求的课元组，当时间片完全被占用,则手工修改排学时间。4. 对话图祈求排学时间取消取消读取课元组祈求的排学时间，时间片已被占用读取课元组祈求的排学时间，时间片空闲 手工修改排学时间 分派排学时间5. 测试用例途径变更控制的过程角

38、色和责任建立变更控制委员会,组织一种由项目风险承当者构成的小组作为变更控制委员会，由她们来拟定进行哪些需求变更,此变更与否在项目范畴内，估价它们,并对此评估作出决策以拟定选择哪些,放弃哪些，并设立实现的优先顺序,制定目的版本。角 色人 员责 任变更控制委员会主席开发小组负责人在C意见不一致的状况下可以独自作出决定CCB全体开发小组人员决定采纳或回绝针对本系统所建议的变更祈求评估者开发小组负责人分析变更对本项目带来的影响修改者全体开发小组人员对已承认的变更祈求准时更新建议者全体开发小组人员顾客代表提交变更祈求验证者开发小组负责人顾客代表确认更改与否对的执行变更注意事项)没有明确的授权。事先应当明

39、确客户方有权提出变更申请的人员和实行方有权受理变更的人员,并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”,而没有人能完整地懂得究竟改了些什么。此外,授权双方接口人的好处是可以屏蔽客户内部的矛盾,如果只有一种接口人，内部尚未达到一致时变更是无法提出来的。从实际经验看，授权可以明显减少变更,特别是那些因内部见解不同而导致的反复变更。 2) 对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立即修改,审核的目的就是为了决定与否需要修改和什么时候修改。例如案例中提到的界面风格问题,就可以先不修改,或者规划一下修改的时间待到后来进行优化。此外，对于核心模块的

40、修改要严格审核把关,否则会引起全局问题,案例中提到的“擅自修改核心模块”导致的事故就是由于没有审核而导致的。 3) 对变更的影响没有评估。变更都是有代价的,应当评估一下变更的代价和对项目的影响，要让客户理解变更的后果,并与客户一起做判断。案例中客户最后的质问正是由于没有事前告诉客户变更的影响导致的。如果客户不懂得你为变更付出的代价，对你的辛苦便难以体会。4) 应当让客户确认与否接受变更的代价。在评估代价并且与客户讨论的过程中,可以请客户一起做判断：“我可以修改,但您能接受后果吗？”。 变更祈求状态开始条件顾客必须通过合适的渠道接受一种合法的变更祈求，本项目通过书面、we表单以及电子邮件申请变更

41、,申请变更请填写需求变更控制报告,不接受任何口头告知。任务进行需求变更影响分析,应评估每项选择的需求变更，以拟定它对项目筹划安排和其他需求的影响。明确与变更有关的任务并评估完毕这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的精确理解，协助做出信息量充足的变更批准决策。通过对变更内容的检查，拟定对既有的系统做出是修改或抛弃的决定，或者创立新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。验证无论需求变更的限度如何，只要需求变化了就必须进行验证，这是基本的原则。本项目组中明拟定义验证员,保证在发生需求变更时，受影响的产品能得到修改并与需求的变更保持一致,受影响的其他组也必须与客户协商一致。需求变更控制报告需求变更申请申请变更的需求文档输入名称,版本,日期等信息变更的内容及其理由评估需求变更将对项目导致的影响申请人签字变更申请的审批意见项目经理签字审批意见: 签字: 年 月 日 客户签字（合同项目）审批意见: 签字： 年 月 日更改需求文档变更后的需求文档输入名称，版本，完毕日期等信息更改人签字重新评审需求文档需求评审小组签字审批意见: 签字: 年 月 日 变更结束项目经理签字 签字: 年 月 日