班级管理系统需求规格说明书

班级管理系统需求规格说明书（共7篇）

篇1：班级管理系统需求规格说明书

班级管理系统需求规格说明书

2学生成绩管理

在班级管理系统中，有一个班级学生成绩数据库，是由班级各学生的学生学习成绩组成，它构成了整个班级的学生学习成绩数据库。由于进行了权限设置，学习委员在学生学习成绩管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：学生学习成绩管理；

执行者：学习委员；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）进入学生学习成绩管理界面，显示目前的学生学习成绩数据库中已有的信息；

b)点击班级学生姓名就可以浏览个每个学生的学习成绩，同时也可以对这个内容进行修改；

c）可以增加学生；

d）可以删除选择的学生。

3财务管理

在班级管理系统中，有一个班级财务状况数据库，是由班级财务各明细科目组成，它构成了整个班级的财务状况数据库。由于进行了权限设置，生活委员在财务管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：财务管理；

执行者：生活委员；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）进入财务管理界面，显示目前的财务数据库中已有的财务信息；

b)点击班级财务的各明细科目可以浏览个明细科目的具体内容，同时也可以对这个试题的具体内容进行修改；

c）可以增加科目；

d）可以删除选择的科目。

4学生参加体育活动管理

在班级管理系统中，有一个班级学生参加体育活动情况的数据库，是由班级各学生参加的体育活动情况组成，它构成了整个班级的学生参加体育活动情况数据库。由于进行了权限设置，体育委员在学生参加体育活动管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：学生参加体育活动管理；

执行者：体育委员；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

b）进入学生参加体育活动管理界面，显示目前的学生参加体育活动情况数据库中已有的信息；

b)点击班级学生姓名就可以浏览个每个学生参加的体育活动情况，同时也可以对这个内容进行修改；

c）可以增加学生；

d）可以删除选择的学生

5用户管理 系统管理员可以进行权限设置，在用户管理界面中对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：用户管理；

执行者：系统管理员；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

c）进入用户管理界面，显示目前的系统用户以及每个用户具有的权限；

d）点击不同的用户，可以显示这个用户的信息以及相应权限，必要时可以修改其权限；

可以增加用户，也可以删除用户。

6请假管理

学生将请假条提交之后，教师将审阅请假条，将符合请假条件的请假条进行标记，然后把请假信息传交数据库，学生可以登录查询请假是否成功。具体功能描述如下：

用例描述：请假管理；

执行者：教师；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）进入请假管理界面，显示目前的请假数据库中已有的请假信息；

b)点击班级请假信息中每个同学姓名可以查询各个学生的请假的具体内容，同时也可以对请假具体内容进行修改；

c）可以增加科目；

d）可以删除选择的科目。

7考勤管理

在班级管理系统中，有一个班级学生出勤情况的数据库，及运用学生请假数据库信息，得出的班级各学生的出勤的情况组成，它构成了整个班级的学生出勤情况数据库。由于进行了权限设置，纪律委员在学生考勤管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：考勤管理；

执行者：纪律委员；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）进入学生考勤管理界面，显示目前的学生出勤情况数据库中已有的信息；

b)点击班级学生姓名就可以浏览个每个学生的出勤情况，同时也可以对这个内容进行修改；

c）可以增加学生；

d）可以删除选择的学生。

8学生奖惩管理

在班级管理系统中，有一个班级学生奖惩情况的数据库，是由班级各学生奖惩情况组成，它构成了整个班级的学生奖惩情况数据库。由于进行了权限设置，班长在学生奖惩管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：学生奖惩管理；

执行者：班长；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）进入学生奖惩管理界面，显示目前的学生奖惩情况数据库中已有的信息； b)点击班级学生姓名就可以浏览个每个学生的奖惩情况，同时也可以对这个内容进行修改；

c）可以增加学生；

d）可以删除选择的学生。

9留言管理

在班级管理系统中，有一个留言管理情况的数据库，是由班级各学生和教师留言情况组成，它构成了整个班级的留言管理情况数据库。由于进行了权限设置，班长在留言管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：留言管理；

执行者：班长；

前置条件：：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）查看当前留言情况；

b）对当前留言进行增加、删除、修改、查询；

10学生参加文艺活动管理 学生参加文艺活动情况的数据库，是由班级各学生参加的文艺活动情况组成，它构成了整个班级的学生参加文艺活动情况数据库。由于进行了权限设置，文艺委员在学生参加文艺活动管理模块的用户管理界面中，可以对用户进行增加、删除、修改、查询。具体功能描述如下：

用例描述：学生参加文艺活动管理；

执行者：文艺委员；

前置条件：系统管理员已登录系统；

后置条件：如果用户信息维护完成，则用户的相应信息将记录到数据库中。基本路径：

a）进入学生参加文艺活动管理界面，显示目前的学生参加文艺活动情况数据库中已有的信息；

b)点击班级学生姓名就可以浏览个每个学生参加的文艺活动情况，同时也可以对这个内容进行修改；

c）可以增加学生；

d）可以删除选择的学生。

第一章班级事务管理信息系统的基本需求分析

第一节项目背景分析

随着信息化的来临和计算机在日常管理中的广泛应用，为了实现班务管理的信息化和方便化，便萌发了这次班务管理信息系统的设计构想。

第二节班级事务信息管理的基本需求

1必要的硬件及设备

2系统软件和相应软件包

3培训操作人员和使用人员

4数据的存储准备

5信息的组织和管理功能的划定

第三节班级事务管理信息系统的可行性分析

为了进一步帮助班主任及班干部进行科学有效的学生管理工作，现通过对部分用户的调查了解，对建立班级事务管理信息系统进行了以下几方面的可行性分析：

1．必要性，随着学生招生规模的不断扩大，班主任及班干部的管理工作也日趋复杂化，原来的仅靠手工进行的班级事务管理已日渐显示出其不足之处，那么就有必要建立一套基于计算机的班级事务管理信息系统。

2．可能性，据了解，各个办公室都已具有基本的硬件设备，那么这就为班级事务管理信息系统的实行提供了必要的可能性；加之相关用户都已具备了一定计算机基本操作能力，所以这又为班级事务管理信息系统的实行提供了用户方面的可能性；再从资金成本等方面讲，因为该系统相对而言只是一个小型的管理系统，所需设计人员较少，消耗费用也在用户的承受能力之内。综合上述几方面，班级事务管理信息系统的建立具有很大的可能性。

3．有益性，班级事务管理信息系统一旦建成，那么通过该系统的使用就可以提高信息的使用质量，提高数据的准确性，减轻用户的工作负担和劳动强度，提高用户的信息处理能力，从而进行有效的决策与管理。

总之，通过以上几方面的可行性分析，开发小组认为建立一套班级事务管理信息系统是可行的。我们通过掌握和调查的相关原始资料，就可以通过小组讨论，对该系统的开发做出相关的计划进度，着手进行系统的分析和设计工作。

篇2：班级管理系统需求规格说明书

1.引言 1.1编写目的

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享，提高工作效率。

本文档从用户、功能、性能、运行环境等各方面对系统进行了分析，以确保在系统开发过程中，确定好具体目标，使工作能有条不紊的进行，提高工作效率。

1.2背景

很多学校特别是中等及高等院校中，学生在校住宿的情况极其普遍。随着高校的扩招，需要住宿的学生人数和学生公寓楼房越来越多，宿舍管理人员的需求量也相应地增加。许多高校后勤实施社会化改革，学生住宿条件得到了很大改善，宿舍安排上打破了原来按专业班级强制集中住宿的限制，可供学生选择的余地也越来越大，相关部门对公寓管理的要求越来越高，导致公寓管理的难度越来越大，原来的手工管理已经无法适应，需要用信息化手段来实现。因此，开发一个学生宿舍分配软件是十分必要的，希望能够为广大教师、校院领导、宿舍管理员和学生提供便利，加强学生住宿管理、规范高校公寓日常工作、提高公寓管理效能的有效工具。

1.3 定义

用例图(Use Case)：是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图。呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

顺序图：是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。

类图(Class diagram)：是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息。

状态图(Statechart Diagram)：是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。

活动图（activity diagram）：是阐明了业务用例实现的工作流程。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。

协作图/通信图(Communication Diagram)：而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。

1.4参考资料

（1）殷建民 主编，《软件系统分析与设计》，中国水利水电出版社，2008（2）《学生宿舍基本需求》（3）《2012级软件系统分析与设计实验指导书（16学时宿舍分配系统）》

2．任务概述

2.1 目标

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享

2.2 用户特点

学生：若要住宿需提交住宿申请，然后等待分配。如有特殊要求，务必专门说明。一旦得到批准通知，可以查询个人宿舍安排。住宿后若有特殊原因，可以申请调整宿舍或床位，但依然要经过审核、批准。一旦调换了宿舍，其所使用的设备也要随之变更记录。

教师：分为班主任和辅导员。辅导员负责查看、初审学生提交的住宿申请，对基本符合要求的，转交给宿舍负责人。班主任和辅导员可以随时查看、了解所负责班级住宿学生的情况。

宿舍负责人：负责对住宿申请进行综合审查，通过的则以班为单位分配床位。可以随时查看和了解宿舍的基本情况、所有住宿情况和设备使用情况，对特殊情况及时进行统计，并报送相关领导。学生一旦毕业或提出退宿，其宿舍和床位会立即变空，等待重新分配使用。

宿舍管理员：负责宿舍设备情况的记录（购入登记、各建宿舍配置、损坏和修理登记、报废登记）、每日查房结果记录、学生晚归记录、宿舍具体情况管理（新房间登记、房间撤消、格局调整）。

校院领导：可以随时查看、了解学校和学院宿舍的详细信息、学生住宿状况和宿舍管理员的基本情况以及每日查房的情况。

2.3 假定与约束

经费限制：由于是学习之作，资金的不足限制了本软件的研发。

开发期限;在时间方面，只能在课余时间完成本软件，对时间的安排需做到合理，恰当才能很好的完成本工程。

3.需求分析建模

3.1功能需求

3.1.1系统需求描述

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享。

基本流程图如下:

宿舍学生提交住宿申请返回不同意返回同意结束N查看住宿申请初审Y判断宿舍负责人是否同意NYN复审负宿人责舍教师查看申请Y分配床位领校导院管宿员理舍

3.1.2 总体功能分析

各类角色的大体功能分析：

学生:填写申请表、提交住宿申请、查看申请结果、申请宿舍调整 辅导员:查看学生住宿情况、查看住宿申请、初审、返回申请结果给学生 班主任：查看本班学生住宿情况

宿舍负责人：复审、分配床位、查看住宿信息、宿舍住退更新、特殊情况报送领导 宿舍管理员:宿舍查房记录、宿舍设备情况记录、晚归记录、宿舍集体情况 校院领导：查看宿舍详细信息、查看住宿情况、宿舍管理员情况、每日查房情况 具体用例图如下： 填写申请表查看学生住宿情况提交住宿申请查看住宿申请初审查看申请结果学生辅导员返回申请结果给学生班主任申请宿舍调整复审宿舍查房记录查看宿舍详细信息分配床位宿舍设备情况记录查看住宿情况查看住宿信息晚归记录院校领导宿舍管理员情况宿舍管理员宿舍负责人宿舍住退更新特殊情况报送领导宿舍集体情况每日查房情况3.1.3 功能模块分析(详述 学生申请)☆由学生申请住宿用例：当学生登录后，进入申请界面，填写申请报告，出现两种情况，即填写正确或错误/部分错误，对应的成功提交申请或返回重新填写申请...构建活动图、协作图、顺序图等来完成功能的具体分析。

活动图：

学生登陆进入申请界面填写申请表还有未审核的申请填写正确保存新申请表填写错误返回主界面重新填写提交申请等待申请结果回到主界面

状态图：

学生申请这一事件对应的状态：首先是要进行申请表的填写预准备工作，即新建一张空白申请表，进行填写，完成后进行提交，即等同于进入等待审核状态；等待后台审核完成后，学生进行查看可以找到‘审核通过’‘不通过’以及‘不通过（部分不符合要求）’三种状态，一次审核通过后二审，产生‘批准’‘不批准’两种状态，批准通过，进入入住状态。

新建批准保存已入住审核通过不批准提交审核不通过部分通过顺序图: 根据流程图和活动图，可以建立学生申请的工作顺序图，首先是登陆到首页>进入申请界面，申请表的填写与是否可以成功提交由提交控制检测并返回可申请/不可申请/有错重新填写，提交成功则学生等待来自辅导员以及宿舍管理员的的审核结果以及宿舍分配结果。

学生首页申请界面提交控制辅导员宿舍负责人登陆登陆成功退出不可以申请可以申请填写申请提交给辅导员有错重新填写反馈同意请求复审同意驳回不同意 协作图：

学生功能界面申请表审核控制辅导员返回不同意返回同意及宿舍分配 3.2性能需求

3.2.1精度

在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数据（如申请表，住宿信息等）时，要求输入准确学生姓名，身份证，学号，班级，宿舍号等，按需求设定字符数。

3.2.2时间特性要求

（1）查询类页面响应时间<=3s（2）更新处理时间，如新建、提交等最长时间不超过2s。（3）数据的转换和传送时间，如远程数据传输不超过5s。

3.3数据需求

3.3.1 输入输出数据要求

1）宿舍的详细数据、学生住宿的情况以及宿管人员的具体数据要完整保管，且一旦发生变化，必须及时变更记录。

2）上述数据要能够导出到excel文件中，或从excel文件导入。3）分配床位时可以采取二种方法：

● 第1是按照一定的算法进行自动分配，● 第2是针对特殊要求进行手工分配 4）学生住宿需要记录的内容主要包括：

学号、姓名、所属学院、所属系、宿舍房间号、床铺号、柜子号、入住时间、联系电话等。5）每个房间需要记录的内容主要包括：

宿舍房间号、面积、可容纳人数、目前空床数、6）为简化宿舍分配过程中学生信息的重复录入，保证数据的一致性和统一性，最好可利用现行的学籍管理系统中的信息。

3.3.2数据分析模型(类图)

people-memberName-memberName学生-memberName-memberName职工-memberName-memberName教师-memberName-memberName院校领导-memberName-memberName宿舍负责人-memberName宿舍管理员-memberName-memberName-memberName辅导员-memberName班主任-memberName-memberName-memberNamec各种记录学生住宿信息班级-memberName-memberName-memberName-memberName-memberName-memberName住宿申请-memberName-memberName住宿登记表-memberName-memberName床位-memberName宿舍-memberName-memberName设备-memberName-memberName-memberName

类图分析：用户主要分为学生和职工两大类，学生类和职工类继承于people类，而教师类、领导类、宿舍负责人类和宿舍管理员类继承于职工类，辅导员和班主任类继承于教师类；学生与辅导员、班级、住宿登记表、床位、宿舍、住宿申请等都是关联关系。

3.4故障处理要求

正常使用时不应出错，对于用户的输入错误应给出适当的改正提示。若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损，可以通过日志来了解故障现象、发生时间。

3.5其他专门要求

（1）进度需求：系统开发的阶段进度要求。（2）运行环境需求：平台、体系结构、设备要求。

（3）培训需求：无实体培训，系统配备《用户使用手册》，提供多媒体教学光盘。

4.运行环境规定 4.1设备

服务器

PC机（建议配置：操作系统 windows 2000/XP/Vista CPU PentiumⅣ以上 内存 128M以上 硬盘空间 100M以上）DVD光驱，打印机等。

4.2支持软件

软件运行基于windows平台上的2000，NT，XP,Vista等。数据库：MySQL 4.3接口

篇3：班级管理系统需求规格说明书

在软件系统开发过程中,形式化方法[1](Formal Methods)是基于数学方法来描述目标软件系统的一种方法。它借助于数学模型和计算,用具有精确语义的形式化语言对目标系统进行定义和描述,为系统的说明、开发和验证提供一个科学的框架,帮助设计者正确而深刻地理解系统,及时发现设计中的错误和缺陷。

Z语言[2]是一种形式规格说明语言,它采用严格的数学表示,对目标系统进行精确、无歧义的规格说明,是一种具有“状态-操作”风格的形式化说明语言。

当前形式化方法在计算机控制、信息安全等软件开发领域已逐步得到应用,但在教育系统的应用几乎是个空白。我国高校教育改革的关键是学分制改革,但目前已有的排课系统大都基于学年制,且没有运用形式化方法建立一个精确、完善的数学模型。排课问题是一个非常复杂的NP完全类问题,对它的研究,国内外一直都很活跃。本文以一个基于学分制的排课系统(Class Scheduling System,CSS系统)为例,运用Z语言形式化定义和构建这样一个系统模型,这将具有非常现实的指导意义。

1问题的提出

CSS系统是高等院校使用的、用于生成专业院系课程表(Class Schedule)的、基于学分制的排课系统。由于学分制方式不针对班级授课,故而首先由专业院系提供课程信息给教务处(课程信息包括课程名称、教师姓名、学时数、要求学生人数等),然后教务处结合课程信息和教室信息(包括教室编号、容纳人数、设备等)编排出合理的课程时间表,在网上公布给学生,由学生根据自己的情况进行自由选课。图1是CSS系统的UML Use Case图[3],它表明了该系统的用户以及使用权限。除管理员(Scheduling Manager)外,其他用户都只能基于Web进行访问。

CSS系统必须避免基本的冲突,如教师冲突(一个教师不能同时上两门课)、教室冲突(一个教室不能同时安排两门课)、必修课冲突(同一学期2门必修课的上课时间不能重叠)、教室特征冲突(教室的容量必须与要求的人数匹配等)等。

2数据模型

Z语言基于一阶谓词逻辑和集合论,通过定义一系列模式来描述对象或操作,并用谓词判定描述给出新的对象或操作。一个目标软件系统的结构和行为特征可以通过模式,以及对模式进行演算来加以抽象的描述[4,5]。

2.1 基本实体的模式定义

CSS系统包括4个基本的实体对象:DayBeginDuration(上课时间区间);Instructor(教师);Room(教室);EventOffer(课程信息)。要定义它们的Z模式,首先由声明section开始:

section basis

接着,需要定义基本的数据类型:DAY (星期几)、RANK (教师级别)、Research_Group (教研室)、ROOM_FEATURE (教室特征)、EVENT_TYPE (课程类型)等:

DAY ::= Mo | Tu | We | Th | Fr | Sa | Su

RANK ::= Prof | Lecturer | Assistant

RESEARCH_GROUP::=ST |DB |AS |ML |CG

ROOM_FEATURE ::= Multimedia | ComputerPool

EVENT_TYPE ::=RequiredClass |SelectiveClass |Lab

之后,是这4个实体的Z模式定义:

DayBeginDuration

Day:DAY

Begin:(8..17)13}

Duration:N

Day≠Sa∧Day≠Su

Begin<13⇒Begin+Duration≤13

Begin<13⇒Begin+Duration≤18

Duration≥1

Instructor

Name:TEXT

Rank:RANK

Group:RESEARCH_GROUP

Room

Capacity:N

Features:P ROOM_FEATURE

Capacity≥3

EventOffer

Instructor:P Instructor

Title:TEXT

Type:EVENT_ FEATURE

ExpectedAttendants:N

PreferredDayBeginDuration:P (P DayBeginDuration )

Instructors≠ϕ

PreferredDayBeginDurations≠ϕ

∧PreferredDayBeginDurations≠{ϕ}

ExpectedAttendant≥3

∀x,y:PreferredDayBeginDurations?

#(TimeFramex)=#(TimeFramey)

∀d:PreferredDayBeginDurations?∀x,y:d?x≠y

⇒x.Day≠y.Day

需要说明的是:上述定义中,模式EventOffer引入了一个辅助函数TimeFrame,它用于表达一个包含在给定的DayBeginDuration内时间的集合。

TimeFrame:PDayBeginDuration→P(DAY×N)

2.2 关系的定义

根据前面定义的Z模式,通过对这些模式的演算可以描述一些新的对象,比如,

(1) PreferredDayBeginDuration:

表示一门课程的DayBeginDurations的集合,通常一门课不应在同一天安排两次。

(2) EventAssignment:

是课程(EventOffer)、上课时间(PreferredDayBeginDuration)、上课教室(Rooms)的集合。

这部分的Z规格说明描述了基本实体之间的关系,是一个新的Section。

Section relation Parents basis

PreferredDayBeginDuration= =P DayBeginDuration

EventAssignment=={ea:EventOfferID×PDayBeginDuration

×seqRoomID|∃eoid:EventOfferID?∃S:PDayBegin

Duration?∃ridS:seqRoomID?((eoid,S,rids)=ea)

∧(#S=#ridS)}

与此同时,还通过给EventOffer对象、Room对象分配ID来建立它们的table,进而得到课表ClassSchedule的table。

EventOfferTable==EventOfferID↔EventOffer

RoomTable==RoomID↔Room

ClassSchedule==EventOfferID↔P(DayBeginDuration×RoomID)

2.3 课表ClassSchedule的定义

通常,一个合理的课表需要满足很多约束。给定一个EventOffer表和Room表,定义函数ClassSchedules来计算合理的EventOffer-Room(课程-教室)配对。

Section classSchedules Parents relation

ClassSchedules:EventOfferTable×RoonTable→

P ClassSchedule

∀eo:EventOfferTable;r:RoomTable?

ClassSchedules(eo,r)={s:ClassSchedules|dom

s=dom eo∧(∀ eoid:dom s?∃dbd:(eo eoid),

PreferredDayDuration?({x:s eoid?first x}

=dbd)∧(∀x:s eoid?second x∈dom r))}

此外,可再定义一个InstructorsSchedule函数来计算“课程-课表-教师”配对,方法相同。

InstructorsSchedule:EventOfferTable×

ClassSchedule×Instructor→P

(EventOfferID×DayBeginDuration)

3状态和操作的Z规格说明

3.1 系统状态

该CSS系统的状态包括:课程表eventOfferTable、教室信息表roomTable、生成课表classScheduleTable、课表是否生成标识classScheduleTableInit。在此,状态标志位类型INIT表示课表是否有效生成。

Section stateV1 parents classSchedule

INIT::=Valid|Invalid

eventOfferTable:EventOfferTable

roomTable:RoomTable

classScheduleTable:ClassScheduleTable

classScheduleTableInit:INIT

3.2 操作

系统管理员对CSS系统的操作包括:添加、删除、修改教室信息和课程信息。由下述语句声明:

Section operationsV1 parents stateV1

对教室的操作即AddRoom,DeleteRoom和UpdateRoom,对课程的操作即AddEventOffer,DeleteEventOffer和UpdateEventOffer。

AddRoom

ΔClassSchedulingSystem

r?:Room

∃rid:RoomID?(rid∉dom roomTable)

∧(roomTable′∪{rid→r?})

eventOfferTable′=eventOfferTable

classScheduleTable′=ϕ

classScheduleTableInit=Invalid

DeleteRoom

ΔClassSchedulingSystem

r?:RoomID

rid?∈dom roomTable

roomTable′=roomTablerid→roomTable rid?}

eventOfferTable′=eventOfferTable

classScheduleTable′=ϕ

classScheduleTableInit=Invalid

UpdateRoom操作和DeleteRoom同理。

这里,对EventOffer的操作说明类似于Rooms,在此就不再赘述。

3.3 冲突

对于生成的课表,可能包括的冲突有教师冲突、教室冲突、必修课冲突、教室特征冲突等。计算冲突的基本思想就是计算满足冲突发生条件的元组的个数。

当课表中要求一个教师在同一时间上两堂课时,就发生了教师冲突。为此,定义函数InstructorConflicts来计算教师冲突。

Section conflicts1 parents classSchedule

InstructorConflicts:

ClassSchedule×EventOfferTable→N

∀s:ClassSchedule;eo:EventOfferTable?

InstructorConflicts(s,eo)=

#{eoid1:doms;eoid2:doms;i:Instructor|

eoid1≠eoid2

∧i∈(eo eoid1).Instructors

∧i∈(eo eoid2).Instructors

∧TimeFrame{sid:s eoid1 firstsid}

∩TimeFrame{sid:s eoid2 firstsid}≠ϕ}

div2

同样地,当一个课程要求的教室特征不是所分配教室的特征的子集,或期望的学生人数大于所分配教室的容量时,一个教室特征冲突就发生了。定义函数RoomFeatureConflicts来计算教室特征冲突。

定义函数RoomConflicts,RequiredClassConflicts来分别计算教室冲突和必修课冲突,它们在section conflicts2中被声明。在此不再一一描述。

3.4 计划排序算法

一个排出的课表可能同时发生几个冲突,不同的课表也可能有着不同的冲突。要判定一个课表是否比另一个课表“好”,就要对这些冲突进行排序。系统对每种冲突的高低顺序是事先计划并定义好的。

Section conflicts1 parents conflicts2

ConflictTuple==(N×N×N×N)

conflicts:ClassSchedule×

EventOfferTable×RoomTable

→ConflictTuple

∀s:ClassSchedule;eo:EventOfferTable;

r:RoomTable?Conflicts(s,eo,r)

=(RequiredClassConflicts(s,eo),

RoomConflicts(s,r),InstructorConflicts(s,eo),

RoomFeatureConflicts(s,eo,r))

relation(_lessConflicts_)

_lessConflicts_:ConflictTuple↔ConflictTuple

∀a,b,c,d,a′,b′,c′,d′:N?

(a,b,c,d)lessConflicts(a′,b′,c′,d′)⇔

a<a′∨(a=a′∧(b<b′∨(b=

b′∧(c<c′∨(c=c′∧d≤d′)))))

在Conflicts(s,eo,r)中,定义了冲突由高到低的次序为:RequiredClassConflicts,RoomConflicts,InstructorConflicts,RoomFeatureConflicts,也可以根据需要定义其他的顺序。

3.5 系统状态和操作的细化

创建课表是一个很耗时的过程,必须设定一些全局参数进行控制。当运行CSS系统后,生成的课表通常都有冲突存在,这就需要检查基本数据是否合理配对。要解决一个冲突,比如通过与任课教师协商,改变其课程信息,这样课表classScheduleTable就可重新生成。

为了实现上述过程,对原状态空间模型进行了细化。首先,引入全局参数maxVersions和maxConflicts,其值可由系统管理员设定。其次,引入一个指针actVersion指向管理员当前正操作的可能在界面上显示的那个课表。下面给出了一个细化的state-space模型:

Section stateV2 parents planner

ClassSchedulingSystem

eventOfferTable:EventOfferTable

classScheduleTable:ClassScheduleID→

ClassSchedule

classScheduleTableInit:INIT

actVersion:ClassScheduleID

maxVersion:N

maxConflicts:ConflictTuple

对于一个给定的eventOffer,给出创建课表的操作CreateClassSchedules:

CreateClassSchedules

ΔClassSchedulingSystem

coid?:PEventOfferID

∃sol:ClassScheduleID→ClassSchedules(

eoid?△eventOfferTable,roomTable)

∃hit:Hitlists(eoid?△eventOfferTable,

roomTable,maxConflicts,maxVersions)

ran sol=ran hit∧

classScheduleTable′=sol∧

classScheduleTable′actVersion=hit(1)

classScheduleTableInit′=Valid

eventOfferTable′=eventOfferTable

roomTable′=roomTable

maxVersions′=maxVersions

maxConflicts′=maxConflicts

课表生成后,要解决发生的冲突,如删去一个指定的eventOffer,定义了RemoveEventsFromClassSchedules操作;增加一个eventOffer,定义操作AddEventsInClassSchedule。

至此,整个CSS系统的形式化规格描述就完成了。

4结语

用Z语言对目标系统进行形式化规格说明,不仅可以精确地对系统进行描述,消除自然语言描述的二义性,而且有利于将来对系统进行更加严格的测试,提高了系统设计和开发的质量。本文通过对一个学分制下排课系统的Z规格说明,建立了该系统精确的数学模型,也表明了形式化方法用于对一个NP完全类问题的复杂排课系统的建模是一种十分有效的方法。

参考文献

[1]GUPTA R,GUERNIC P L,SHUKLA S K.Formal me-thods and models for system design:a system level perspec-tive[M].[S.l.]:Springer,2001.

[2]JACKY Jonathan.The way of Z:practical programmingwith formal methods[M].UK:Cambridge UniversityPress,1996.

[3]BOOCH Grady,RUMBAUGH James,JACOBSON Ivar.The unified modeling language user guide[M].[S.l.]:Addison-Wesley,1999.

[4]JIM Woodcock,JIM Davies.Using Z:specification,refine-ment,and proof[M].[S.l.]:Prentice-HallInternational,1996.

[5]SPIVEY J M.The Z notation:a reference manual[M].2nd ed.[S.l.]:Prentice-Hall,1997.

[6]王长元,赵莉,王淑蓉.软件工程与建模[M].西安:西安交通大学出版社,2010.

[7]郭广义,李代平,梅小虎.Z语言与软件体系结构风格的形式化[J].计算机技术与发展,2009(5):9-12.

[8]王永伟.基于构件的形式化方法在软件开发中的应用研究[D].哈尔滨:哈尔滨工程大学,2010.

[9]邢小英,王维维.两次数据精化的形式化软件开发方法[J].计算机工程,2006(1):23-25.

篇4：机票订票系统需求规格说明书

三、需求规格说明书

1．引言................21.1编写目的...............2

1.2项目背景...............2

1.3参考资料...............2

2．任务概述...................2

2.1目标...................2

2.2运行环境...............2

2.3条件与限制.............2

3．数据描述...................33.1静态数据...............3

3.2动态数据...............3

3.3数据库介绍.............3

3.4数据词典...............3

4．功能需求...................44.1功能描述...............4

5． 性能需求..................55.1系统处理的准确性和及时性.............5

5.2系统的开放性和系统的可扩充性................5

5.3系统的易用性和易维护性...............5

5.4系统的标准性...........5

5.5系统的先进性...........6

6． 运行需求..................6

7．其它需求...................6

第 1 页

1．引言

1.1编写目的本机票预定系统在可行性研究的基础上，是为了进一步明确机票预订系统的软件需求，以便安排项目规划和进度，组织软件开发与测试，撰写本文档。

本文档供设计人员、开发人员参考。

1.2项目背景

开发软件名称：机票预订系统

项目任务提出者：兰州理工大学软件工程学院 项目开发者：第13小组 用户：航空公司

实现软件单位：兰州理工大学软件工程学院

1.3参考资料

1.《软件工程导论》，张海藩，清华大学出版社。2.《实用软件工程》，郑人杰等，清华大学出版社。3.机票预定系统项目计划任务书。4.机票预订系统可行性研究报告。

2．任务概述

2.1目标

旅客在飞机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打印出机票给旅客。此外航空公司为随时掌握各个航班飞机的乘载情况，需要定期进行查询统计，以便适当调整。

2.2运行环境

操作系统：Microsoft Windows 7 支持环境：IIS 5.0

数 据 库：Microsoft SQL Server 2000

2.3条件与限制

1.人力、资金、时间的约束

机票预订系统实施的目标就是要带给轮胎生产公司看得出见的效益，其开发过程中也要考虑到人力、资金和时间的约束。因此，在设计中，重点是企业间信息的网络交流，能提供各部门间的方便快捷的联系，并提高数据统计的即时性、准确性、方便性，给公司带来良好的效益。

2.在分析系统功能时要考虑有关证件的合法性验证。

3．数据描述

3.1静态数据

系统管理员，售票员，服务器终端显示数据，客户机终端显示数据，客户机终端显示数据。

3.2动态数据

事务航班信息的更新，查询请求。

3.3数据库介绍

数据库采用sql server。

3.4数据词典

名字：订票申请表单 描述：旅客订票时所填的资料

定义：订票申请表单=旅客姓名+旅客性别+起飞日期+飞行目的地+座位类型位置：在客户端由旅客填写 名字：航班信息

描述：所有从本地起飞的班机信息

定义：航班信息=航班号+起飞日期+飞行目的地+座位空数+商务仓票价+经济仓票价 位置：从服务器端查询后，发送到客户端 名字：帐单信息

描述：已定票的旅客信息资料

定义：帐单信息=帐单号+旅客姓名+旅客性别+旅客身份证号+工作单位

位置：在服务器端产生，发送回客户端（client端）名字：机票信息 描述：旅客所定机票

定义：机票信息=旅客姓名+旅客性别+身份证号码+航班号+起飞时间+飞行目的地+座位号

4．功能需求

4.1功能描述

5．性能需求

5.1系统处理的准确性和及时性

系统处理的准确性和及时性是系统的必要性能。在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足企业对信息处理的需求。在系统开发过程中，必须采用一定的方法保证系统的准确性。

5.2系统的开放性和系统的可扩充性

机票预订系统在开发过程中，应该充分考虑以后的可扩充性。例如企业中管理模块的加入（人事管理、工资管理、日常事务管理等）也会不断的更新和完善。所有这些，都要求系统提供足够的手段进行功能的调整和扩充为ERP系统。而要实现这一点，应通过系统的开放性来完成，即系统应是一个开放系统，只要符合一定的规范，可以简单的加入和减少系统的模块，配置系统的硬件。通过软件的修补、替换完成系统的升级和更新换代。

5.3系统的易用性和易维护性

机票预订系统是直接面对使用人员的，而使用人员往往对计算机并不时非常熟悉。这就要求系统能够提供良好的用户接口，易用的人机交互界面。要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。

5.4系统的标准性

系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。所有这些都要符合主流国际、国家和行业标准。例如在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准。如规范的数据库操纵界面、作为业界标准的TCP/IP网络协议及ISO9002标准所要求的质量规范等；同时，在自主开发本系统时，要进行良好的设计工作，制订行之有效的软件工程规范，保证代码的易读性、可操作性和可移植性。

5.5系统的先进性

目前计算机系统的技术发展相当快，做为机票预订系统工程，应该保证系统在一段时间内是先进的，在系统的生命周期尽量做到系统的先进，充分完成企业信息处理的要求而不至于落后。这一方面通过系统的开放性和可扩充性，不断改善系统的功能完成。另一方面，在系统设计和开发的过程中，应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。

6．运行需求

1、服务器端子系统的运行要求：系统软件：windows 7数据库管理系统：SQL server

硬件要求：英特尔至强 2.0Ghz、1G RAM、100G HD2、客户端子系统的运行要求：系统软件： Windows 7 数据库管理系统：SQL server

硬件要求：CPU：英特尔奔腾III 1.0Ghz、256M RAM、10G以上可用空间

7．其它需求

篇5：图书馆管理系统需求规格说明书

图书馆管理系统需求规格说明书

1．导言 1.1编写目的

图书管理信息系统的前阶段，对本系统的需求做了详细的阐述，并提出了这份软件需求规格说明书。

此需求规格说明书对图书管理信息系统软件做了全面细致的用户需求分析，明确所要开发的软件应具有的数据库、功能、性能等，使系统分析人员及软件开发人员都能清楚地了解用户的需求，并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。本说明书的预期读者为用户、需求分析人员、代码编写人员、测试人员、用户文档编写者、项目管理人员。

在下一段的设计中，程序设计员可参考此需求分析规格说明书，在需求分析说明书对图书馆管理信息系统所做的模块结构设计的基础上进行详细设计。在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改或发现错误时找出在本阶段的不足或错误。1.2项目背景

由于图书馆书籍多，查找、增加、借阅、归还极为不便，要浪费许多的人力、脑力、物力。图书的管理不当会严重导致图书馆书籍的遗失等问题。于是我们希望能找到解决的方法。

为了解决以上的问题，让图书馆能够有效的管理图书馆书籍，有效的利用软件的便捷，保护好书籍，促进图书馆管理的信息化和规范化。我们多方听取意见、分组讨论、查阅资料，进而了解图书馆管理的流程，开发出一套适合于图书馆书籍多而复杂的管理系统。1.3缩写说明

系统：若未特别指出，统指本图书信息管理系统。SQL：Structured Query Language（结构化查询语言）。

1.4术语定义SQL SERVER：系统服务器所使用的数据库管理系统（DBMS）。

SQL：一种用于访问查询数据库的语言。主键：数据库表中与其他表主键关联的域。外部主键：数据库表中的关联域。值互不相同。

需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。

软件需求规格说明书

1.5参考资料

《软件工程实务》罗先文、徐军，重庆大学出版社，2005年3月

《UML 用例驱动对象建模》Doug Rosenberg、Kendall Scott著，徐海、周靖、陈华伟译，清华大学出版社，2003年5月

《UML 系统分析设计应用案例》 冀振燕，人民邮电出版社，2003年6月 《NET语言程序设计》 陈炜，人民邮电出版社，2005年1月 《SQL Server数据库》吕凤顺，清华大学出版社，2006年9月 《网页设计与制作》于巧娥、何金奎，北京大学出版社，2006年1月 2．任务概述 2.1系统定义

实现图书管理信息系统的基本需求。让图书馆能够有效的管理图书的查询、借阅、增加、归还等操作，保护好文件，促进图书管理的信息化、规范化，实现图书馆的智能化管理，以提高图书馆的的工作效率。2.2应用环境

硬件环境：一台586 以上的微机及兼容内存16MB（最好32MB内存）

软件环境：windows 98 以上的操作系统 ；Office 2000应用软件 操作系统：Microsoft Windows 2000 Advanced Server 支持环境：IIS 5.0 数 据 库：Microsoft SQL Server 2000 2.3假定条件与限制

本图书管理信息系统软件是应用于中小型的图书馆。在功能上还不是很健全，还需要进一步完善，还可进一步实现与E-Mail和Internet电话连接起来，成为网络图书管理信息系统软件。3．需求规定 3.1对功能的规定

(1)图书信息表(book)：数据结构（自动编号ID,图书编号（BookID），书号（ISBN），价格（Price），类别名（Kind），图书名（BookName），出版社（Publish），借出日期（BorrowDate），是否借出（IsBorrowed））

(2)借出图书信息表（bookoff）：数据结构(自动编号ID,借书证号（LoanNum），姓名（Name），图书编号（BookID），书名（BookName），价格（Price），类别（Kind），出版社（Publish），借出日期（BorowDate）)

软件需求规格说明书

(3)管理员信息表（Librarian）：数据结构（自动编号ID,名称（LibName），密码（Password））

(4)读者信息表（personal）：数据结构（自动编号ID,读者编号（ReaderNum），借书证号（BorrowNum），姓名（Name），班级(Class)，部门(Depart)，职称(Tittle)，罚款（Fine））

(5)图书类型信息表(type)： 数据结构（自动编号ID，类别名(Kind)，借出天数(BorrowedDay)）3.2对性能的定义 3.2.1 精度

（1）要按照严格的数据格式输入，否则系统不给予响应进行处理。

（2）查询时要保证查全率，所有相应域包含查询关键字的记录都应能查到。（3）添加记录时必须写入正确的记录字段。3.2.2时间特性要求

一般操作的响应时间应在1~2秒内，对软磁盘和打印机等的操作也应在可接受的时间内完成。3.2.3灵活性说明

满足图书馆使用的需求（记录量控制在100项内）；对前面提到的运行环境要求不应存在困难。3.3输入输出的要求

输入数据：菜单选项，查找关键字，新建记录项。

输出数据：由查询关键字确定的数据库记录集合。（1）系统管理

1)用户登录：用于管理员或读者登录，进行图书馆书籍及资料的查询。2)用户注册：用于用户及管理员的注册，当数据库中有了用户资料之后此用户才有权限登录系统。

3)修改密码:只限于已经注册的用户或管理员的操作。以便于个人登录的识别。

（2）图书管理

1)图书的分类：主要是适合于管理员的操作，对图书进行分类以便读者查询、借阅书籍。

2)查询书籍：主要给借阅者使用，是为了方便借阅者查询自己想要的图书，

软件需求规格说明书

借阅者输入图书的相关关键字，按下按钮即可查询到于此相关的书籍。

3)图书的添加：是给管理员用的功能，如有新增书籍，可通过这项功能，在数据库中添加一项纪录，让读者预留、借阅等。

4)图书的删除：是给管理员用的功能，当图书馆没有此书籍时，在数据库中删除此图书的信息。（3）借书证管理

1)借书证的添加:仅图书管理员可以使用的功能，在数据库中添加读者的借书证信息，方便读者借阅图书。

2)借书证信息的修改：修改读者的图书证信息记录

3)借书证的删除：删除读者的图书证信息记录

4)借书证的借书上限和逾期罚金： 根据等级或其他信息规定该读者最多能借阅几本书籍，归还书籍时如果超过期限，规定超过一天罚多少钱（4）借书和还书操作管理

1)借书操作：用户借书后在借出图书信息表中添加用户信息及书籍信息等 2)还书操作：用户归还书籍后在表中删除借出信息便于他人借阅。3)续借操作：当用户图书到期后，如需再借阅则可使用此功能。（5）打印报表

1)打印单条图书记录:主要适用于一般浏览者和一般用户。他们只能打印在他们的权限和级别范围内所能查看的图书馆信息资料。

2)打印全部档案:是为管理员设置的，管理员可以根据需要设置打印。也可以让档案以报表或其它形式生成文本文件或HTML文件输出。打印操作人员的信息只限管理员使用。

3.4数据管理能力的需求（五个基本数据表单）

图书信息表(book)借出图书信息表（bookoff）图书编号 BookID 借书证号 BorrowNum 书号 ISBN 图书编号 BookID 价格 Price 借出日期 BorowDate 类别名 Kind 是否借出 IsBorrowed 图书名 BookName 出版社 Publish 数量 Amount 作者 Author

读者信息表（personal）管理员信息表（Librarian）姓名 ReaderName 名称 LibName

软件需求规格说明书

密码 Password 密码 Password 班级 Class 部门 Depart 图书类型信息表(type)职称 Tittle 图书编号 BookID 借书证号 BorrowNum 类别名 Kind 罚款 Fine 借出天数 BorrowedDay 3.5故障处理要求

正常使用时不应出错，若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损。调试中遇到的问题及解决的方案：

（1）遇到跳出“数据库已经关闭”提示信息阻止程序运行时：可以查看一下进行此项操作时，操作的表是否已经被关闭了或者是在没有关闭此表的情况下又一次运用打开语句打开此表。

（2）关于空记录带来的麻烦：有些空记录往往会使程序无法运行。此时你可用“if not isnull”语句先判断一下是否为空记录，再操作。（3）有些运行错误也可用如下语句排除 On Error GoTo Erropoint

Erropoint :

Msgbox Err.Descripton

Exit sub

或用On Error resume Ｎext 等语句进行处理。3.6其他要求

（1）系统的功能实现情况: 用户可在本系统下实现各种用户要求的功能（2）系统的安全性: 对于系统的重要数据都有密码保护，具有一定的安全性（3）系统的容错性: 用户输错数据都有提示信息，具有较好的容错性能。（4）系统的封闭性: 用户的封闭性较好，用户基本上在提示信息下输数据 4．运行环境规定 4.1设备

本软件不需要特定的硬件或硬件接口进行支撑；486以上PC机均可运行此软件。4.2支持软件

运行于Windows95及更高版本具有WIN32 API的操作系统之上。开发软件：Dreamweaver、SQL Server、Microsoft web developer 4.3双方签字

软件需求规格说明书

篇6：班级管理系统需求规格说明书

1引言

1.1编写目的

此需求规格说明书对项目的背景、范围、验收标准和需求等信息进行说明，包括功能性需求和非功能性需求，确保对用户需求的理解一致。

预期的读者有(甲方)的需求提供者、项目负责人、相关技术人员等，北京亚思晟商务科技有限公司(乙方)的项目组成员，包括项目经理、客户经理、分析设计开发测试等人员。

1.2背景

ERP系统是基于互联网的应用软件，为东北某城市一大型工业生产企业提供的全面企业管理解决方案。其功能涵盖了从采购、销售、生产、质量、人事、考勤、财务、档案、设备、新品、基础数据等模块。此处将与生产相关的模块功能做详细介绍。

1.3定义  成品入库分为两种：一种为生产中的成品入库，另一种为采购中的成品入库  凡是出库需判断现有库存量，有审核的需审核后才能确认出库

 半成品库中，材料名称指的是原材料库中“材质”，材质+规格可唯一判定该材料  材料进厂指的是：“原材料在外加工后形成的半成品”进厂入库

 转序卡中的数量指的是：根据材料而得出投放数量，一批材料可对应多个转序卡  转序卡中的成品入库数量：指的是投放后该产品的实际入库数量。当第一张转序的剩余数量为零时，入库的产品数量转入下一张转序卡；

 转序卡中的报废数量指的是：投放后该产品的实际报废或核销数量。当第一张转序的剩余数量为零时，报废或核销的产品数量转入下一张转序卡；  每张转序卡中的剩余数量=投放数量-入库数量-报废或核销数量  材料请领是有计划的一个投放

 成品库中的零件号与其总承号同义，半成品库中分为零件总承号、零件号  返修品出库与入库要有对应关系，一次出库可能多次入库，总数量有对应关系  废品是有原因的报废，需追究相关责任人；核销是定期有针对性、有正当原因的处理。核销必须有申请与审核，原因如锈蚀，产品件下线等多种

 实现盘点：只要点击盘点，所有库房同时冻结，然后所有库房的期末数都冻结，时间点之后的所有单子不参加逻辑运算；然后生成一个所有库房的期末数的盘点单，也就是期末数的汇总报表，然后打印。用账面的期末数（也就是盘点时的期末数）到各个库房对实物数量进行核对，核对后出盘盈盘亏，查出原因及调整库存数量后，才可以重新解冻，进行之后所有入出单子的逻辑运算  所有的成品不一定都有半成品  一个零件名称可能有多个零件号  盘盈数量加上现有库存修改库存数量

 现有库存减去盘亏数量修改库存数量

1.4参考资料

ERP系统理论和实践

2任务概述

2.1目标

本ERP系统是基于互联网的应用软件，通过此系统可以实现采购、销售、生产、质量、人事、考勤、财务、档案、设备、新品管理等核心业务，实现企业各部门工作流程的优化重组，超越时间、空间和部门分隔的限制，建成一个精简、高效、廉洁、公平的运作模式，以便全方位地实现企业优质、规范、透明、符合国际水准的管理。该软件系统是一项独立的软件，整个项目外包给北京亚思晟商务科技有限公司来开发维护。

2.2用户的特点

本软件的最终用户为企业内的日常使用者，操作人员和维护人员有较高的教育水平和技术专长，同时使用的用户数量初步估计为100人。

2.3假定和约束

假定此系统为自包含的，不过分依赖其它外部系统。本项目的开发期限为6个月。

3需求规定 3.1对功能的规定

整体功能用例图（Use-Case Diagram）：

4.用例规格

4.1公共信息管理用例描述：

（1）角色：系统管理员（2）前提条件：登录（3）主事件流

1.点击进入公共信息管理模块 2.点击部门维护（S1）

3.点击员工基本信息（S2）（4）分支事件流

S1: 部门维护（E1）1.添加部门 2.修改部门 3.删除部门

4.返回部门列表页面 S2: 员工基本信息(E2)1.添加员工基本信息 2.修改员工基本信息 3.删除员工基本信息 4.返回员工列表页面（5）异常事件流

E1: 无法添加、修改、删除部门 E2: 无法添加、修改、删除员工

4.1.1用户界面

进入界面：单击左侧菜单栏中的公共信息管理，打开后选中部门维护单击，进入部门维护界面，如下图4.1.1.1

（图4.1.1.1）

选中左侧树图中的结点：如总部，单击“添加部门”按钮，将生成新的编号，在下

面各输入框内输入相应信息，如下图（图4.1.1.2）

（图4.1.1.2）

点击添加按钮，将在选中的部门下生成新的子部门。操作成功的界面如下图（图9.1.13）

（图4.1.1.3）

注意：类别应添2、3等，指的是所在树形结构中的级别。如2为在总部下

选中左侧树图中的部门（如总部），单击“操作”按钮，可在右侧修改或删除此部门信息,如下图（图4.1.1.4）

(图4.1.1.4)

修改或删除成功后如下图(图4.1.1.5)5

(图4.1.1.5)

4.1.2用户界面

点击左侧“公共信息管理”，打开菜单后单击“员工基本信息”，如下图（图4.1.2.1）

（图4.1.2.1）

选中员工所在的“部门”，在输入框内输入员工姓名后单击保存按钮。如下图（图4.1.2.2）

（图4.1.2.2）

保存成功后的界面如下图（图4.1.2.3）

（图4.1.2.3）

4.2基础信息管理用例描述：

（1）角色：库房管理员（2）前提条件：登录（3）主事件流

1.点击进入基本信息管理模块

2.点击半成品库（S1）3.点击成品库（S2）4．点击原材料库（S3）5.点击辅助材料库（S4）

6．点击标准价库（S5）7.点击工具库（S6）8.点击工装备件库（S7）9.点击工序基础信息（S8）10.点击定额基础信息（S9）4）分支事件流

S1: 半成品库（E1）1.添加半成品库 2.修改半成品库 3.删除半成品库

4.返回半成品库列表页面 S2: 成品库（E2）1.添加成品库 2.修改成品库 3.删除成品库

4.返回成品库列表页面 S3: 原材料库（E3）1.添加原材料库 2.修改原材料库 3.删除原材料库

4.返回原材料库列表页面 S4: 辅助材料库（E4）1.添加辅助材料库 2.修改辅助材料库 3.删除辅助材料库

4.返回辅助材料库列表信息 S5: 标准件库（E5）1.添加标准件库 2.修改标准件库 3.删除标准件库

4.返回标准件库列表信息 S6: 工具库（E6）1.添加工具库 2.修改工具库 3.删除工具库

4.返回工具库列表信息 S7: 工装备件库（E7）1.添加工装备件库 2.修改工装备件库 3.删除工装备件库

4.返回工装备件库列表信息S8: 工序基础信息（E8）1.添加工序基础信息 2.修改工序基础信息（3.删除工序基础信息 4.返回工序列表页面 S9: 定额基础信息（E9）1.添加定额基础信息 2.修改定额基础信息 3.删除定额基础信息 4.返回定额列表页面（5）异常事件流

E1: 无法添加、修改、删除半成品库 E2: 无法添加、修改、删除成品库 E3: 无法添加、修改、删除原材料库 E4: 无法添加、修改、删除辅助材料库 E5: 无法添加、修改、删除标准件库 E6: 无法添加、修改、删除工具库 E7: 无法添加、修改、删除工装备件库 E8: 无法添加、修改、删除工序基础信息 E9: 无法添加、修改、删除定额基础信息

4.2.1用户界面

单击左侧“基础信息管理”菜单，找到“半成品库”，单击后进入“半成品库”维护，如下图（4.2.1.1）

（图4.2.1.1）

单击添加按钮，进入添加新半成品的界面，如下图（图4.2.1.2）

（图4.2.1.2）

首先选中公司，根据公司选中零件总承号，添加上对应的各项基本信息，如下图（图4.2.1.3）说明：公司名称与零件总承号可在基础信息管理的“成品库”中先维护，详见4.2.2

（图4.2.1.3）

单击添加，正确添加后，则在提示处显示为“1”，如下图（图4.2.1.4）

（图4.2.1.4）

单击返回，返回到“半成品库”主界面

单击主界面的查看按钮，可查看当前记录的详细信息，同时也可修改当前记录。单击主界面的新增厂家，打开添加后，公司名称不可改变，新增半成品信息

单击主界面的新增零件，打开添加后，公司名称与零件总承号不可改变，在此基础上添加新的半成品信息，操作界面同“添加”

选中主界面的复选框后，单击删除按钮，可直接删除选中的记录

4.2.2用户界面

单击左侧“基础信息管理”中的“成品库”，进入成品库管理界面，如下图（图4.2.2.1）

（图4.2.2.1）

选中复选框，单击删除按钮，如下图（图4.2.2.2）

（图4.2.2.2）

删除成功后，界面如下图（图4.2.2.3）

（图4.2.2.3）

单击添加按钮，进入添加界面，添加信息，如下图（图4.2.2.4）

（图4.2.2.4）

注意：此处的查询功能，是为查询已有公司而设的，在公司输入框内输入要查询的公司名称，便可在查询的下拉框内查出相应的公司名称，查出后需添写到公司名称处，才可保存。

查询功能如下图（图4.2.2.5）

（图4.2.2.5）

选择时间控件时的界面如下图（图4.2.2.6）

（图4.2.2.6）

添加成功后，提示处为“1”，界面如下图（图4.2.2.7）

（图4.2.2.7）

单击主界面“查看/修改”，进入“查看/修改”界面，如下图（图4.2.2.8）

（图4.2.2.8）

点击修改按钮，可修改当前记录，成功后，提示处为“1”，如下图（图4.2.2.9）

（图4.2.2.9）

单击“返回”按钮返回主界面。单击“新增公司”按钮，进入界面如下图（图4.2.2.10）

（图4.2.2.10）

公司名称不做改变，新增产品信息。同添加

单击主界面上的“新增零件”按钮，进入界面如下图（图4.2.2.11）

（图4.2.2.11）

公司名称与零件名称不变，添加新的产品信息，同添加。

4.2.3用户界面

参照4.2.1节中的“半成品”及4.2.2中的“成品”操作

4.2.4用户界面

参照4.2.1节中的“半成品”及4.2.2中的“成品”操作

4.2.5用户界面

参照4.2.1节中的“半成品”及4.2.2中的“成品”操作

4.2.6用户界面

参照4.2.1节中的“半成品”及4.2.2中的“成品”操作

4.2.7用户界面

参照4.2.1节中的“半成品”及4.2.2中的“成品”操作

4.2.8用户界面

单击“基础信息管理”菜单后，点击“工序基础信息”，进入工序基础信息维护界面。展开树图，如下图（图4.2.8.1）

（图4.2.8.1）

单击零件号后，界面中多出一个添加按钮（或是显示出查询结果，在结果中有新增工序的按钮），如下图（图4.2.8.2）

（图4.2.8.2）

单击添加按钮后进入添加界面，如下图（图4.2.8.3）

（图4.2.8.3）

输入工序名称后单击添加按钮，提示“添加成功！”，单击返回，回到主界面。（图4.2.8.4）单击主界面修改按钮，进入修改界面，如下图（图4.2.8.5）

（图4.2.8.4）

（图4.2.8.5）

单击修改按钮，成功后提示修改成功！如下图（图4.2.8.6）

（图4.2.8.6）

回主界面，选中复选框后点击删除按钮，如下图（图4.2.8.7）

（图4.2.8.7）

删除后界面如下图（图4.2.8.8）

（图4.2.8.8）

4.2.9用户界面

单击左侧“基础信息管理”菜单下的“定额基础信息”，进入界面如下图（图4.2.9.1）

（图4.2.9.1）

单击“新增定额”按钮后进入新增界面，如下图（图4.2.9.2）

（图4.2.9.2）

添加信息，如下图（图4.2.9.3）

（图4.2.9.3）

说明：点击“查”按钮可打开左侧树图，点击左侧树图可添加承制部门名称

成功后界面如下图（图4.2.9.4）

（图4.2.9.4）

主界面中点击修改/查看按钮，如下图（图4.2.9.5，图4.2.9.6）

（图4.2.9.5）

（图4.2.9.6）

修改成功后的界面如下图（图4.2.9.7）

（图4.2.9.7）

删除功能参照“成品或半成品”

如未选中工序时单击“新增定额”按钮，将出现中下图所示的提示（图4.2.9.8）

4.3采购管理

用例描述：

(1)角色：采购管理员

(2)前提条件：登录、基础库添加完整信息(3)主事件流: 1.点击进入采购管理 2.点击成品入库（S1）3.点击半成品入库（S2）4.点击原材料采购（S3）5.点击辅助材料采购（S4）6.点击标准件采购（S5）

7.点击工具采购（S6）8.点击工备件采购（S7）9.点击采购申请（S8）10.点击采购计划（S9）（4）分支事件流

S1: 成品入库（E1）

1.添加成品入库 2.修改成品入库 3.删除成品入库

4.返回成品入库列表页面 S2: 半成品入库（E2）1.添加半成品入库 2.修改半成品入库 3.删除半成品入库

4.返回半成品入库列表页面

S3: 原材料采购（E3）

1.添加原材料采购单 2.修改原材料采购单 3.删除原材料采购单 4.返回原材料列表页面 S4: 辅助材料采购（E4）

1.添加辅助材料采购单 2.修改辅助材料采购单 3.删除辅助材料采购单 4.返回辅助材料列表页面 S5: 标准件采购（E5）

1.添加标准件采购单 2.修改标准件采购单 3.删除标准件采购单 4.返回标准件列表页面 S6: 工具件采购（E6）

1.添加工具件采购单 2.修改工具件采购单 3.删除工具件采购单 4.返回工具件采列表页面 S7: 工备件采购（E7）1.添加工备件采购单 2.修改工备件采购单 3.删除工备件采购单 4.返回工备件列表页面 S8: 采购申请（E8）

1.添加采购申请 2.修改采购申请 3.删除采购申请

4.返回采购申请列表页面

S9: 采购计划（E9）

1.添加采购计划 2.修改采购计划 3.删除采购计划

4.返回采购计划列表页面（5）异常事件流

E1: 无法添加、修改、删除成品库 E2: 无法添加、修改、删除半成品库 E3: 无法添加、修改、删除原材料采购 E4: 无法添加、修改、删除辅助材料采购 E5: 无法添加、修改、删除标准件采购 E6: 无法添加、修改、删除工具采购 E7: 无法添加、修改、删除工装备件采购 E8: 无法添加、修改、删除采购申请 E9: 无法添加、修改、删除定采购计划

4.3.1用户页面

点击上方“采购管理”中的“成品入库”，进入界面如下图（图4.3.1.1）

（图4.3.1.1）

点击添加按钮，进入界面（图4.3.1.2）

（图4.3.1.2）

选择零件，进入界面如下图（图4.3.1.3）

（图4.3.1.3）

选中零件后，进入界面如下图（图4.3.1.4）

（图4.3.1.4）

单击添加后返回主界面如下图（图4.3.1.5）

（图4.3.1.5）

单击主界面的查看界面后如下图（图4.3.1.6）

（图4.3.1.6）

单击修改按钮，进入界面如下图

单击修改后可返回主界面

4.3.2用户页面

操作同9.3.1.中的“成品入库”操作

4.3.3用户页面

操作同9.3.1.中的“成品入库”操作

4.3.4用户页面

操作同9.3.1.中的“成品入库”操作

4.3.5用户页面

操作同9.3.1.中的“成品入库”操作

4.3.6用户页面

操作同9.3.1.中的“成品入库”操作

4.3.7用户页面

操作同9.3.1.中的“成品入库”操作

4.3.8用户页面

单击上方“采购管理”中的“采购申请单”，如下图（图4.3.8.1）

（图4.3.8.1）

单击添加按钮，进入界面如下图（图4.3.8.2）

（图4.3.8.2）

单击选择部门，如下图（图4.3.8.3）

选择部门及申请人，添加信息返回主界面

在主界选中复选框，点击“审批”按钮，成功后界面如下图（图4.3.8.4）

（图4.3.8.4）

4.3.9用户页面

点击上方菜单“采购管理”中的“采购计划”，如下图（图4.3.9.1）

（图4.3.9.1）

单击添加按钮，进入界面如下图（图4.3.9.2）

（图4.3.9.2）

点击选择材料，进入界面如下图（图4.3.9.3）

（图4.3.9.3）

选择材料后，点击“添加”按钮，如下图（图4.3.9.4）

（图4.3.9.4）

单击“保存信息”按钮，返回主界面，如下图（图4.3.9.5）

（图4.3.9.5）

4.4生产管理用例描述：

（1）角色：生产管理员（2）前提条件：登录（3）主事件流: 1.点击进入生产管理模块 2.点击客户订单（S1）3.点击材料请领单（S2）4.点击产成品入库（S3）5.点击转序卡（S4）6.点击生产计划（S5）7.点击材料进厂（S6）8.点击日排产计划（S7）（4）分支事件流

S1: 客户订单（E1）1.添加客户订单 2.修改客户订单 3.删除客户订单

4.返回客户订单列表页面 S2: 材料请领单（E2）1.添加材料请领单 2.修改材料请领单 3.删除材料请领单

4.返回材料请领单列表页面 S3: 产成品入库（E3）1.添加产成品入库单 2.修改产成品入库单 3.删除产成品入库单

4.返回产成品入库单列表页面 S4: 转序卡（E4）1.添加转序卡

2.修改转序卡 3.删除转序卡

4.返回转序卡列表页面 S5: 生产计划（E5）1.添加生产计划 2.修改生产计划 3.删除生产计划

4.返回生产计划列表页面 S6: 材料进厂（E6）1.添加材料进厂单 2.修改材料进厂单 3.删除材料进厂单

4.返回材料进厂单列表页面 S7: 日排产计划（E7）1.添加日排产计划 2.修改日排产计划 3.删除日排产计划

4.返回日排产计划列表页面（5）异常事件流

E1: 无法添加、修改、删除客户订单 E2: 无法添加、修改、删除材料请领单 E3: 无法添加、修改、删除产成品入库 E4: 无法添加、修改、删除转序卡 E5: 无法添加、修改、删除生产计划 E6: 无法添加、修改、删除材料进厂 E7: 无法添加、修改、删除日排产计划

4.4.1用户页面

点击上方菜单“生产管理”中的“客户订单”，进入主界面，点击主界面中的查看后，界面如下图（图4.4.1.1）

（图4.4.1.1）

点击“添加”按钮，进入界面如下图（图4.4.1.2）

（图4.4.1.2）

点击“选择零件”进入界面如下图（图4.4.1.3）

（图4.4.1.3）

添加零件后进入界面如下图（图4.4.1.4）

（图4.4.1.4）

在数量输入框内输入数量，单击添加按钮后返回主界面，如下图（图4.4.1.5）

（图4.4.1.5）

4.4.2用户页面

点击上方“生产管理“菜单中的”材料请领单“，进入界面如下图（图4.4.1.6）

（图4.4.1.6）

其添加过程同9.4.1中的“客户订单”，添加后返回主界面，如下图（图4.4.1.7）

（图4.4.1.7）

单击批准，如果库存不足，则提示如下图（图4.4.1.8）

33（0

（图4.4.1.8）

如果领取通过，则提示界面如下图（图4.4.1.9）

（图4.4.1.9）

4.4.3用户页面

点击“生产管理”菜单中的“产成品入库”，进入界面如下图（图4.4.3.1）

（图4.4.3.1）

其操作参照4.4.1中的“客户订单”

4.4.4用户页面

点击上方菜单“生产管理”中的“转序卡”，进入界面如下图（图4.4.4.1）

（图4.4.4.1）

点击“添加”按钮，进入界面如下图（图4.4.4.2）

（图4.4.4.2）

选择零件添加后，输入数量，单击“计算数据”后，点击“确定”按钮，返回主界面，如下图（图4.4.4.3）

（图4.4.4.3）

单击“查看”按钮，界面如下图（图4.4.4.4）

（图4.4.4.4）

4.4.5用户页面

点击上主菜单“生产管理”中的“生产计划”，进入界面如下图（图4.4.5.1）

（图4.4.5.1）

点击“添加”按钮，进入界面如下图（图4.4.5.2）

（图4.4.5.2）

“浏览”后选择厂家、零件名称、零件号返回，输入“月计划数量”后（图4.4.5.3）单击“确定”，返回主界面（图4.4.5.4）

（图4.4.5.3）

（图4.4.5.4）

单击“查看”后界面如下图（图4.4.5.5）

（图4.4.5.5）

4.4.6用户页面

点击上方菜单“生产管理”中的“材料进厂”，进入界面如下图（图4.4.6.1）

（图4.4.6.1）

点击“添加”按钮后，选择“浏览”按钮打开界面如图（图4.4.6.2），添加零件名称、零件总承号、厂家、板材定额等，进入界面如图（图4.4.6.3）

（图4.4.6.2）

（图4.4.6.3）

如果信息不正确，则弹出提示界面如图（图4.4.6.4）

（图4.4.6.4）

单击“查看”按钮，界面如下图（图4.4.6.5）

（图4.4.6.5）

4.4.7用户页面

操作参照9.4.5中的“生产计划”

4.5库房管理

用例描述：

(1)角色：库房管理员（2）前提条件：登录（3）主事件流: 1.点击进入库房管理模块 2.点击废品库（S1）3.点击核销（S2）4.点击返修出库（S3）5.点击返修入库（S4）（4）分支事件流 S1: 废品库（E1）

1.添加废品单 2.修改废品单 3.删除废品单

4.返回废品单列表页面 S2: 核销（E2）

1.添加核销单 2.修改核销单 3.删除核销单

4.返回核销单列表页面 S3: 返修品出库（E3）

1.添加返修品出库单 2.修改返修品出库单 3.删除返修品出库单

4.返回返修品出库单列表页面 S4: 返修品入库（E4）

1.添加返修品入库单 2.修改返修品入库单 3.删除返修品入库单

4.返回返修品入库单列表页面（5）异常事件流

E1: 无法添加、修改、删除废品单 E2: 无法添加、修改、删除核销单

E3: 无法添加、修改、删除返修品出库单 E4: 无法添加、修改、删除返修品入库单

4.5.1用户界面

点击上方菜单中的“库房管理”，进入界面如下图（图4.5.1.1）

点击添加按钮，进入界面如下图（图4.5.1.2）

选择部门，如下图所示（图4.5.1.3）

(图4.5.1.3)

选择报废产品，如图所示（图4.5.1.4）

（图4.5.1.4）

选择零件后，添加数量，自动计算总价后单击确定。如下图（图4.5.1.5）

（图4.5.1.5）

确定后界面如下图（图4.5.1.6）

（图4.5.1.6）

单击审核按钮，如不成功，弹出提示界面如下图（图4.5.1.7）

（图4.5.1.7）

如成功，则弹出界面如下图（图4.5.1.8）

（图4.5.1.8）

审核成功后，当前记录的“审批”处显示为通过，如下图（图4.5.1.9）

（图4.5.1.9）

单击查看，进入界面如下图（图4.5.1.10）

（图4.5.1.10）

单击下方“查看”，可进入修改界面如下图（图4.5.1.11）

（图4.5.1.11）

修改相应信息，可返回主界面。

4.5.2用户界面

操作同4.5.1中的“废品库”操作

4.5.3用户界面

点击上主菜单“库房管理”中的“返修出库”，进入界面如下图（图4.5.3.1）

（图4.5.3.1）

点击“返修品出库新增”按钮，进入界面如下图（图4.5.3.2）

（图4.5.3.2）

点击新增按钮，进入界面如下图（图4.5.3.3）

（图4.5.3.3）

单击保存，界面如下图（图4.5.3.4）

（图4.5.3.4）

单击返回，返回主界面

4.5.4用户界面

点击上方“库房管理”菜单中的“返修入库”，进入如下界面（图4.5.4.1）

（图4.5.4.1）

选择上方的出库记录，输入返回数量，进入界面如下图（图4.5.4.2）

（图4.5.4.2）

选择当前返修入库记录后，点击入库，如数量不合理，弹出提示界面如下图（图4.5.4.3）

（图4.5.4.3）

如数量合理，弹出如下提示界面，如下图（图4.5.4.4）

（图4.5.4.4）

4.6销售管理

用例描述：

（1）角色：销售管理员（2）前提条件：登录（3）主事件流: 1.点击进入销售管理模块 2.点击产成品出库（S1）3.点击PA收发清单（S2）（4）分支事件流

S1: 产成品出库（E1）

1.添加产成品出库单 2.修改产成品出库单 3.删除产成品出库单

4.返回产成品出库单列表页面 S2: PA收发清单（E2）1.添加PA收发清单 2.修改PA收发清单 3.删除PA收发清单

4.返回PA收发清单列表页面（5）异常事件流

E1: 无法添加、修改、删除产成品出库单 E2: 无法添加、修改、删除PA收发清单

4.6.1用户页面

点击上方菜单“销售管理”中的产成品出库，进入界面如下图（图4.6.1.1）48

（图4.6.1.1）

点击“新增出库”按钮，进入新增界面如下图（图4.6.1.2）

（图4.6.1.2）

添加数量后，单击新增出库

单击保存，如果库存不足，则弹出提示界面如下图（图4.6.1.3）

（图4.6.1.3）

篇7：班级管理系统需求规格说明书

一、软件服务外包人才需求规格

目前, 软件服务外包企业需求的工作岗位多样, 主要包括软件开发工程师、软件测试工程师、项目管理工程师等, 这些岗位人才应具备以下技能和素质:

1、熟悉软件的开发流程及企业的工作流程。

2、在项目开发过程中, 注重工作经验的积累。

3、较强的外语能力以及对海外文化具备必要的了解。

4、具有职业道德意识及按照职业规范开展工作的习惯。

5、具有较强的法律意识和知识产权和信息安全保护意识。

6、良好的沟通表达能力和团队合作精神。

二、软件服务外包人才缺乏的原因

高等教育是服务外包人才培养的主要途径, 然而, 高等教育周期长、偏于理论、实践能力不足, 导致学生在学校所学的知识及形成的专业能力与用人单位的实际需要形成较大的差距, 造成用人单位无合适人才可用, 究其原因, 主要有如下几方面。

1、普适性教育问题

软件服务外包行业对于人力资源结构的需求呈现“橄榄球”形状, 对中间掌握专门技能的技术人才需求巨大, 但是, 当前各高校普遍采取的是一种普适性教育, 课程体系更注重对软件行业的全覆盖, 人才结构呈现“金字塔”形状, 即高端人才缺乏, 中间技术人才也相对不足, 而处于金字塔底端、对技术要求不高的低端人才数量充足。

2、教学实践问题

高校和企业由于体制和模式的不同, 高校的课程安排注重理论的学习, 实践性较少, 按照教学大纲规定培养人才, 到了企业, 还需要几个月的时间去适应和“补课”。

目前, 在已形成的校企合作中, 多数企业跟学校的合作只是停留在实习基地的提供、安排学生实习等方面, 不够深入。导致专业教育和生产实践联系不够紧密, 产学研合作的目标与短期行为相互矛盾。

3、专业缺位的问题

目前, 我国软件从业人员3/4以上来自于全国各大高校和科研机构的计算机科学与技术、软件工程、信息管理等计算机与软件相关专业, 不同专业方向的学生在同一人才培养模式下接受教育, 软件人才的差异性、梯度性不强, 人才技能单一, 远远不能满足软件服务外包企业多样化的工作需求, 导致一边是大量找不着工作的毕业生, 一边是众多找不到合适人才的软件企业的现象。

三、构建良好的软件服务外包人才培养模式

软件服务外包业务属知识密集型产业, 需要有素质较全面、符合实际需求的软件专业人才。对于为其服务的相关专业, 必须根据软件服务外包特点和人才需求来采用新的人才培养模式, 这就要求高校和软件外包企业发挥各自的优势, 共同培养软件外包人才。

1、校企共同参与

良性校企合作的软件服务外包人才培养模式是基于软件服务外包产业发展目标导向型的高校和行业企业共同培养软件人才的双赢驱动方式, 核心是解决学校育人和企业用人的问题, 从合作机制和运行模式两个核心层面促使高校和软件企业充分实现优势互补全方位的合作。

一方面, 高校必须破除落后的、封闭的办学观念, 主动与企业联系, 根据企业生产任务的特点和企业岗位需求增设或变更课程, 形成符合市场经济和现代高等教育发展要求的办学理念, 按企业需求设置专业、共同制定培养计划和课程体系、联合教材开发、联合建设实训基地、软件类教师和软件服务外包专家的互聘、确保高校的教学实施和企业生产经营的无缝对接。

另一方面, 企业也要认识到高校在科研和人才综合能力、人才素质培养上的优势, 从企业发展的长远利益出发, 尽心尽力为培养企业“准员工”而努力, 让高校在技术升级、人才储备、提高竞争力方面为企业源源不断地输入动力。

2、落实实训环节

培养软件外包服务人才职业能力的有效手段就是实训, 强化在校期间的动手实践能力训练, 接受企业提供的真实的项目、真实的目标管理、真实的绩效考核实训, 是培养合格“实用型”人才不可或缺的程序。学生实训期间, 学校安排专职教师做好学生的管理和校企之间沟通与协调, 保证实训有序进行;企业用实训成绩替换教学计划中相应实践性教学环节的成绩。校企共同管理学生, 在提高学生的专业技能, 文化素养的同时, 提升学生的职业素养和职业道德, 打造“一专多能”的软件服务外包人才。

3、开设服务外包行业语言课程

目前, 发达国家是外包业务的主要发包国, 其中美国约占全球市场份额的三分之二, 欧盟和日本占三分之一, 要想了解国际上软件技术的发展趋势, 掌握最新的研究成果, 或者与国外同行进行技术交流, 就必须掌握共通的语言。

这种外语培训有别于传统的公共英语, 更加注重模拟学生在外国软件企业中会遇到的各种工作场景, 加强学生在软件专业领域和商务领域中的听、说、读、写的能力。可能的话, 专业课程在讲解时也可用双语教学。这样, 一方面可以缓解社会上“专业+语言”的综合性软件人才奇缺的现状, 另一方面也拓展了高校人才的就业渠道, 提升了人才的就业层次。

四、结论

依靠高等院校的教育资源和企业的一线资源, 针对企业用人需求, 把产业人才需求与高等职业教育相衔接, 在加强学生专业知识积累的同时, 提高学生服务外包的职业技能, 解决软件服务外包人才供给的失衡问题, 可以为我国软件外包快速地发展打好坚实的基础。

参考文献

[1]王秀平:《产业转型背景下的高职软件人才培养模式的探索与实践》, 《计算机教育》, 2010 (6) 。

[2]卢建平:《服务外包转变经济增长方式的绿色引擎》, 《开发研究》, 2010 (1) :22-26。

[3]惠学东:《高职教育与服务外包产业无缝连接的扁平化视野》, 《辽宁高职学报》, 2009 (9) :15-16。