需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。
1. 需求获取
需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户是无法完整地讲述其需求，因此需求获取是一件看似简单，做起来很难的一件事情，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。
1.1. 明确需要获取的信息（What）
需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。
通常需求获取要获取的信息包括三大类：
· 与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；
· 与要求解决的问题直接相关的信息；
· 用户对系统的特别期望与施加的任何约束信息。
1.2. 明确所需获取信息的来源与渠道（Where）
需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。
需求信息的来源通常包括：
· 来自客户的需求
a) 旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求
b) 系统的潜在用户或客户对系统的需求
· 竞争对手的产品优势与不足
· 国家政策、业务规则以及相关行业标准
· 实施产品设计所需满足的需求
· 执行测试验证工作所需满足的需求
· 实施系统安装、维护所需满足的需求
获取需求信息的渠道包括：
· 用户或客户
· 研发部
· 市场部
· 旧有系统的研发项目组
· 来自项目组内
1.3. 获取需求（How）
在明确须获取什么需求、需求的来源与获取渠道后，项目经理应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：
１） 用户访谈
用户访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对性地进行；非结构化是只列出一个粗略的想法，根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。
用户访谈具有很好的灵活性，有较广的应用范围，但实际操作时存在许多困难，例如客户经常很忙，难以获得充足的访谈时间；客户访谈需要需求分析师有很强的沟通能力，同时也要求需求分析师有足够的相关业务领域知识。
２） 用户调查
用户调查是通过精心设计提问问题形成调查问卷，然后下发到相关人员手中，让他们填写答案，来获取用户需求。
用户调查的方法最大的缺点是缺乏灵活性，由于缺乏面多面的交流，所获取的信息量也比较有限。因此在实际工作中，我们建议可以先采用用户调查的方式获取一定量的信息，然后有针对性地开展用户访谈。
３） 现场观摩用户的工作流程，观察用户的实际操作
俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。
４） 从行业标准、规则中提取需求
如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则，需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。
这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向，这对从技术出身的需求分析师来说是一个巨大的考验。
５） 文档考古
对于一些数据流比较复杂的、工作表单较多的项目，有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究，考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告，获得所需的信息。
６） 需求讨论会
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表，分析人员，开发人员，通过有组织的会议来讨论需求。
在会议之前，应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。
７） 原型法
原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
原型的基本步骤：
１） 根据客户原始需求、项目建议书、市场需求或合同要求，确定系统要做什么，即系统的边界、主要业务或功能、系统的接口；
２） 根据这些需求，形成系统原型。对于所形成的原型的基本要求包括：
· 体现主要的功能；
· 提供基本的界面风格；
· 展示比较模糊的部分，以便于确认或进一步明确，防患于未然。
· 原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
３） 进行原型评价并获取系统的需求，原型评价可以从几个方面进行：
· 在公司内部演示、评审，进一步获取内部信息，并求得共识
· 与用户进行演示与交流，挖掘用户需求，从而确定软件的目标和需求
４） 根据原型评价的意见修改原型，直到求得共识
原型法的优点是：
· 鼓励业务管理者的积极参与；
· 有助于解决业务管理者之间的差异；
· 能给业务管理者一个对最终系统的直观感受；
· 周期短；
· 成本低；
· 用户较满意。
但原型法也有缺点，主要为：
· 导致人们认为最终系统将很快产生；
· 对系统操作权限的说明较弱；
· 不适合于开发大系统；
· 开发过程管理困难。
1.4. 需求获取资料的保管
根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理，并且整理生成项目的原始需求文档。需求获取的记录与资料包括但不限于：
· 用户访谈的访谈纪要；
· 需求研讨会的会议纪要；
· 相关的政策法规文件，业务规则文件以及行业标准文件；
· 需求原型。
2. 需求分析
在完成需求获取所得到的记录与资料的分析与整理后，项目经理应组织软件的需求分析工作，建立各需求元素之间的关系，明确分配给软件的需求、需求的分类、需求的优先级等。
需求分析的方法种类繁多，但常见的需求分析方法主要是结构化分析方法和基于用例的需求分析方法。
2.1. 结构化分析方法
结构化分析方法的主要特点是“自顶向下、逐层分解”，它把系统看作一个过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析，描述工具有：
· 数据流图（Data Flow Diagram，DFD）：数据流图是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理过程、数据存储。
· 数据字典（Data Dictionary，DD）：数据字典技术是一种有效表达数据格式的手段，它是对所有与系统相关的数据元素的一个有组织的列表和精确、严格的定义，从而使用户和系统分析员对于输入、输出、存储成分和中间计算机有共同的理解。
· 结构化语言：结构化语言是结构化编程语言与自然语言的有机结合，可以采用顺序结构，分支机构、循环结构等机制，来说明加工的处理流程。
· 判定表和判定树：判定表是一种处理逻辑的表格表示方法，其中包括决策变量，决策变量值、参与者或公式；而判定树则使用像树枝一样的线条对过程逻辑进行图表化的描述。判定表和判定树用来描述复杂决策逻辑，要远远优于使用结构化语言。
· 实体-关系图（Entity RelationshipDiagram，E-R图）：E-R图可以用来描述数据的存储需求，包括数据实体，数据实体的属性以及它们之间的关系等。
结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法，它不仅是需求分析计划，也是完成需求规格化的有效技术手段，使用结构化分析方法时可遵循下列活动：
１） 建立系统的物理模型
首先，画出系统得数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪些处理过程。在这个数据流图中，可以包括一些非计算机系统中数据流及处理过程的名称，如部门名、岗位名、报表名等。这个过成可以帮助分析人员有效地理解业务环境。
２） 建立系统的逻辑模型
在物理模型建立之后，接下来的工作就是画出相对于真实系统的等价逻辑数据流图。将所有自然数据流图转换为等价的逻辑流。
３） 划清人机界限
最后，确定在系统逻辑模型中，哪些部分将采用自动化完成，哪些部分仍然保留手工操作，从而清晰的划清系统的范围。
2.2. 基于用例的分析方法
从定义中我们得知用例是由一组用例实例组成的，用例实例也称为“使用场景”，是用户使用系统的一个实际的、特定场景。用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（High Level）用户功能性需求。用例分析技术是一种需求合成技术，它利用现有的需求获取技术从客户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中进行整理、提炼，从而建立用例模型。
使用用例分析方法时可遵循以下步骤：
1) 识别系统参与者，确定谁会直接使用该系统。参与者是同系统交互的所有事物，该角色不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟。
2) 合并需求获得用例。找到所有参与者之后，根据需求获取所得到的用户需求，定义每个参与者希望系统做什么，参与者希望系统作的每件事将成为一个用例。
3) 绘制用例图。将所识别的参与者以及所定义的用例通过用例图的形式整理出来，以获得例模型的框架。
4) 细化用例描述。用例描述包括以下几个部分：
· 用例名称；
· 用例参与者；
· 用自然语言对用例进行简要的描述；
· 描述参与者何时使用该用例，即用例的触发条件；
· 描述在一般情况下，参与者使用该用例时会发生什么事情，即用例的基本过程；
· 在基本过程的基础上，考虑一些可变情况，把他们创建为扩展用例；
3. 需求定义
需求定义的目的是根据需求获取和需求分析的结果，进一步定义软件需求，产生《需求规格说明书》。
3.1. 标识需求
为了确保需求的易跟踪、易修改，需求分析师应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并体现于需求规格说明书。
3.2. 定义需求的优先级
需求分析师应确定每个需求的优先级并写入需求规格说明书，需求的优先级的评价。
标准如下：
优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
