软件需求分析案例资料.doc

《软件需求分析案例资料.doc》由会员分享，可在线阅读，更多相关《软件需求分析案例资料.doc（29页珍藏版）》请在三一办公上搜索。

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

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

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

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

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

6、表，并进行修订。教室管理员教室管理员将使用系统来查询所管辖教室的课表。教室管理员提供上课可用的教室类型、教室数量、以及教室的名称和容纳人数。教室管理员需要在生成的课表中查找每间教室的使用时间以及班级。任课教师任课教师将使用系统来查询个人的上课课表。任课教师提供自己本学期可上的课程和可用的排课时间做为教学任务的一部分。任课教师需要在生成的课表中查找自己上课的课程、班级、时间以及教室。b. 4运行环境硬件平台：Pentium以上PC；内存16M及以上；VGA及以上显示器；Microsoft鼠标或其它兼容鼠标；Windows支持的各种打印机。操作系统： Windows Win98/XP/2000数据

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

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

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

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

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

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

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

14、室。l 使一周的课程尽量均匀分布到每天，不能有班级出现有一天或半天完全没有课。e.5用户文档编号：1高校课程调度系统软件需求规格说明书编号：2系统分析模型编号：3数据字典编号：4风险管理计划编号：5概念测试用例编号：6变更控制的过程系统分析模型顶层图:高校课程调度系统教室管理员教室信息教室课表教务管理员时间片约束完全课表任课教师任课课程可用时间个人课表课务管理员教学任务完全课表0层图：任课教师任课课程可用时间时间片约束3排课时间管理教务管理员上课周、天数日上课节数上课节次班级时间排课时间信息教室信息2提供教室信息教室管理员教室名称容纳人数教室类型教学楼信息教室数据4排课处理5生成课表数据合成时

15、间约束教室信息教学任务完全课表完全课表个人课表教室课表教学任务1下达教学任务课务管理员教学计划基础数据开课班级教学任务信息课程信息系统数据字典院 系 院系编号 院系名院系编号 *2位正整数，并能唯一标识每个院系或单位*院 系 名 *小于13位字符（包括中文、字母、数字）*教 师 教师编号 教师姓名 出生年 性别教师编号 *6位数字，头2位数字为该教师所在系号,并能唯一标识每个教师；若用户学校以教研室为单位管理, 头4位应是教研室编号*教师姓名 *小于9位字符（包括中文、字母、数字）*出 生 年 *4位数字*性 别 “男“| “女”课 程 课程编号 课程名称课程编号 *小于11位字符, 头2位是

16、课程开课系的编号, 并能唯一标识每门课程*课程名称 *小于21位字符（包括中文、字母、数字）*专 业 专业编号 专业名称专业编号 *小于5位字符, 头2位为该专业所属的系号, 并能唯一标识每个专业* 专业名称 *小于13位字符（包括中文、字母、数字）*教 学 楼 教学楼编号 教学楼名称教学楼编号 *4位数字，第1位是校区码，并能唯一标识每个教学楼*教学楼名称 *小于17位字符（包括中文、字母、数字）*教室 教学楼编号 教室名称 容纳人数 教室类型教室名称 *小于7位个字符，（包括中文、字母、数字）*容纳人数 *3位正整数*教室类型“-1”|“0”|“1”|“2”|“3”|“4”|“5”|“6”

17、|“7”|“8”|“9” * -1表示不分教室；0 表示一般的上课教室；1和2均表示制图室；39为自定义小于5位字符*学生班级 班级编号 年级 班名 人数 固定教学楼 固定教室编 号 *4位字符, 是该班所在专业的编号*年 级 “1”|“2”|“3”|“4”班 名 标识符 序号 标识符 *小于7位字符* 序 号 *2位字符，允许为空*人 数 *3位数字*固定教学楼 *小于13位字符（包括中文、字母、数字），允许为空*固定教室 *小于7位字符（包括中文、字母、数字），允许为空*教学计划 编号 年级 学期 课程编号 课程名称 学时 学分 周学时 是否必修 是否考试 起周次 末周次学 期 “1”|“

18、2”|“3”学 时 *3位正整数*学 分 *2位正整数, 1位小数*周 学 时 *2位正整数, 1位小数*是否必修 “0”|“1”|“2”* 选修为2, 必修为1,限选为0*是否考试 “0”|“1”* 考查为1, 考试为0*起 周 次 *2位正整数，允许为空*末 周 次 *2位正整数，允许为空*教学任务 课程编号 课程名称 学时 周学时 是否必修 是否考试 主讲 助课 上课班级 合班数 人数 起周次 末周次 连上节数 时间要求 排课模式 教室类型 教学楼 教室合 班 数 *2位正整数*连上节数 “1”|“2”|“3”|“4”|“5”|“6”|“7”|“8”* 04 表示该课每次上课的节数, 0

19、 也表示连上 2 节； 5 表示上午2节，下午4节； 6 表示排2个下午； 7 表示1天； 8 表示1个上午2节，2个下午* * 连上节数是5-8时周学时对排课不起作用*排课模式 “1”|“2”|“3”|“4”|“5”|“6”|“7”* 0表示上、下午排课；1表示单周上午、双周下午排课；2表示双周上午、单周下午排课；3表示上、下午排课，并均匀分布课时；4表示下午、晚上排课，并均匀分布课时；5表示下午排课；6表示晚上排课；7表示上、下午、晚上均排课*联合课码 *小于6位字符，在一种联合课中, 主行课的联合课码是正整数, 并行课的联合课码是该数的负数*讲课课程 课程编号 课程名称 容纳数 固定教学

20、楼 固定教室 教室类型容 纳 数 *2位正整数, 表示该课每个时间片可容纳课元组的数目*风险管理计划有关概念：风险（Risk）是在规定的费用、进度和技术的约束条件下不能实现整个项目目标的可能性的一种度量。风险包括两个方面：(1)不能实现具体目标的概率；(2)因不能实现该目标所导致的后果/影响。 风险事件（Risk event）即可能导致某个项目或系统发生问题，需要作为采办项目要素加以评估以确定风险水平的事件。风险事件的定义应使人们易于理解其潜在影响和致因。可能会有一系列潜在的风险事件，这需要有关专家进行筛选、考察和评估。 风险的概率和后果之间的关系比较复杂。为避免评估结论含糊不清，与某个事件有

21、关的风险应以概率和后果这两个参量表征。作为评估的一部分需要含有支持数据和评估理由的背景材料。风险管理（ Risk management）是指控制风险的行动或实践。它包括进行风险规划、评估风险域，拟定风险处理备选方案，监控风险变化情况和记录所有风险管理情况。 风险规划（Risk Planning）是指研究一套有组织的、全面的和相互作用的策略和方法并将其形成文件的过程，这套策略和方法用于辨识和跟踪风险域；拟定风险缓解方案；进行持续的风险评估，从而确定风险变化情况并配置充足的资源。 风险评估（Risk assessment）指对项目各个方面的风险和关键性技术过程的风险进行辨识和分析的过程，以增加满足

22、性能、进度和费用目标的可能性。风险辨识指对项目各个方面和各个关键性技术过程进行调查研究，从而辩识并记录有关风险的过程。风险分析是指调查研究已辨识出的风险域或过程以进一步细化风险描述，隔离风险的原因和确定风险影响的过程。它包括风险等级评定和优先次序排序， 风险事件的等级和排序是根据风险发生的概率、后果的严酷度以及与其他风险域或技术过程的相互关系来确定的。 风险处理（Risk handling）是指对风险进行辩识、评价、选定并实施应对方案的过程，目的是在给定项目约束条件和目标下使风险保持在可接受水平上。它包括详细说明应当做些什么，应于何时完成，由谁负责，以及有关的费用和进度等具体问题。要从这些应对

23、方案中选取最恰当的策略。风险处理是一个包罗万象的术语，而风险缓解和风险控制则是它的子集。 风险监控（Risk monitoring）是指在整个采办过程中，按既定的衡量标准对风险处理活动的效果进行系统跟踪和评价的过程，必要时还要进一步研究风险处理备选方案。它还反馈信息给风险规划、风险评估和风险处理等其它的风险管理活动。 风险文档（Risk documentation）是指记录、维护和报告风险的评估、处理分析方案以及监控结果的文件，包括所有的计划、给项目经理和决策者的报告以及项目管理办公室的内部报表。 风险管理的组织结构 执行风险管理功能的主要是项目开发人员。开发人员由项目经理负责，他是风险管理的

24、最终负责人。 风险管理既是整个项目管理的一个有机组成部分，也是项目管理的一种有力手段和方法。它的任务是要弄清费用风险、进度风险和性能风险的相互关系。其目的是使参与项目工作的一切人员都能建立风险意识，在设计、研制和部署系统时考虑风险问题。本系统风险管理的组织形式，为在集中式风险管理，项目经理要组建一个专门的风险管理组，来负责风险管理的所有工作，如编写计划、进行评估、评价风险处理备选方案和监控风险管理工作的进展情况等。l 项目经理是进行规划、分配资源和执行风险管理的最终负责人，因此要求项目经理检查和参与风险管理过程。 l 项目经理必须最佳地使用可用资源，即人力、组织和资金。l 风险管理是一项团队功

25、能。这是因为风险的广泛性和风险处理计划要影响到项目的其他计划和行动。总的来说，风险评估、风险处理和风险监控对所有的项目活动和组织都有影响。任何企图实施积极主动向前看的风险管理计划，而没有项目经理参与，都将导致混乱、迷失方向和资源浪费。人 员 工作职责项目经理 风险管理的计划、组织、领导和控制； 报告项目风险和建议缓解措施。 风险管理协调员制定和维护风险管理计划； 提供风险管理培训； 定义项目使用的风险报告的范围； 建立和维护风险管理信息系统； 准备风险管理报告； 向项目经理提出有关使用独立风险评估员的建议。 独立风险 评估员 对项目经理指定的关键风险域进行独立风险评估； 报告这些评估的结果给项

26、目经理； 和风险管理协调员共同工作。 风险管理工作步骤如下： 在项目计划和项目进度（如果适用）中，标识出风险。 根据项目定义的软件过程，建立补救措施计划文档。此计划将贯穿整个项目软件生命周期。补救措施计划应包括以下方面的工作：可选项识别、可选项影响度评估、可选项的技术可行性，和可选项使用时机的决定标准。 为每一风险定义出可供选择的补救措施，如果有可能，也要列出这些补救措施的选择标准。 软件计划的最初版本和主要的修订版，要经过同行评审后才可发行。 管理并控制软件计划。 在有选择的项目里程碑处、在指定的风险检查阶段点、和在对软件项目有影响的计划重大变更过程中，都应对风险进行跟踪、再评估，和重新计划

27、。 检讨并修正风险级别。 利用风险监控所获得的信息，进一步精化风险评估和软件计划。 风险检查表：提示：请使用者根据机构和项目的实际情况完善本检查表。商业风险风险类型检查项政治法律市场政府或者其它机构对本项目的开发有限制吗？有不可预测的市场动荡吗？有不利于我方的官司要打吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？竞争对手有不正当的竞争行为吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？是否在开发很少有人真正需要却自以为很好的产品？是否在开发可能亏本的产品？客户客户的需求是否含糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品

28、的健壮性、可靠性、性能等质量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。子承包商供应商与子承包商、供应商签订的合同公正吗？双方互利吗？子承包商、供应商的信誉好吗？子承包商、供应商有可能倒闭吗？子承包商、供应商能及时交付质量合格的产品（或部件）吗？子承包商、供应商有能力做好售后服务吗？管理风险风险类型检查项项目计划对项目的规模、难度估计是否比较正确？人力资源（开发人员、管理人员）够用吗？合格吗？项目所需的软件、硬件能按时到位吗？项目的经费够用吗？进度安排是否过于紧张？有合理的缓冲时间吗？进度表中是

29、否遗忘了一些重要的（必要的）任务？进度安排是否考虑了关键路径？ 是否可能出现某一项工作延误导致其它一连串的工作也被延误？任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？项目团队项目成员团结吗？是否存在矛盾？是否绝大部分的项目成员对工作认真负责？绝大部分的项目成员有工作热情吗？团队之中有“害群之马”吗？技术开发队伍中有临时工吗？本项目开发过程中是否会有核心人员辞职、调动？是否能保证“人员流动基本不会影响工作的连续性”？项目经理是否忙于行政事务而无暇顾及项目的开发工作？上级领导行政部门合作部门本项目是否得到上级领导的重视

30、？上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？行政部门的办事效率是否比较底，以至于拖项目的后腿？行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？机构是否能全面、公正地考核员工的工作业绩？机构是否有较好的奖励和惩罚措施？本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？技术风险风险类型检查项需求开发需求管理需求开发人员懂得如何获取用户需求吗？效率高吗？需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？需求开发人员能否与客户对有争议的需求达成共识？需求开

31、发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？综合技术开发能力包括设计编程、测试等开发人员是否有开发相似产品的经验？ 待开发的产品是否要与未曾证实的软硬件相连接？对开发人员而言，本项目的技术难度高吗？开发人员是否已经掌握了本项目的关键技术？如果某项技术尚未实践过，开发人员能否在预定时间内掌握？开发小组是否采用比较有效的分析、设计、编程、测试工具？分析与设计工作是否过于简单、草率，从而让程序员边做边改？开发小组采用统一的编程规范吗？开发人员对测试工作重视吗？能保证测试的客观性吗？项目有独立的测试人员吗？懂得如何进行高效率地测试吗？是否对所有重要的工作成果进行了同行评审（正式评审或

32、快速检查）？开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？开发人员重视质量吗？是否会在进度延误时降低质量要求？已识别的风险：风险管理报告风险编号1风险识别人项目经理风险名称风险识别日期风险描述开发人员不够，造成开发时间增加风险可能性0.5风险影响8风险危害值4.0风险处理人风险减缓措施1. 聘请有开发类似系统的开发人员参与系统开发2. 聘请资深程序员作为技术指导3. 规划开发进程，设定标志性任务，一旦发现超过规定时间未完成任务，考虑增加人手跟踪记录（1）记录何人在何时做了什么事情（2）记录当前风险状态（正在处理，已经解决，不作处理）风险编号2风险识别人项目经理风险名称风险识别日

33、期风险描述用户需求不断扩大，造成开发难以进行风险可能性0.8风险影响8风险危害值6.4风险处理人风险减缓措施1. 在早期多收集用户需求2. 与用户代表一起召开会议以确定开发需求3. 开发一个包括核心功能的用户界面原型。让用户代表来评审此原型 跟踪记录（1）记录何人在何时做了什么事情（2）记录当前风险状态（正在处理，已经解决，不作处理）风险编号3风险识别人项目经理风险名称风险识别日期风险描述程序员语言开发环境不同，协调工作困难风险可能性0.8风险影响5风险危害值4.0风险处理人风险减缓措施1. 尽量要求程序员使用同一种语言作为开发语言2. 建议使用Borland c+ 作为开发环境跟踪记录（1）

34、记录何人在何时做了什么事情（2）记录当前风险状态（正在处理，已经解决，不作处理）风险编号4风险识别人项目经理风险名称风险识别日期风险描述用户提出的需求表达不清楚，造成系统无法满足用户业务需求风险可能性0.2风险影响9风险危害值1.8风险处理人风险减缓措施1. 开发人员参与用户日常办公，熟悉业务过程2. 定期与用户召开会议，确定用户的真正需求跟踪记录（1）记录何人在何时做了什么事情（2）记录当前风险状态（正在处理，已经解决，不作处理）概念测试用例用例11 业务需求“高校课程调度系统”根据教学计划只拟定现有班级的教学任务。2 使用实例课务管理员输入教学任务相应班级的编号，系统通过与基础数据库进行比

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

36、该教学任务。否则，生成新的课程信息，重新制定教学任务。4. 对话图请求排课资源 课程信息 按输入的编号和名称生成新的课程信息 接受该课程的任务取消输入课程编号、名称，基础数据库存在该编号新的课程信息存在的课程取消输入课程编号、名称，基础数据库不存在编号和名称输入课程编号、名称，基础数据库存在名称，不存在编号 按输入的名称生成新的课程信息取消新的课程信息5. 测试用例路径用例31. 业务需求“高校课程调度系统”排课时为课元组分配固定教室，教室不能冲突。2. 使用实例排课预处理后，进行教室分配。系统优先分配相应类型和容纳人数的教室给提出了教室请求的课元组。请求发生冲突时，系统根据请求班级的年级分配

37、或拒绝分配教室。3. 功能需求如果请求教室资源，当请求的教室空闲，系统将教室分配给请求的班级所开课程；当教室已被占用，该班级将与已占用教室的班级比较所在年级，如果所在年级高则将此教室重新分配给它。4. 对话图请求教室资源 与已占用教室的班级比较所在年级 取消所在年级高读取课元组请求的教室类型及容纳人数，无空闲教室读取课元组请求的教室类型及容纳人数，有教室空闲 分配教室信息取消5. 测试用例路径用例41. 业务需求“高校课程调度系统”排课时为课元组分配上课时间，时间不能冲突。2. 使用实例预处理排课数据，进行时间分配。系统根据课元组提出的请求优先分配或拒绝分配上课时间。3. 功能需求如果请求排课

38、时间片，只有请求的时间片有空闲，系统才将时间分配给提出请求的课元组，当时间片完全被占用，则手工修改排课时间。4. 对话图请求排课时间取消取消读取课元组请求的排课时间，时间片已被占用读取课元组请求的排课时间，时间片空闲 手工修改排课时间 分配排课时间5. 测试用例路径变更控制的过程角色和责任建立变更控制委员会，组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。角 色人 员责 任变更控制委员会主席开发小组负责人在CCB意见不一致的情况下可以独自作出决定

39、CCB全体开发小组人员决定采纳或拒绝针对本系统所建议的变更请求评估者开发小组负责人分析变更对本项目带来的影响修改者全体开发小组人员对已认可的变更请求按时更新建议者全体开发小组人员用户代表提交变更请求验证者开发小组负责人用户代表确认更改是否正确执行变更注意事项1) 没有明确的授权。事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好处是可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际经验看，授权可以显著减少变

40、更，特别是那些因内部看法不同而导致的反复变更。 2) 对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。比如案例中提到的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。 3) 对变更的影响没有评估。变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不

41、知道你为变更付出的代价，对你的辛苦便难以体会。4) 应该让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。 变更请求状态开始条件用户必须通过合适的渠道接受一个合法的变更请求，本项目通过书面、web表单以及电子邮件申请变更，申请变更请填写需求变更控制报告，不接受任何口头通知。任务进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。通过对变更内容的检验，确定对现有的系统做出是修改或抛弃的决定，或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。验证无论需求变更的程度如何，只要需求变化了就必须进行验证，这是基本的原则。本项目组中明确定义验证员，确保在发生需求变更时，受影响的产品能得到修改并与需求的变更保持一致，受影响的其它组也必须与客户协商一致。需求变更控制报告需求变更申请申请变更的需求文档输入名称，版本，日期等信息变更的内容及其理由评估需求变更将对项目造成的影响申请人签字变更申请的审批意见项目经理签字审批意见： 签字： 年 月 日 客户签字（合同项目）审批意