采购支付内部控制子系统物理建模阶段的主要工作是依据逻辑建模阶段形成并通过论证的需求报告，通过设计，将内部控制系统的所采用的理想的控制流程、控制内容、控制方法、控制关键点的设置等通过设计方案描述出来，以利于随后实施阶段工作的顺利进行。
4.3.1 设计的过程
内部控制工程方案设计主要是依据需求报告，经过需求分析过程，编写概要设计说明书、详细设计说明书、管理文档等。
在物理建模阶段，需生成多种设计模型，为实现的系统提供设计蓝图，对模型进行分析和评估，判断它们能否满足需求，根据这些模型，编制或修改后续的实施计划和测试计划。
采购支付内部控制系统的设计分为架构设计和详细设计。
架构设计（或称总体设计或概要设计）用于描述系统最顶的结构和组织形式，标识系统的各个组成部分，各组成部分的关联和牵制，主要是面向系统的整体设计，需有系统观和整体观，利用结构化方法进行；
详细设计用于描述每个组成部分的内部结构，用于指导设计人员具体设计每个部门、岗位的控制细节，便于局部的控制目标的顺利实现，强调微观设计、流程改造和细节的设置缜密而简洁，需要有全面性和高效性，利用面向职能法进行。
本系统架构设计和详细设计因比较简单，故合而为一，形成一份文档，即设计说明书，进行一次评审。
设计采购支付内部控制子系统分为四个具体步骤，即问题描述、确定对象、建立对象关系、填制分析/设计工作表格。
（1）问题描述和讨论。
描述采购支付系统内部控制系统所要面对和解决的问题，包括内部控制的特点、风险，探讨应对内部控制风险所要采取的措施和活动，并分析其合理性和可行性，用规范化的语言对需求报告中的流程描述进行重新描述，将内部控制活动的具体内容，分解为便于理解的短句，每句都为主动语态的短句，且主语、谓语、宾语唯一，以进行对象筛选、确认的工作，便于后续的工作人员的理解和沟通。
（2）确定对象。
将问题描述与讨论阶段最终生成的描述性主动语态短句作为研究对象，用基于语言的信息分析方法（LIA）① 进行进一步的研究。从采购支付的四个子作业（采购请求、采购订货、验收、采购结算）中确定内部控制对象（包括内控主体、内控客体、内控工具）、对象的行为。
（3）建立对象关系。
对需求报告中的组织结构、流程描述进行进一步的分析，确定内部控制主体或客体所完成的工作及活动的顺序，描述他们行为的时间序列和相互间的牵制、协作的关系。
描述对象所完成的工作及对象活动的顺序，对象间的行为具有时间和逻辑的关系，对象行为的时间序列以及相互间的牵制、协作通过系统的动态视图表现出来。还可以使用另一种常用而简便的方法，即将第二步确定含有对象的规范化语言进行拓展，将其行为加上前提和后续，再进行语法分析，从中找出对象间或行为的关系，如物流部门根据请购单和实际库存编制采购单转交采购部门，此句中，可看出物流部门是主语，编制是行为，根据请购单和实际库存是编制的行为前提，转交是下一行为，采购部门是编制采购单行为的牵制、监督单位或控制主体。
（4）将分析结果填入分析/设计工作表格。
采购支出子系统分析/设计的工作表格需填制功能名称、部门、输入、输入部门、工作处理、输出、输出部门等七项。其中输入和输入部门是本部门的控制客体，输出和输出部门是部门本次处理工作的监督部门或控制、牵制主体，处理是控制内容。
4.3.2 设计的方法
（1）整体架构阶段的设计方法。
××公司采购支付内部控制子系统仍然涉及到多个部门，也可以将其作为阶段性的完整系统，可以采用结构化设计方法（StructuredDesign，SD）或称模块分解的方法进行整体化的分解，结构化设计方法常用于设计系统的整体结构，根据系统分析资料确定系统应由哪些子系统或模块构成，采用何种方式联结，如何连接。
在应用结构化方法进行模块分解时，应遵循下列原则①：
①提高模块的独立性，降低模块间的耦合，提高模块的内聚来达到，如对订购单的审批，不能在环节中多次流转，会消耗时间，降低系统运转效率；如将支票打印做到验收部门，可有效减少业务处理环节，提高结算效率。
②模块规模适中，部门人员太多会造成责任不清，沟通混乱，太少会增加管理的层级。
③扇入扇出适当②。扇出过大，表明分解太细，需要控制和协调过多的关联模块，工程学经验表明，当扇出大于7时，出错率会大幅上升，效率会急剧下降；扇出过小，管理组织层次过多，会造成信息传递，管理意图贯彻滞后；以3~5为宜。扇出过大的模块，可以增加中间层次的模块。扇出过小的模块，可并入其他模块。当然分解或合并时应遵循模块独立的原则。扇入大的模块表明其重要性高，是核心部门，也是内部控制重点，需重点关注。
模块化方法是工程领域广泛应用的设计和实施方法，它的好处是多方面的，我们前面已多次提及，在此不再赘述，总的来说，模块化方法一方面可以降低了系统的复杂性，使得系统容易理解和修改；另一方面推动了系统各个部分的并行开发，从而提高了系统的建设效率。
（2）详细设计阶段的方法。
在用结构化设计方法将系统划分为易于实现的子系统后，利用面向对象方法来实现各个子系统的设计。在详细设计阶段，利用面向对象方法完成两个环节的工作：首先利用面向对象分析（Ob-ject-OrientedAnalysis，OOA）细化总括分析阶段未触及的部门或子系统的细节问题，主要完成对象识别、筛选、确定、对象关联的工作，然后利用面向对象设计（Object-Oriented Design，OOD）来具体实现。
在内部控制系统中，我们以职能对象为主体进行研究，即面向职能设计，可以应用用例图来进行。用例图是对用户（称为活动者，在内部控制系统中为内部控制的行为人）所影响的系统功能建模。用例是行为人和系统之间的相互影响、条理分明的功能单元，目的是列举活动者和用例，显示活动者在每个用例中的参与情况。用例模型是把应满足用户需求的基本功能聚合起来表示的工具。对于正在设计的新系统，用例描述系统应该做什么；对于已设计完成的系统，用例则反映了系统能够完成什么样的功能。用例模型的基本组成部件是用例、角色和系统。用例用于描述系统的功能，也就是从外部用户的角度观察，系统应具有哪些功能，是对系统功能的宏观描述。一个完整的系统通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有的基本功能，用例的相互衔接构成系统的业务流程。角色是与系统进行交互的外部实体，可以是控制主体、控制客体（包括公司的客户）。系统的边界线以内的区域，即用例的活动区域，表示系统能够实现的所有的基本功能。系统运转的大致过程是外部角色将自己的意图输入用例或用行为驱动用例，用例执行所代表的功能，执行用例的过程中或过程后，用例返回给用户一些值，这些值可以是用户需要的来自系统的输出。我们以订购为例演示用例图的用法。
绘制完用例图后，还要对用例进行描述。
4.3.3 设计的管理过程
设计管理的中心任务是保证设计方案或成果实现内部控制系统的目标，遵循系统的需求，确保设计方案的合理性、可行性，保证在方案实施时的成本、进度、信息沟通在预想的范围内。设计管理贯穿于物理建模的全过程，包括设计确认、设计评审、设计跟踪和设计变更。其主要目的和思想与需求分析的管理相同，区别主要在于参与者的构成。设计管理过程包括设计确认、设计评审、设计跟踪和设计变更。
（1）设计确认：
设计阶段开始后，需指定明确的负责人，负责与使用者及其他关联模块的建设者协商并确认设计方案，对方案中的各个细节确认其可行性、合理性和必要性。
（2）设计评审：
在形成设计方案后，需组织相关人员对设计方案进行评审，评审成员一般包括决策者、管理者、使用者、其他关联模块的参与者，如果系统是外包建设，对需求的评审，除了后续工作的参与者如开发者与使用者外，还可以邀请独立的第三方参加，如专家，同行。评审的对象是初步的设计方案，包括设计文档、设计说明文档。相关的评审人员通过阅读找出其中的错误、难以实现的环节、表达不清以及与总体目标不符的地方。
（3）设计跟踪：
是跟踪不符合项的改正情况，获得设计工作的实现状态，确保设计工作满足进度、质量、成本的需求。跟踪信息可为人员培训、审计、方案变更、关键成员离开、系统再设计等提供帮助，并可以减少风险和提高用户满意度。
（4）设计变更：
设计变更同样包括组织、业务、人员、环境等的变化，设计变更往往由需求变更引起，会发生在建设和使用的各个阶段，需遵照规定的变更流程进行，变更的设计方案和变更的过程要再次进行评审和跟踪。
