作为一个软件工程的专业人员，如何能够从客户所提供的模糊需求建立一个明确的范围，然后从这个范围中建立整个系统的功能需求，让我们可以控制软件开发的过程，减少项目的范围变动，降低开发过程中的修改需求，让我们能够按预算、按工期，提交符合质量要求的交付物，达到客户的预期目标，我们便需要理解问题的根源，打破过去的工作习惯，寻找一套可行的方法。

　　在项目管理知识体系(PMBOK)中我们学习范围变动管理，而不是需求变动管理，范围变动才是需求变动的主要原因。其实在这里PMBOK做了一个假设，就是有了明确的范围便可以建立明确的功能需求，如果能够控制范围，便能够控制功能需求。

　　功能需求变动是导致软件工程在开发过程中进行修改的主要原因，那是说我们在软件工程项目启动的时候没有把握好项目的范围，才会发生我们面对的问题。所以，我们首先需要理解范围与功能需求的关系，什么是范围?什么原因导致需求模糊?能够明确理解两者的异同，才能够找出解决的方法，建立明确的项目范围，转换成功能需求。让我们能够从模糊的需求转变成为明确的需求。

　　建立明确的项目范围代替不明确的范围，才能够减少开发过程中的修改。本人最近一直从过去30多年的科技项目开发和管理经验中，结合近年回国后对国内IT企业运营模式的理解，我国技术人员的工作习惯，客户的思维、心态和期盼，总结出一套建立明确项目范围的方法，特在此与读者分享，共同改善我国软件企业的困境(请参考希赛顾问黄绍良教授的《我国软件企业的未来生存空间》一文)。

　　70年代的项目范围与需求

　　项目范围与项目需求是两个完全不同的概念，但两者却不能单独处理。让我们回到上世纪70年代的时候，国外企业正进行自动化的过程。项目基本上是把人工作业流程转变成计算机程序。那时候并没有项目范围这个名称，我们用Terms of Reference (ToR)来界定项目的边界，采用文字描述的方法说明这个项目要做什么。例如，要为希赛公司建立一个库存管理系统，这个项目的ToR会说明货品从进入仓库开始，到货品因应生产或销售申领要求离开仓库为止，其中包括货品存入量的统计，存放位置记录，总库存量统计、申领数目、检货、提取货品、准备出仓，最后更新货品存量统计等工作过程。这个项目的Term of Reference只说明这个项目的范围，包括一些需要执行的工作和记录等。