软件需求规格说明书.docx
《软件需求规格说明书.docx》由会员分享，可在线阅读，更多相关《软件需求规格说明书.docx（16页珍藏版）》请在冰豆网上搜索。
软件需求规格说明书
<任务调度中心后台管理系统>
需求规格说明书
作者：
完成日期：
修订历史记录
日期
版本
说明
作者
V1.0
1.引言
1.1目的
该文档首先给出项目的整体结构和功能结构概貌，试图从总体架构上给出整个系统的轮廓。
同时对功能需求、性能需求进行了详细的描述。
便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。
本文档面向多种读者对象：
（1）项目经理：
项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。
（2）设计员：
对需求进行分析，并设计出系统，包括数据库的设计。
（3）程序员：
了解系统功能，编写《用户手册》。
（4）测试员：
根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。
（5）用户：
了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。
在阅读本文档时，首先要了解产品的功能概貌，然后可以根据自身的需要对每一功能进行适当的了解。
1.2背景
本次待开发的软件为任务调度中心后台管理系统。
用户通过使用该系统在移动终端完成任务分配等操作。
1.3概述
该平台是一个轻量级分布式任务调度平台，其核心设计是统一管理任务调度平台上调度任务，负责出发调度执行，并且提供任务管理平台。
1.4参考文献
[1]GB-T8567-2006，《计算机软件文档编制规范》[S]
2.项目概述
2.1产品特性
1、简单：
支持通过Web页面对任务进行CRUD操作，操作简单，容易上手；
∙2、动态：
支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，即时生效；
∙3、调度中心HA（中心式）：
调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群部署，可保证调度中心HA；
∙4、执行器HA（分布式）：
任务分布式执行，任务"执行器"支持集群部署，可保证任务执行HA；
∙5、注册中心:
执行器会周期性自动注册任务,调度中心将会自动发现注册的任务并触发执行。
同时，也支持手动录入执行器地址；
∙6、弹性扩容缩容：
一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
∙7、路由策略：
执行器集群部署时提供丰富的路由策略，包括：
第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；
∙8、故障转移：
任务路由策略选择"故障转移"情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
∙9、失败处理策略；调度失败时的处理策略，策略包括：
失败告警、失败重试；
∙10、失败重试：
调度中心调度失败且启用"调度失败重试"策略时，将会自动重试一次；执行器执行失败且启用"执行失败重试"策略，或回调失败重试状态时，也将会自动重试一次；
∙11、阻塞处理策略：
调度过于密集执行器来不及处理时的处理策略，策略包括：
单机串行（默认）、丢弃后续调度、覆盖之前调度；
∙12、任务超时控制：
支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；
∙13、分片广播任务：
执行器集群部署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；
∙14、动态分片：
分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
∙15、事件触发：
除了"Cron方式"和"任务依赖方式"触发任务执行之外，支持基于事件的触发任务方式。
调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。
∙16、任务进度监控：
支持实时监控任务进度；
∙17、Rolling实时日志：
支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志；
∙18、GLUE：
提供WebIDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。
支持30个版本的历史版本回溯。
∙19、脚本任务：
支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS等类型脚本;
∙20、任务依赖：
支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行,多个子任务用逗号分隔；
∙21、一致性：
“调度中心”通过DB锁保证集群分布式调度的一致性,一次任务调度只会触发一次执行；
∙22、自定义任务参数：
支持在线配置调度任务入参，即时生效；
∙23、调度线程池：
调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；
∙24、数据加密：
调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；
∙25、邮件报警：
任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
∙26、推送maven中央仓库:
将会把最新稳定版推送到maven中央仓库,方便用户接入和使用;
∙27、运行报表：
支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；
∙28、全异步：
系统底层实现全部异步化，针对密集调度进行流量削峰，理论上支持任意时长任务的运行；
2.2产品设计理念
当前各大行业人群密集，因大量繁琐的任务分配不及时而困扰，繁琐的根源便是邮件的收发、电话沟通，需要人工分配任务，最终人工汇总表格，工作量大且出错率高。
任务调度中心系统致力于通过平台便捷地完成此项工作，且大大降低出错率。
2.3用户特点
本系统的最终用户群体普遍接受高等教育，学习及适应能力强。
能快速适应该软件，并充分感受到在任务调度中心的效能变化，提出合理改进意见。
操作人员及维护人员为了解该工作的整体流程，深入用户交流，便于调整软件功能，实现客户需求。
2.4一般约束
进行本系统开发工作的约束条件如下：
1.开发周期短：
两个月的开发时间需要开发者合理规划时间，做到多项任务并发。
2.所采用的方法与技术有限：
项目团队成员的技术水平不够成熟，需要在开发中并发学习多种技术和能力。
2.5假设与依据
本项目是否能够成功实施，主要取决于以下的条件：
（1）团队成员的积极合作配合，为了项目的开发和实施，对个人时间进行合理规划同时为团队做出合理牺牲，配合队友完成任务。
（2）完整详细的功能和性能需求资料，以便于团队对其进行分析，从而形成完善的软件需求。
（3）团队掌握先进的能够适用于该项目的技术，这是系统的性能是否优化和项目能否成功的保证。
3.总体设计
3.1架构设计
3.1.1设计思想
将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。
将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。
因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；
3.1.2系统组成
调度模块（调度中心）：
负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。
调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块；支持可视化、简单且动态的管理调度信息，包括任务新建，更新，删除，GLUE开发和任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器Failover。
执行模块（执行器）：
负责接收调度请求并执行任务逻辑。
任务模块专注于任务的执行等操作，开发和维护更加简单和高效；接收“调度中心”的执行请求、终止请求和日志请求等。
3.1.3架构图
3.1.4调度中心HA（集群）
基于Quartz的集群方案，数据库选用Mysql；集群分布式并发环境中使用QUARTZ定时任务调度，会在各个节点会上报任务，存到数据库中，执行时会从数据库中取出触发器来执行，如果触发器的名称和执行时间相同，则只有一个节点去执行此任务。
3.1.5调度线程池
调度采用线程池方式实现，避免单线程因阻塞而引起任务调度延迟。
任务调度中心系统中业务逻辑在远程执行器执行，全异步化设计，调度中心每次触发调度时仅发送一次调度请求，执行器会将请求存入执行队列并且立即响应调度中心，异步运行；相比直接在quartz的QuartzJobBean中执行业务逻辑，极大的降低了调度线程占用时间；
任务调度中心系统中每个逻辑非常“轻”，单个一次运行平均耗时基本在"10ms"之内（基本为一次请求的网络开销）；因此，可以保证使用有限的线程支撑大量的并发运行；
理论支撑任务量公式如下：
理论支撑任务量=线程数配置/平均调度频率（每秒）*平均触发耗时（单位s）
实际场景中，由于调度中心与执行器ping延迟不同、DB读写耗时不同、任务调度密集程度不同，会导致任务量上限会上下波动。
如若需要支撑更多的任务量，可以通过"调大调度线程数"、"降低调度中心与执行器ping延迟"和"提升机器配置"几种方式实现。
3.1.6日志回调任务
调度模块的“调度中心”作为Web服务部署时，一方面承担调度中心功能，另一方面也为执行器提供API服务
3.1.7调度日志
调度中心每次进行任务调度，都会记录一条任务日志，任务日志主要包括以下三部分内容：
任务信息：
包括“执行器地址”、“JobHandler”和“执行参数”等属性，点击任务ID按钮可查看，根据这些参数，可以精确的定位任务执行的具体机器和任务代码。
调度信息：
包括“调度时间”、“调度结果”和“调度日志”等，根据这些参数，可以了解“调度中心”发起调度请求时具体情况。
执行信息：
包括“执行时间”、“执行结果”和“执行日志”等，根据这些参数，可以了解在“执行器”端任务执行的具体情况；
调度日志，针对单次调度，属性说明如下：
执行器地址：
任务执行的机器地址；
JobHandler：
Bean模式表示任务执行的JobHandler名称；
任务参数：
任务执行的入参；
调度时间：
调度中心，发起调度的时间；
调度结果：
调度中心，发起调度的结果，SUCCESS或FAIL；
调度备注：
调度中心，发起调度的备注信息，如地址心跳检测日志等；
执行时间：
执行器，任务执行结束后回调的时间；
执行结果：
执行器，任务执行的结果，SUCCESS或FAIL；
执行备注：
执行器，任务执行的备注信息，如异常日志等；
执行日志：
任务执行过程中，业务代码中打印的完整执行日志。
3.1.8任务依赖
任务调度中心每个任务都对应有一个任务ID，同时，每个任务支持设置属性“子任务ID”，因此，通过“任务ID”可以匹配任务依赖关系。
当父任务执行结束并且执行成功时，将会根据“子任务ID”匹配子任务依赖，如果匹配到子任务，将会主动触发一次子任务的执行。
在任务日志界面，点击任务的“执行备注”的“查看”按钮，可以看到匹配子任务以及触发子任务执行的日志信息，如无信息则表示未触发子任务执行。
3.1.9通讯数据加密
调度中心向执行器发送的调度请求时使用RequestModel和ResponseModel两个对象封装调度请求参数和响应数据,在进行通讯之前底层会将上述两个对象对象序列化，并进行数据协议以及时间戳检验,从而达到数据加密的功能;
3.2.0分片广播、动态分片
执行器集群部署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务；
"分片广播"以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
"分片广播"和普通任务开发流程一致，不同之处在于可以可以获取分片参数，获取分片参数进行分片业务处理。
3.2.1访问令牌（AccessToken）
为提升系统安全性，调度中心和执行器进行安全性校验，双方AccessToken匹配才允许通讯；
调度中心和执行器，可通过配置项"xxl.job.accessToken"进行AccessToken的设置。
调度中心和执行器，如果需要正常通讯，只有两种设置；
一：
调度中心和执行器，均不设置AccessToken；关闭安全性校验；
二：
调度中心和执行器，设置了相同的AccessToken；
3.2.2故障转移、失败重试
一次完整任务流程包括"调度（调度中心）+执行（执行器）"两个阶段
"故障转移"发生在调度阶段，在执行器集群部署时，如果某一台执行器发生故障，该策略支持自动进行Failover切换到一台正常的执行器机器并且完成调度请求流程。
"失败重试"发生在"调度+执行"两个阶段，如下
调度失败重试：
调度中心调度失败且启用"调度失败重试"策略时，将会自动重试一次；
执行失败重试：
执行器执行失败且启用"执行失败重试"策略，或回调失败重试状态（IJobHandler.FAIL_RETRY）时，也将会自动重试一次；
3.2.3任务超时控制
支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；
4.系统功能
4.1功能需求
4.1.1系统角色及登陆
该系统共有三种角色：
JobClient（作业客户机）,JobTracker（作业跟踪器）,TaskTracker（守护进程者）。
所有角色都具有登陆功能，根据角色不同登陆后进入各个角色所对应的页面。
1.登录界面
用户通过输入账号密码，点击登录，登录不同的账号自动判断角色，进入不同的界面。
2.JobClient:
主要负责提交任务和接收任务执行反馈结果。
3.JobTracker:
负责接收并分配任务，任务调度。
4.TaskTracker:
负责执行任务，执行完反馈给JobTracker。
4.1.2工作流程
1.JobClient提交一个任务给JobTracker,这里我提供了两种客户端API,一种是如果JobTracker不存在或者提交失败，直接返回提交失败。
另一种客户端是重试客户端,如果提交失败，先存储到本地leveldb（可以使用NFS来达到同个节点组共享leveldb文件的目的,多线程访问，做了文件锁处理），返回给客户端提交成功的信息，待JobTracker可用的时候，再将任务提交。
2.JobTracker收到JobClient提交来的任务，先生成一个唯一的JobID。
然后将任务储存在Mongo集群中。
JobTracker发现有（任务执行的）可用的TaskTracker节点（组）之后，将优先级最大，最先提交的任务分发给TaskTracker。
这里JobTracker会优先分配给比较空闲的TaskTracker节点，达到负载均衡。
3.TaskTracker收到JobTracker分发来的任务之后，执行。
执行完毕之后，再反馈任务执行结果给JobTracker（成功or失败[失败有失败错误信息]），如果发现JobTacker不可用，那么存储本地leveldb，等待TaskTracker可用的时候再反馈。
反馈结果的同时，询问JobTacker有没有新的任务要执行。
4.JobTacker收到TaskTracker节点的任务结果信息，生成并插入（mongo）任务执行日志。
根据任务信息决定要不要反馈给客户端。
不需要反馈的直接删除,需要反馈的（同样JobClient不可用存储文件，等待可用重发）。
5.JobClient收到任务执行结果，进行自己想要的逻辑处理。
4.2外部接口需求
4.2.1用户接口
本系统采用B/S架构，所有界面使用APP风格，用户界面的具体细在功能需求文档中描述。
4.2.2硬件接口
无特殊需求。
4.2.3软件接口
无特殊需求。
4.2.4通信接口
无特殊需求。
4.3性能需求
非功能性需求当前尚未形成完整文档。
4.4属性
4.4.1可用性
（1）方便操作，操作流程合理。
尽量从用户角度出发，以方便使用本产品。
如：
新增信息时，敲入回车键光标的自动跳转、输入法的自动转换，信息检索时输入汉语简拼快速检索到结果等。
（2）控制必录入项。
本系统能够对必须录入的项目进行控制，使用户能够确保信息录入的完整。
同时对必录入项进行有效的统一的提示。
（4）容错能力。
系统具有一定的容错和抗干扰能力，在非硬件故障或非通讯故障时，系统能够保证正常运行，并有足够的提示信息帮助用户有效正确地完成任务。
（5）操作完成时有统一规范的提示信息。
例如删除操作时，系统可提示警示框“您确认删除记录吗？
操作不可恢复！
”，用户点击确认后，系统才执行删除操作，删除后可直接返回相关页面。
4.4.2安全性
（1）权限控制
根据不同用户角色，设置相应权限，用户的重要操作都做相应的日志记录以备查看，没有权限的用户禁止使用系统。
（2）重要数据加密
对一些重要的数据按一定的算法进行加密，如用户口令、重要参数等。
（3）数据备份
允许用户进行数据的备份和恢复，以弥补数据的破坏和丢失。
（4）记录日志
本系统应该能够记录系统运行时所发生的所有错误，包括本机错误和网络错误。
这些错误记录便于查找错误的原因。
日志同时记录用户的关键性操作信息。
4.4.3可维护性
当前尚未形成完整文档。
5.系统开发计划和时间规划
该系统分为5个阶段执行，系统为期六个月，项目参与总人数为20人。
5.1系统启动阶段
此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成（大体为以上四个阶段）。
5.1.1成立项目组
一般项目合同签署完成后，公司会通过《项目实施流程表》先通过“市场管理中心”审核检阅，主要包括合同相关款项及系统签署的相应功能模块是否符合要求；审核结束后到项目部部门经理接到实施申请后，任命该项目的项目经理，指定项目目标，由项目经理指定项目组成员及成员任务，并报相关分管副总或者总经理。
5.1.2前期需求调研
项目经理及项目组成员，在商务人员或者销售人员配合下，建立与用户的联系，对合同中签订的系统主要功能模块进行调研。
确定客户他们的需求和期望，如何修改完善满足和影响这些需求、期望以确保项目能够成功。
若涉及到相关的硬件设备，在做需求调研的同时，需协调系统集成部门完成硬件服务器及网络环境的搭建。
5.1.3制定《项目总体计划》
《项目总体计划》文档主要介绍项目建设目标、主要项目实施阶段、里程碑、可交付成果。
通常包括以下几方面内容：
项目建设背景描述，项目建设目标、主要项目阶段、里程碑、可交付成果。
所计划的职责分配参与配合的相应客户人员；沟通管理计划，确定客户人员沟通的需要。
5.1.3启动会
项目组成员与用户共同召开的宣布该项目正式开始的会议
5.2需求调研确定阶段
此阶段的主要工作是项目实施人员向用户调研后用户对系统的需求，包括系统流程调研、功能需求调研、数据查询需求调研等，实施人员调研完成后，会编写相关文档，并交付用户进行确认并且签字确认，待用户对文档上所提到的需求确认签字完毕后，项目实施人员将提交该需求调研分析书给相关副总或总经理签字，签字完成后以此为依据提交开发进行软件功能的修改完善。
5.2.1进行需求调研前期准备
5.2.2制定《需求文档》
5.2.3内部评审是否通过《需求文档》
项目组、项目经理、销售等人员根据合同要求和项目实际情况对《需求文档》草稿进行评审，如评审通过，领导签字确认，如评审不通过则重新修改和客户再次确认相关细节。
5.2.4签署《需求文档》
签署《需求调研计划》，则作为以后需求调研工作的证明手段
5.2.5《需求文档》是否有变更
如果计划存在变更，则再次确认变更相关需求，否则按计划进行后续工作。
5.2.6需求开发实现阶段
此阶段主要是用户需求得到公司领导及通过公司内部评审通过后转交开发部门修改阶段，开发部门根据需求调研分析计划书具体要求去修改软件系统相应功能模块。
5.2.7软件测试阶段
此阶段主要是在开发完成后进行的系统功能测试阶段，以确保开发修改后的模块实现客户的相关要求及修改后是否存在相应的程序bug及功能性错误。
5.3系统部署安装阶段
此阶段主要是实施人员及测试部门人员共同完成的，实施人员提供系统部署的硬件环境及网络环境。
测试人员根据其环境要求先对系统进行性能型测试，满足要求后进行远程部署安装或者现场安装。
5.4系统培训阶段
系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以公司和用户双方要对此阶段的工作给予足够的重视。
要充分认识培训的重要性和艰巨性。
在项目实施之前对用户的相关人员进行系统和规范的产品培训是非常必要的，达到让用户了解软件产品具体操作，最终自己能够解决使用中的具体的问题。
5.4.1培训前准备
在培训开始前3天和客户沟通协调参与培训相关人员及部门。
5.4.2签署培训计划
署《培训计划》，进一步确认培训安排工作
5.4.3培训通知
将培训内容、时间，场地，人员等信息通知给他们，由他们通过具体参与人员。
5.4.4搭建培训环境
公司项目组在培训开始前，将培训环境搭建及检查妥当（投影仪、电脑），将培训提纲及培训手册准备好。
5.4.5培训考核
公司项目组培训工程师与用户（操作者）沟通，通过现场提问方式考核参训人员。
5.5系统安装测试及试运行阶段
5.5.1签署计划
用户签署《测试及试运行计划》，进一步确认测试及试运行安排。
5.5.2测试及试运行通知
当系统培训完成后，测试部门会进行二轮回归测试，主要确认系统部署完成后是否存在问题，同时用户已经完成培训，进行试运行阶段。
5.5.3组织测试及试运行
用户相关各级领导给予全面配合，组织相关人员进行测试及试运行。
公司项目组负责担当指挥，检查用户人员组织情况并给予指导，跟踪检查如下情况：
功能模块操作流程状况。
升级会员 