税务软件需求说明书的编写方法与实例
 

2009-04-28 作者:肖宁宁 殷非 杨元 来源:江苏国税网

 

近年来,我国税务行业信息化建设取得了很大进展,信息软件已经被广泛应用于税收管理的各个领域。一套好的税务应用软件与调研论证、需求、设计、开发、测试和用户使用有很大关系,这其中需求又是关键中的关键,以下结合笔者编写需求的一些经验,谈一谈如何进行税务需求说明书的编写。

一、确立需求编写组织。在需求编写前,按照需求的规模,确定需求编写人员的组成,建立需求编写组织。根据税务行业的机关特点,最好能够有中层以上领导(主要是起协调作用)参加,并担任需求组组长,其余主要由业务和技术人员(特别是有税务行业经验的资深技术开发人员)组成,根据经验,最好按照1:7:2来配置,以后可以根据需求编写的进展情况,确定是否需要增加和减少人员。

在南京地税“金力四期”项目中,需求编写由征管处处长担任组长,各分局业务骨干和计算机中心人员共同参与。

二、确定信息系统的边界范围。按照信息系统的设计要求,简要概括税务信息系统的业务功能包含的范围(实现哪些税收业务)和作用(达到怎样的管理目的),设计该套软件的依据是什么,以及该软件可以分成哪些部分以及每部分之间的主要关系,可以采用文字描述和框图、表相结合的方式来实现。如果在边界上存在与其他信息系统的关联关系,还需要描述边界之间的关系(如果存在功能和数据之间的共享关系,还要在最终的需求说明书中详细描述)。该部分内容应该由需求编写组资深专家完成,然后,在需求组内进行讨论,最终确定需求编写的边界范围。

南京地税“金力四期”项目税收业务的系统边界就确定为包括管理服务、征收管理、稽查管理等子系统在内的完整税收业务的税务信息系统,每个子系统又确定了自己的边界,表述上基本采用图表方式。

如:管理服务中的税务登记模块边界图(见下图):

图一:税务登记

三、确定需求编写组织的内部组成以及相互之间的协调内容。业务需求组组长确定业务需求组人员的分工,如果业务需求范围比较小,可以不再分组,如果需求定义的范围比较大,还需要进行分组,前期确认的人员不够,还可以增加新的人员。按照需求示范书的要求,需求编写组人员对具体内容进行业务需求的编写,在业务需求编写过程中,遇到需求与需求之间交叉的内容,业务需求编写人员要进行会议协调,以确定相互处理范围和内容,在需求中忌讳税收业务的交叉和需求流程不闭合。在需求编写过程中,如果编写人员对需求有不确定的地方,必须进行实地调研,以确定需求内容。

南京地税“金力四期”项目的需求编写组,由两个大组组成,一组主要由业务资深税收业务人员组成(该组内部又分如税务稽查、申报征收、税务管理等组),主要负责与用户交流,整理用户的要求,进行初步的提炼优化,填写本组的需求模板,传递到另一组并负责解释;另一组主要由技术人员组成,主要负责对前一组传递来的需求模板进行技术提炼,找出系统操作、系统性能等非功能性需求,形成用于开发的需求。对于技术上限制无法实现或对技术实现影响重大的功能也要反馈给前一组进行处理。

四、编写需求示范书和确定需求格式。在确定组织构成和需求编写边界范围以后,需求编写组有经验的需求编写人员要编写出需求说明示范书,示范书的内容要选取本次编写的需求中相对复杂部分,这样才能给其他组员有实际的参考意义,同时要确定业务需求的书写格式(章、节、段内容划分)、版式(字体大小、目录结构、图表、框架图的格式等)、模块与模块之间的接口格式(数据的入口和出口)。在完成该部分以后,要组织需求编写组人员进行培训,让所有参加人员掌握需求编写的基本方法和需求编写的统一编写格式。

南京地税“金力四期”项目,作为一个大型的税务应用软件,采用了两套需求示范书,制定了两套需求规格说明编写模板,一套用于和业务人员和操作人员交流,一套用于系统开发,前者的目标是让用户较容易理解,后者则更加专业化。在示范内容的选择上,选取了“税务登记”作为示范模块,该模块属于税收业务的最基础模块,与税户管理、稽查关系密切,业务涉及面宽;同时,该模块直接在业务前台使用,对系统的非功能性需求较高,关系着系统的基础架构设计,此该模块具有典型意义。

以税务登记作为例,结构如下(斜体字是原始需求,括号后边是解释,下同)

1 管理服务(章,管理服务)

1. 1税务登记(节,税务登记,也是大的功能模块)

以下首先采用框架图的形式来描述税务登记大模块包含的功能模块,每一个功能模块就是一节。

1. 1。1功能边界图(参见图一)

1.1. 2功能概述(以“开业登记”为例)

1.1.1开业登记 (功能模块,开业登记,模块划分到这一层就可以了,在模块内就是模块要实现的功能)。

首先要描述一下,该功能模块要实现的主要业务内容,内容要高度概括,为以后软件开发人员了解和掌握业务有非常大的帮助。(详略)

1.1. 3概要流程图

图2:开业登记

1.1.4 流程详细描述(略)

五、书写需求编写的详细内容。在具体业务需求编写编写过程中,只需要将目前比较合理的业务流程进行详细描述即可(当然,要考虑到以后可能的变化),在描述过程中要确定哪些是需要计算机完成的,哪些需要人手工来完成的。对于业务需求描述过程中遇到的表证单书,要详细说明表单如何填写和计算机是如何生成的,对于系统中可能用到的字典(税收术语、行政管理术语),要全面描述字典的内容,可以在主体需求中直接描述,也可以单独一章来说明。对于需求中涉及的分支流程和异常情况,需求说明中要分析清楚。在具体书写过程中,对于大型软件需求,可以采用版本控制的迭代编写方法,来渐进完善。由于现在大多数税务部门已经应用的信息系统较多,所以在需求编写过程中要注意需求编写的内容与现有信息系统之间的关系和数据资源共享问题。

南京地税“金力四期”在编写需求的详细内容过程中,使用了版本控制的迭代编写方法,对于涉及的详细内容进行了持续改进,逐步丰富的方法。首先从用户需求中确定合理流程,再对流程的节点进行分析,分离出表证单书,关键数据等。这步工作主要由业务资深专家需求组完成。以“税务登记”模块中“开业登记”的流程中“受理”的流程详细描述为例,说明一些关键注意事项:

1.1.1.1受理

一、征收分局征收所登记岗(这个非常重要,是以后软件实现后功能和数据权限控制的基础)收到纳税人登记申请时,针对纳税人不同类型,发放《税务登记表》(DJGL001-DJGL007,这个详细表单见表单章节,由于表单太长,不再列出,但要说明的是,在这张表单中,要说明一些重要的内容,如税务登记证号的产生规则,字典内容,如行业等),由纳税人填写完毕后,手工审核下列相应的附列资料,同时在计算机中注明报送的附列资料内容(这句话非常重要,确定了手工和计算机操作的范围,给软件需求分析人员快速识别计算机处理内容提供帮助):

(一)营业执照或其它核准执业证件原件及复印件;

(二)有关机关、部门批准设立的文件;

… …(以下由于文章篇幅,省略)。

对于来本县(市)从事经营活动的外地纳税人,凭所持的“外出经营税收管理证明单”办理纳税登记事项。其登记必须有期限。(对于需求中的分支,一定要说清楚)

对经初审不符合规定的,登记岗当即退回纳税人补正。

二、登记岗对《登记表》及资料进行初审完毕后,对经初审符合条件的,打印、发放《税务文书领取通知单》(DPWS001)(注明领取证件、登记表的期限,为30日。这句话也非常重要,确定了时间要求,给以后系统提醒和绩效考核提供数据来源)。登记岗于受理登记表后1日内,将登记表及附列资料交征收所管理岗。在《待批文书传递清单》(DPWS003)上标注已发出。对超过规定期限的已受理未发出户,用颜色注明,并每天出现提示。

三、登记岗在对《登记表》及资料进行初审完毕后,对经初审符合条件的“三资”企业,输入有关税务登记证中相关信息后(如,纳税人名称、地址、行业,限于篇幅,以下省略,在需求中一定不能出现“有关”、“相关”、“主要信息”,一定要描述出有关什么信息、相关什么信息、主要什么信息,便于软件需求分析人员确定内容),打印、发放发放税务登记证正、副本,注册税务登记证及其副本、临时税务登记证及其副本。在打印登记证完毕后,系统提示收取税务登记工本费。

由于税务登记受理比较简单,所以在流程描述中我们没有提供框图来表述,对于复杂的业务内容,如分之和控制要求较多的业务,无法使用语言描述来说清楚的,建议采用图形、语言结合的方式来说明,比如“金力四期”的申报征收需求就是采用框架流程。

六、详细描述非功能性需求。非功能性需求是描述软件中区别于应用软件的一些业务功能的要求,如特殊的易用性,可靠性,用户体验类有性能、操作习惯、业务的可能扩展等。该部分内容往往是需求编写人员忽略的内容,但这部分需求对于系统的技术架构实现有着非常关键的作用。因此,需求编写人员必须对系统的响应时间,特殊的易用性,可靠性,系统性能、用户操作习惯、业务的可扩展性,系统的兼容性等,详加描述,该部分最好由对有相当软件调试和维护背景且对业务精通的资深人员进行编写。

南京地税“金力四期”的“申报征收”业务提出了“前台开票”响应速度的非功能性需求,因此,在最终实现上,在“金力四期”大的B/S架构下,“前台开票”采用了三层体系的胖客户设计,保证了性能要求。以下说明申报征收开票部分的一些非功能性需求:

(1)申报录入全部要能够采用键盘小键盘实现;

(2)对于税目、子目要能够使用热键来实现快速帮助;

(3)从保存到结果返回(在1000万条记录情况下),能够在10秒内处理完成;

(限于篇幅,以下省略)

七、需求总串。当所有人员需求编写完成以后,需求编写组必须对所有需求进行总串,消除需求相互矛盾的地方、需求流程不闭合的内容、统一需求格式,总串的时间要充分满足,根据经验,一般要占整个需求编写的1/4时间。初期可以由一到两个人进行初步整理,然后,召开全体需求编写人员会议,对初步整理的结果进行详细审核,能够当场确定的,就及时修改,需要进一步讨论确定的,记录在案,会后进一步召开相关人员会议,确定修改内容,然后将修改的内容在全体人员会议上讨论确定。最终形成需求编写书。

八、需求书征求意见、反馈和完善。对于形成的需求编写文档,必须下发各个涉及到的业务部门进行需求内容的意见征求,需求编写组收集征求意见以后进行梳理,符合要求的,修订业务需求,不符合要求给出说明,反馈提交部门,最终形成正式的业务需求书。接着就可以交开发公司进行开发了,当然,在开发公司开发过程中,原来的需求编写的核心人员(特别是技术人员)还要负责对需求的解释工作,最好需求核心编写人员全程参加软件的开发、测试和推广工作。

南京地税“金力四期”项目,在软件开发阶段,专门成立软件开发项目组,包含业务和技术人员,这些人员主要就是前期需求编写人员,很好地保证了需求解释的连贯性。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织