系统需求规格说明书.docx
- 文档编号:30527281
- 上传时间:2023-08-16
- 格式:DOCX
- 页数:50
- 大小:65.61KB
系统需求规格说明书.docx
《系统需求规格说明书.docx》由会员分享,可在线阅读,更多相关《系统需求规格说明书.docx(50页珍藏版)》请在冰豆网上搜索。
系统需求规格说明书
重庆理工大学计算机学院
文档编号
产品版本
密级
XK-DN-2000-10-11-11
V1.0
产品名称:
任务管理系统
共48页
任务管理系统项目
需求规格说明书
(仅供内部使用)
组长:
罗伟
组员:
江志伟
殷渝
王玥
张自萌
指导教师:
徐传运王森
重庆理工大学计算机学院
2011年01月13日
修改记录
版本号
修改人
修改日期
修改说明
审核人
目录
1.引言4
1.1项目名称4
1.2编写目的5
1.3项目背景5
1.4参考资料6
2.任务概述7
2.1项目总体目标7
2.2业务需求7
2.3运行环境7
3.功能需求8
3.1功能总体描述8
3.2任务管理9
3.2.1业务概述9
3.2.2需求列表18
3.2.3实体类19
3.3任务组管理22
3.3.1业务概述22
3.3.2需求列表27
3.3.3实体类27
3.4任务统计29
3.4.1业务概述29
3.4.2需求列表34
3.4.3实体类34
3.5历史任务查询36
3.5.1业务概述36
3.5.2需求列表40
3.5.3实体类40
3.6短信管理42
3.6.1业务概述42
3.6.2需求列表45
3.6.3实体类45
4.非功能需求45
4.1时间特性45
4.2适应性46
4.3安全性46
4.4可靠性46
4.5可扩充性46
4.6互操作性:
46
4.7健壮性:
46
4.8易使用性:
47
4.9可维护性:
47
4.10可移植性:
47
4.11可重用性:
47
5.接口说明47
5.1软件接口47
5.2硬件接口47
1.引言
1.1项目名称
任务管理系统
1.2编写目的
本文档详细、准确和全面定义任务管理系统TMS(TaskManagementSystem)的外部行为,设计约束,以及其它相关因素,指导软件系统的后续开发工作,进一步定制软件开发的细节问题,为软件需求者(软件使用者)与软件设计者能更好的交流、沟通提供书面途径。
同时本说明书还是《用户手册》和《测试计划》的编写依据。
本文档可作为任务管理系统设计人员,技术支持人员,程序员,测试人员,使用人员的参考资料。
1.3项目背景
21世纪是一个信息时代,企业日常办公中的资料越来越多,其中绝大部分信息都十分重要,而且许多资料都是以纸质文档的形式保存。
然而,纸质文档需要大量的空间,且不易修改,还有做好防腐防潮工作,使用十分不便。
电子文档占用空间小,便于修改和保存,因此,电子文档成为了文档存储的主要方式。
但是电子文档由于易修改、误删、存在设备丢失等因素使得电子文档很容易丢失,特别是一些重要的任务信息的丢失会带来严重的后果。
在实际工作中,我们可能需要将某项工作重新分配给其他人,这时任务的发布人需要再次将资料发布的新的执行人和当前执行人,如果某些工作的执行人失去联系,则需要花费大量的时间和精力来重启他所负责的任务,这样使得任务的重新分配和任务的多层管理是否不便。
同时,在任务的发布和执行过程中,任务发布人经常不能及时确认任务执行人是否接受任务或者是否开始执行,也不能了解任务的执行进度,从而导致在任务出现困难的时候不能及时调整任务,影响下一步的工作。
为此,08创新实验室决定自主开发一个任务管理系统,用来提高工作效率,降低工作中的失误,解决实际工作中由于各种因素引起的任务信息丢失,任务重新分配和多层管理的不便,任务执行状况不易监管等问题。
同时,本系统将首先在计算机学院试行,然后推广到重庆理工大学,最终作为一个商业软件运用在各大企业单位任务管理工作中。
1.4参考资料
[1]KarlE.Wiegers.软件需求(第2版)(SoftwareRequirements)[M].刘伟琴,刘洪涛译.北京:
清华大学出版社,2004.
[2]姜同强.信息系统分析与设计[M].北京:
机械工业出版社,2008.
[3]DavidC.Hay.需求分析[M].北京:
清华大学出版社,2008.
[4]范晓平.UML建模实例详解.北京:
清华大学出版社,2005.
2.任务概述
2.1项目总体目标
1)任务信息,将其保存至数据库,并且及时通知相关人员。
2)任务重新分配和任务多层管理的支持:
根据用户要求将任务重新分配,并及时同时相关责任人,同时根据任务实际情况进行多层管理。
3)监管任务执行状况:
及时统计任务执行情况,并在适当时候给予相关负责人必要的提示。
2.2业务需求
开发本系统旨在提高工作效率、方便管理、节约成本。
2.3运行环境
操作系统:
MicrosoftWindows2003AdvancedServer
支持环境:
Tomcat6.0
数据库:
Mysql5.1
3.功能需求
3.1功能总体描述
本任务管理系统的主要分为任务管理、任务组管理、任务统计、短信管理和历史任务查询五个模块。
图3-1系统顶层用例图
本系统的用户主要是:
系统用户、部门主管、任务发布人、任务执行人(任务执行人在执行任务的过程中将任务分解并且下发给下级人员也视为任务发布人)。
系统各模块主要功能如下:
◆任务管理模块:
主要负责任务的创建、分解、查询、过滤、分类和任务的提交、任务的申请删除,以及在这些过程中的有管理附件资料的管理。
◆任务组管理模块:
主要负责创建任务分组,并且为每个分组添加成员,同时提供任务组的删除、重命名操作及任务组成员的增、删、改操作。
◆任务统计模块:
主要处理系统用户对自己所负责任务的统计信息的查询。
◆短信管理模块:
主要负责将任务信息及其他系统信息及时通知用户,以便用户及时处理。
◆历史任务查询模块:
主要处理系统用户对历史任务信息的查询请求。
3.2任务管理
3.2.1业务概述
图3-2任务管理模块用例图
任务发布人首先创建任务信息,然后将任务发布给任务组成员执行。
如果该任务包含相关任务资料,发布人可以以附件方式随任务信息一同发布给任务执行人。
任务发布人也可以根据任务状态对任务进行分类以便对执行人进行筛选过滤。
任务执行人在接到任务后,可以下载附件中的任务相关资料,然后开始执行任务,在任务执行过程中,由于某些因素导致任务无法继续执行,任务执行人可以申请删除任务,任务发布人接到任务执行人请求后可以删除该任务执行人的任务以便重新将任务分配给其他人。
任务执行人在执行任务过程中应该将进度情况以附件形式提交给任务发布人以便任务发布人及时掌握任务执行情况。
任务执行人完成任务后应该完善任务信息(包括任务汇报,任务相关资料等)并且提交任务。
任务发布人发布附件资料,在任务执行过程中,任务发布人和任务执行人均可以对任务信息及相关资料进行修改,任务执行人在下载或查看任务相关附件资料后也可以删除附件信息。
另外,任务执行人在接到任务后,如果发现任务可以进行分解,则可以将任务进行分解并且下发给下一级任务执行人。
以下表格是每个用例的详细描述。
用例名称:
任务创建
活动者:
任务发布人
用例目标:
发布新的任务或发布某任务的相关子任务。
前置条件:
任务创建之前必须选择,创建的任务是父级任务还是子集任务。
后置条件:
系统记录新添加的任务信息。
事件流
活动者
系统响应
基流
当用户点击按钮“创建任务”时,用例启动。
1.系统提示用户输入任务的相关信息,选择任务执行人,并且指定任务是否可以分解。
2.用户输入相关任务信息,选择任务执行人并指定任务是否可以分解。
3.用户指定是否父级任务,提交。
(E-1)
4.系统检查用户输入信息,发布任务。
替代流
E-1:
选择
1.[用户选择父级任务]指定任务是父级任务,提交。
2.系统检查用户输入信息,发布任务。
表3-1任务创建用例描述
用例名称:
任务查询
活动者:
任务发布人
用例目标:
根据任务发布人选择的查询条件和输入的检索词查找任务。
前置条件:
任务查询界面必须处于激活状态且有正确的数据。
后置条件:
系统在输出窗口输出查询结果。
事件流
活动者
系统响应
基流
当用户点击菜单“任务查询”时,用例启动。
1.系统提示用户选择查询条件,指定检索词。
2.用户选择查询条件(查询条件可以是任务名称,任务代号,父级任务名称等),指定检索词,提交。
(E-1)
3.系统根据用户指定的信息查找相关任务,输出查询结果。
替代流
E-1:
高级搜索可以进行多类型和多检索词进行查询。
表3-2任务查询用例描述
用例名称:
任务分类
活动者:
任务发布人
用例目标:
完成任务发布人根据任务情况对任务的分类。
前置条件:
任务必须已经发布。
后置条件:
系统输出任务类型更改结果。
事件流
活动者
系统响应
基流
当用户选择“任务类型”时,用例启动。
1.系统提示用户选择任务类型。
2.用户选择任务类型提交。
3.系统根据用户指定的任务类型更改任务类型,输出更改结果。
表3-3任务分类用例描述
用例名称:
任务分解
活动者:
任务发布人
用例目标:
授予任务执行人分解任务的权限。
前置条件:
在创建任务,修改任务的时候才能对是否可分解进行设置。
后置条件:
任务的可分解状态记录在系统中。
事件流
活动者
系统响应
基流
当用户任务设置是否可以分解时,用例启动。
1.系统提示用户选择任务是否可以分解。
2.用户设置是否可以分解,提交。
(E-1)
3.系统将任务设置为可分解状态。
表3-4任务分解用例描述
用例名称:
任务过滤
活动者:
任务发布人
用例目标:
通过任务类型对人物进行筛选。
前置条件:
后置条件:
事件流
活动者
系统响应
基流
当用户点击“任务过滤”时,用例启动。
1.系统提示用户选择任务状态。
2.用户指定任务状态,提交。
3.系统过滤任务,返回此状态的所有任务。
表3-5任务过滤用例描述
用例名称:
申请删除任务
活动者:
任务执行人
用例目标:
选中执行任务,选择申请删除。
前置条件:
用户必须是此任务的执行人,才有资格申请删除此任务。
后置条件:
任务状态变换成申请删除。
事件流
活动者
系统响应
基流
当用户点击菜单“申请删除任务”时,用例启动。
1.系统显示任务信息。
2.用户选择申请删除,提交。
(E-1)
3.系统将此任务的状态设置为申请删除状态。
替代流
E-1:
选择
1.[用户点击取消]请求取消申请删除操作。
2.此用例终止。
表3-6申请删除任务用例描述
用例名称:
提交任务
活动者:
任务执行人
用例目标:
完成把已经完成的任务(包括任务汇报,任务相关资料)提交给任务发布人。
前置条件:
任务是正在执行任务,且当前用户是任务执行人。
后置条件:
任务状态由正在执行转换为已提交。
事件流
活动者
系统响应
基流
当用户点击菜单“提交任务”时,用例启动。
1.系统提显示任务信息,提示用户填写任务汇报。
2.用户填写任务汇报。
3.用户上传附件。
(E-1)
4.用户提交任务。
(E-2)
5.保存提交任务信息,提示用户任务提交成功。
替代流
E-1:
选择
1.[用户点击取消]请求取消任务提交。
2.此用例终止。
E-2:
附件
1.无附件上传
表3-7提交任务用例描述
用例名称:
附件上传
活动者:
任务执行人
用例目标:
上传执行任务相关的附件信息。
前置条件:
当前用户是任务执行人。
后置条件:
任务附件信息保存到系统中,且发送给任务发布人。
事件流
活动者
系统响应
基流
当用户选中任务时,用例启动。
1.系统显示选中任务的详细信息。
2.用户选择进入详细信息的附件视图。
3.系统显示所有的执行任务附件。
4.用户点击添加附件。
5.系统显示文件选择对话框。
6.用户选择提交的资料,编辑附件信息,点击上传。
(E-1)
7.系统提示附件上传成功。
替代流
E-1:
选择
1.[用户点击取消]请求取消编辑上传。
2.此用例终止。
表3-8上传附件
用例名称:
下载附件
活动者:
任务执行人
用例目标:
下载任务相关的附件。
前置条件:
当前用户是任务执行人且存在任务附件。
后置条件:
任务附件从系统中下载下来。
事件流
活动者
系统响应
基流
当用户点击按钮“下载”时,用例启动。
1.系统弹出附件下载对话框。
2.用户点击确认(E-1)
3.系统提示附件下载成功。
替代流
E-1:
选择
1.[用户点击取消]请求取消下载。
2.此用例终止。
3.[用户点击打开]请求直接打开附件。
4.系统直接打开附件,用例终止。
5.[用户点击保存]请求保存附件。
6.系统选择文件存储位置对话框。
6用户选择存储位置。
7系统提示附件下载成功。
表3-9下载附件用例描述
用例名称:
编辑附件
活动者:
任务执行人
用例目标:
编辑执行任务相关的附件信息。
前置条件:
当前用户是任务执行人。
后置条件:
任务附件信息保存到系统中。
事件流
活动者
系统响应
基流
当用户点击“编辑”时,用例启动。
1.系统显示附件编辑界面。
2.用户填写相关数据,提交。
(E-1)
3.系统提示附件信息保存成功。
替代流
E-1:
选择
1.[用户点击取消]请求取消编辑。
2.此用例终止。
表3-10编辑附件
用例名称:
删除附件
活动者:
任务执行人
用例目标:
删除任务相关的附件。
前置条件:
当前用户是任务执行人且存在任务附件。
后置条件:
任务附件从系统中删除。
事件流
活动者
系统响应
基流
当用户选中任务时,用例启动。
1.系统显示选中任务的详细信息。
2.用户选择进入详细信息的附件视图。
3.系统显示所有的执行任务附件。
4.用户选中附件,点击删除。
5.系统提示用户是否删除,请用户确认。
6.用户点击确认。
(E-1)
7.系统提示附件删除成功。
替代流
E-1:
选择
1.[用户点击取消]请求取消删除。
2.此用例终止。
表3-11删除附件用例描述
3.2.2需求列表
No
需求说明
P
备注
2000
任务管理
5
2001
任务查询
5
2100
创建任务
5
2101
创建顶级任务
5
2102
创建同级任务
5
2103
创建下级任务
5
2104
短信通知任务信息
5
2002
分解任务
5
2003
查看执行任务详细
5
2200
查询任务历史
5
2201
查询已完成任务
5
2202
查询已终止任务
5
1200
直接选择人员
5
3000
分解任务
3001
申请删除任务
3002
上传附件
3003
提交任务
3004
下载附件
3005
删除附件
3006
编辑附件
3007
在线浏览附件
3.2.3实体类
类名
属性名
说明
Task
Id
任务ID
Code
任务代号
Deadline
任务截止日期
description
任务描述
finishTime
任务完成时间
hasChild
该任务是否有子任务
isDecompose
是否可分解
level
级数顶级人物级数为
name
任务名称
promulgatorTime
任务下达时间
remark
任务备注
taskState
任务状态
category
任务类别
parentTaskExecute
若该任务是被分解得到的,则记录分解人对应的任务执行实体
partentTask
父级任务
promulgator
任务下达人
topTask
顶级任务
submitWay
提交方式(直接提交,需要审核)
EmployeeTaskGroup
id
任务ID
employee
任务组组员
taskGroup
任务组
TaskGroupCode
任务组代号
createPerson
任务组创建人
TaskGroup
Id
任务组ID
code
任务组代号
name
任务组名称
createEmployer
任务组创建人
partenttg
上级任务组
employeeTaskGroups
任务组所有职工
hasChild
是否有下级
Level
级数
Employee
EmployeeId
员工Id
department
所属部门
code
职员编码
电子邮件
linkTel
联系电话
name
姓名
organization
所属单位
identitCardId
身份证
nativePlace
籍贯
Department
faxNumber
传真
code
部门编码
departmentId
部门Id
officePhoneNumber
办公电话
description
备注
address
地址
departmentType
部门类型
name
部门名称
organization
所属单位
Organization
organizationId
单位id
billCodeMode
单据编号方式
manager
单位只属上级领导Code
modifyTime
修改时间
code
单位编码
fullCode
编码全称
organizationType
单位类型
webSite
单位网址
description
备注
电子邮件
linkTel
联系电话
creatTime
创建时间
name
单位名称
outGB
国际编码
parent
上级单位
shortCode
单位简码
children
下级单位
departmentLevel
级别
codeLength
单位代码长度
isHaveChildren
是否是有孩子节点
organizationUpManagerName
单位只属上级领导Name
organizatonManagerCode
单位领导Code
organizationManagerName
单位领导Name
TaskExecute
Id
任务执行id
code
任务执行代号
firstReadTime
首次阅读时间
lastReadTime
最近打开时间
submitTime
任务提交时间
executeState
任务执行状态
executeNote
任务执行情况说明
isBeaked
任务是否分解
task
对应的任务id
topTask
顶级任务
employeeId
执行人id
deadLine
任务提交最后期限
childrenTasks
由此任务执行人分解生成的子任务集合
3.3任务组管理
3.3.1业务概述
图3-3任务组管理用例图
在实际工作中,我们经常把完成同一项任务的人划分为一组,或者把经常合作的人按类型划分为一组,这样便于在任务执行过程中进行管理。
在本系统中,用户可以自己创建一个任务组,组员可以是同一个团队(例如08381班全体同学)的成员,也可以是同一工作角色(例如计算机学院所有学习委员)。
任务组创建完成后,用户便可以向该任务组中添加任务执行成员。
当系统存存在大量不常用的任务组时,用户可以删除这些不常用的任务组。
任务组之间有层次关系的,当上级任务组被删除后,下级任务组也会自动被删除。
已存在的任务组,由于客观因素需要更改名称时,用户可以根据实际情况修改任务组的名称。
另外,在任务组删除或重命名时,必须是创建此任务组的用户才有权限执行操作。
以下表格是每个用例的详细描述。
用例名称:
新建任务组
活动者:
任务发布人
用例目标:
完成任务组的创建。
前置条件:
新建任务组界面必须处于激活状态且有正确的数据。
后置条件:
系统创建任务组并输出创建结果。
事件流
活动者
系统响应
基流
当用户点击菜单“新建任务组”时,用例启动。
1.系统提示用户任务组信息,选择任务组组员。
2.用户指定任务组相关信息。
(E-1)
3.用户依次选择任务组组员,提交。
4.系统创建任务组,输出新建任务组的确认信息提示用户确认。
5.用户点击确认。
(E-2)
6.系统保存任务组相关信息,提示任务组创建成功。
替代流
E-1:
如果任务组名称与已存在的任务组重名,不能创建任务组。
E-2:
选择
1.[用户点击取消]用户组信息有误,用户请求取消。
2.跳转至步骤2。
表3-12新建任务组用例描述
用例名称:
重命名任务组
活动者:
任务发布人
用例目标:
完成任务组的重命名。
前置条件:
任务组管理界面必须处于激活状态,有正确的数据且用户选中待修改的任务组。
后置条件:
系统在输出窗口输出结果。
事件流
活动者
系统响应
基流
当用户点击菜单“重命名任务组”时,用例启动。
1.系统显示任务组信息组名编辑界面,提示用户更改任务组组名信息。
2.用户输入任务组新的名称。
3.系统暂存任务组,输出重命名任务组的确认信息提示用户确认。
4.用户点击确认(E-1)
5.系统保存任务组相关信息,提示任务组信息组名修改成功。
替代流
E-1:
选择
1.[用户点击取消]用户组信息有误,用户请求取消。
2.跳转至步骤2。
表3-13重命名任务组用例描述
用例名称:
删除任务组
活动者:
任务发布人
用例目标:
完成删除用户指定的任务组。
前置条件:
删除任务组界面必须处于激活状态且有正确的数据,且任务组必须是当前用户创建的,当前用户才有资格删除此任务组,其用户创建的任务组,没有权限删除。
后置条件:
系统删除任务组,提示任务组已删除。
事件流
活动者
系统响应
基流
当用户点击菜单“删除任务组”时,用例启动。
1.系统显示用户由创建的任务组,提示用户选择待删除的任务组。
2.用户选择待删除的任务组,提交。
3.系统提示用户是否删除
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 需求 规格 说明书