项目管理的范围通俗的说是项目的实施边界,边界以里的归项目管理,以外的不属于项目.软件需求是指软件实现的功能,操作的方便性能、兼容性和可扩展性

通过需求开发来获取信息系统项目的需求，在此基础上确定项目的范围、进行项目范围管理。确定每一期应满足的需求后，该期的范围管理就有了基础。需求管理处理需求的变更，需求的变更会引起项目范围的变更。

在讲述项目管理课程的时候，归纳出一个比喻：
需求是回答为什么要进行这个项目
范围是回答，项目需要完成什么才能满足需求。这里仅仅是指产品范围，也就是最后的可交付物。
如果我们把范围扩展到工作范围的话，则是在做什么工作能够完成产品范围，满足需求
质量则是回答：产品应该达到什么要求
成本和时间则是回答完成工作的效率
这里面阐述了需求，范围，质量，时间和成本之间的关系。国内的论述鲜有提及。大多只在时间，成本和质量之间讨论。这可能是传统项目领域的限制，因为那些建筑工程类项目大都是需求明确，范围清晰的，项目经理的精力则主要和实施效率上作斗争。所以所谓的项目约束条件也仅仅在质量与时间和成本之间寻求平衡。看看项目管理的教科书，翻译加摘抄的思维定式也就不会有人去关注效果和效率之间的关系了。

但我在实施软件和IT类项目多年的经验来看，传统项目管理所关注的效率因素并不能解决软件项目的真正难点，也就是所谓效果目标。但凡一个项目启动，其目的不是说客户点名要什么产品，而是需要利用某个产品来解决自身的问题。而这里所谓要解决的问题就是“客户需求”。而能够解决问题的产品就被定义在产品规格，也就是Product Specification当中。项目的起因显然来自需求，但是项目工作本身却起始于产品范围的界定，也就是规格。

在需求工程中有一句话：“客户需求不是客户所说的”。这句话仔细研究起来，也对，也不对。说对，是因为和客户的沟通是获取需求的重要根源，你不听取客户的意见如何了解需求信息。说它不对，是因为大多数客户和技术人员交流时会陷入到直接定义产品功能和规格上去。也就是客户并不是直接表述“我的需求是什么”，而是“我要的是什么”。这就提早了需求到规格之间的转化。但问题的关键是这个转化往往是错误的，因为沟通的双方都不是对方领域的专家。这个转化做的越早越快，越容易出错。这个错误往往会在最后交付阶段才会被发现。因为它不是功能错误和缺陷，它是做错了功能。

既然双方都不是对方领域的专家，由哪一方完成了。我们只能说这个时候由技术实现方来完成更好。因为毕竟后续的大量工作是由实现方完成的，让他们掌握的更全面将会更有利于项目的完成。所以，需求的收集和开发工作就是这类型项目的第一个重要工作。需求收集的方法很多，这里给出一个判据，也就是通过需求收集的目的和结果来判断其工作是否到位。如果工作结果是：客户想要什么产品，说明结果是错误的。如果工作结果是回答：客户用我们的产品来解决什么问题，则是正确的。从这一点上，用例是一个不错的需求收集和记录的工具。

需求收集工作完成之后，才开始定义产品规格，其目的是满足客户需求。我们可以说传统的需求分析工作目的就是定义项目的产品范围。而后的工作分解结构就是将产品范围进行任务分解。