××公司采购支付内部控制子系统逻辑建模阶段的主要工作是通过需求分析，将系统功能和性能的总体概念描述为具体的需求说明。
需求分析阶段的任务以缘由分析、流程、方案的简单阐述为主，这种简单描述一方面可以加快进度，另一方面需求分析需要多次评估、修改，技术性太强或太周密，不利于部分关联者的理解，因此，对流程、关键点设置进行详细描述的工作在设计阶段实现。
4.2.1 需求分析的过程
需求分析针对合同或立项建议书，以及对系统运行环境的调研、分析和确认，经过需求分析过程，编写需求报告及需求管理文档。
在需求分析做到采购支付子系统时，系统的整体目标、组织构成已经确定，系统的结构化分析也已完成，在此基础上，对采购支付子系统进行进一步的需求分析，应分四步进行，即问题识别、分析与综合、编制文档和测试审核。
（1）问题识别：根据企业的总目标和采购支付在系统的作用，调研和分析采购支付业务所涉及到的参与者的内部控制角度的目的、要求、活动、环境，以及与其他相关部门的联系和牵制。
（2）分析与综合：从采购支付的业务流和信息流出发，找出流程中各结点，确定它们的特性、联系，分析存在的合理性，是否需要改进，依据系统需求、环境需求，增删相应的环节，形成系统的解决方案，做出采购支付系统的逻辑模型。具体包括：
①研究利用整体系统的组织结构图，一般在进行本阶段时已完成，可以直接采用，本阶段主要细化采购支付子系统的组织结构模型，列出采购支付业务所涉及到的部门和岗位角色表。
②画出采购支付系统的流程图，包括信息流、业务流、资金流、物流，即业务模型。通过对系统流程的理解，可以分析各个部门或单位的职能、风险、关键点，进而确定采购支付系统的控制目标。
③确定采购支付系统的建设和运行环境。
（3）整理前两步的成果，并在此基础上编制采购支付业务的需求报告和需求管理文档。
（4）需求分析评审：对需求分析阶段的工作进行复查，对采购支付系统阶段需求描述的正确性、完整性、清晰性以及其他指标达成程度给予评价，由系统的参与者共同进行，协调一致后签字确认。
4.2.2 需求分析采用的方法
在进行需求分析时，应查找和筛选已掌握的需求分析的经验，向用户发放需求调查表格，深入到重点岗位了解需求，必要时参加实际的业务工作，整理文档，定期向用户中的操作层、管理层、决策层分别汇报，演示目标系统的控制流程、控制环节、控制措施，征求修改意见，最终形成需求分析报告。
在××公司采购支付内部控制系统需求分析的过程中，所采用需求分析方法有：
结构化分析方法：用于分解采购支付内部控制子系统涉及的组织结构。
面向流程分析法：用于描述简洁的采购支付的业务流、物流、资金流、信息流、控制流。
我们通常将需求分析分两个阶段进行，一是战略性的整体分析；二是详细的局部分析。在系统整体分析阶段，一般是以企业的组织结构和特点为依据，由分析师辅助决策层和管理层进行，通常是利用结构化分析方法的系统性、全局性的优点，在系统性需求的引导下，将系统划分为规模适宜、便于理解、相互关联的子系统；在对单独子系统进行进一步的分析时，一般是由分析师辅助部门经理、职员进行，通常利用面向流程的分析方法对业务流、资金流、信息流等进行研究，正确了解每个环节、岗位的控制目标与控制内容。
4.2.3 需求的管理过程
需求管理的中心任务是保证项目或产品满足系统参与者的需求，优质高效的建设、使用内部控制系统。需求管理贯穿于需求分析的全过程，包括需求确认、需求评审、需求跟踪和需求变更。
（1）需求确认：系统建设始于需求确认，需求管理要求指定明确的负责人，负责与使用者协商并确认需求，包括确认技术需求和非技术需求。技术需求描述系统的功能、性能、手段、方法等多方面的内容；非技术需求一般在协议、条件和合同条款中描述，包括提交的产品、日期和辅助说明等内容。
（2）需求评审：在将需求落实前，需要工程组评审需求，需求的评审一般需要使用者参与，评审的对象是需求确认的结果，包括技术需求文档、非技术需求文档。相关的评审人员阅读需求文档，找出其中的错误、不正确的假设、表达不清的地方以及与标准不符的地方。如果系统是外包建设，对需求的评审，除了后续工作的参与者如开发者与使用者外，还可以邀请独立的第三方参加，如专家，同行（是指和建设者在被评审的系统上有相同建设经验和知识的人员）。同行评审是工程学的重要经验，通过同行评审，提高了项目的连续性和可理解性，培训了后备人员，有利于系统的维护和升级。
需求评审的重点主要包括：需求是否描述清楚，不存在歧义；需求间是否存在冲突，以及它们之间的依赖关系；需求是否注明来源；需求评审结束标志着与客户协商确认需求的结束。
（3）需求跟踪：是跟踪不符合项的改正情况，获得需求目前的实现状态，确保用户的需求的满足程度。可靠的跟踪信息可为需求变更、系统维护、关键成员离开、系统再设计等提供参考和指导，并可以减少风险和提高项目成功率。用于追溯需求来源，预测需求的影响，当需求发生变化时，需求跟踪是分析影响的根据。需求应能向前追溯到它的发起人或原始的系统需求，向后追溯到实现它的具体工作和实体。
（4）需求变更：需求变更是难以避免的，即使比较成熟的企业也时常会发生变更，包括组织、业务、人员、环境等，需求变更可能会发生在建设和使用的各个阶段，会引起计划和项目的变更，需遵照规定的变更流程进行，变更的内容和变更的过程都需要进行跟踪。
