在上世纪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)”的说明来牢牢地建立一个固定项目范围。
1
2
下一页>>
