任务信息管理系统需求分析说明书【案例参考】(20210426051335)

1、技术文件 文件名称：任务管理系统需求说明书项目名称：任务管 理系统 （包括封面） 作者： 1引言 1.1编写目的 本文详细描述任务管理系统的需求，表述的需求信息要求明确、无二义性。 开发方与软件使用者充分沟通需求，最终形成此文档。此文档是后续软件开发的依 据。 1.2背景 任务管理系统是一个XX与XX电气新技术有限公司产学研合作项目，项目由XX 机电新技术有限公司提出，由XX承担开发任务。 13定义和缩略语 本文使用了表所显示的面向用户的术语、定义，包括通用词语在本文档中的 专用解释。 表1.1术语/定义 术语/定义 说明 开发方 XX 用户 XX电气新技术有限公司 用例图 反映用户与系统交互

2、情况的一种图形，常用于需求分析 表1.2所列为本文用到的缩略语 表1.2缩略语 缩略语 说明 TIMS 任务信息管理系统(Task In formation Man ageme ntSystem) XX XX机电新技术有限公司 1.4参考资料 本文使用了表1.2所列为本文用到的参考资料 表1.3参考资料 编号 资料名称 作者 1 项目概述 2 开发合同 3 XX提供的电子表格资料 15用户 任务信息管理系统的目前用户为XX公司电气事业部，电气事业部使用成功后 可 能会在XX公司推广。 2任务概述 2.1目标 XX公司电气事业部目前的任务主要有2类：常规工作任务和临时性工作任务。 针对临时任务布

3、置信息很多时候是处于一种开放状态，缺少任务信息的修 正、回馈、 和统计分析。而日常职责规定的常规工作，虽然可以通过标准化的文 件固化下来并形 成常规工作计划表作为一种制度来执行，也需要主管在百忙之中花很多时间去检 查完成情况。 TIMS系统要求工作管理信息能够规范录入，任务信息流向可以选择，任务信 息 依据轻重排序，可以设定信息提醒，任务完成情况可以评估、任务完成情况依 据选 择项进行统计输出、工作量进行评估。 2.2系统的特点 TIMS项目的需求主要由XX公司电气事业部提出，因此本文档是与XX公司 电气事 业部交互后形成的需求定义，系统的功能和使用特点优先满足XX公司电 气事业部的需求，若系

4、统后续由于在XX公司全面推广而引入的新需求，则不在本文 档考虑范围之内。 2.3假定和约束 本文档经双方确认后，开发方依据本文档进行下阶段工作。若中途需求发生变更 则XX公司需及时告知开发方，若因XX公司原因引入的需求变更造成开发方 工作量 的大幅增加，具体解决方案双方另行协商。若需求变更引入的工作量不大，开发方应 尽量配合。 4.需求规定 4.1组织架构 XX公司电气事业部的组织架构如图4-1 o 总经理 图4-1电气事业部组织架构 TIMS系统面向整个电气事业部使用，图 4T给出了电气事业部的详细组织。 4.2权限需求 系统的用户是XX公司的员工，员工在现实逻辑中分属不同的部门并具有相 应

5、的 工作权限。系统权限分配时与员工的组织架构并无对应关系。TIMS系统的 权限需求有2层含义。 1. 针对系统功能设置用户的操作权限。 2. 针对用户可以设置查看哪些任务的权限。例如可以设置某用户查看生产部 的所有任务信息；设置用户A可以查看用户B及用户C的任务信息。 4 43任务处理流程需求 431系统用例图 TIMS系统关 TIMS主要对任务信息进行管理，实现任务信息的标准化管理。 于任务处理的用例图如图4-2 任务信息管理系统TIMS A 任务接收者 图4-2系统用例图1 A 发布任务者 管理岗位用户 详细的功能需求说明请参见本文档后续章 节。 432任务处理流程 针对TIMS系统中任务

6、可能的流程进行分析。为方便理解，对应图 44进行 表述 DO D1 D2 图4-4人员组织架构示例图 流程设计思想： TIMS系统米用信息闭坏的思想，即任务由任务发布者发布出去，任务最终也在 任务发布者处结束，图45简单的表示了这一思想，同时也概括了任务在TIMS系统 中的处理流程。 任务承担者 任务下达采用逐级的层次方式，任务的反馈采用逐级向上的方式。 例如下达任务给制造组的Z3时，任务发布者X应该将任务发布给制造组的主管 Z0,由主管Z0在自己的主管范围内分配该任务，而最终的任务接收者是Z3。若Z3提 交完成情况和延期申请，则先提交至ZO,ZO根据实际情况决定是否提交以及如何提 交给Xo

7、X最终决定是否同意延期以及对任务完成情况进行评价。 具体任务处理规则说明如下: 1. 关于任务发布者 1) 默认的情况下，任务只能由组织的主管发布，且不能越级发布。例如 生产部主管SO只能给GO JO、Z0发布任务。假若最终任务T由Z1承担，那么 是SO向Z0下达任务，Z0再将任务T分配给Z1。 2) 系统可以设定用户可向哪些人员发布任务。 例如： 可以设定计划组的J1向ZO、GO发布任务； 可以设定SO向KO L0发布任务。 3) 可以设定用户直接向具体人员发布任务。 例如： 可以设定J1直接向D2发布任务。正常的发布顺序应该是 J1-ZO-DO-D2o系统自动记录任务相关人员ZO、DO,任

8、务延期、提交完 成情 况由任务承担者D2直接提交给任务发布者J1,但自动设定ZO、DO同 意延期 和提交完成情况。 2. 关于任务的分配和分解 1 )若任务的接收者是组织的主管，则可以将任务分配给其组织的直接下 属。例如制造组的主管Z0可以将任务分配给Z1、Z2、Z3,当然也可以分 配给自己，但不能将任务分配给D1,需要将任务先分配给DO,由DO再在自 己的组织进行同样方式的分配。（说明：图43中制造组主管Z0直接 下属是 ZO、Z1、Z2、Z3、DC） o 2 ）任务接收者接收到任务T后，可以将任务分解为若干子任务T1-Tn,然后 发布给本组织的员工。 3. 关于发布任务 1）任务接收者可以

9、有多个，必须设定一个主任务接收者。任务主接收者 体现 在任务的实际协调上。 2）任务接收者可以是组织的主管，也可以不是。如果是组织的主管则可 以分 配任务和分解任务。 3）任务的第一接收人是指最初接收到任务的员工。例如X发布任务给ZO, Z0 再分配任务给Z3。那么Z0为任务第一接收人，Z3为任务的承担者。 4）任务第一接收人在接收到任务后必须决定是否接收任务。只有在接收了任 务后，才能进行后面的分配任务和分解任务操作。若不同意接收任务则拒绝任 务。 5）任务的第一接收人有多个的情况，例如SO给Z0和J0发布任务To （1）主管Z0和主管J0必须作出是否接收任务的判定。 若Z0拒绝了任务T,则

10、SO处理Z0的拒绝信息，可以打回或者接 受 Z0的拒绝。若SO因为Z0的拒绝而修改了任务信息，则需要通知J0,如 果J0之前已经接收了任务，则可以针对修改后的任务信息再次 进行拒绝或 者接收操作。 （2）只有Z0和J0都接收了任务，则任务T的状态为进行状态。 （3）只有任务状态为进行状态Z0和J0才能分配任务。 4. 关于任务反馈 1 ）任务是逐级下达，任务反馈则是逐级汇报。 2 ）以X发布任务给ZO, Z0又将任务分配给Z1、Z2为例。 （1）Z1可以向所有任务相关人员（Z0、X、ZK Z2）发送信息。 （2）ZK Z2若要申请延期，则只能向任务分配者Z0申请。 (3) Z0收到Z1或者Z2

11、的延期申请后，处理此延期申请。Z0根据整个任务的进 度情况，来人为判断Z1或者Z2的延期是否对整个任务造成延期，若对整 个任务 不造成延期，不需要向X提出延期申请；若对整个任务造成延期，可以向任务发 布者X提交延期申请。任务发布者X最终决定任务是否延期。 (4) Z1X Z2向对应的任务分配者提交完成情况，Z1、Z2的工作由Z0评价，Z0 最终汇总Z1、Z2的任务完成情况，向X提交完成情况。X根据任务第一接 收人 提交的完成情况进行评价,同时对整个项目进行评价。 5 关于任务完成情况及评价 1) 由任务发布者决定任务的完成状态。 (1) 如果所有第一接收人在任务期限内都确认完成了任务，任务发布

12、者给出 每个任务接收的评价后，设定任务为完成。 (2) 如果第一接收人没有申请延期，但确认完成任务时间晚于任务期限，则 系统自动设定为非正常延期完成。 (3) 若任务在期限内没有完成，或者说任务已经不可能完成，任务发布者可 以设 定任务为未完成。 (4) 若有第一接收人申请了延期，且延期理由合理，任务发布者同意延期，并修 改任务期限。应设定任务为正常延期完成。 (5) 若有第一接收人申请了延期，但延期理由不合理，任务发布者不同意延 期。 应设定任务为非正常延期完成。 4.3.2.1任务发布流程 1. 任务第一接收人只有一个 so 任务知晓者完成任务、申请延期/ 分配任务 /Z0经讨评估后向X后

13、侍/ T M / / DO 分配任务 发布任务70 f、 / 分配任务 、 拒绝任务、 Z2 完成任务、申请延期 DO经过评估后向ZO反馈 完成任务、申请延期 向。反馈 完成任务、申请延期 向Z0反馈 D1 图4-6任务发布流程1 流程说明： 1) X发布任务给制造组的主管Z0,同时将任务抄送so,由于任务是初始发送给ZO, Z0必须决定是否接收才能进行后续操作。 2) Z0接收任务后，可以将任务分配给自己，也可以分配给制造组内用户， 如图43所示，Z0将任务分配给DO和Z2,而DO是工段1的主管，他仍然 可以将 分配到自己的任务继续向下属分配，DO将任务分配给了 D1o 3) D1的延期申请、完成情况均直接提交给其任务分配者DO,由DO对其完 成情况 进行评价。DO若认可了 D1的延期申请，则由DO向Z0提交延期申请，若Z0同 意了 DO的延期