需求管理

软件需求相关工作问题集

需求收集真正的体现了需求的市场和用户驱动。访谈，调查表，头脑风暴，竞争对手和产品分析都是需求收集的方法。需求收集我们需要搞清楚用户真正的需求，问题背后的深层次问题，这样才可能为挖掘需求提供数据。需求收集的过程应该流程化，收集的需求应该分类入库的归档化。必须将需求收集活动看做为一个结构化的流程或过程，以真正的促进收集的过程和采集的数据的有效性。

在各种企业级系统开发的过程中难以避免都会遇到权限处理的设计。好的权限系统不但能为系统提供安全的解决方案，同时还能节约开发时间，提高系统的可维护性。

需求是整个软件项目最关键的一个输入，据统计，不成功的项目中有37%的问题是由需求造成的。和传统的硬件生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，在硬件生产企业中，产品的需求是明确的、有形的、客观的、可描述的、可检测的，而软件需求不具备此特征。需求文档作为客户和开发人员、开发人员之间进行交互的文档，它将系统的需求进行了“固化”，是需求的载体，其作用是至关重要的。笔者结合多年的企业管理信息系统的开发经验，总结了如下的需求描述的方法与经验，供各位同行参考。

“需求变更”，一旦提到软件开发项目进程中的需求变更，无论是项目经理还是程序开发人员都感觉到头疼。而且，在一些项目管理顾问的PPT课件中，以及一些软件项目管理的技术图书和教程中，也把“需求变更”作为单独的一项来研究。本文中，与您共同探讨软件开发项目中的需求变更发生的原因、需求变更控制，以及当发生需求变更的时候如何应对解决。

在做好基本的需求控制的基础上，既然面对不断变化的需求，就要求项目组对事件的反应要快。在这种快节奏的项目环境中，充满了太多的不确定因素，成功的按时完成项目就像是一场长距离障碍跑。项目组经常要在没有完整确切的数据情况下决定如何做，项目范围的重点和方向要经常改变，如果软件承包商内部不协调一致，复杂的项目将经常会陷入泥潭，不能自拔。

需求管理是CMM二级中列出的第一个关键域，这是因为它实际上是二级引入到开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级的其他关键过程域中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

Borland在被Micro Focus收购之后，随即推出基于浏览器的需求定义模拟与协作工具。该名为TeamDefine的工具是Borland应用周期管理(ALM)套件的一部分，可以让开发人员通过拖曳实现屏幕元素与数据和逻辑之间的关联。

我们在实施项目的时候，往往做着做着，突然发现项目的进度已经落下了这么多。查找其原因，我们往往会发现，项目的某些需求在悄然的发生着改变，或者是某些的功能在现有基础上功能增强了，或者是某些功能的性能上有更大的要求，或者增加了一些小的新需求，或者是某些需求的实现方式发生了变更。

变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件研发过程中需求的变更会给研发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件研发的进度、成本和质量也就有了"安全"的基础。

变更控制的目的是管理变化。变更控制对项目成败有重要影响，事前要明确定义，事中要严格执行。实施变更之前有四个重要控制点：授权、审核、评估和确认；在实施过程要进行跟踪和验证，确保变更被正确执行。

变更控制是用于变更管理的一个传统项目管理流程。在传统的项目中，变更控制主要表现为填写一个详细的变更需求表，表中包含了像变更细节、对项目的影响、风险、缓解计划等条目。它还需要多人批准。传统的变更控制和敏捷相违背，因为它和“响应变化胜过遵循变化”的原则相冲突。在大量的表要填和大量的需求要确认的情况下，响应变更是困难的。精益敏捷Scrum群组发起了一个有趣的讨论，群组成员就Scrum中对变更控制的需求、变更可被跟踪的可能方法等展开了讨论。

变更控制的目的是管理变化。变更控制对项目成败有重要影响，事前要明确定义，事中要严格执行。实施变更之前有四个重要控制点：授权、审核、评估和确认；在实施过程要进行跟踪和验证，确保变更被正确执行。

在项目管理中，需求的重要性是众所周知的，在IT业界的研究是：高达60%缺陷来源于需求不清晰，超过80%的项目维护成本用于需求问题处理，需求管理影响了整个项目成败，而关键项目成败则影响了公司的生存。

辛辛苦苦的熬了几个月，软件开发终于快要告一段落了。系统功能已经基本完成了，在准备按部就班的完成最后的测试时，客户突然提出要改变某些非功能性需求。这对于软件开发团队来说，不亚于晴天惊雷。

需求在软件项目中扮演着及其重要的角色。不管哪种类型的项目，无论是新产品开发，还是外包项目，开发队伍都面临着普遍存在的需求问题，比如如何获取有效的需求、如何处理需求的变更等等。这些问题有其共性的一面，也有和项目类型相关的一面。本文着重讨论了在新产品开发项目中的一些需求问题，以及避免和解决这些问题的建议。

什么是需求？什么是需求分析？什么是需求跟踪？什么是需求获取？什么是需求规格？什么是需求验证？什么是需求变更？……一堆关于需求的问题，一堆关于需求和需求管理的恼人问题，需求真的很重要吗？那为什么如此难以把握？为什么在软件工程中如此难以应用呢？

软件需求的管理和控制是非常专业的学问，作者在这里结合自己的实践提出一些粗浅的认识，只是想起到一个抛砖引玉的作用，希望大家可以一起来面对和想办法解决我们在系统开发过程中的实际问题，我想那样才是我真正想达到的目的。

做软件项目，特别管理软件类的项目，客户软件需求的把握是一件十分重要且困难的事情。项目的需求很容易变更、蔓延。客户开始的时候很难明确自己的需求，需求很难确认，确认后的需求也经常会发生变化，需求的变化极易引起项目成本的提高、进度的拖延、质量的风险。

在本文中，笔者从项目管理的角度来讨论对变化需求管理的策略。首先是讨论在构建前需求的质量，然后说明了如何在构建过程中对需求进行跟踪，最后讲述了当真正发生需求变更的时候，我们应该如何去面对。