软件需求分析案例.docx

1、软件需求分析案例髙校课程坍度系毓软件需求規格说明书a引言a. 1目的高校教务管理工作是高等教育中的一个极为重要的坏节，是整个院校管理的 核心和基础。面对种类繁多的数据和报表，面对手工处理方式已经很难眼上现代 化管理的步lo 算机及通爪技术的飞速发展，高等教育对教务管理工作提岀了更高的要求。尽快改变传貌的管理模式，运用现代化手段进行科学管理，已 经成为整个教育系貌页侍解决的课题之一。根据全国高校教学管理軟件市场的需求，开发完成教学管理系貌尤其是课程 调度管理系统迫在眉吐，为廿算机管理课程iS I作提哄全面的解决方案。a. 2预期的挟者和阅挟建次本需求分折说明书适用于该顶目客户、业务或需求分析人员

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

3、普通高等学校教学管理制度和学生学jsta有关问题的暫行 规定、教学一览、课程编号一览、软件工程、廿算机系筑导论、数据库原理与方法、Software Requirementb综合描述b.1产品的前景各级教学管理部门作为各个高等学附的一个重要服能部门，管理、制定、执 行匂学校头等大事一教学工作有关的各顼工作员碩策。其中，教学计划的实施 是一个重要的坏节。每学期管理人员都要制定、整理教学廿划，根据教学廿划下 这敦学任务书，然后根据教学任务书编Jj果程表。在逆些課程调度工作中，既有 大量繁预的数据整理工作，也有严谨思维的腑力劳动。此外，还有种类繁名的数 据和报表。为了提高教学管理册门的工作效率，其管理

4、工作的计算机化已刻不容 缓。通il大量的调查研究发现，目前，教学管理部门的管理模式存在以下主要问 题：业务流程不规数据资料分散、重复、易遗漏数据信息不全面数据查询困难统计、排课工作耗时、贾力、不准确等针对目前存在的各种间题，使我们意识到，必需通ilit算机管理辅ffll教学管 理部门日常工作，优It管理模式,才能这到业务流程规化、业务数值化、资料数 据库化以及决策模觥的管理水准。为此，研制和开发高校课程调度系境已刻不 容缓，具有广泛的使用和推广前景。b2产品的功能助能表述图:高校课程调度系统b. 3用户类和特征“高校课程调度系筑的用户类课务管理员课务管理员管理着全校的教学任务以及1作。他竹是排

5、课管理的唯一 使用者，将处理来自教务菅理员的时间列東并提供完全课表；向教室菅理 员请求孙课可用教室并提供教室的课表淸卑；获皿任课教师的任课课棺和 可用时间并提供教师的个人课表。教务管理员教务管理员是教务科科长甚至教育处处长。他111便用系貌是力了获得符合 学校教学管理.安孙的完全课表，进行宏观管卑、保证教学工作正常开展。 教务管理员規供学校统一的时间要求。教务管理员需要在生成的课表屮得 到一系列课表,包牯总课表，册级、教师、教室课表，并进行修订。教室菅理员教室管理员將使用系蔬来查询所管辖教室的课表。教室管理员提供上课可 用的教室类里、教室数量、WKS室的名称和容纳人数。教室管理员需要 在生成的

6、课表中查找6(0室的便用时间1及册级。任课教厕任课教师為使用系统来査询个人的上课课表。仮课教师提供自己本学期可 上的课程和可用的II课时间做为敦学任务的一部分。任课教师需要在生成 的课表中查找自己上课的课椁、讯级、W(bWK室。b4运彳亍环境硕件平台：Pentium U PC；存16M及以上;VGA及以上显示器；Microsoft鼠标或其它兼容鼠标;Windows支持的各种打印机。操作系貌：Windows Win98/XP/2000数据库系貌：SQL Server等常用数据库b. 5设廿和实现上的限胃所使用的设廿符号表示必须符合高等学校教学管理的规。b6假按和依頼本狀件在开发的11程中，分为技

7、术实现与软件工程两大部分，两部分都有侧 重点，若技术支持岀现故邱或樋难冋題无法解决、程序开发岀现偏差，会延误工 程a,影响工程的按期完工。若软件工程述岀现问题，部分描述含混不清，则 会影响系貌的完整性与可堆承性。在管理方面，如管理者没有预见性，对岀向的 冋題无法呆用可行的解决手段,都会影晌开发模块之同的互a, m而影响工程的 顺利开展，导致工程无法按期完工。C外部接口需求C. 1用户界面根据高校课程调度系貌的特点，用户界面呆用桌面应用程序方式实现。c2復件接口硕件坏境是高校课程调度系貌运行的物质基础，它必须有较高的性能，必须 是隐定可靠的，同时还应菽是可以扩充的。c3軟件接口廿算机信息系貌之间

8、的信息交换，除了有硬件要求之外，还必须iOft同的 狀件接口标准。高校课程调度系貌必须能服提俱数据专换接口。高校课程调度系筑的软件接口由WINDOWS操作系貌(Windows 98/Windwos2000/Windows XP )、SQL Server 组成。c4通信接口本产品的没有特殊的通讯接口，通讯接口由所使用的PC Hl决定。d系筑特牲d. 1排课管理1.说明和优先级排课的优先级为髙。要求将学校的课表按教学任务无冲突的排好，并尽量满 足课元组提岀的特殊请求(如：教室i青求、排课时间请求等)。但是，不保证是 最优方案。2.序列读取教学廿划生成教学任务,師排课预处理。输人或修改教学任务，进行

9、排课预处理。输人任课教师和上课JB级的特殊时同请求,分配上课时间。输人开设课程的特殊教室请求，分配上课教室。3.功能需求管理排课时间片：管理影哨井课的各种时间片,包括本学期排课周数、 每周排课天数、毎天排课节数、排課开始节次、J9级可用时间、任课教 师可用时间、井课时间模式等排课预处理：读取教学任务及排课时间片，进行数幽处理，优先为在教学任务中提岀特殊请求的课元组分配时间教室分配：为排課预处理后的课元组分配教室，优先为在教学任务中提 出特殊请求的课元组分配教室修订、检验课表：对在排课处理里中发生的冲突（时同冲突、教室冲突） 进行修校正至没有冲突及空缺。生成课表d2按分类打印课表管理1-说明利优

10、先级按分类打印课表的优先级为中。要求将排好的课表按各种用户的要求分类打 印,满足不同的用途。2.序列输人院系、专业、册级，打印总课表。输入任课教师,打印教师课表。输人教室编号，打印教室课表。3.功能需求打印总课表：打印学校的总课表，容色括所在院系、所在专业的所有册 级的上课课程、任课教师、上课时间、上课的教室。打印教师课表:扌JEP每位任课教厕的个人课表，容包括教！I所上的课程、 上课JI级、上课时间和上课的教室。扌I印教室课表:打印每间教室的教室课表,容色祐教室使用的时间、所上的课程和上iO级。d.3课表査询1.说明和优先级课表查查询的优先级为低。只要能嚴在系统中查询、能样贝课表数据、能在网

11、上査询。2.功能需求课表查沟：使用本系貌按不同的条件查询课表（M：按册级、课程、教 师、教室等） j果表数据拷贝：将生成的课表文件拷贝到其他安装该系貌的it算机上进 行査询生戒j果表网页：在生成课表的同时生成按教帅分类的课表网页，佻用户 及其他人员（院系领导、学生）查询课表。e其它非功能需求e.1性能需求高校课程调度系貌II能需求见下表:在进行向数据库文件梶取数据时，要求数据记录定也准确，在住数 据库文件数组中淡加数时，要求输人数准彌。时间特性a.哨应时间应在人的慰觉和視觉事件围；b.更新处理时何，I着系统的版本升级，课桿涮度系统將HI应的 进行更新。灵活性当需求发生杲些变化时，课棺凋度系统软

12、件棵作方式、数据结构、 运行坏境基本不会发生变化，变化只是為对应的数据库文件的记录 改变，或為筛选条件改变即可。数据管理能力本系统数据库的管理能力取决于SQL server对数振的管理能力, Microsoft SQL Server是一个较成熟的大里数摇库系躱,能满足本系 统的要求。故障处理故障几率小，II除简单（只需拷贝动态库文件，不需車新安装）。e2安全牲需求保证应用系统信息安全。肪止郡或敏感信息的泄漏以及外郡不良信息的侵入。提侠必要的冗余和备卅措施。当系统发生於障时能無立HI恢复，保込系 统可靠运行；系统备卅、数据库备份：定时后备，快速恢复。e3軟件质量属性可靠性：由干软件失效引起排课出

13、錯的阕率应不起过5%。 18址性：所有的排课参数都要荷定一个缺省值，当输人数据丢失或无效时，就使用缺省值数据。可用性：在文件菜单中的所有功能都必须定义快捷建，该快捷建是由Alt 维和其它维组合实现的。e4业务規则只有在输人了教学it则之后，才能在新建教学任务时渎取教学it Wo只有在输入了教学任务之后,才能进行排课。只有在设置了时间片之后，才能进行排课。排课时,要同时安排任课教师和上课教室。使一周的课程尽量均匀分布到每天，不能有册级岀现有一天或半天完全股有课。e5用户文档编号：1高校课程调度系竦软件需求規格说明书编号：2系铳分桥模型编号：3数襦字典编号：4风险管SitM编号：5撕念测试用例编号

14、：6变更控*1的过程系统分折模型课务管理员教学任务完全课表顶层图:懿至管理员教室信息教室课表高校课程调度系统时间片约束完全课表教务管理员1n个用人时课间衰1任课教师一冰J、人煮X /日上课节数上课节次 丄班级时间k完全课表位 znF排课时间信息课纟理员j课程信息5课 班 级vr用时间系院个完全课表教学任务信息EIE教室墨教室类型容纳人数教室名称教学楼信息院系名 =*小于13也字符（包站中文、字母、数字V教 W =教轴编号+教师+岀生年+性别教帅编号 =*6EU字，头2EH字为该教師所在系号，并能唯一标识每个教帅；若用户学校以教研室为单位菅理，头4E是教研室编号*教加 =*/h于9位字符（包播中

15、文、字骨、数字厂岀生年 =*4EU字*性 别 二“男“I “女”课 程 =课程编号+课程名称课程编号 =*小于11也字符，头2位是课程开课系的编号，并能唯一标识毎 门课程*课程名称 =*/h于21位字符（包括中文、字骨、数字）专 业 =专业编号+专业名称专业编号 = 小于5也字符，头2位为该专业所闹的系号，并能唯一标识毎个专业专业名称 =*/h于13也字符（包括中文、字骨、数字厂教学楼 =教学楼编号+教学楼名称教学楼编号教学楼名称教室教室名称容细人数教室类型“学生册级编 号年 级J8 名=*4（5字，第1也是校区码,并能唯一标识每个教学ST= */h于17位字符（包括中文、字骨、数字厂=教学楼

16、编号+教室名称+容纳人数+教室类型二*小于7位个字符,（色扌舌中文、字母、数字）*= *3R正整数*-F | “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9” -1表示不分教室；0表示一般的上课教室;1和2沟表示制图室；39为自定义小于5位字符*=册级编号+年级+ ffig+人数+固定教学楼+固定教室=r也字符，是iOIhJi在专业的编号*=“1” | “2” | “3” | “4” =标识符+序号标识符=*小T7E字符*序号 =*2位字符，允许为空*人 数 =*3位数字*固定教学楼=*/h于13也字符（包括中文、字骨、数字），

17、允许为空 固定教室 =小干7位字仔（色括中文、字骨、数字），允许为空* 教学廿划 =编号+年级+学期+课程编号+课程名称+学时+学分+周学时+是否助修+是否考试+起周次+末周次学 期 =“1” 丨 “2” | “3” 学 时 =壮也正整数*学 分 =*2也正整UJE小周学时 =*2位正整8,1（5小数是否必修 =uOn | “1” I “2” *选修为2,必修为1,限选为（T是否考试 二“0” | “1” *考查为1,考试为0*起周次 =*2R正整数，允许为空*未周次 =*2位正整数，允许为空教学任务=课程编号+课程名称+学时+周学时+是否必修+是否考试+主讲+助课+上课册级+合册数+人数+起

18、周次+末周次+连上节数+时同要求 +排课模式+教室类型+教学楼+教室合册数 =*2位正整数*连上节数 =ar | “2” | “3” | “4” | “5” | “6” | “7” | “8” *0-4表示该课每次上课的节数,0也表示连上2节；5表示上午2节，下午4节；6表示排2个下午;7表示1天；8表示1个上午2节，2个下午*连上节数是58时周学时对排课不起作用*排课模式 =“1” I “2” | “3” | “4” | “5” | “6” | “7” F表示上、下午排课；1表示单周上午、双周下午排课；2表示双周上午、单周下午排课；3表示上、下午排课，并沟匀分布课时；4表示下午、晚上排课，并

19、均匀分布课时；5表示下午排课;6表示晚上排课;7表示上、下午、晚上均SHV联合课码 =*小于6也字符，在一种朕合课中，主行课的联合课码是正整数,并行课的联合课陷是複数的负数*讲课课程 =課程编号+课程名称+容细数+固定敦学楼+固定教室+教室类型容纳数 =*2也正整数，表示该谍每个时间片可容纳课元组的数目*风险管理廿划有关U余:风险（Risk）是在规定的费用、进度和技术的约東条件下不能实现整个项目 目标的可能性的一种度量。风险包括两个方面：（1）不能实现具体目标的IR率；（2） 因不能实现该目标所导致的后果/影响。风险事件（Risk event）即可能导致某个顶目或系统发生问題，需要作为釆 亦顶

20、目要素加以评估以确定风险水平的事件。风险事件的定义应使人们易于理解 其潜在影响和致因。可能会有一系列潜在的风险事件，这需要有关专家进行筛选、 考察和评估。风险的IM率和后果之同的关系比较夏杂。为遐免评估结论含刪不清，与某 个事件有关的风险应以做率和后果这两个参量表征。作为评估的一部分需要含有 支持数据和评估理由的背景林料。风险菅理（Risk management）是指控制风险的行动或实践。它包插进行风 险规划、评估风险域，SI定风险处理备选方案，监腔风险变化悄况和记录所有风 险管理悄况。风险规划(Risk Planning )是指研究一套有组织的、全面的和相互作用的策 昭和方法并将其形成文件的

21、il程,这套策峪和方法用于辦识和跟踪风险域;1定 风险缓解方案；进行持续的风险评估，U而确定风险变It悄况并配置充足的资瀾。风险评估(Risk assessment)指对项目各个方面的风险和关堆性技术过程的 风险识和分折的il程，以增加满足性能、进度和费用目标的可能性。风险 辨识抬对项目各个方面和各个关健性枝粗程进行调查研究，从而辩识并记录有 关风险的过程。风险分折是拒调查研究已辨识岀的风险域或11程以进一步细化风 险描述，隔离风险的原因和确定风险影喇的过程。它色括风险等级评定和优先次 序排序，风险事件的等级和排序是根据风险发生的is率、后果的严san及与 其他风险域或技术过程的相互关系来确定

22、的。风险St a ( Risk handling )是指对风险fifiSI识、评价、选定并实施应对方 案的il程，目的是在给定顶目约束条件和目标卞使风险保持在可接受水平上。t 色扌舌详细说明应当做些什么，应于何时完成,由谁负责，以及有关的费用和进度 等具体间题。要从送些应对方案中选取最恰当的策略。风险处理是一个色罗JI象 的术语,而风险缓解和风险腔制则是它的子集。风险监控(Risk monitoring )是指在整个呆亦过程中，按既定的IB量标准对 风险处理活动的效果进行系貌跟踪和评价的il程，必要时还要进一步研究风险处 理备选方案。它还反馈信息给风险规则、风险评估和风险处理等其它的风险管理

23、活动。风险文B ( Risk documentation )是荷记录、绒护和报告风险的评估、处理分 折方案以及监腔结果的文件，包祐所有的廿划、给顶目经理和决策者的报告以及 项目管理亦公室的部报表。风险管理的组级结构执行风险管理功能的主要是项目开发人员。开发人员由项目经理负责，他 是风险管理的最终负责人。风险tiH是整个的一个有机组成部分，也 是顶目管理的一种有力手13和方法。它的任务是要弄清费用风险、进度风险和性 能风险的相互关系。其目的是使参与顶目工作的一切人员都能建立风险愆识，在 设计、研制和部署系统时考虑风险间题。本系貌风险管理的组纵形式，为在集中式风险管理，顶目经理要组建一个 专门的风

24、险管理组，来负责风险管理的所有工作，如编写廿划、进行评估、评价 风险处理备选方案和监腔风险管理工作的进展悄况等。顶目经理是进行規划、分配资源和执行风险管理的最终负责人，因此要求顶 目经理检査和参与风险管理过程。顶目经理助须最佳地使用可用资源，即人力、组织和资金。风险管理是一顶01臥功能。这是因为风险的广泛II和风险处3it M要影响到 项目的其他计划和行动。总的来说，风险评估、风险处理和风险监控对所有 的顶目活动和组级部有影响。任何企图实施枳极主动向前看的风险管理廿 剤,而没有项目经理参与，部稱导致混乱、迷失方向和资源浪费。人员工作1O頂目经理风险管理的it划、组级、领导和控制； 报告项目风脸

25、和建议缓解措施。风险管理协调员翎定和维护风险管理itJ;提供风险管理培调；定义顶目使用的风险报告的围；建立和维护风险管理信息系筑;准备风险管理报告;向项目经理提出有关使用独立风险评估员的建议。独立风险坪估员对顶目经理指定的关鍵风险17立风险评估；报告迪些评估的给果给项目经理；和风险管理协调员共同工作。风险管理工作步骤如下:在顶目计划和顶目进度（如果适用）中，标识出风险。根据顶目定义的軟件11程，翟立补敕措施廿划文甘。此it则将贯穿整个顶 目軟件生命周期。补救措施廿划应包折以下方面的工作：可选顶识别、可 选顶影响度评估、可选顶的技术可行性，和可选顶使用时机的决定标准。为毎一风险定义岀可佻选择的补

26、救措施，如果有可能，也要列出这些补救 措施的选择标准。软件廿刘的最初版本和主要的修订版,要经il同行评审后才可发行。管理并控制软件itiHo在有选择的顶目里程碑处、在荷定的风险检查阶段点、和在对軟件顶目有 影响的it划重大变更过程中,部应对风险进行限踪、再评估，和重新廿1。检过并修正风险级别。利用风险监控所获得的信息,进一步精化风险评估和軟件it Mo风险检査表:提示:请便用者根据机构利頂目的实际悄况完善本检査表。商业风论岡际类型检査Hilffl或者其构对本顶目的开发有限制吗？有不可fi溥的市场动游蚂？政治有不利于我方的官司要打眄？迭律本产品孙售后在使用过程中可能导致发牛更大的損失或伤亡串故吗

27、？帀场克争对手有不正当的克争行为眄？本产品细售后在使用过程中可能导致发生重大的損失或仿亡串故码？是否在开发很少有人真正需耍却自以为很妤的产品？是否在开发可能亏本的产品？客户客户的篙否含剧不消？客户是否反反見复地枚动需求？客户指定的儒求和交付朋眼任客观上可行吗？客户对产品的體址11、可靠滋、滋能等质邑回素有非帘过分的更求吗？客户的合作态厦更善期？与客户签的合同公正期？玻方互利罔？客户的時舊好呜？西规按客户的需求开发了产品，M是客户可能不即买。子承包商供应商与子承包商、哄廊商签ij的合同公正時？毁方互利屿？子廉色商、供应商的信音好屿？子廉色商、供应商有可能倒团鸟?子廉色商、供应商能及时交付质虽合陷

28、的产品（或部件）吗?子承包商、供陋商有能力似好售后股务眄？管理风匯财类型楡查哎顶目it則对頃目的规模、淮度估计是否比较正晞？人力贾源（开发人员、管用人员）够用期？合格罔？顶目和的離件、厦件能按附到位眄？顶目的蛉股昭用吗？i!度安H是否过于累？有合理的媒沖时同蚂？i!度表中是否遺忘了 一些更要的（处要的）任务？H度安带是否考虑了关建略径?是否可能岀现某一顶工作迤淚导致與它一连审的工作也被迤获？什务分配是否合理？（即把卄务分就给合诡的顶目皈员，无分发挥其才能）是否为了节省找，不采用（刚买）成熟的款件蟆块，一口从零做址？顶目团从i目皈员01站屿？是否存在牙暗？是否克大部分的頂目战员对工作认貞负贯？克

29、大部分的頃目成员有工作热tfi吗？团臥之中有“害辭之马”眄？技术开发瓜历中有tewi?本填目开发il程中是否会有核心人员SHL说朋？是否能保11 “人员耐星本不僉雳用工作的连续性”？放目经理是否忙于仃枚串务而无眠拽及填目的开发Ift?上级领导合作叭本顶目是否福到上级領导的重酣?上级领导是否调本顶目的资海用干其E “髙优先级”的顶目？上级领导是否过多地介人本顶目的爭务并冃瞎指挥？行政部J的办审效率是否比较风，以至干拒頂目的岳龍？行政部0是否经帘干一些无益于生产力的审怖，以至干憂扰本頃目？1构是否能全面、公正地考核员工的工作业绩？1构是否有较好的奖加和怎罚赭施少本頂目的合作部J的态度枳檢眄？是否应付了串？或者偷爭与廉诺的不一致？技术风脸风關类型楡查攻镒求开发痔求管理需求开发人员露福血冋蔵取用户需求屿？效率畐吗？需求开发人员露福顶目两苗及的貝体业务罔？能否理解用户的需求？需求文档能館正确地、芫备地表迭用户需求罔？需求开发人员能否与客户对有争取的需求迭成共识？需求开发人员能否获福客户对蕭求文档的承荒？保ill客户不肪便变更需求？球台技术 开发能力 色牯设廿 编程、遇试等开发人员是否有开发相规产品