这个时候，简单的ToR已经不能够说明项目的范围，但可以采用多个ToR来加以说明。工作说明(Statement of Work)在这个时候诞生，开始取代ToR成为项目范围的主要工具。一个项目可能有多个Statement of Work(SOW)才能够有效说明项目包含的范围。例如要建立一个 “订单管理系统”的时候，这个系统可能包括销售部门，库存管理部门，会计部门，运输部门，生产部门等，这些部门也可能分布在不同的地区。

　　项目负责人首要是建立这个“订单管理系统”的范围，保证能够提供订单管理的的全部工作，所以会首先进行初步调查，理解一张订单从不同业务点如何把订单传送回销售部门，销售部门如何把订单信息转进仓库，如何结合现有库存管理系统，如何通知会计部门有关销售，如何通知运输部门需要送货，或者如何通知生产部门需要进行生产等内容。在与个别部门负责人完成初步访谈后会，理解订单在各个部门的进入点和输出点后才建立这个项目的工作说明(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中说明。如果用户认为一定需要增加这两个操作流程，那么项目的范围会变动，带出额外的工作量，额外的开发时间，额外的投资预算，修正系统的架构，增加软件模块，追加人力资源等等因应的后果。有能力的项目负责人会尽量说服客户把有关工作在目前的系统建设完成后才进行处理，避免延误项目的进度和交付日期。

　　这个系统集成的项目再一次说明如何从项目范围中建立有关功能需求。建立功能需求是软件从业人员的责任，不是客户或用户能够提供的内容。在完成人工操作过程分析订立系统的功能需求后，更要进一步考虑如何让科技提升企业的运营效率。也许在设计过程中发现当时的货品运送流程是从仓库直

上一页  [1] [2] [3] [4] 下一页