SOW 并不是我们所说的系统功能，是在项目完结后这个系统所应该提供的终目的。以上的SOW 说明了这个项目的范围，包括的有关部门及现有系统的连接。在客户确认后每一个SOW 将当作一个ToR处理，这个ToR 便成为整个系统建设项目中的一个子项目(也是子项目名称的起源)。如何才知道我们建立的SOW 已经包含整个系统的各个部门，如何保证这个范围能够有效地提供一套“订单管理”的系统，这需要项目负责人对行业有一定的理解，同时为保证开发过程中能够控制范围的变动，在有关文档中明确说明SOW 所包含或不包含那些工作。利用“包含(Inclusive)”和“不包含(Exclusive)”的说明来牢牢地建立一个固定项目范围。

在项目规划完成后，系统分析师便按照被分派的SOW 采用ToR 的调查方式进行深入调查，对有关工作进行访谈，理解有关SOW 的工作流程后对有关流程进行分析，并找寻初步的解决方案。如何利用科技取代电话咨询库存量，利用科技取代传真把订单从业务部门传送回销售部门，或取代传真送货通知单到运输部门，取代内部文件传送发票副本到会计部门等等工作，什么时候需要进行数据收集，需要进行数据更新，需要打印发票或其它有关报告等工作便成为项目的功能需求。

如果在开发过程中，用户认为需要货品在运送完毕后，收货单应该自动确认有关应收账款的作业流程，或者需要增加万一退货后的订单处理操作流程时，我们便可以依据原SOW 来控制项目的范围变动，因为这两项操作流程并没有在项目的SOW 中说明。如果用户认为一定需要增加这两个操作流程，那么项目的范围会变动，带出额外的工作量，额外的开发时间，额外的投资预算，修正系统的架构，增加软件模块，追加人力资源等等因应的后果。有能力的项目负责人会尽量说服客户把有关工作在目前的系统建设完成后才进行处理，避免延误项目的进度和交付日期。

这个系统集成的项目再一次说明如何从项目范围中建立有关功能需求。建立功能需求是软件从业人员的责任，不是客户或用户能够提供的内容。在完成人工操作过程分析订立系统的功能需求后，更要进一步考虑如何让科技提升企业的运营效率。也许在设计过程中发现当时的货品运送流程是从仓库直接送到销售部门，再由销售部门安排货品连同发票一起送到客户的指定地点，设计师可能考虑是否可以直接从仓库把货品运送到客户指定地点，销售部门另外把有关发票直接送交客户?这个改变会为企业带来多大效率改善?有了确实的构思后便需要说服用户这个系统如何能够更有效地完成有关货品运送的过程，要说服用户这些功能可以提升货品运送的效率和客户满意度，让销售部门和运输部门可以体会未来的工作流程将有所改变。决定终解决方案及用户认可后依据分析师的建议建立有关系统的功能，交由系统设计师对有关功能进行模块组合及逻辑设计。到这里，我们可以清楚知道系统建设不是依据客户的需求而建设，是依据如何达到项目终目的和项目的终交付而建设。需求不是客户或用户提供，是我们作为一个专业人员依据我们要开发的项目目标(如何达到)和项目的终交付而制定出来的结果。没有项目范围，我们便不能建立有关系统的功能。没有项目范围，我们便不能控制任务的工作量，不能预估完成日期并按时完成。

从上述两个例子中可以看到，功能需求与业务流程直接相连的，理解了业务流程，便能够建立有关的功能需求，利用科技完成有关工作，提升运营效率，减低业务部门有关工作量和工作人员的需求。

软件工匠和软件工程师

如果我们需要客户提供有关功能或需求才能够完成软件开发，那么我们便沦为软件工匠。一个工匠，如木匠、泥水匠等都是依据客户的需求去完成任务的技术人员，这个工匠可以把工艺做到很好，很精，很细腻，成为一个很的木工或泥水工，但永远不会成为大师，因为他们没有创思，没有沟通能力去说服客户如何能够更有效地达到客户的投资目的。

希赛顾问团首席顾问张友生博士认为，一个专业的技术人员需要理解本身的专业能力，理解客户投资的终目的，理解如何更有效地达到客户的终目标而建议客户应该如何进行建设或改良，才有可能成为这个行业的大师。目前我国充斥着很多软件工匠，如果我们要把自己打造成为一个软件工程师，我们便需要放弃以前的思维，不用老是抱怨“客户不明确本身的需求，所以我们不能够完成项目的交付”。我们需要思考如何才能够把握项目的终目标，建立系统的功能需求。

从20世纪90 年代中期开始，计算机在企业中已经从自动化的时代进入信息化的时代，从科技的应用提升企业的运营效率，转变成科技应用所能带出来的价值，让企业能够减低运营成本，改善产品，提供增值服务，开拓市场，增加利润等成为软件开发的主要目标。

客户在决定投资一套软件系统建设的项目前，本身很明确知道希望这套系统能够带来什么价值，但对于如何能够利用科技来达到目标则一概不清楚。希望透过软件工程师的专业知识来告诉他们如何才能够满足他们的愿景，客户希望透过人工智能(AI)去理解顾客的采购习惯，背景，行为和对现有产品的反馈对产品进行改良;他们希望透过企业资源规划(ERP)来减低生产或运营成本，提升资源对企业的价值;希望透过客户关系管理(CRM)软件的应用来保留顾客对企业品牌的忠诚，增加顾客对企业的满意度。这些都是透过科技应用所希望带出来的普遍价值和投资愿景。但技术人员仍然停留在科技应用的层面上，希望客户能够告诉他们需要那些功能来达到这个愿景，让他们能够利用技术完成客户的系统建设。这些构思型或愿景型的项目如何进行交付，是上世纪末期开始对软件行业的一大挑战。

在这种情况下，技术人员如何能够满足客户的愿景，客户如何能够告诉技术人员有关这个投资项目的功能需求，变成项目在实施过程中不断进行修改，不断延误的主要原因。如何解决这个困境是当时急迫需要处理的难题。所以计算机行业新增加了一个岗位，叫做业务分析师(Business Analyst 或简称BA)，业务分析师应该有深厚的行业知识，透过BA对行业的理解，对愿景项目进行流程分析及建设，然后让技术人员对有关流程进行分析，建立功能需求，设计有关模块，为这些构思型或愿景型项目提供所需的基本信息。但可惜行业知识与技术知识两者还是有相当大的距离，BA 未能发挥应有的效益。美国PMI 也是在这个时候订立项目赞助人(Sponsor)及项目干系人(Stakeholders)的角色，在项目开发过程中，项目赞助人需要确认BA 的流程建议，需要取人系统建设每一个阶段的交付。项目干系人需要确认流程及系统功能不会影响部门的正常操作，两者要确保整个项目能够达到预期的交付愿景和目的。