会员登录
会员注册
这段时间软件工程的焦点是在范围确认后的信息搜集(Facts Finding)和需求分析(Requirement Analysis)中。依据PMBOK的论述，我们在20世纪70年代，的确可以从范围的建立带出明确的功能需求，减少开发过程中的修改，降低项目延误的风险。这个模式在我国软件产业发展初期采用，大概是20世纪80年代后期至90年代中期的时间进行自动化过程。
80年代的项目范围与需求
到上世纪80年代中后期，国外企业的自动化过程已经接近尾声，企业开始整合部门的计算机系统，加上个人电脑开始取代终端，项目多数包括跨部门或跨地区的系统集成、综合数据库应用、远程计算(Remote Access)、网络连接等为项目主体。在这种情况下，传统的ToR已经不能够明确说明项目属于哪个部门，从哪里开始，如何才是项目完结。ToR已经不能够有效地界定项目的范围，所以，我们利用多个工作描述来说明，成为我们知道的工作说明“Statement of Works (SOW)”，其中包括项目开发过程中需要处理(inclusive)的工作说明和开发过程中不需要(NOT-inclusive)处理的工作说明，整合这些SOWs 后成为我们今天所认识的项目范围，利用工作说明以明确的语句来说明项目中包含的每一个工作内容。例如，在一个项目范围中包括的工作说明可能是:“连接A市及B市两地办公室的主机，通过A市数据中心的中央货品库存数据库，为A市工场和B市销售中心提供即时货品存量查询及货品预订功能”。
这些工作说明便成为这个工程需要提交的最终成果。利用项目范围中的SOW替代ToR，一个项目可以容许多个SOW来描述系统建设的内容，所有的SOW描述的建设内容都包含在这个项目的范围中。但实际上每一个SOW的结果如何实现，还是需要技术人员透过调查和进行分析后才能够清楚具体的操作该如何实现。每一个SOW的具体操作过程都成为这个SOW的功能需求。整合全部SOW的个别操作过程，才是项目的最终功能需求。
简明的说，每一个SOW都是一个小范围，它本身也不是一个需求。我们还是需要通过理解SOW的内容才能够把握这个SOW的需求。每一个SOW可以成为一个独立的项目，“子项目”的名称也是在这个时候诞生。
从上述的历程中可以看到，用户或客户告诉我们的永远都不是需求，是客户或用户希望在最后交付物中看到的部分成果，永远不会完整，只是客户或用户的部分期盼、愿景和目标。如果把这些期盼、愿景和目标当作了需求，那么我们永远不能在项目初期建立满足用户对交付物的期盼。需求从来不是用户或客户提供，需求是技术人员依据范围中需要实施的工作过程进行分析后寻找出来可以提交项目最终交付物的结果，然后才能够把这些需求转变成一个软件工程，在项目指定的范围中利用科技达到用户的最终目的。