企业员工内训管理系统需求规格说明书文档格式.docx

企业员工内训管理系统需求规格说明书文档格式.docx

《企业员工内训管理系统需求规格说明书文档格式.docx》由会员分享，可在线阅读，更多相关《企业员工内训管理系统需求规格说明书文档格式.docx（15页珍藏版）》请在冰点文库上搜索。

便于对需求进行双向跟踪。

便于系统移植、功能扩展和后期维护。

总的来说本说明书目的在于明确说明系统需求，界定系统实现功能的范围，指导系统设计以及编码。

1.2范围

本文档作为系统概要设计、详细设计、数据库设计的根据和对照文档以及项目的验收依据，所有设计都要围绕需求规格说明书来进行。

1.3读者对象

预期读者是项目组所有成员、需求提出者以及一些相关领导。

1.4参考文档

1.5术语定义

2系统说明

2.1概述

在这一部分应对影响系统的主要因素进行描述。

对于系统的详细功能描述应在下一节进行。

在此，应侧重需求的背景并使在下一节所做的叙述易于理解。

可包括：

现有系统描述、新系统解决方案描述、产品用途、产品功能、用户特点、局限性、前提和假设等。

2.2产品介绍

由于软通动力集团业务的逐年扩展，越来越多的IT人才加入到软通这个现代化的IT企业中来。

作为软通旗下的埃卡内基学院担负着庞大的员工内训的任务，为软通动力输送合格的人才。

随着培训学员数量的剧增，学员的种类也变得越来越多，使学员日常、教学管理变得异常复杂，以往的系统已经不足以应付目前这种状况。

鉴于目前这种形式，集团打算为埃卡内基开发一个企业内训管理系统来解决目前的困境。

该系统应该具备对所有学员的基本信息进行管理，对学员住宿情况进行管理，以及对学员受训班级的相关信息管理的功能。

2.3产品中的用户与角色

埃卡内基行政管理人员，方便其对学员的管理

2.4产品范围

2.5产品应当遵循的标准或规范

本产品遵循CMMI3的标准规范。

3功能性需求

在这一部分应对所有的软件需求进行足够详细的描述。

详尽程度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试计划和编写测试用例为准。

按系统功能的体系结构组织本章内容。

3.1学员基本信息管理

在这一部分应对所有的软件的功能需求进行足够详细的描述。

各功能应用普通文字或图表描述。

并同时指出功能实现与业务需求的关系，即此功能实现了哪一部份的业务需求。

3.1.1基本信息查询

3.1.1.1业务概述

根据客户需求，主要实现：

根据查询条件进行查询显示功能、增加学员信息、修改学员基本信息、批量修改学员信息、导出功能。

3.1.1.2使用者

培训管理

3.1.1.3输入要素

学员类型，学历，班级，技术方向，姓名，性别，政治面貌，籍贯，毕业院校，学校类型，专业，毕业时间，是否推荐，项目组名，工作经验，意向工作城市，语言掌握，数据库掌握，入训时间，退训日期，外语水平，学员状态。

3.1.1.4处理流程

用户输入相应信息→点击查询，按照用户输入的信息进行相应的查询，根据查询条件将从数据库获得的信息反馈到学员基本信息列表。

对查询出来的学员信息→进行更为详细的信息显示、进行修改。

对查询出来的学员信息→点击“批量修改”，进行学员信息批量修改。

在学员信息列表下方→点击“增加学员”，学员基本信息的录入，添加新的学员

对查询出来的学员基本信息→点击“导出”，将学员基本信息导出为excel。

3.1.1.5输出要素

学号、姓名、身份证号、性别、籍贯、班级、学员类型、毕业院校、技术方向、状态、外语水平、项目组、政治面貌、入学日期、意向工作地。

3.2基本信息导入

批量导入和单个导入学员基本信息的功能。

3.2.1.1业务概述

3.2.1.2使用者

内训管理人员

3.2.1.3输入要素

批量导入：

使用者所需的“Excel表格”

单个导入：

学员基本信息输入：

学员学号，姓名，性别，身份证号，政治面貌，籍贯，费用来源，信息来源，邮政编码，意向就业城市，意向职位，家庭电话，家庭住址，兴趣爱好，备注，上次照片；

毕业院校信息输入：

毕业院校，是否211，专业，毕业时间；

培训信息：

学员类型，班级，语言方向，房间号，状态，是否推荐，入训时间；

联系方式信息：

手机号码，紧急联系号码1.、2。

MSN,QQ,宿舍电话，邮箱，现居住地；

技能掌握信息：

外语水平，外语分数，办公软件了解程度，软件开发掌握程度，开发语言、数据库掌握程度。

3.2.1.4处理流程

使用者：

点击→“基本信息管理”链接，点击→“批量导入学员信息”链接，点击→“浏览”按钮，在本地选择一个Excel文件，点击→“导入”按钮。

点击→“基本信息管理”链接，依次填入学员基本信息，点击“确定添加”按钮。

3.2.1.5输出要素

提示添加成功，并在页面显示刚导入学员信息。

3.3宿舍管理

3.3.1学员住宿管理

3.3.1.1业务概述

根据查询条件进行查询显示功能、删除学员住宿信息功能、修改学员住宿信息功能、增加学员入住信息功能、调整宿舍功能、导出功能。

3.3.1.2使用者

3.3.1.3输入要素

住宿地点，宿舍号，入住时间，住宿状态，房间规模,入住费用,费用是否已交

3.3.1.4处理流程

用户输入相应信息→点击查询，按照用户输入的信息进行相应的查询，根据查询条件将从数据库获得的信息反馈到学员住宿信息列表。

对查询出来的住宿信息→进行更为详细的信息显示、进行修改。

对查询出来的住宿信息→点击“删除”，进行删除学员住宿信息。

对查询出来的住宿信息→点击“调整宿舍”，进行学员住宿信息的调换→输入原来的宿舍，以及要调换到的宿舍，点击“更新”，完成宿舍信息调换

点击“学员入住”，进行单个信息录入或者批量信息的录入功能。

对查询出来的住宿信息→点击“导出”，将学员住宿信息导出为excel。

3.3.1.5输出要素

学员住宿信息，包括学员姓名、学号、宿舍号、入住时间、是否租车、住宿地点、宿舍规模等。

3.3.2宿舍信息管理

3.3.2.1业务概述

根据查询条件进行查询显示功能、添加宿舍功能、删除旧的不用的宿舍的功能、导出功能。

3.3.2.2使用者

3.3.2.3输入要素

住宿地点，房间规模，是否住满

3.3.2.4处理流程

用户输入相应信息→点击查询，按照用户输入的信息进行相应的查询，根据查询条件将从数据库获得的信息反馈到宿舍信息列表中。

对查询出来的宿舍信息→点击“添加”，开辟新的宿舍来使用。

对查询出来的宿舍信息→点击“删除”，、删除不用的宿舍。

对查询出来的宿舍信息→点击“导出”，把宿舍信息导出为excel

3.3.2.5输出要素

宿舍信息，包括房间号、可住人数、当前住宿学员、住宿地点。

3.4班级管理

3.4.1班级基本信息管理

3.4.1.1业务概述

根据查询条件进行查询显示功能、删除班级信息功能、修改班级信息功能、添加班级功能、导出功能。

3.4.1.2使用者

班级管理员

3.4.1.3输入要素

班级名称、教室号、班主任名称、班主任联系方式，开班日期,结束日期,讲师名称,班级额定人数,

班级方向（java,c++,test…）

3.4.1.4处理流程

用户输入相应信息→点击查询，按照用户输入的信息进行相应的查询，根据查询条件将从数据库获得的信息反馈到班级信息列表。

对查询出来的班级信息→进行更为详细的信息显示、进行修改。

对查询出来的班级信息→点击“删除”，进行删除班级信息。

对查询出来的班级信息→点击“修改”，进行班级基本信息的修改

在班级信息列表下方→点击“添加班级”，进行单个班级的基本信息添加。

对查询出来的班级信息→点击“导出”，将学员住宿信息导出为excel。

3.4.1.5输出要素

班级名称，教室号，开班日期，班主任名称以及班主任的联系方式等。

3.4.2班级学员信息管理

3.4.2.1业务概述

根据查询条件进行查询显示功能、为班级添加学员、为学员进行班级调整、为学员进行退班、导出功能。

3.4.2.2使用者

3.4.2.3输入要素

班级号、教室号、入班时间、学员状态、班级人数。

3.4.2.4处理流程

用户输入相应信息→点击查询，按照用户输入的信息进行相应的查询，根据查询条件将从数据库获得的信息反馈到班级学员信息列表；

对查询出来的班级学员信息→进行更为详细的信息显示、进行修改；

对查询出来的班级学员信息→进行班级调整，将学员调入到其他班级去；

对查询出来的班级学员信息→进行退班，将学员从当前班级退出；

对查询出来的班级学员信息→进行添加学员，用于向班级中添加学员；

对查询出来的班级学员信息→信息导出，将选择的记录进行Excel导出。

3.4.2.5输出要素

学号，姓名，状态，班级名称，教室号，入班时间等。

4非功能性需求

4.1技术需求

4.1.1软硬件环境需求

4.1.2性能需求

性能需求表示用户对系统响应速度、处理能力、数据处理精度以及可靠性等指标的要求。

一般性能需求分类如下：

Ø

处理速度——要给出关键交互界面的业务处理速度的量化时间和输入数据次数，如简单查询响应时间、动态查询响应时间、后台处理效率等，以便以后测试人员验证。

处理结果的精度要求——按照不同的业务数据要求，给出相关数据小数点保留位数和累加后数据的误差范围。

产品处理的存储空间要求以及磁盘容量要求，如系统需要保留多少年的数据量等

数据的值域要求

事务处理的吞吐量要求

资源使用的有效性要求：

比如CPU、内存、表的填充因子等

以上方面的扩展要求

4.1.3安全保密需求

指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。

这个领域的具体需求产品的安全性、保密性和完整性三方面需求。

例如：

要求对接入系统的用户进行身份验证。

对不同角色的用户设置不同的权限，通过角色定义实现不同角色个性化菜单的定制，有效控制用户的功能权限。

系统应提供日志记录和管理功能，记录所有用户访问系统的全部活动，并能够形成审计报告。

要求在传输过程中对数据进行加密处理，保证数据传输的安全性和完整性。

系统应具备病毒防范能力。

防止主机崩溃方法和数据备份方法等。

4.1.4运行保障需求

运行保障需求，主要从系统推广、运行后日常维护角度进行考虑，包括硬件、系统软件、应用软件、数据备份等的运行保障。

1、对硬件，特别是应用服务器和数据库服务器，要求一般故障能够在？

天之内予以解决；

对于硬件重大故障，要求在？

星期之内予以解决。

另外，要对系统数据量做出正确估算，预测硬件需要升级的时间点。

2、系统软件，主要指操作系统及数据库软件，对一般问题能在？

？

分钟以内予以解决，对重大问题在？

天之内予以解决。

3、支撑软件产品。

本系统需要以下软件产品：

……旦出现使用问题，有关公司应在最短时间内到现场予以解决。

4、应用软件。

应用软件出现问题后，有关人员能及时到位，在最短时间内查找问题原因，予以解决。

5、数据备份。

对系统数据制定备份策略，定期进行数据备份与保管。

零级备份每？

做一次。

增量备份针对于一定时期内发生变化的数据。

譬如：

有重大事件发生时等。

6、系统对效率要求如何，应认真计算网上传输数据量，计算系统对网络带宽的要求。

4.2接口需求

详细说明对系统的用户界面等的要求。

还可包括和其它系统的接口、地址、协议等。

4.2.1用户接口

提供用户使用软件产品时的接口需求。

例如，如果系统的用户通过客户端进行操作，就必须指定如下要求：

对屏幕格式的要求；

报表或菜单的页面、打印格式等用户对软件外观风格的一种要求。

如：

公司标志，界面色彩基调等。

规格的定义方式可以采用草图或静态原型的方式表示，一般描述分为两个部分：

整体描述和基于每个界面的细节描述。

输入输出的相对时间；

程序功能键的可用性。

4.2.2硬件接口

要指出软件产品和系统硬部件之间每一个接口的逻辑特点和交互方式。

还可能包括如下事宜：

支撑什么样的设备，如何支撑这些设备，有何约定。

4.2.3软件接口

在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或有关软件包），以及同其他应用系统之间的接口。

对每一个所需的软件产品，要提供如下内容：

1.名字；

2.助记符；

3.规格说明号；

4.版本号；

5.来源。

对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。

4.2.4通讯接口

指定各种通信接口。

例如，局部网络的协议等等。

4.3质量需求

4.3.1可用性

用户使用的方便性、易用性和易学习性，如：

1.输入的无合法性检查和值域检查

2.对于复杂的动作要有必要的提示信息

3.记忆用户的设置或操作习惯，方便用户操作

4.对系统或数据进行重大修改，要有用户确认

4.3.2可靠性和健壮性

在这一部分应对所有的影响软件的可靠性需求进行足够详细的描述。

应注意用数字说明所要求的可靠程度。

同时避免如“24x7”这样的陈述。

例如使用年度正常运行时间、月正常运行时间、维护时间、当机时间来说明系统的可靠程度；

使用可允许的缺陷数量来界定系统质量，如最大缺陷数量、缺陷比例、安全操作——系统强壮性要求和操作的有效性要求，比如用户误操作的系统容错能力、操作的正常次序要求和有效性输入检查等等。

通常给出平均无故障时间或两次故障间的平均间隔时间等。

4.3.3可维护性

规定若干需求以确保软件是可维护的。

1.软件模块所需要的特殊的耦合矩阵；

2.使用行业标准、编码标准、开放式结构、可兼容语言、备份及复原和数据交换等。

3.规定把软件从一种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束。

4.3.4可扩展性

说明该软件在需求或环境发生某些变化时，该软件对这些变化的适应能力的要求，如：

1．需求及流程变化；

2．操作方式变化；

3．机构人员变化；

4．空间地点变化（移动用户、分布式）；

5．操作系统环境变化。

4.4文档需求

4.4.1培训要求

4.4.2用户手册

4.4.3在线帮助系统

详细说明对在线帮助系统等的要求。

4.5设计约束

详细说明对系统的设计局限性。

设计局限的定义代表了对系统要求的决策,这可能出于商务运作、资金、人员、时间等多方面的综合考虑从而指导软件的设计和开发。

例如，软件的开发语言、开发环境、开发工具、第三方软件、硬件使用以及网络设备等。

4.5.1<

设计约束要求1>

4.5.2<

设计约束要求2>

5验收标准

详细说明对系统的验收要求。

此要求将作为验收测试计划和测试的基线。

如果所开发的产品能满足此要求，则项目可结束并由客户方按合同规定付款。

6附录A：

需求建模与分析报告

建议使用RationalRose、BorlandTogether、MSVisio等建模工具进行需求的建模分析，通过分析系统的功能模型、结构模型和行为模型，进行系统建模。

建模的过程包括系统功能建模、系统数据建模和体系结构建模，在需求开发阶段应至少完成功能建模。

功能建模的方式包括静态建模和动态建模。

静态建模要求画出用例图、主要的类图和对象图，动态建模要求画出主要的状态图、时序图、协作图和活动图等。

6.1Actors

描述系统中的Actors及其关系。

主要活动的时序图等。

6.2Use-case模型

按系统功能的体系结构组织内容，描述各Use-case及其关系，需标明每个用例的业务描述、业务数据、业务流程、入口条件、输出结果、异常处理等。

6.2.1用例1

6.2.1.1业务描述

6.2.1.2业务数据

可以用对象图说明

6.2.1.3业务流程

可以用状态图、活动图或时序图等说明。

6.2.1.4入口条件

6.2.1.5输出结果

6.2.1.6异常处理

6.2.2用例2

7附录B：

系统原型

如果已开发了系统原型或计划开发系统原型，则在此进行说明。

8附录C：

需求确认

参见《需求评审报告》