《需求开发与管理指南》.docx
《《需求开发与管理指南》.docx》由会员分享，可在线阅读，更多相关《《需求开发与管理指南》.docx（12页珍藏版）》请在冰豆网上搜索。
《需求开发与管理指南》
需求开发与管理指南
过程编号
IASPEC-SP-RDM-G01
文件状态
[]草稿[√]正式发布[]正在修改
当前版本
V1.0
修订
日期
2006-6-21
审核
日期
2006-7-8
批准
日期
2006-8-15
发布日期
2006年8月18日
生效日期
2006年8月18日
修订历史记录
A-增加M-修订D-删除
变更版本号
日期
变更类型
（A*M*D）
修改人
摘要
备注
目录
1.目的4
2.需求获取4
2.1.明确需要获取的信息（What）4
2.2.明确所需获取信息的来源与渠道（Where）4
2.3.获取需求（How）4
3.需求获取资料的保管6
4.需求分析7
4.1.问答分析法7
4.2.结构化分析方法7
4.3.基于用例的分析方法8
4.4.需求的优先级的评价标准9
5.需求跟踪10
5.1.建立需求跟踪矩阵10
5.2.需求跟踪矩阵的维护与使用10
1.目的
定义需求开发与管理过程中的需求获取和需求分析方法，给需求分析人员提供一定的指南。
2.需求获取
需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户是无法完整地讲述其需求，因此需求获取是一件看似简单，做起来很难的一件事情，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。
2.1.明确需要获取的信息（What）
需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。
通常需求获取要获取的信息包括三大类：
Ø与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；
Ø与要求解决的问题直接相关的信息；
Ø用户对系统的特别期望与施加的任何约束信息。
2.2.明确所需获取信息的来源与渠道（Where）
需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。
需求信息的来源通常包括：
Ø来自客户的需求；
✧旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求；
✧系统的潜在用户或客户对系统的需求。
Ø竞争对手的产品优势与不足；
Ø国家政策、业务规则以及相关行业标准；
Ø实施产品设计所需满足的需求；
Ø执行测试验证工作所需满足的需求；
Ø实施系统安装、维护所需满足的需求。
2.3.获取需求（How）
在明确须获取什么需求、需求的来源与获取渠道后，项目经理应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。
需求获取技术包括但不限于：
1）用户访谈
用户访谈的形式包括结构化和非结构化两种。
结构化是指事先准备好一系列问题，有针对性地进行；非结构化是只列出一个粗略的想法，根据访谈的具体情况进行发挥。
有效的访谈需要灵活的结合这两种方法。
用户访谈具有很好的灵活性，有较广的应用范围，但实际操作时存在许多困难，例如客户经常很忙，难以获得充足的访谈时间；客户访谈需要需求分析师有很强的沟通能力，同时也要求需求分析师有足够的相关业务领域知识。
2）用户调查
用户调查是通过精心设计提问问题形成调查问卷，然后下发到相关人员手中，让他们填写答案，来获取用户需求。
用户调查的方法最大的缺点是缺乏灵活性，由于缺乏面多面的交流，所获取的信息量也比较有限。
因此在实际工作中，我们建议可以先采用用户调查的方式获取一定量的信息，然后有针对性地开展用户访谈。
3）现场观摩用户的工作流程，观察用户的实际操作
俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。
4）从行业标准、规则中提取需求
如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则，需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。
这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向，这对从技术出生的需求分析师来说是一个巨大的考验。
5）需求讨论会
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。
它通过联合各个关键客户代表，分析人员，开发人员，通过有组织的会议来讨论需求。
在会议之前，应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。
在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。
6）原型法
原型（prototype）即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。
同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。
原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
原型的基本步骤：
1）根据客户原始需求、项目建议书、市场需求或合同要求，确定系统要做什么，即系统的边界、主要业务或功能、系统的接口
2）根据这些需求，形成系统原型。
对于所形成的原型的基本要求包括
Ø体现主要的功能；
Ø提供基本的界面风格；
Ø展示比较模糊的部分，以便于确认或进一步明确，防患于未然。
Ø原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
3）进行原型评价并获取系统的需求，原型评价可以从几个方面进行
Ø在公司内部演示、评审，进一步获取内部信息，并求得共识；
Ø与用户进行演示与交流，挖掘用户需求，从而确定软件的目标和需求。
4）根据原型评价的意见修改原型，直到求得共识
原型法的优点是：
１）鼓励业务管理者的积极参与；２）有助于解决业务管理者之间的差异；３）能给业务管理者一个对最终系统的直观感受；４）周期短；５）成本低；６）用户较满意。
但原型法也有缺点，主要为：
１）导致人们认为最终系统将很快产生；２）对系统操作权限的说明较弱；３）不适合于开发大系统；４）开发过程管理困难。
3.需求获取资料的保管
根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理。
需求获取的记录与资料包括但不限于：
Ø用户编写的原始需求文档；
Ø用户填写的需求调查表；
Ø用户访谈的访谈纪要；
Ø需求研讨会的会议纪要；
Ø相关的政策法规文件，业务规则文件以及行业标准文件；
Ø需求原型。
4.需求分析
在完成需求获取所得到的记录与资料的分析与整理后，项目经理应组织软件的需求分析工作，建立各需求元素之间的关系，明确分配给软件的需求、需求的分类、需求的优先级等。
需求分析的方法种类繁多，但常见的需求分析方法主要是结构化分析方法和基于用例的需求分析方法。
4.1.问答分析法
常见的问题包括：
Ø需求是否存在二义性
Ø需求文档上下文是否有矛盾
Ø需求是否完备
Ø需求是必要的吗
Ø需求可实现吗
Ø需求可验证吗
Ø需求的优先级确定了吗
4.2.结构化分析方法
结构化分析方法的主要特点是“自顶向下、逐层分解”，它把系统看作一个过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析，描述工具有：
Ø数据流图（DataFlowDiagram，DFD）：
数据流图是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理过程、数据存储。
Ø数据字典（DataDictionary，DD）：
数据字典技术是一种有效表达数据格式的手段，它是对所有与系统相关的数据元素的一个有组织的列表和精确、严格的定义，从而使用户和系统分析员对于输入、输出、存储成分和中间计算机有共同的理解。
Ø结构化语言：
结构化语言是结构化编程语言与自然语言的有机结合，可以采用顺序结构，分支机构、循环结构等机制，来说明加工的处理流程。
Ø判定表和判定树：
判定表是一种处理逻辑的表格表示方法，其中包括决策变量，决策变量值、参与者或公式；而判定树则使用像树枝一样的线条对过程逻辑进行图表化的描述。
判定表和判定树用来描述复杂决策逻辑，要远远优于使用结构化语言。
Ø实体-关系图（EntityRelationshipDiagram，E-R图）：
E-R图可以用来描述数据的存储需求，包括数据实体，数据实体的属性以及它们之间的关系等。
结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法，它不仅是需求分析计划，也是完成需求规格化的有效技术手段，使用结构化分析方法时可遵循下列活动：
1）建立系统的物理模型
首先，画出系统得数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪些处理过程。
在这个数据流图中，可以包括一些非计算机系统中数据流及处理过程的名称，如部门名、岗位名、报表名等。
这个过成可以帮助分析人员有效地理解业务环境。
2）建立系统的逻辑模型
在物理模型建立之后，接下来的工作就是画出相对于真实系统的等价逻辑数据流图。
将所有自然数据流图转换为等价的逻辑流。
3）划清人机界限
最后，确定在系统逻辑模型中，哪些部分将采用自动化完成，哪些部分仍然保留手工操作，从而清晰的划清系统的范围。
4.3.基于用例的分析方法
从定义中我们得知用例是由一组用例实例组成的，用例实例也称为“使用场景”，是用户使用系统的一个实际的、特定场景。
用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（HighLevel）用户功能性需求。
用例分析技术是一种需求合成技术，它利用现有的需求获取技术从客户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中进行整理、提炼，从而建立用例模型。
使用用例分析方法时可遵循以下步骤：
1）识别系统参与者，确定谁会直接使用该系统。
参与者是同系统交互的所有事物，该角色不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟。
2）合并需求获得用例。
找到所有参与者之后，根据需求获取所得到的用户需求，定义每个参与者希望系统做什么，参与者希望系统作的每件事将成为一个用例。
3）绘制用例图。
将所识别的参与者以及所定义的用例通过用例图的形式整理出来，以获得例模型的框架。
4）细化用例描述。
用例描述包括以下几个部分：
Ø用例名称；
Ø用例参与者；
Ø用自然语言对用例进行简要的描述；
Ø描述参与者何时使用该用例，即用例的触发条件；
Ø描述在一般情况下，参与者使用该用例时会发生什么事情，即用例的基本过程；
Ø在基本过程的基础上，考虑一些可变情况，把他们创建为扩展用例。
4.4.需求的优先级的评价标准
需求的优先级的评价标准如下：
级别定义
判断标准
采取的措施
高
满足以下任意一条时：
1）需求实现的紧急程度为特急或紧急；
2）国家或行业法律法规、标准要求的，客户明确要求的,满足正常业务必须的；
对于这些需求在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现。
通常这类需求在当前版本必须实现。
中
满足以下任意一条时：
1）客户隐含要求，对正常业务影响程度不大；
2）需求实现的紧急程度为中；
3）支持必要的系统操作，实现这些需求将增强产品的性能，是产品最终所要求的。
这些需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，如果有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。
低
满足以下任意一条时：
1）功能或质量上的附加功能；
2）实现这些需求会使产品更完美，若不实现也不影响产品的功能与性能，属于锦上添花；
3）需求实现的紧急程度为低；
实现或不实现均可；可以在项目组有较足够的时间时考虑这些需求的实现。
5.需求跟踪
对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。
因此，一个比较好的方法就是建立一种需求双向跟踪机制。
双向跟踪即：
Ø正向跟踪：
当发生需求变更时，通过从需求向后追溯到下游相关工作产品，可分析出这些关联项是否需要变更，从而达到追溯的目的；
Ø逆向跟踪。
通过从下游工作产品回溯到需求，可分析需求是否得到满足，从而达到回溯的目的。
进行需求双向跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。
这个映射可以用需求跟踪矩阵来实现。
5.1.建立需求跟踪矩阵
当《软件需求规格说明书》通过评审之后，项目经理应组织根据确定的需求跟踪的粒度编制《需求跟踪矩阵》。
项目经理指定人员对需求跟踪矩阵进行个人复查，确保跟踪粒度合理、跟踪项适用。
5.2.需求跟踪矩阵的维护与使用
随着软件设计、编码、以及测试开发的不断推进，各个阶段的负责人员在各个阶段产品形成时，将相关的信息填入《需求跟踪矩阵》，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，使阶段工作产品与需求形成对应关系。
对于已纳入《需求跟踪矩阵》的相关工作产品产生的变更，则由《需求跟踪矩阵》的维护人员（项目配置管理员）在每次变更完成后根据变更修改《需求跟踪矩阵》的对应关系，在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。
在项目实施过程中，项目组可以利用需求跟踪矩阵实施相关的控制，如：
Ø利用需求跟踪矩阵，审核所有定义的需求是否已经在相关产品中得到实现；
Ø当发生需求变更时，可以利用需求跟踪矩阵受需求变更影响的其它工作产品，确保不忽略每个受到影响的系统元素；
Ø当相关的工作产品产生变更时，可以向前追溯到与其相关的需求与其它工作产品，从而判断是否需要对这些关联产品进行变更；
Ø在开发过程中，可以对所有定义的需求的当前开发状态进行跟踪。
6.需求建议
我们可以从以下几个方面来初步评价我们的需求质量。
Ø首先，看句子和段落是否简短。
长句子看起来会非常困难，很难弄懂真正的需求：
另外，过长的句子和段落容易让人忽视一些需求。
所以，如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。
Ø其次，句子是否有语法错误，还要注意标点符号，有时，标点符号点错了就完全成了另外一个意思。
再次，是否存在模糊不清的需求，出现“可能，大概，或者”等词汇表述。
Ø最后，注意是否存在形容词及比较性词语，比如：
容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的、界面友好的、减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围。
Ø另外，保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化就很容易造成代码的返工，出现程序员尽管加班加点却总是不能如期完成任务的情景。
怎样才能判断需求细化的程度呢？
需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？
答案是：
是否可以将需求写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要进一步进行细化。
升级会员 