浅谈软件项目的需求管理
软件项目区别于其它项目的最显著的特征是其不可见性，它不像硬件购销、建筑工程，都是实实在在可见的东西。而软件项目在系统交付之前很长一段时间，客户是无法感知自己想要的系统究竟是什么样子。因此，需求管理就显得十分重要，据相关统计数据分析，软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的。 需求管理作为软件项目管理的一个重要内容，贯穿项目实施的全生命周期。俗话说：万事开头难。需求作为软件开发的第一个环节，其重要性不言而喻。市面上关于需求管理的相关理论和书籍很多，但多数停留在理论层面，实操性不强。本文主要是根据我们以往项目的经验，进行一些需求管理方面的探讨。我们可以简单的将软件项目的需求管理分为需求获取、需求分析与验证、需求变更控制三个核心内容。
(一)需求获取
需求获取是软件项目需求管理的第一个过程，在这个过程中我们需要运用科学的方法以及相关的项目经验库辅助我们进行需求获取。需求获取的核心内容是通过调研掌握软件项目的实际需求，以便于指导整个项目的实施。需求获取的主要方法包括：用户访谈、问卷调查、现场观摩、头脑风暴等方法。在实际的项目操作过程中，相对比较明确的需求，我们可采用比较固定的需求获取方式，比如：问卷调查等。而对于相对比较模糊的需求或者说用户无法清晰表述自己需要的是什么的时候，我们可采用比较灵活的方式，例如：用户访谈、现场观摩等。
需求的类型主要包括：业务需求、用户需求和功能需求。在需求获取的过程中，无论采用哪种方法，我们都需要自顶向下或自下向上去了解用户真实的想法。业务需求的获取对象主要是客户的高层领导，我们都知道，项目的发起、实施、最终的成败很大程度上都取决于高层领导，我们需要对他们进行访谈，了解高层领导的公司战略、发展方向，更为重要的是获取他们对将要开发的软件系统的期望，以及希望该系统在解决现有业务问题，对公司整体战略的支撑方面的期望。帮助我们去更好地理解系统的宏观构想。在掌握了业务需求后，我们需要对中层管理人员进行调研，核心问题是搞清楚在宏观战略目标落地的这层，或者说指标细化并负责实施的中层他们对软件系统的期望以及实际要求，他们或希望此系统能够带来工作便利，或希望此系统能够做到精细化管理，如此等等。但他们都是具体的业务部门负责人，对自身的业务以及系统对业务的促进方面，有比较深刻的体会。最后，我们需要在掌握了业务需求、用户需求的基础之上，通过对IT管理部门、主要操作人员的需求调研或根据我们对需求的理解，细化出系统的功能需求，这个需求是最低层次的需求，也是一个层层落地的过程。
(二)需求分析与验证
在获取到软件项目需求后，接下来的工作就是对需求进行分析与验证，在项目的实际操作过程中，主要包括：需求分析建模、需求规格说明书编写和需求评审三个大的阶段。
需求分析建模主要是对已搜集到的信息进行提炼、分析和仔细审查，为最终用户所看到的系统建立一个概念模型，确保所有干系人都明白其含义，并能找出其中的错误、遗漏或不足。需求分析是软件项目需求管理的最重要一环。
在需求分析与建模过程中，对于用户需求不确定或用户无法清晰表述需求的，为了加快项目进度，我们往往采用原型法进行需求分析与建模，即根据我们的经验以及对用户基本需求的理解，用Axure等原型设计工具搭建一套原型系统。另外，我们还需要采用UML工具进行用例分析、用例描述等，并最终编写形成《软件需求规格说明书》。
需求验证或需求评审是衡量需求阶段产出成果的重要手段，在完成需求分析与建模后，项目相关干系人应组织召开需求评审会，邀请相关专家、外部相关单位等进行需求评审，就需求分析的结果《需求规格说明书》、原型系统等进行评审，并对评审结果进行签字确认，确保需求没有偏离用户要求，又略高于用户要求。
(三)需求变更控制
需求管理贯穿于软件项目开发的全生命周期，在完成需求获取、分析与验证等任务后，项目组将根据形成的相关报告进行系统设计、编码、测试、发布等工作，这些过程其实都会涉及到需求的变更，这就需要我们有一套较好的机制和方法来管理和控制需求变更，以便于项目能够按期保质又在成本范围内完成。
通常的做法是我们为了避免需求变更的无序、频繁、过度，在项目启动时会制定一套章程，会有一个CCB(变更控制委员会)，通过召开项目启动会的方式，给相关干系人确定项目的实施方法、里程碑、沟通计划，并着重强调需求变更的流程。
在实际操作中，首先是通过VSS等版本控制工具对需求文档进行管理，建立需求基线，并通过需求跟踪矩阵对需求项进行详细标注。
其次，是在项目执行过程中对需求进行变更控制，有一套规范的流程，过程虽然繁琐，但能够给项目的风险控制带来很好的效果。用户提出需求变更申请，由项目实施团队进行需求变更的评估，评估包括可能造成的对系统其它功能的影响、实施此次变更需要投入的工作量等，评估完成后由变更控制委员会确定是否同意变更。如果同意，则由项目组进行变更的实施，并对上线后的变更内容以及整个系统进行验证，确保不影响系统运行和操作。如果不同意，则变更不成立，直接驳回用户方。通过这样一种虽然看似繁琐的方法能够很好地进行需求变更的控制，可以有效避免无序、无理、过度的需求变更，确保项目在可控范围内实施。 以上是我们对软件项目需求管理的一点认识，软件需求管理之所以重要，主要是因为绝大多数项目的失败主要由需求的理解不到位、需求的变更没有得到有效控制等原因造成的。因此，这就要求我们在软件项目的需求管理方面，要下更大的力气去做好需求的获取、分析、变更控制，结合项目管理的相关理论，如PMBOOK、CMMI等，在项目实践中，不断总结经验教训，做好需求管理。
浅谈软件项目的需求管理
软件项目区别于其它项目的最显著的特征是其不可见性，它不像硬件购销、建筑工程，都是实实在在可见的东西。而软件项目在系统交付之前很长一段时间，客户是无法感知自己想要的系统究竟是什么样子。因此，需求管理就显得十分重要，据相关统计数据分析，软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的。 需求管理作为软件项目管理的一个重要内容，贯穿项目实施的全生命周期。俗话说：万事开头难。需求作为软件开发的第一个环节，其重要性不言而喻。市面上关于需求管理的相关理论和书籍很多，但多数停留在理论层面，实操性不强。本文主要是根据我们以往项目的经验，进行一些需求管理方面的探讨。我们可以简单的将软件项目的需求管理分为需求获取、需求分析与验证、需求变更控制三个核心内容。
(一)需求获取
需求获取是软件项目需求管理的第一个过程，在这个过程中我们需要运用科学的方法以及相关的项目经验库辅助我们进行需求获取。需求获取的核心内容是通过调研掌握软件项目的实际需求，以便于指导整个项目的实施。需求获取的主要方法包括：用户访谈、问卷调查、现场观摩、头脑风暴等方法。在实际的项目操作过程中，相对比较明确的需求，我们可采用比较固定的需求获取方式，比如：问卷调查等。而对于相对比较模糊的需求或者说用户无法清晰表述自己需要的是什么的时候，我们可采用比较灵活的方式，例如：用户访谈、现场观摩等。
需求的类型主要包括：业务需求、用户需求和功能需求。在需求获取的过程中，无论采用哪种方法，我们都需要自顶向下或自下向上去了解用户真实的想法。业务需求的获取对象主要是客户的高层领导，我们都知道，项目的发起、实施、最终的成败很大程度上都取决于高层领导，我们需要对他们进行访谈，了解高层领导的公司战略、发展方向，更为重要的是获取他们对将要开发的软件系统的期望，以及希望该系统在解决现有业务问题，对公司整体战略的支撑方面的期望。帮助我们去更好地理解系统的宏观构想。在掌握了业务需求后，我们需要对中层管理人员进行调研，核心问题是搞清楚在宏观战略目标落地的这层，或者说指标细化并负责实施的中层他们对软件系统的期望以及实际要求，他们或希望此系统能够带来工作便利，或希望此系统能够做到精细化管理，如此等等。但他们都是具体的业务部门负责人，对自身的业务以及系统对业务的促进方面，有比较深刻的体会。最后，我们需要在掌握了业务需求、用户需求的基础之上，通过对IT管理部门、主要操作人员的需求调研或根据我们对需求的理解，细化出系统的功能需求，这个需求是最低层次的需求，也是一个层层落地的过程。
(二)需求分析与验证
在获取到软件项目需求后，接下来的工作就是对需求进行分析与验证，在项目的实际操作过程中，主要包括：需求分析建模、需求规格说明书编写和需求评审三个大的阶段。
需求分析建模主要是对已搜集到的信息进行提炼、分析和仔细审查，为最终用户所看到的系统建立一个概念模型，确保所有干系人都明白其含义，并能找出其中的错误、遗漏或不足。需求分析是软件项目需求管理的最重要一环。
在需求分析与建模过程中，对于用户需求不确定或用户无法清晰表述需求的，为了加快项目进度，我们往往采用原型法进行需求分析与建模，即根据我们的经验以及对用户基本需求的理解，用Axure等原型设计工具搭建一套原型系统。另外，我们还需要采用UML工具进行用例分析、用例描述等，并最终编写形成《软件需求规格说明书》。
需求验证或需求评审是衡量需求阶段产出成果的重要手段，在完成需求分析与建模后，项目相关干系人应组织召开需求评审会，邀请相关专家、外部相关单位等进行需求评审，就需求分析的结果《需求规格说明书》、原型系统等进行评审，并对评审结果进行签字确认，确保需求没有偏离用户要求，又略高于用户要求。
(三)需求变更控制
需求管理贯穿于软件项目开发的全生命周期，在完成需求获取、分析与验证等任务后，项目组将根据形成的相关报告进行系统设计、编码、测试、发布等工作，这些过程其实都会涉及到需求的变更，这就需要我们有一套较好的机制和方法来管理和控制需求变更，以便于项目能够按期保质又在成本范围内完成。
通常的做法是我们为了避免需求变更的无序、频繁、过度，在项目启动时会制定一套章程，会有一个CCB(变更控制委员会)，通过召开项目启动会的方式，给相关干系人确定项目的实施方法、里程碑、沟通计划，并着重强调需求变更的流程。
在实际操作中，首先是通过VSS等版本控制工具对需求文档进行管理，建立需求基线，并通过需求跟踪矩阵对需求项进行详细标注。
其次，是在项目执行过程中对需求进行变更控制，有一套规范的流程，过程虽然繁琐，但能够给项目的风险控制带来很好的效果。用户提出需求变更申请，由项目实施团队进行需求变更的评估，评估包括可能造成的对系统其它功能的影响、实施此次变更需要投入的工作量等，评估完成后由变更控制委员会确定是否同意变更。如果同意，则由项目组进行变更的实施，并对上线后的变更内容以及整个系统进行验证，确保不影响系统运行和操作。如果不同意，则变更不成立，直接驳回用户方。通过这样一种虽然看似繁琐的方法能够很好地进行需求变更的控制，可以有效避免无序、无理、过度的需求变更，确保项目在可控范围内实施。 以上是我们对软件项目需求管理的一点认识，软件需求管理之所以重要，主要是因为绝大多数项目的失败主要由需求的理解不到位、需求的变更没有得到有效控制等原因造成的。因此，这就要求我们在软件项目的需求管理方面，要下更大的力气去做好需求的获取、分析、变更控制，结合项目管理的相关理论，如PMBOOK、CMMI等，在项目实践中，不断总结经验教训，做好需求管理。