【IT168 技术文章】
约定：本文涉及到的关键字概念和采用的技术的概念都不做详细解释，里面的概念定义请查阅相关书籍，这里只讨论这些在需求管理中的使用;同时里面的案例信息也不在这里做详细交代。
引用案例：某市网上审批项目。
1 概述
我们知道现代项目管理的六要素是：时间、成本、质量、组织、范围、客户满意度，实际上，要满足这六个要素，计划一个良好的需求分析是实现这六因素的前提，如果我们在项目生命周期的某些阶段出了问题，而我们可能还不知道，这将影响整个项目周期，无论该计划如何详尽，如果需求有误和需求分析不到位，项目的控制将没有任何价值，IT软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)，从某种意义来讲，项目的成功基于项目的需求管理的成功。
2 需求的定义及特点
根据IEEE项目工程标准词汇表(1997)年中对需求的描述如下：业主解决问题或达到目的所需的条件或权能，和系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。在PMBOK中，项目需求就是在“项目范围”约定的。
需求最显著的特点是“随着项目而改变、随着项目而渐进明晰”，项目管理的特点是随着进展而渐进明细化，可以看出需求管理和项目管理一样，这就意味着需求在项目的整个生命周期都可能存在的，这样项目管理的过程，也必不可少需求的管理。
3 如何获取需求
获得需求的方式可以有多种多样：电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书)，其实这些方法都是GET方式，我们可以通过以下两类技术手段来达到：GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求，而这两个过程都是必须交互进行的，一般我们可以筛选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程师，长期在客户那里工作，他的工作主要是界定项目的范围和需求变更管理，通过我们编制的各类模板文档来实现需求变更的控制;
一般来讲IT集成需求包含三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需求提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求，必须具备一定的业务背景和技术背景，能从三个不同的层次发掘客户的需求。
根据我们在某市网上审批项目中的经验，我们采用如下方法，其中每项工作都记录文档备案：如查阅了大量资料和病历资料格式、各类应急防御措施、统计分析报表、系统规划书、旧系统业务状况、历史资料、还访谈了操作员的应用感受、多次技术交流、专题讨论等多种形式的交互式讨论和分析。这样无论是业务、功能、用户详尽的期望我们都了解的比较透彻。
4 需求管理
获取了需求接着要作的的工作就是对需求分析、消化和评审、基线制定、需求说明书制定，这里我们主要集中在需求分析和需求说明书两方面来。
4.1需求分析
1)建立需求关联图：需求关联图是用于定义系统与系统外部实体间的界限和接口的简单模型，同时它也明确了通过接口的信息流和物质流，通过关联图，对用户需求的约定和确认以及CCB的评审都是非常关键的。
2)创建开发原型：创建用户接口原型可以在如下应用如下情况：如果开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。通过开发原形，业主和集成商都可以相互了解业务，发掘潜在的信息，避免用户需求的不必要变更。
3)分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍，这个主要用于内部评审和制定技术线路提供依据，如在什么情况下采用.NET技术,什么情况下采用J2EE技术,我们在2003年电子政务网上审批系统中充分对需求(业务、技术、用户操作人员需求、现有系统需求等)做整体提取分析来确定技术线路的选型。
4)确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5)为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6)编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
