审计机构项目信息系统需求分析,软件工程硕士论文

　　第三章系统需求分析

　　需求分析是软件系统开发的首要环节，其任务是确定“为了解决这个问题，目标系统必须做什么”，主要是明确目标系统必须具备哪些功能。在系统开发过程中，需要通过需求来指导开发，确保项目开发朝着正确的方向推进。在项目结束后，需要通过需求来验证已完成的应用系统是否能够满足用户的实际需要[29]。因此，详尽、清晰的需求分析至关重要。

　　3.1 系统建设总体目标。

　　审计项目管理应用系统建设的总体目标是：在行政办公管理平台基础上，融入审计业务管理职能，以数字技术为手段搭建一个一体化综合信息管理平台。该平台具有审计业务支撑、审计办公管理、领导决策支持、审计信息共享等功能，以审计计划项目为基础，对审计项目实施、公文流转、审计决策、结果反馈等各环节进行全面管理和技术支持，在流程上实现审计项目的计划、立项、实施、审理、报告、统计、归档自动化，形成审计业务、管理、决策一体化[30]，实现审计管理与审计业务最大限度自动关联与耦合，实现各类审计信息的集中管理和应用，进而促进信息的交流和共享，使审计资源得到充分优化和利用[31]，进一步完善审计监督机制，提高风险防范能力，提高监管效果与效率，构建一个结构合理、安全高效、快速反应的审计项目管理平台，促进审计信息化建设持续、协调和全面发展。

审计机构项目信息系统需求分析

　　3.2 功能需求分析。

　　结合系统建设的总体目标，系统的功能需求主要体现在对人员角色进行合理设置的基础上，对审计项目计划、项目公文及项目信息进行管理，实现审计项目的集中管理，总体功能需求详见图 3.1。

　　3.2.1 系统管理。

　　审计项目管理应用系统采用“一站式”管理，通过将组织机构及人员信息维护到系统中来实现整个组织架构在系统中的数字化，每个人员在系统中都对应一个部门、一个账号。通过对组织架构的集中管理，根据业务需求对同类人员划分为一种角色，授予相关权限，以此来实现部门和人员的统一管理、功能权限的统一设置。主要包括部门、职务、角色和功能管理。

　　1.部门管理。

　　按照单位现有组织架构，由系统管理员统一维护部门信息和人员基本信息。按照目前各部门的主要职责与分工，将部门分为机关领导、行政管理和业务处室三个类别。其中：机关领导主要包括局长、副局长、副调研员等领导；行政管理主要包括办公室、人教处、监察室、法规处、经审处等综合管理部门；业务处室主要为具体实施审计项目的相关部门。

　　2.职务维护。

　　根据单位内部的行政关系，维护系统人员的职务。同时设置职务与角色的关联关系，一个职务可具有多个角色。职务设置完成后，需根据具体职务的使用需要进行使用授权。

　　3.角色人员。

　　按照审计项目管理流程，根据不同的业务需求将某同类人员划分为一种角色，以便进行日常的业务处理。审计项目管理过程中涉及的主要角色有：全局人员、项目计划管理员、项目计划分解人、项目计划审核人、部门负责人、法规处负责人、经审处审核人、法规处审理人、局领导、文印员、机要员等。部门、人员、职务、角色之间的关系如图 3.2 所示。

　　4.功能管理。

　　功能管理分为功能组管理和功能模块管理。每个功能模块有其对应的功能类型。在角色授权时，系统管理员可以根据对应的类型进行授权。以项目公文管理为例，对功能模块进行维护，如图 3.3 所示。

　　5.项目基本资料维护。

　　对项目中频繁使用的选项内容进行维护，主要包括：项目来源、项目类型、项目状态、审计人员类型、组织形式、审计内容、审计或专项审计调查、项目级别、项目类别、专业类别、数据库级别、资料类型、授权行业、计划年度等内容。在审计项目计划录入、项目计划管理等操作时，对上述选项内容可进行自行选择。项目基本资料的主要参数设置如表 3.1 所示。

　　3.2.2 项目计划管理。

　　项目计划管理要符合日常工作需要，主要包括以下业务功能：法规处计划录入、业务处分解、法规处审核确认、项目变更、项目实施、项目跨年滚动等内容。主要业务需求如图 3.4 所示。

　　1.法规处计划录入。

　　由法规处根据年度计划录入审计项目基本情况，主要包括以下内容：立项年度、计划性质、项目号、项目来源、计划年度、责任处室、项目名称、类型、重要审计项目（是/否）、保密期（默认 2 个月）、审核人员，计划编码等内容。

　　2.业务处分解。

　　相关业务处室在法规处已录入内容的基础上，根据审计项目基本情况和人力资源安排，完善下列信息：审计组组长、副组长、主审、审计人员（可以多人）、审计开始日期、审计结束日期、审计范围起始日期、审计范围终止日期、审计目标、审计重点、组织形式、备注等。

　　3.法规处审核确认。

　　法规处对相关业务处室填写的审计项目信息进行确认审核，审核完毕后项目组的成员即可起草各类审计文书，按项目进行分类管理。

　　4.项目变更。

　　新增审计项目或变更本人参与的审计项目的相关信息，对于变更的信息进行日志记录。

　　5.项目实施。

　　根据项目的实际实施情况，更新项目实施状态，实施状态主要包括未实施、审计中、待结案、已结案、调减 5 种状态。通过项目实施状态，对项目计划执行情况进行有效管理。

　　6.项目滚动。

　　对于年度尚未结案的审计项目，可以滚入下一年度继续实施。

　　3.2.3 项目公文管理。

　　1.文种维护。

　　根据审计业务流程，设置项目公文的文种类型及文书模板，方便发文时选择。

　　审计项目涉及的主要文种类型如图 3.5 所示。

　　2.项目公文。

　　项目公文即是业务公文的发文流转，要做到流程节点自定义，用户角色自定义，与特定的审计项目相关联，实现发送、审批、传阅等公文流转功能。项目公文流转流程如图 3.6 所示。

　　项目公文在 B/S 架构下必须支持在线编辑功能，且要求在公文流转过程中能够进行添加、修改痕迹的保留，在公文流转结束后公文能够进行清稿打印。同时提供各种公文模板的套用功能，方便审计人员方便快捷地完成文书的登记，提高日常办公效率。

　　3.默认项目。

　　用户可根据工作实际，将当前审计项目中的某个项目设置为默认项目，则可在项目公文、项目资料登记时将默认选中该项目，以提高工作效率和项目的组织管理程度。

　　4.业务流程定制开发。

　　审计业务流转过程中，根据不同业务需求，有不同的工作流。通过创建流程、定义流程节点和流程关系，实现工作流的程序化运行。主要包括以下三个环节：

　　流程创建：利用工作流引擎定义创建、编辑具有特定业务意义的流程，包括流程功能按钮定义、业务数据表及业务流转控制表定义。

　　流程节点定义：根据实际业务需求将业务节点进行数据化定义，即在实际业务中的每个工作事项在系统中实现工作节点的数据化，同时包括定义每个节点的执行角色，以及本节点的基本处理功能等设置。

　　流程关系定义：根据实际业务节点之间的关系进行数据化定义，定义后业务公文将按照定义的节点关系进行审批流转。

　　3.2.4 项目信息管理。

　　1.项目执行情况。

　　依据权限设定，查询本人参与的、分管的，或者经过申请授权可以查看的审计项目的信息，显示项目执行进度。

　　2.项目基本信息。

　　依据权限设定，选择相应审计项目查看项目基本信息。

　　3.审计项目档案。

　　根据审计项目档案归档要求，将审计项目执行过程中生成的各类文书和资料显示在相对应的审计项目的档案资料中，按结论类、证明类、立项类和备查类进行归档，并且可导出生成审计项目档案目录。

　　3.3 非功能性需求分析。

　　3.3.1 数据库优化。

　　审计项目管理应用系统是审计部门的业务数据库，随着时间的推移，业务数据的累积，系统的操作反应会受到影响，在系统设计与维护过程中，应充分考虑数据库性能优化[32]，以提高数据的访问速度。

　　3.3.2 稳定性。

　　保证数据存取和逻辑处理等不出现异常错误，确保 7×24 正常运转[33]。若因软件、硬件等故障导致平台无法使用，系统应及时切换到备份服务器中，保证平台的正常使用。

　　3.3.3 系统安全性和数据完整性。

　　防止恶意破坏或非法存取、使用数据，确保数据在处理、存储、传输等过程中不被篡改。防止错误信息的输入或输出造成无效操作或错误结果，能够及时恢复因人为误操作等引起的数据删除，确保数据的完整性。系统能够对输入的数据进行有效性、合法性校验，排除数据不一致的问题，从逻辑上保证数据的质量。

　　3.3.4 可扩展性。

　　在系统设计时，应充分考虑系统技术和业务应用的可扩展性，技术选择应建立在统一的标准和规范之上，采用开放的系统架构，以适应不同情况下用户的需求，使系统能够运行在多种不同的平台之上[34]。同时，系统设计必须在满足现有业务需求的基础上，充分评估今后的业务拓展需求，使系统处理能力能满足新增需求。

　　3.3.5 系统容错性。

　　系统容错是指应用系统对错误操作的承载性能，即系统操作时出现错误的概率和错误出现后得到解决的效率。系统对错误的操作或系统异常应能提供正确的响应，对可能发生的错误要进行正确的判断和分类，确定实现容错的范围，针对瞬时错误和永久错误采取不同的容错设计。

　　3.3.6 用户界面。

　　用户界面是对软件的人机交互、操作逻辑、界面风格的整体设计。它是用户与程序沟通的唯一途径，要能为用户提供方便、快捷、有效的服务。设计时，应做到：

　　（1）界面简洁：通过简化操作步骤、采用分类菜单等方式，便于用户理解和使用，用户只需要简单培训就能掌握系统操作要求，减少用户作出错误选择的可能性。

　　（2）界面友好：界面的结构必须清晰且一致，排列有序，相关数据项应存放在临近的位置。操作灵活、方便，具有互动多重性，合理设置快捷键。界面操作能正确地处理数据，界面表现真实。界面用语规范，前后表述一致[35]。

　　3.4 本章小结。

　　本章主要介绍了系统建设的总体目标和建设原则，并对系统的功能性和非功能性需求进行了详细的分析，重点介绍了系统四大模块的主要业务需求和功能，为系统设计奠定了基础。

返回本篇论文导航