下载文档原格式
项⽬范围管理5.1 范围管理概述 项⽬范围管理需要做以下三个⽅⾯的⼯作： （1）明确项⽬边界，即明确哪些⼯作是包括在项⽬范围之内的，哪些⼯作是不包括在项⽬范围之内的。
（2）对项⽬执⾏⼯作进⾏监控，确保所有该做的⼯作都做了，⽽且没有多做。
对不包括在项⽬范围内的额外⼯作说“不”杜绝做额外⼯作。
（3）防⽌项⽬范围发⽣蔓延。
范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项⽬范围的扩⼤。
5.1.1 产品范围与项⽬范围 1、产品范围是指产品或者服务所应该包含的功能，项⽬范围是指为了能够交付产品，项⽬所必须做的⼯作。
2、产品范围是项⽬范围的基础，产品范围的定义是产品要求的描述；⽽项⽬范围的定义是产⽣项⽬管理计划的基础。
3、项⽬的范围基准是经过批准的项⽬范围说明书、WBS和WBS词典。
4、判断项⽬范围是否完成，要以范围基准来衡量。
⽽产品范围是否完成，则根据产品是否满⾜了产品描述来判断。
5、产品范围描述是项⽬范围说明书的重要组成部分，因此，产品范围变更后，⾸先受到影响的是项⽬的范围。
5.1.3 范围管理的过程 1、项⽬范围管理主要是通过规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围六个过程来实现的。
2、范围管理各过程 3、范围管理各过程输⼊、输出、⼯具和技术5.2 规划范围管理 1、规划范围管理是编制范围管理计划，书⾯描述将如何定义、确认和控制项⽬范围的过程，其主要作⽤是在整个项⽬中对如何管理范围提供指南和⽅向。
2、规划范围管理过程的输⼊有项⽬管理计划、项⽬章程、事业环境因素和组织过程资产，使⽤的⼯具与技术有专家判断和会议，输出有范围管理计划和需求管理计划。
5.2.1 范围管理计划 1、范围管理计划是制订项⽬管理计划过程和其他范围管理过程的主要输⼊，包含如下内容 （1）如何制订项⽬范围说明书。
（2）如何根据范围说明书创建WBS。
（3）如何维护和批准WBS。
（4）如何确认和正式验收已完成的项⽬可交付成果。
项目范围控制措施引言本文档旨在提供项目范围控制措施的相关信息和指导，以确保项目按时完成、在预算内，并达到预期目标。
背景信息项目范围控制是在项目执行过程中管理和控制项目范围的一项关键活动。
范围控制措施旨在确保项目在规定的范围内，并能及时应对任何可能导致范围变更的因素。
范围控制措施以下是一些常见的项目范围控制措施，项目团队应根据具体情况选择和实施合适的措施：1. 项目计划的密切监控项目团队应密切监控项目计划的执行情况，确保工作按计划进行，并及早发现任何潜在的偏离。
如果发现范围外的工作正在进行，团队应及时采取措施纠正。
2. 清晰的项目需求定义在项目启动阶段，确保项目需求得到准确明确的定义。
与相关利益相关者和客户充分沟通，明确他们的期望和需求，并将其纳入项目范围中。
这样可以减少后期范围变更的可能性。
3. 范围变更控制对于任何可能导致范围变更的请求，项目团队必须遵循严格的变更控制过程。
此过程应包括对变更提议的评估、沟通和决策，并在批准后及时更新项目范围文档。
4. 有效的沟通和利益相关者管理项目团队应与所有利益相关者保持有效的沟通，包括项目范围的变更和控制措施的实施。
及时沟通项目进展、风险和变更将有助于管理预期和期望，防止范围蔓延和歧义。
5. 冲突解决和问题管理在项目执行过程中，可能会出现冲突和问题。
项目团队应采取适当的解决措施，确保冲突不会影响项目范围的控制。
建立有效的问题管理流程，及时解决和追踪问题，有助于防止范围失控。
结论项目范围控制措施是确保项目成功的关键。
通过密切监控项目计划、明确项目需求、严格控制范围变更、有效沟通和解决问题，项目团队可以有效地控制项目范围，确保项目顺利实施。
以上措施应根据具体情况进行调整和实施。
论项目管理中的范围管理摘要：从业的这些年里，经历过软件研发、研发管理、集成项目实施和实施管理。
经历的大大小小的项目，有非常成功的，也有不怎么顺利的甚至失败的。
项目的失败可能是有各种名样的原因导致的，但是否实施了有效的范围管理却是关键因素，本文论述我在多年工作中对项目范围管理的一些认识，希望与大家分享。
关键词：项目管理范围管理需求2008年我从研发部门调入实施部门负责实施项目管理工作，这之后整整一年时间，一直在努力完成一个投入不断增加、迟迟无法完成验收的项目。
推动验收的过程非常艰难，因为项目合同范围签得很虚很空，而项目过程中也没有签署相应的范围说明书及需求说明书，因此跟客户的每一次沟通在项目是否完成建设目标上都难以达成一致，双方对需求范围的理解和界定也无法达成一致。
每一次沟通，都会在原有的遗留问题或需求列表中多出新的内容来，项目组一直在不断地投入，期望最终客户能够满意，但是事实是随着系统的不断调整，客户方和项目组已经没有人能真正说清楚，这样的情况使得验收推动更加困难。
其实相信大家在项目管理的经历中，大多有过类似的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。
客户总是有新的需求要集成商做，就像客户在“漫天要价”，而系统集成公司则总是疲于应付，从而带来项目周期拖长、项目成本超出预算、客户满意度降低、公司信誉受损等一系列后果，甚至还可能导致项目失败。
实际上，造成上述问题的根本原因，就是因为项目没有执行有效的范围管理，即项目中没有就哪些该做，哪些不该做，做到什么程度等与客户达成一致。
信息系统集成项目特点之一是实施的周期长、对业务的依赖性强，特别是一些跨业务的项目，要完全把客户的全业务流程稳定下来，并通过系统实现，是需要较长的时间来巩固的，因此在项目实施过程中常常出现需求不稳定、需求变更，项目范围失控的现象，如果在此问题上没有一个“度”的控制，那么项目的范围将失去可控性，随之而来的是项目风险和成本的失败，最终导致项目的严重滞后甚至是失败。
项目管理中的项目范围变更与控制项目管理中，项目范围的变更与控制是确保项目在规定的范围内进行的关键过程。
范围变更的合理管理可以提高项目的成功率，确保项目目标的实现。
本文将探讨项目范围变更的必要性以及如何进行有效的范围变更与控制。
一、项目范围变更的必要性在项目实施过程中，可能会出现各种原因导致项目范围的变更。
以下是项目范围变更的主要原因：1. 客户需求变更：客户需求是项目范围的核心，如果客户在项目实施过程中提出变更需求，项目团队需要及时响应并进行相应的调整。
2. 技术变革：随着技术的不断创新，新技术的引入可能会改变项目范围。
项目团队需要根据新技术的发展情况进行范围的调整。
3. 外部环境变化：外部环境的变化可能会对项目范围产生影响，如法规政策的变更、市场竞争的加剧等。
4. 内部问题：项目实施过程中可能会出现内部问题，如资源不足、进度延迟等，这些问题可能需要对项目范围进行调整。
以上是项目范围变更的常见原因，项目经理需要与相关利益相关方进行紧密合作，及时做出决策，确保范围变更的合理性和可行性。
二、项目范围变更的过程项目范围变更的过程可以分为以下几个步骤：1. 变更识别：项目经理需要与项目团队成员、客户以及其他利益相关方进行沟通，及时了解到变更需求。
同时，需要评估变更的影响范围、时间和成本等因素。
2. 变更评估：在变更识别的基础上，项目团队需要对变更进行评估。
评估的内容包括变更对项目目标的影响、变更的可行性以及变更后项目成果的可交付性等。
3. 变更决策：根据变更的评估结果，项目经理需要与相关利益相关方进行协商，并做出决策。
决策的内容包括是否接受变更、对变更进行调整或者拒绝变更等。
4. 变更实施：一旦变更决策达成，项目团队需要开始实施变更。
实施的过程中需要与相关团队成员进行有效的沟通和协作，确保变更的顺利进行。
5. 变更控制：在变更实施过程中，项目经理需要进行变更控制，确保变更符合原有的项目目标和范围。
同时，变更控制还包括对变更进行跟踪和监控，及时纠正和调整。
项目管理中的范围控制和范围变更项目管理是一项复杂的任务，涉及诸多方面的规划、实施和监控。
其中，范围管理是保证项目顺利实施的重要环节之一。
范围控制和范围变更是范围管理中的两个关键过程，本文将对这两个概念进行详细的解析和说明。
一、范围控制的概念和重要性范围控制是指在项目实施过程中，对项目的范围进行管理和控制，确保项目实现既定目标。
范围控制的重要性不言而喻。
首先，项目的范围是确定项目目标、任务和交付物的基础，范围控制能够确保项目团队明确任务，并集中精力完成关键工作；其次，范围控制有助于控制项目的时间和成本，避免无效劳动和资源浪费；最后，范围控制有助于提高项目的质量和客户满意度，确保项目交付物符合客户的需求和期望。
二、范围控制过程范围控制是一个迭代的过程，包含以下几个关键步骤：1. 识别范围变化的发生：范围的变化是项目过程中难以避免的，项目经理需要及时发现范围变化的迹象，并对其进行分析和评估。
2. 评估范围变化的影响：对于发生的范围变化，项目经理需要评估其对项目目标、任务和交付物的影响，以确定是否需要进行范围控制。
3. 制定范围控制计划：根据范围变化的评估结果，项目经理需要制定相应的范围控制计划，明确控制范围的方法和措施。
4. 实施范围控制：根据范围控制计划，项目经理需要组织项目团队实施相应的控制措施，确保范围变化得到控制和管理。
5. 监控范围控制的效果：范围控制是一个持续的过程，项目经理需要定期监控范围控制的效果，并根据实际情况对控制措施进行调整和改进。
三、范围变更的概念和原因范围变更是指在项目实施过程中，对项目的范围进行调整和修改，以满足项目目标和客户需求的变化。
范围变更是项目管理中普遍存在的情况，以下是一些常见的范围变更原因：1. 项目目标的变化：由于市场竞争、技术进步或企业战略等原因，项目的目标有可能发生变化，需要对项目范围进行调整。
2. 客户需求的变化：客户在项目实施过程中可能会提出新的需求或修改原有需求，项目团队需要根据实际情况进行范围变更。
项目管理中的项目范围变更与调整项目范围变更和调整是项目管理中的重要环节，它们对于确保项目成功的实现起着至关重要的作用。
本文将从不同的角度探讨项目范围变更与调整的重要性、原因、影响以及有效管理的方法。
一、项目范围变更与调整的重要性在项目实施过程中，项目范围的变更与调整是常见的情况，它能够使项目更符合实际需求，增强项目的可操作性和可持续性。
项目范围变更与调整的重要性主要体现在以下几个方面：1. 满足需求变化：在项目实施过程中，需求是会不断变化的。
通过项目范围的变更与调整，能够满足变化的需求，使项目更加适应市场和用户的需求。
2. 有效分配资源：项目的范围和目标的变更会导致资源的重新分配，将资源更合理地应用到项目的关键领域，提高项目的整体效能。
3. 提升项目成果质量：范围变更与调整可以修正项目中的缺陷和错误，改进项目的实施计划，提升项目的成果质量。
4. 强化变革管理：项目的变更和调整可以被看作是主动的变革管理方式，它不仅能提高项目的稳定性，还能增加项目组织对变化的适应能力。
二、项目范围变更与调整的原因1. 需求变更：在项目实施过程中，需求会随着市场的变化或者用户的反馈而发生变更。
为了满足新的需求，项目范围需要进行相应的变更与调整。
2. 技术原因：新技术的出现或者技术方法的升级也可能引发项目范围的变更与调整，以适应新技术的应用要求或者改进项目实施的效率。
3. 组织策略调整：组织在项目实施过程中可能发生战略调整，例如市场竞争环境的变化或者目标重新制定，这会导致项目范围的变更与调整。
4. 风险控制：项目实施过程中的风险因素可能导致项目范围的变更与调整，以控制风险的发生和影响。
三、项目范围变更与调整的影响项目范围变更与调整对项目管理过程和项目结果会产生一系列的影响。
1. 时间与成本：范围的变更与调整通常会导致项目的时间和成本发生变化，需要重新评估项目进度和成本预算，并进行相应的调整。
2. 项目团队：范围的变更与调整会对项目团队的工作产生一定的影响，需要对项目团队进行沟通和协调，确保团队能够适应变更带来的需求变化。
软件项目开发过程中的主要项目风险及对策在软件项目的开发过程中，项目风险是无法避免的。
如果不加以应对和管理，这些风险可能导致项目的延误、超出预算或者质量问题。
为了确保项目的成功，开发团队需要提前识别和评估主要项目风险，并采取相应的对策来解决这些风险。
本文将讨论软件项目开发过程中的主要项目风险，并提供相应的对策。
1. 需求变更风险在软件开发过程中，需求的变更是常见的。
需求变更可能导致范围蔓延、进度延误以及影响团队的工作效率。
为了减少需求变更风险，项目管理团队应该与客户建立良好的沟通渠道，确保需求的准确理解。
同时，应该制定严格的变更控制程序，确保每一个需求变更都经过评估和批准。
2. 人员变动风险软件项目通常需要多个团队成员的合作。
但是，在项目的不同阶段，人员的变动是很常见的。
人员变动可能导致沟通不畅、工作延误以及知识流失等问题。
为了减少人员变动风险，项目管理团队应该制定合理的人员管理计划，确保人员变动对项目的影响最小化。
此外，应该建立项目知识库，记录和共享项目相关的知识和经验。
3. 技术风险在软件项目开发过程中，技术风险是无法避免的。
技术风险可能来源于技术选型不当、技术难题无法解决等问题。
为了应对技术风险，项目团队应该在项目初期进行技术评估，确保选择适合项目的技术方案。
同时，项目团队应该及时跟踪技术发展，学习新技术，以便在面临技术挑战时能够有所应对。
4. 进度风险软件项目的进度是非常关键的。
进度延误可能导致项目推迟交付、增加成本以及影响客户满意度。
为了减少进度风险，项目管理团队应该制定合理的项目计划，并严格按照计划执行。
同时，应该建立有效的进度跟踪机制，及时发现并解决进度延误的问题。
5. 资源风险软件项目所需的资源包括人力资源、物质资源以及财务资源等。
资源的不足可能导致项目延误或者质量不达标。
为了减少资源风险，项目管理团队应该在项目初期进行充分的资源评估，明确需要的资源类型和数量。
同时，应该与相关部门或者供应商建立良好的合作关系，确保资源的及时供应。
范围管理与变更控制范围管理与变更控制是项目管理中关键的流程，目的是确保项目的交付物和目标能够在既定的时间、预算和质量范围内完成。
本文将讨论范围管理与变更控制的重要性以及如何有效实施。
一、范围管理的重要性范围管理是项目管控的核心之一，它对项目的成功与否有着深远的影响。
范围管理的重要性主要体现在以下几个方面。
1. 确定项目目标和交付物：范围管理的第一步是明确项目的目标。
通过明确项目的目标，并将其细化为具体的交付物，可以帮助团队明确项目的范围及其界限。
2. 防止项目范围的蔓延：在项目的执行过程中，很容易出现范围的蔓延，即所谓的“功能脑裂”。
范围管理可以通过明确项目的边界，防止项目范围的不断扩大，从而保证项目的可控性。
3. 优化资源利用：范围管理可以帮助项目经理合理分配团队资源，确保资源的高效利用。
通过明确项目的交付物，可以避免资源的浪费，提高项目的执行效率。
二、范围管理的流程范围管理包括以下几个阶段的流程。
1. 规划范围管理：在项目开始之前，项目经理需要与团队成员一起制定范围管理计划。
这个计划包括范围确认的方法、范围变更的流程以及范围的控制和验证等内容。
2. 收集需求：在范围管理计划完成后，项目团队需要与利益相关者一起收集需求，并将其记录下来。
这些需求可以是项目目标、项目交付物的要求以及项目成果的期望等。
3. 确认范围：在收集完需求之后，项目团队需要与利益相关者一起审查并确认项目范围。
这个过程包括对项目交付物的详细描述和确定项目边界。
4. 控制范围：在项目执行过程中，项目团队需要对项目范围进行控制，防止范围的蔓延。
这个过程包括范围变更的识别、评估和决策，确保任何范围变更都按照预定的流程进行。
5. 确认交付物：在项目接近尾声时，项目团队需要与利益相关者一起确认项目交付物是否符合预期。
在确认交付物之后，项目才能正式结束。
三、变更控制的重要性变更控制是范围管理的一个关键环节，它确保项目范围的稳定性和可控性。
需求管理与需求变更控制技术需求管理是软件项目开发中至关重要的一环，它负责确保项目团队正确理解、收集和记录客户需求，并将其转化为可执行的任务。
同时，需求变更控制技术也是必不可少的，因为项目需求的变动是常态，如何控制变更并确保项目顺利进行是项目成功的关键。
一、需求管理的重要性需求管理涉及整个项目的生命周期，它确保了项目的目标和范围与客户期望保持一致。
以下是需求管理的重要性所体现的几个方面：1. 提高项目成功率：通过有效的需求管理，项目团队能够更好地理解客户需求，减少开发过程中出现的误解和沟通问题，从而提高项目成功的概率。
2. 降低开发成本：需求管理可避免项目在后期发现需求变更导致的重复开发或无效工作，从而减少了开发成本和时间的浪费。
3. 提高工作效率：清晰的需求管理可帮助开发团队更好地规划任务和工作流程，提高工作效率和质量。
二、需求管理的过程需求管理的过程包括需求获取、需求分析、需求规格说明书编写、需求验证和需求更改控制五个基本步骤。
1. 需求获取：在这个阶段，项目团队与客户沟通并收集相关需求信息，包括功能需求、非功能需求等。
2. 需求分析：对收集到的需求进行分析和分类，明确需求的优先级和相互关系。
3. 需求规格说明书编写：根据需求分析的结果，编写详细的需求规格说明书，包括需求描述、用例分析等内容。
4. 需求验证：验证需求是否符合客户的期望和要求，确保需求理解的准确性和完整性。
5. 需求更改控制：对于客户提出的需求变更，项目团队需要进行评估和控制，决定是否接受变更、如何影响项目目标等。
三、需求变更控制技术需求变更是软件项目中难以避免的，如何控制变更并确保项目稳定进行是需求变更控制技术的核心问题。
1. 变更评估：对于客户提出的需求变更，项目团队需要评估变更的必要性和影响程度，包括成本、资源分配等方面的考虑。
2. 变更记录与跟踪：所有的需求变更都需要记录，并追踪变更的原因、时间和结果，以便及时调整项目计划和资源分配。
如何管理软件开发过程中的需求变更在软件开发过程中，需求变更是非常常见的现象。
由于客户需求的变化、技术实现的不完善等因素，可能会导致原有的需求难以实现，或者需求本身也需要进行一定的调整。
而如何管理软件开发过程中的需求变更，对于保证项目的进展和最终的交付质量非常关键。
下面就为大家介绍一些应对软件开发过程中的需求变更的方法和技巧。
一、明确变更管理的标准要管理需求变更，首先需要明确变更管理的标准。
比如: 变更的定义、变更的申请流程、变更的评审标准、变更的实施要求等等。
只有做到变更管理标准的明确，才能更好的应对软件开发过程中的变更问题。
同时，要将变更管理的标准明确告知客户和项目组成员，让他们都能够清楚地知道变更管理的流程和实施要求。
二、及时发现和记录需求变更及时发现和记录需求变更是应对变更的最基本要求。
在软件开发过程中，客户的需求常常会有变化，而开发人员也需要根据实际情况进行相应的调整。
因此，在整个开发过程中，应该建立起有效的需求管理体系，及时收集客户的需求变更，记录下变更的具体内容、原因、解决方案等信息。
这样一来，才能够对变更进行有效的管理和控制。
三、准确评估变更的影响范围和风险一旦发现了需求变更，就需要对变更的影响范围和风险进行准确的评估。
对于每一个需求变更，都需要在评估范围内进行分析和评估，看看变更会对哪些方面产生影响，可能会引起什么样的风险等等。
只有做到这一点，才能更好地掌握需求变更的影响范围和风险，并针对不同的变更做出相应的决策。
四、严格按照评审标准进行变更管理变更管理要严格按照评审标准进行。
在变更管理的过程中，需要进行评审，评审的目的是确保变更的合理性和可行性。
只有经过评审的变更，才能够在后续的开发过程中得到实现。
因此，建立起一套严格的评审标准非常重要。
在评审的过程中，需要严格按照标准进行，确保评审结果的准确性和一致性。
五、灵活应对需求变更的具体实现方式在具体实现过程中要灵活应对需求变更。
一旦确定了需求变更，并经过评审审批后，就需要开始实施。
减低开发过程中的变动依赖项目范围管理作者：黄绍良来源：希赛网摘要：在上世纪70 年代后期，系统分析师、系统设计师，和其他从事软件工程的专业人员一直争取希望能够有一个国际公认的资格，类似会计师、律师、建筑师等专业的地位，但到了80 年代中期，这个议题已经不再存在，主要的原因是软件工程内包含太多专业，除了软件和硬件两大类之外，还渐渐包括网络，通信，数据库等多方面。
在上世纪70 年代后期，系统分析师、系统设计师，和其他从事软件工程的专业人员一直争取希望能够有一个国际公认的资格，类似会计师、律师、建筑师等专业的地位，但到了80 年代中期，这个议题已经不再存在，主要的原因是软件工程内包含太多专业，除了软件和硬件两大类之外，还渐渐包括网络，通信，数据库等多方面。
计算机从业人员开始体会及认识到本身的工作与会计师、律师、建筑师等专业资格可以在考核及认证后授予一定的权责，和建立一套环球衡量标准的模式是不一样的。
其实软件工程比较像艺术家，大部份的软件是模仿别人的成果加以个别的应用需求进行个性化的结果，把思维转变成交付成果的一门专业。
过去数年常听到一些软件从业人员的投诉包括：“他们（客户）基本上不知道自己的需求，怎么做他们都不满意，功能不断增加，如何能够完成他们的系统建设？”“他们（客户）上周说要这个功能，今天说要这个功能，为什么不全告诉我们，让我们可以不用在开发过程中不断更改！”一些类似的投诉只说明我们的软件从业人员基本上没有明白到范围建设的重要性，而且未能在项目启动前把项目范围建立起来。
范围与功能的分别在“如何把握不存在的需求”一文中，已经说明范围是有效管理需求变更的唯一方法。
有明确的项目范围，我们才能够学习及分析范围内的作业流程，建立系统的功能需求，并在开发过程中当客户要求变动的时候有效管理我们的工作范围，才能够有机会按照预算在指定的时间内完成项目的交付。
软件开发项目从开始到今天，一直以来客户都不能够告诉我们需要哪些功能，他们只能告诉我们系统需要完成哪些目标。
回顾“如何把握不存在的需求”一文中的第一个例子，20世纪70 年代的客户需要把库存管理进行自动化，收到的指示会像下例：“建立一套库存管理系统取代目前的人工作业流程”。
这一句指示是唯一任务说明。
系统分析员在接受这个任务后第一个工作是建立项目的Term of Reference （ToR）。
系统分析员会进行初步调查，通过简单的访谈，与库存部门负责人明确理解他们工作的开始点和终结点，得出的结果可能像下例：“从货品（包括原材料，半成品及制成品）进入仓库开始，到货品因应生产或销售申领要求离开仓库为止，其中包括货品存入量的统计，存放位置记录，总库存量统计，申领数目，检货，提取货品，准备出仓，最后更新货品存量统计等工作过程”。
这是所谓的Term of Reference，也是我们今天所认识的项目范围。
在用户及管理层认同上述的ToR 后，这个项目的负责人便需要估计需要对多少人进行访谈，需要多久时间进行访谈，需要多少时间对访谈结果进行分析，多少时间建立项目需求，编写需求说明书，需要多久进行系统设计，多少程序员及多少时间进行程序编写，如何进行测试，编写系统文档，编写用户手册，什么时候在仓库安装终端，如何连接主机，什么时候进行用户培训，如何让系统取代目前的人工作业等等有关工作计划及时间表。
在系统分析员完成访谈后，便需要依据访谈结果进行分析，理解什么时候知道有货品进入仓库，什么时候更新有关数据，如何更新，采用哪些表单，仓库人员如何决定货品应该存放在哪里，如何记录有关信息，如何知道需要检货，什么时候进行数据更新，如何分别哪些货品要去生产部门或者直接送到客户指定地点等等信息。
这些信息便成为系统在不同过程中所需的功能需求。
从上述的开发过程说明中可以体现功能需求并不是客户或用户提供，是系统分析员在理解目前的人工作业后分析出来的结果。
在系统移交到仓库中运行前，仓库中的工作人员需要对系统的操作进行学习及测试。
要知道当时仓库的工作人员并不是针对系统的功能进行测试，是对系统能否满足他们的工作过程进行测试。
基于这批工作人员对人于工作业的过程十分理解，如果系统未能提供一些他们操作过程中的日常工作，他们会要求技术人员对系统进行修改。
这个过程让我们误会用户是对功能需求进行测试，这个误会一直到今天让我们把系统开发的焦点错误地放在功能上，而不是系统的最终交付上。
而系统的最终交付是否能够满足ToR 的要求是当时项目成败的主要指标。
系统集成的范围及需求20世纪70 年代的项目多以部门单独运营为主，自动化的目的是提升部门本身的运营效率进行系统建设。
到80 年代，企业高层开始体会企业中的数据分散在不同的部门或子公司的部门中。
哪些数据是最新的？哪些是最准确的？应该采用哪个部门的数据做决定呢？如何整合这些数据，如何获得即时的数据，如何利用当时的区际网络（AreaNetwork），客户/服务端（Client/Server），遥程存取（Remote‐Access）数据库（Data Base）等科技来更有效提升企业的运营效率呢？这些问题提供软件开发项目进行系统集成及数据分享的工作，最终的目的还是环绕原来自动化提升企业（不单是70 年代提升部门）的整体运营效率为主要目标。
这个时候，简单的ToR 已经不能够说明项目的范围，但可以采用多个ToR 来加以说明。
工作说明（Statement of Work）在这个时候诞生，开始取代ToR 成为项目范围的主要工具。
一个项目可能有多个Statement of Work（SOW）才能够有效说明项目包含的范围。
例如要建立一个“订单管理系统（Order Processing System）”的时候，这个系统可能包括销售部门，库存管理部门，会计部门，运输部门，生产部门等，这些部门也可能分布在不同的地区。
项目负责人首要是建立这个“订单管理系统”的范围，保证能够提供订单管理的的全部工作，所以会首先进行初步调查，理解一张订单从不同业务点如何把订单传送回销售部门，销售部门如何把订单信息转进仓库，如何结合现有库存管理系统，如何通知会计部门有关销售，如何通知运输部门需要送货，或者如何通知生产部门需要进行生产等内容。
在与个别部门负责人完成初步访谈后会，理解订单在各个部门的进入点和输出点后才建立这个项目的工作说明（SOWs）如下：SOW‐1：连接业务点各终端到销售系统，建立当天的销售记录。
SOW‐2：连接销售系统与库存管理系统，容许销售部门查询仓库管理系统中有关货品库存量。
SOW‐3：容许销售部门在库存系统中预订货品数量以便运送到客户指定地点。
SOW‐4：容许销售部门指示库存工作人员进行检货，并通知运输部门有关订单的运送要求。
SOW‐5：在销售部门计算有关订单的总金额，运送费及保险费用，并生成发票送交客户。
SOW‐6：自动更新仓库货品储存量，如有关货品低于最低数时，建立货品生产通知单并传送到生产规划部。
SOW‐7：自动通知业务点有关订单发货日期。
SOW‐8：有关发票内容自动转发会计部门，建立有关应收账款记录。
SOW 并不是我们所说的系统功能，是在项目完结后这个系统所应该提供的最终目的。
以上的SOW 说明了这个项目的范围，包括的有关部门及现有系统的连接。
在客户确认后每一个SOW 将当作一个ToR处理，这个ToR 便成为整个系统建设项目中的一个子项目（也是子项目名称的起源）。
如何才知道我们建立的SOW 已经包含整个系统的各个部门，如何保证这个范围能够有效地提供一套“订单管理”的系统，这需要项目负责人对行业有一定的理解，同时为保证开发过程中能够控制范围的变动，在有关文档中明确说明SOW 所包含或不包含那些工作。
利用“包含（Inclusive）”和“不包含（Exclusive）”的说明来牢牢地建立一个固定项目范围。
在项目规划完成后，系统分析师便按照被分派的SOW 采用ToR 的调查方式进行深入调查，对有关工作进行访谈，理解有关SOW 的工作流程后对有关流程进行分析，并找寻初步的解决方案。
如何利用科技取代电话咨询库存量，利用科技取代传真把订单从业务部门传送回销售部门，或取代传真送货通知单到运输部门，取代内部文件传送发票副本到会计部门等等工作，什么时候需要进行数据收集，需要进行数据更新，需要打印发票或其它有关报告等工作便成为项目的功能需求。
如果在开发过程中，用户认为需要货品在运送完毕后，收货单应该自动确认有关应收账款的作业流程，或者需要增加万一退货后的订单处理操作流程时，我们便可以依据原SOW 来控制项目的范围变动，因为这两项操作流程并没有在项目的SOW 中说明。
如果用户认为一定需要增加这两个操作流程，那么项目的范围会变动，带出额外的工作量，额外的开发时间，额外的投资预算，修正系统的架构，增加软件模块，追加人力资源等等因应的后果。
有能力的项目负责人会尽量说服客户把有关工作在目前的系统建设完成后才进行处理，避免延误项目的进度和交付日期。
这个系统集成的项目再一次说明如何从项目范围中建立有关功能需求。
建立功能需求是软件从业人员的责任，不是客户或用户能够提供的内容。
在完成人工操作过程分析订立系统的功能需求后，更要进一步考虑如何让科技提升企业的运营效率。
也许在设计过程中发现当时的货品运送流程是从仓库直接送到销售部门，再由销售部门安排货品连同发票一起送到客户的指定地点，设计师可能考虑是否可以直接从仓库把货品运送到客户指定地点，销售部门另外把有关发票直接送交客户？这个改变会为企业带来多大效率改善？有了确实的构思后便需要说服用户这个系统如何能够更有效地完成有关货品运送的过程，要说服用户这些功能可以提升货品运送的效率和客户满意度，让销售部门和运输部门可以体会未来的工作流程将有所改变。
决定最终解决方案及用户认可后依据分析师的建议建立有关系统的功能，交由系统设计师对有关功能进行模块组合及逻辑设计。
到这里，我们可以清楚知道系统建设不是依据客户的需求而建设，是依据如何达到项目最终目的和项目的最终交付而建设。
需求不是客户或用户提供，是我们作为一个专业人员依据我们要开发的项目目标（如何达到）和项目的最终交付而制定出来的结果。
没有项目范围，我们便不能建立有关系统的功能。
没有项目范围，我们便不能控制任务的工作量，不能预估完成日期并按时完成。
从上述两个例子中可以看到，功能需求与业务流程直接相连的，理解了业务流程，便能够建立有关的功能需求，利用科技完成有关工作，提升运营效率，减低业务部门有关工作量和工作人员的需求。
软件工匠和软件工程师如果我们需要客户提供有关功能或需求才能够完成软件开发，那么我们便沦为软件工匠。
一个工匠，如木匠、泥水匠等都是依据客户的需求去完成任务的技术人员，这个工匠可以把工艺做到很好，很精，很细腻，成为一个很优秀的木工或泥水工，但永远不会成为大师，因为他们没有创思，没有沟通能力去说服客户如何能够更有效地达到客户的投资目的。
