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

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

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

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

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

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

如：管理服务中的税务登记模块边界图（见下图）：

图2：开业登记

1．1．4 流程详细描述（略）

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

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

1.1.1.1受理

（一）营业执照或其它核准执业证件原件及复印件；

（二）有关机关、部门批准设立的文件；

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

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

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

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

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

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

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

（1）申 录入全部要能够采用键盘小键盘实现；

（2）对于税目、子目要能够使用热键来实现快速帮助；

（3）从保存到结果返回（在1000万条记录情况下），能够在10秒内处理完成；

（限于篇幅，以下省略）

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

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

相关资源：金财助手开票 税软件一键 税-互联 工具类资源-CSDN文库