需求管理对范围管理的影响
案例场景
黄工负责某基金投资公司的一个证券分析系统项目的研发，率领项目组进驻该基金公司进行研发已经快一年了，现在项目已经接近尾声，但似乎并没有交付的意思。从系统试运行那天起，用户就不断提出新需求，似乎总是有新的需求要项目研发方来做，基金公司的经理在试运行系统时，经常把自己的新思路讲给黄工，要求优化系统的功能，项目变成了一个无底洞，没完没了地往下做。
黄工要求结项，但基金公司以系统功能没有满足需求为由而推迟验收，要求继续完善。黄工查阅了项目开发合同，而合同中并没有对需求的详细描述。此时，国家新出台了一项投资法规，依据整个法规，系统的一些功能肯定又要修改，虽然这些功能不影响系统的正常运行，但这些功能需求似乎仍在合同规定的范围之内，这些功能的需求开发需要大量的时间和人力。
黄工认为，含糊的需求和范围经常性的变化严重影响了项目的进展，他必须寻找良策以管理范围，促使项目早日完工。
# 问题1
请用200字以内的文字，指出本项目开发中存在的问题。
# 问题2
请用200字以内的文字，建议黄工该如何解决现在的问题。
# 问题3
请用400字以内的文字，论述需求开发、需求管理和范围管理的区别与联系。
案例分析
需求管理贯穿信息系统项目的整个生命周期，只有经过需求分析过程之后才能确定项目的范围。
本项目的范围管理没有做好，其实是从合同一开始，就没有一个明确的“需求”，从而导致在项目实施中出现了各种问题。在一个项目中应该知道对方需要什么，自己要做什么，这是项目成功的基础所在。
对案例场景进行分析，就能发现项目中存在的问题，进而找出对策。
# 问题1
从案例场景中可以看出：
“基金公司以系统功能没有满足需求为由而推迟验收，要求继续完善”，项目不能交付，因为验收这一环节一直无法执行，在试运行期间，还有需求变更和新需求的提出；“基金公司的经理在试运行系统时，经常把自己的新思路将讲给黄工，要求优化系统的功能”。这就说明很可能黄工一开始在做需求分析时，就没有充分了解项目干系人的需求，需求分析报告也没有得到用户的确认，特别是关键用户的确认，所以项目的范围无法确定，也就无法进行范围控制。
“用户不断提出新需求，似乎总是有新需求要项目研发方来做”，这些新需求经过变更控制了吗？是不是真正的新需求呢？这些需求是否超出了项目的范围？是否值得变更呢？对需求变更没有规范管理，变更没有任何依据。在变更之前，是需要通过变更控制委员会评审的，以确定变更对项目的影响。
“黄工查阅了项目开发合同，而合同中并没有对需求的详细描述”，合同中对系统功能的描述不可能是详细的，只能是一个大致的目标说明，具体的功能一般要看合同附件，例如双方签署的技术附件，有可能本项目没有技术附件这一类对系统功能详细描述的文件，最终导致了在验收时无据可依，只能由用户说了算。
“国家新出台了一项投资法规，依据这个法规，系统的一些功能肯定又要修改，虽然这些功能不影响系统的正常运行，但这些功能需求似乎仍在合同规定的范围之内，这些功能的需求开发也需要大量时间和人力”，风险的出现是不可避免的，合同中应该有对意外事件处理的办法，不应该完全由乙方承担风险，应该由一个协商解决的办法，也可能在合同中没有预想到新法规出台给项目带来的风险，无法界定是否在项目范围内，也没有应对措施。是不是基金公司已经预料到有政策要出台，有意拖延项目验收呢？在政策出台后，可以将系统做得更完美些，如果项目已经交付，再修改完善会有许多不方便的地方，如重新申请项目资金等。
针对案例场景中的描述，对于项目开发中存在的问题，可以做出以下总结：
1）在开发合同中没有明确系统的需求，没有进行范围确认。
2）对需求变更没有规范管理，变更没有依据。
3）项目的范围制订太模糊，无法作为验收的依据。
4）在合同中没有描述新法规出台给项目带来的风险，无法界定是否在项目范围内，也没有应对措施。
# 问题2
在找到了存在的问题后，就可以相应地给出解决办法。
现在的关键问题是系统面临的验收问题，可以与各级别用户进行沟通，重新确认以下用户的需求，与现有功能进行核实，核实以下还有多少没有实现，逐个消项。列出用户的需求清单，要求用户签字确认，这些需求将作为系统验收时的依据，为验收做好准备。
对于变更的处理，和基金公司的项目负责人协商以下，双方组成一个变更控制小组，规范变更控制流程，确保变更是有效的，且没有超出项目的范围，没有对项目的完成造成太大的影响。
对于项目的范围，必须与甲方的关键用户进行确认，确认做哪些，不做哪些。在确定范围时首先要确定最终产生的是什么，它具有哪些可清晰界定的特性。
特性必须要清晰，以认可的形式表达出来，例如文字、图表或某种标准，能被项目参与人理解，绝不能含含糊糊、模棱两可。如果项目的范围太大，可以分解成一个个小的子项目，分阶段交付，并制订一个交付时间表，对于交付的成果有一个明确的说明，要得到甲方的认同。
新法规出台的现实是无法改变的，通过和基金公司的项目负责人进行沟通，讲明现在的情况，协商解决的办法和期限，既然“这些功能不影响系统的正常运行”，那么完全可以将这些功能放在二期实现，这些功能需求是否在合同规定的范围之内，双方可以确认以下，讲出各自的依据。如果用户客观上需要必须本期实现，对于项目组增加时间和人力是可以理解的，可以给项目组一定的经济补偿。
归纳如下：
1）与客户进行沟通，明确系统的需求，和用户进行一次范围确认，可以以技术附件的形式或补充协议形式，要求用户签字确认。
2）规范变更控制流程，规范新增需求和需求变更管理的流程，对范围变更进行控制。
3）与基金公司的项目负责人一起重新核实项目的范围，制订分阶段交付时间表和验收依据。
4）针对新法规的出台对项目的影响，与基金公司的项目负责人协调，说明新功能的需求开发需要增加时间和人力的现实情况，增加项目投资和延长项目的交付时间，或将新功能在项目的二期工程中实现，对现有的系统功能先行验收，完成本期项目的交付。
# 问题3
首先需要了解几个概念：
1）需求：指的是由项目接受的或项目产生的产品和产品构件需求，包括由组织征集的对项目的需求。这种需求既有技术性的，也有非技术性的。
2）需求工程：所有与需求直接相关的活动通称为需求工程。需求工程的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求管理的目的是确保各方对需求的一致理解；管理和控制需求的变更；从需求到最终产品的双向跟踪。
3）项目范围管理：确保项目包含且仅仅只包含项目所必须完成的工作。包括为成功完成项目所需要的范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制5个过程。每个过程都要用到一些方法和工具，如范围计划编制要由“专家判断”、“模板、表格和标准”；范围定义要有“产品分析”、“可选方案识别”和“专家判断法”；创建工作分解结构要有“工作分解结构模板”、“分解”；范围确认要有“检查”；范围控制要有“变更控制系统”、“配置管理系统”和“重新规划”。
需求开发、需求管理和范围管理在项目实施中有区别也有联系，不是孤立的，他们之间是相互影响的。要点如下：
1）通过需求开发来获取项目的需求，在此基础上确定项目的范围、进行项目范围管理。
2）需求管理是对已批准的项目需求进行全生命周期的管理，其过程包括需求管理定义、需求管理流程、制订需求管理计划、管理需求和实施建议等。
3）对于项目需求，可以根据需求的紧急重要程度、项目本身和甲乙双方的实际情况，分步或分期满足。确定每期应满足的需求后，本期的范围管理就有了基础。
4）需求管理处理需求的变更，需求的变更会引起项目范围的变更。
参考答案
# 问题1
1）在开发合同中没有明确系统的需求，没有进行范围确认。
2）对需求变更没有规范管理，变更没有依据。
3）范围的范围定制太模糊，无法作为验收的依据。
4）在合同中没有描述新法规出台给项目带来的风险，无法界定是否在项目范围内，也没有应对措施。
# 问题2
1）与客户进行沟通，明确系统的需求，和用户进行一次范围确认，可以以技术附件的形式或补充协议形式，要求用户签字确认。
2）规范变更控制流程，规范新增需求和需求变更管理的流程，对范围变更进行控制。
3）与基金公司的项目负责人一起重新核实项目的范围，制订分阶段交付时间表和验收依据。
4）针对新法规的出台对项目的影响，与基金公司的项目负责人协调，说明新功能需求开发需要增加时间和人力的现实情况，增加项目投资和延长项目的交付时间，或将新功能在项目的二期工程中实现，对现有的系统功能先行验收，完成本期项目的交付。
# 问题3
1）通过需求开发来获取项目的需求，在此基础上确定项目的范围、进行项目范围管理。
2）需求管理是对已批准的项目需求进行全生命周期的管理，其过程包括需求管理定义、需求管理流程、制订需求管理计划、管理需求和实施建议等。
3）对于项目需求，可以根据需求的紧急重要程度、项目本身和甲乙双方的实际情况，分布或分期满足。确定每期应满足的需求后，本期的范围管理就有了基础。
4）需求管理处理需求的变更，需求的变更会引起项目范围的变更。
内容来源：
《信息系统项目管理师案例分析指南》
全国计算机专业技术资格考试办公室推荐
张友生 刘现军 主编
希赛IT教育研发中心 组编
清华大学出版社
