在“软件及实施服务”主合同中已经明确了项目目标、地域、周期、费用支付这些业务内容的条款，也明确了保密、冲突等方面的法律条款。但在项目需求与范畴、实施计划、项目组织、需求变更、验收与交付、项目维护等方面并未给出明确且详细的界定，这些内容就需要在合同附件中给予细致的界定。
合同附件的价值就在于实现对主合同的补充，并将那些在主合同中无法详细表达的内容在附件中给予充分的表达，它是合同的一个组成部分。从法律的意义上讲，它并不因其为附件而丧失它的法律价值。
在信息系统建设中，许多企业的CIO总是试图通过合同把握项目建设中不确定性的内容，但是苦于没有好的方法，最终只好作罢，而合同的附件恰恰是把握方法的极好手段。作为企业的CIO，在项目推进过程中，最为关注的是“需求是否满足”、“实施是否按计划完成”、“系统能否稳定运行”三个方面的问题。
说明：“上面的这个关系图实际上是CIO在合同制定过程中所思考的内容。遗憾的是，绝大多数CIO在思考之后，并未将此图中的关联内容贯穿到合同中去，造成信息化合同由于不严谨而作用贬值。”
“需求是否满足”这个问题，受制于“标准软件适应性、客户化程度”两大因素，而标准化软件的适应性问题，已经在招投标过程中解决，企业大多选择了标准化软件中适应性最佳的产品。而其不适应的部分就是通过“客户化程度”多寡这个指标来表达，而客户化的好与坏又由“企业管理需求和软件开发方法”来决定。为此，要关注“需求是否满足”这个指标，那么就必须关注企业管理需求、软件开发方法。
同样，“实施是否按计划完成”这个指标受制于“客户化程度和实施计划执行度”两个因素，其中实施计划执行度的执行好坏又与“实施方法”的完备与否有很大的关联。为此，要关注“实施是否按计划完成”这个指标，那么就必须关注“企业管理需求、软件开发方法、实施方法”。
“系统是否稳定”是一个结论性指标，它基本上受制于“需求是否满足、实施是否按计划完成”，同时“软件的测试强度”等因素也是系统稳定的基础。这里特别将软件测试提出来，是由于国内软件商和实施团队对于软件测试都抱有一种漫不经心的态度（导致国内软件商品化进程不快的一个重要原因），但是它确实是影响系统稳定的一个核心因素。
由此可以看到，为保证合同的有效性、严谨性，在合同附件中需要关注“管理需求”的同时，也要关注另外两项很易被忽略的内容——实施方法和软件开发方法。企业的CIO必须注意，一个软件公司如果缺乏必要的实施方法，缺乏必要的软件开发方法，对于项目的实施的确存在很大的风险性。因此，在合同附件中要求乙方提供详细的实施计划，这个实施计划实际上就是方法论的完整步骤，而软件开发方法的灵魂性内容也将通过客户化开发计划表达出来，这就是附件中为何要关注这两个方面的核心因素。
一、附件一——《项目需求报告》
1.需求报告
《项目需求报告》中的核心是管理需求与软件功能列表，这两项内容在甲乙双方经过认真讨论和明确后将签署确认文件，并将需求报告和功能列表的详细内容作为双方《项目需求报告》认可的基础内容。项目需求报告和软件功能列表的具体框架内容如下：
1.企业基础管理模型
1.1 企业内部组织
1.1.1 企业组织结构
1.1.2 组织机构职责
1.1.3 组织对业务流动的制约
1.1.4 企业分销机构
1.1.5 企业仓储机构
1.1.6 企业制造机构
1.1.7 企业机构代码体系问题及现状
1.2 企业外部联盟
1.2.1 需求与难题
1.2.2 企业外部机构分类与编码体系
1.2.3 内外机构之间业务流图
1.2.4 内外机构间业务不畅的核心点
1.3 价格体系与规则
1.3.1 价格体系需求与难题
1.3.2 价格控制过程的疏漏
1.3.3 显性价格的管理难题
1.3.4 隐性价格的管理难题
2.业务流程需求与难题
2.1 采购流程需求与难题
2.1.1 需求与难题
2.1.2 流程与流程描述
2.1.3 相关核心规则
2.2 销售流程需求与难题
2.2.1 需求与难题
2.2.2 流程与流程描述
2.2.3 相关核心规则
2.3 制造流程需求与难题
2.4 仓储流程需求与难题
2.5 分销流程需求与难题
2.6 财务流程需求与难题
2.7 收付流程需求与难题
2.8 人力资源管理流程需求与难题
3.流程间业务处理需求与难题
3.1 流程间需求与难题综述
3.2 与销售流程间的关系
3.2.1 需求与难题
3.2.2 流程间描述
3.2.3 管理制度与规则
3.3 与制造流程间的关系
3.3.1 需求与难题
3.3.2 流程间描述
3.3.3 管理制度与规则
3.4 与仓储流程间的关系
3.5 与采购流程间的关系
3.6 与支付流程间的关系
3.7 与财务流程间的关系
3.8 与研发流程间的关系
4.各项调查明细
4.1 企业管理模型调查明细
4.2 企业业务流程调查明细
4.3 企业业务流程间关系调查明细
4.4 企业内外流程调查明细
4.5 企业的各种编码体系
5.管理需求下的软件功能明细
5.1 软件维护模块的功能明细
5.2 渠道管理功能明细
5.3 订单管理功能明细
5.4 库存管理功能明细
5.5 收付管理功能明细
2.需求管理
（1）甲方根据管理需求，对乙方分销系统提出软件需求，企业内部的需求调查报告。
（2）乙方对甲方所提需求开展调查研究，并经过需求分析后形成《项目需求报告》。
（3）《项目需求报告》经过正式评估后，作为乙方后续客户化开发、项目实施的基础。
（4）《项目需求报告》实行版本管理，并可以随时查询不同版本，并标注版本差异内容。
（5）《项目需求报告》实行变更控制，保证“软件需求的变更”处于受控状态。
（6）需求管理需要明确需求的提出部门，因此在项目需求报告中需要明确注明需求的来源，并且来源是可以重现的。
（7）需求管理需要明确针对乙方所形成的《项目需求报告》开展评估，评估工作由甲乙双方人员共同参加。评估过程主要关注如下内容：
需求描述。
①审查需求是否正确地反映了甲方的需求。
②审查需求是否完备地反映了甲方需求。
③审查需求是否是必要的，没有多余的。
④确认需求之间是没有矛盾的，是一致的。
⑤确认需求是无歧义的，不会引起误解。
⑥确认需求是可以验证、测试的。
是否可行
①确认需求在给定的软硬件环境下是可实现的。
②确认开发方案。
③开发成本、进度估算。
④确认开发风险。
（8）《项目需求报告》经双方组织的评估小组评估后，乙方应根据评估结论对需求做出相应的修改，修改完成后，由评估小组做出最终审核。审核后，甲乙双方评估代表共同签署审批意见。
（9）《项目需求报告》评估与审批，由甲乙双方成立的需求评估小组（临时）负责。其中，甲方人员由与软件应用相关的部门负责人和业务骨干担任评估小组成员，甲方评估负责人同时具有最终审批权力。
（10）《项目需求报告》应根据实际工作需求安排，建立需求实现过程的优先级，这一优先级的设定是为满足客户化工作的需要而设定。
（11）《项目需求报告》会根据实施过程的实际情况动态调整，一旦需求发生变更，双方应实施需求变更控制管理，针对变更内容，双方协商确认后，甲方提出变更请求，乙方修改《项目需求报告》并形成变更列表和需求说明。
二、附件二——《项目的组织》
领导小组组长由甲方领导担任，小组副组长由乙方领导担任，甲方领导小组组员由相关应用部门的负责人和信息部门主管组成，乙方领导小组组员由乙方实施小组组长和乙方客户化小组组长组成。领导小组负责项目的需求管理、实施管理、客户化管理等过程中的决策性内容。
2.项目实施各个阶段计划
项目实施的阶段计划需要根据乙方的实施方法论中所涉及的各项工作制定，这些工作必须细化到每个步骤的操作层面，例如：需求分析阶段，必须明确订单需求调研、订单需求写作、订单需求分析、订单需求功能分解等操作步骤，而不是笼统的订单需求调研。这样做的目的是为了保证在实施过程中明确每个操作步骤所花费的时间和人员安排，做到事事落实、事事有人负责、事事有时间安排，只有做好这些步骤，实施计划才能够体现出实施方法论的具体应用。
在各个阶段的计划中，包含需求分析阶段工作计划、流程调整阶段工作计划、教育培训阶段工作计划、系统运行模拟工作计划、切换准备与切换工作计划（试点实施阶段）、试点推广工作计划、验收与交付阶段工作计划。最后必须针对客户化工作的内容，给出详细的客户化工作计划，这个计划需要按照软件开发方法的步骤和要求制定。
所有的计划内容需要得到甲乙双方的认可并签字确认后再开展实施工作，这种运作方式的核心是双方可以根据各个阶段的实施计划安排人员和时间，避免过多地造成双方人员管理上的混乱和无序。具体计划内容如下：
项目实施各个阶段计划列表
1.需求调查与分析阶段详细计划
1.企业基础管理模型调研
1.1 企业内部组织
1.1.1 企业组织结构
1.1.2 组织机构职责
1.1.3 组织对业务流动的制约
1.1.4 企业分销机构
1.1.5 企业仓储机构
1.1.6 企业制造机构
1.1.7 企业机构代码体系问题及现状
1.2 企业外部联盟
1.2.1 需求与难题
1.2.2 企业外部机构分类与编码体系
1.2.3 内外机构之间业务流图
1.2.4 内外机构间业务不畅的核心点
1.3 价格体系与规则
1.3.1 价格体系需求与难题
1.3.2 价格控制过程的疏漏
1.3.3 显性价格的管理难题
1.3.4 隐性价格的管理难题
2.业务流程需求与难题调研
3.流程间业务处理需求与难题调研
4.各项调查明细分析
5.管理需求下的软件功能明细分析
3.教育培训阶段详细计划
4.系统运行模拟阶段详细计划
5.切换准备与切换阶段详细计划
6.试点推广阶段详细计划
7.验收与交付阶段详细计划
8.客户化工作详细计划
