本文是一篇项目管理论文，本文以ZX软件项目开发公司为研究主题，通过总结以往ZX公司开发项目需求管理的过程和经验，运用历史项目信息、访谈、调查问卷得到的结果，分析出ZX公司需求管理存在的问题，包括客户与需求管理人员沟通不到位，导致结果与实际产品存在偏差；需求模棱两可，缺乏准确性；
第一章 绪论
1.1 课题研究背景与意义
1.1.1 课题研究背景
软件开发项目不同于传统工程项目，它更多是大量的、复杂的、高强度的脑力劳动，而不是物理实体，由于软件和软件项目固有的特殊性、复杂性和不可见性，使得软件开发项目的失败率居高不下。美国专门从事跟踪IT项目的权威机构“Standish Group”每年的CHAOS Report报告中给出了IT项目相关调查数据结果，根据2015年发布的Chaos report，有19%的项目是彻底失败，高达52%的项目进度超期或者成本超支，仅仅29%的项目被认为是成功的。Chaos Report根据数据总结了影响软件项目成败的因素，其中十大软件项目失败的原因就有一半与需求直接相关，包括“不完整的需求”、“缺乏用户参与”、“不切实际的用户期望”、“需求变更频繁”及“提供不再需要的”。而十大软件项目成功的原因也包含了3个与需求相关的因素，它们是：“用户参与度”、“明确的业务目标”及“稳定的基本需求”[1]。由此可见，需求很大程度上决定项目的成败。
由上述数据可以清楚得知，需求的管理是非常必要的。因此如何能准确地把握用户的需求成为一个项目成功的关键。科学的需求管理不但能够大大增加交付高质量产品的几率，还能减少由于重复开发而导致的项目实施进度的拖延与研发成本的增加。对于软件需求管理，我国的研究还不算非常成熟，为了提高企业项目的成功率，必须充分运用国外成熟的理论基础和丰富的实践经验，结合我国企业的实际情况，整理出一套有效的管理方法。
1.2 国内外研究情况
1.2.1 国内外需求管理研究现状
在上世纪60年代中期，处于计算机发展的萌芽时期，软件的应用并不那么广泛，软件开发人员通常是为自己的使用而编写程序。在这个时期，由于软件的规模较小，很少使用系统化的开发方法，需要提前规划，也不需要对开发过程进行管理。60年代后期，随着科学技术的发展，软件行业也在不断进步，运用领域也在慢慢扩大，人们逐渐意识到需求管理在软件开发过程中的重要性，人们第一次开始关注起软件需求管理问题。到了80年代，人们开始着手进行一系列需求管理的研究，他们发现需求问题不仅仅存在于软件开发的前期，而是在软件开发的每个阶段都需要进行管理。
20世纪80年代中期人们开始提出需求工程（Requirement Engineering，RE）的概念，并在随后的时间逐渐成为软件界的研究热点。从1993年起，需求工程国际讨论会（International Symposium on Requirements Engineering，ISRE)每隔两年都会举办一次，需求工程相关的研究开始兴起，比如需求获取、建模、验证和变更管理等。其他北美、欧洲国家也随后举办需求工程相关交流会议。1996年“Requirements Engineering”学术期刊发行，也吸引更多学者参与讨论和交流，随后一些需求相关的组织陆续建立并开始工作[3]。
近年来，国外学者对软件需求的研究从没停过。Kumar、Shukla和Agarwal在JAD的帮助下为敏捷中的需求工程提供了一种混合方法，该观点有助于敏捷中需求的优先级划分[4]。Fernando Belfo分析了软件失败的原因之一为需求说明书倾向于高估需求的技术，良好的需求只有通过三个维度的正确组合才能得到保证：人员、组织和技术[5]。Azeddine Chikh基于知识创造的SECI模型，提出了一个知识管理框架，旨在开发给定软件项目中与软件需求相关的隐性和显性知识[6]。Riaz等人为了减少用自然语言编写的需求的不明确性和不一致性，介绍了目前可用的自动检测自然语言歧义工具和技术。
第二章 需求管理相关理论
2.1 软件需求的定义及层次
2.1.1 软件需求的定义
IEEE软件工程将需求定义为[20]:
1、用户解决问题或达到目标所需的条件或能力。
2、系统或系统部件要满足合同、标准、规范或其他正式规定文档所具有的条件或能力。
一种反映上面1或2所描述的条件或能力的文档说明。
其中第一条是以用户的角度来看待需求是怎样解决用户问题的，即用户希望软件能做什么事情，完成什么功能，达到什么性能，而第二条则是从软件开发人员角度来看，需求包括用户要解读的问题，达到的目标，以及实现这些目标所需要的条件。
对于不同的人来说，对同一款软件的需求可能会完全不一样。例如，对于一款OA办公软件，有人希望它可以有定时发送邮件功能，有人则希望它能有已发送邮件撤回功能。因此，对于开发人员来说，弄明白用户到底需要软件来解决什么问题是项目获得成功的首要要求，否则即使投入再多的时间与精力去实现软件产品，也只是白费功夫。
企业之所以要进行需求管理，是因为有效的需求管理能帮助开发人员准确地实现用户的真实需求，通过有效科学的需求管理能降低软件的失败率，提高软件产品的质量的同时降低开发成本，因此需求管理是项目取得成功的第一步。
2.2 软件需求工程内容
2.2.1 软件需求工程的定义
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科；它通过合适的工具系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持[23]。需求工程由需求开发和需求管理两个部分组成，其中需求开发过程由需求获取、需求分析、需求规格编写和需求确认过四个部分；而需求管理过程由需求基线、需求跟踪和需求变更三个部分，如图2-2所示。
第三章 ZX公司软件项目需求管理存在问题分析 .............................. 15
3.1 ZX公司简况 ............................. 15
3.1.1 ZX软件开发公司简介 .................................... 15
3.1.2 ZX公司软件需求管理的现状 ..................... 16
第四章 ZX公司P项目需求管理改进对策及实施效果 ......................... 31
4.1 P项目背景 ........................................... 31
4.1.1 Scrum团队的组建.............................. 32
4.1.2制定Scrum会议规则......................... 34
总结与展望 ..................... 54
第四章 ZX公司P项目需求管理改进对策及实施效果
4.1 P项目背景
此次案例是ZX公司为广东一家CX设计工程有限公司开发的绩效考核管理系统，简称P项目。绩效考核是一个有效促进员工工作的效率，帮助企业选拔人才，推动企业目标实现的激励机制。P项目辅助绩效部门人员使用自动化网上办公，以解决简单人手操作问题，使员工不但可以减少办公纸张浪费，还可以优化日常操作的流程，避免因手工填写表格出错而更改的困难。为广大员工提供一种人机办公辅助化的途经，从而极大提高员工的工作效率。
根据CX公司的性质和员工岗位不同，P项目可分为三部分组成，分别是项目绩效考核、年度绩效考核系统、岗位绩效考核系统，考核对象为除公司总经理、副总经理、退休返聘人员以外的所有员工。其中：
1、项目绩效适用于具体承担项目任务的所有设计/造价岗位员工和部分管理岗位员工，包括设计人、校核人、审核人、主设人及项目经理。
2、岗位绩效适用于非设计/造价岗位员工。
3、年度考核适用于项目绩效和岗位绩效的所有员工。
ZX公司之所有选择P项目作为此次组建Scrum敏捷开发团队及采用敏捷需求管理流程的试点项目是基于以下三个理由：
首先，P项目团队规模适合敏捷。敏捷团队不适合太多人数，会影响沟通的效率，增加沟通成本，ZX公司根据项目的大小规模及项目特点，定下了10人规模的团队。
其次，P项目计划完成周期时间合适。适合敏捷项目的开发时间最好不要超过半年，如果项目时间持续太长，等整个项目都完成，大家对敏捷的期待也许没那么高了。如果项目时间持续时间太短，还来不及发现问题，项目就已经完成了。选择的项目持续时间为6个月，适合作为试点项目。而且此项目可以分为多个Sprint，适合Sprint的循环迭代。
最后，是来自客户公司的支持。客户公司赞同敏捷的思想，认同人的沟通交流的重要性，愿意尽力配合，专门派出一位员工作为本次项目的负责人，并让其全程参与到项目中去。客户公司还专门提供一个会议室作为Scrum开发团队的办公场所，以方便团队成员集中办公专心工作。
总结与展望
研究成果总结
本文以ZX软件项目开发公司为研究主题，通过总结以往ZX公司开发项目需求管理的过程和经验，运用历史项目信息、访谈、调查问卷得到的结果，分析出ZX公司需求管理存在的问题，包括客户与需求管理人员沟通不到位，导致结果与实际产品存在偏差；需求模棱两可，缺乏准确性；需求跟踪管理不到位导致部分功能无法定位来源及需求变更管理不规范，并深入分析了这些问题产生的原因，再结合查阅文献，研究需求管理的相关理论知识，得出一套通过组建Scrum团队及引入敏捷需求管理模型的适合ZX公司实际需求管理的改进方案。
然后ZX公司把此套改进方案运用到公司的实际项目即P项目实践中组去。首先组建了Scrum团队，在Scrum方法、思想及工件的帮助下，再对需求获取、需求分析、需求确认、需求跟踪、需求变更等环节应用了敏捷管理方法，此套改进方案保证了项目灵活性，提高对客户的响应速度，变更需求过程流畅有序，项目团队有较高的透明性，强调以人为本的根本思想，使团队成员不自觉的加入到需求管理之中，极大的调动了项目团队成员的积极性，从而提高了团队工作效率有序推动需求实现。
可以看出，在应用改进方案后，项目范围变得清晰明确、敏捷开发保证了项目的进度和质量，需求变更有序可控，从而验证了这套方案在理论和实践上的可行性和有效性。
参考文献（略）