系统需求规格说明书.docx

系统需求规格说明书.docx

《系统需求规格说明书.docx》由会员分享，可在线阅读，更多相关《系统需求规格说明书.docx（46页珍藏版）》请在冰豆网上搜索。

系统需求规格说明书

重庆理工大学计算机学院

文档编号

产品版本

密级

XK-DN-2000-10-11-11

V1.0

产品名称：

任务管理系统

共48页

任务管理系统项目

需求规格说明书

（仅供内部使用）

组长：

xx10803080203

组员：

xx10803080409

xx10803080122

xx10803080120

xx10803080128

指导教师：

xxxx

重庆理工大学计算机学院

2011年01月13日

修改记录

版本号

修改人

修改日期

修改说明

审核人

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上传附件

用例名称:

下载附件

活动者:

任务执行人

用例目标:

下载任务相关的附件。

前置条件:

当前用户是任务执行人且存