软题库 移动APP 扫码下载APP 随时随地移动学习 培训课程
当前位置:信管网 >> 综合知识 >> 文章内容
需求开发和需求管理过程
来源:信管网  2015年01月26日  【信管网:项目管理师专业网站所有评论

软件需求工程包括了需求开发和需求管理两个部分,需求开发的目的是通过调查与分析,获取用户需求并定义软件需求。需求开发的主要活动包括:需求获取,需求分析和需求定义。

需求管理的目的是在客户与项目组之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。 需求管理的主要活动包括:需求确认,需求变更和需求跟踪控制。

1. 需求获取

需求获取的目的是通过各种途径获取用户的需求信息,由于在实际工作中,大部分客户是无法完整地讲述其需求,因此需求获取是一件看似简单,做起来很难的一件事情,需求获取的质量,对后续的需求分析和需求定义工作将会产生重大影响。

1.1. 明确需要获取的信息(What)

需求分析师应在需求获取前明确需要获取的需求信息,以确保在实施需求获取时有的放矢。

通常需求获取要获取的信息包括三大类:

l  与问题域相关的背景信息(如业务资料,组织结构图,业务处理流程等);

l  与要求解决的问题直接相关的信息;

l  用户对系统的特别期望与施加的任何约束信息。

1.2. 明确所需获取信息的来源与渠道(Where)

需求分析师在明确了所需要获取的信息之后,应确定获取需求信息的来源与渠道,以提高需求分析师在需求获取阶段的工作效率,使得所收集的信息更加有价值、更加全面。

需求信息的来源通常包括:

l  来自客户的需求

a)     旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求

b)     系统的潜在用户或客户对系统的需求

l  竞争对手的产品优势与不足

l  国家政策、业务规则以及相关行业标准

l  实施产品设计所需满足的需求

l  执行测试验证工作所需满足的需求

l  实施系统安装、维护所需满足的需求

获取需求信息的渠道包括:

l  用户或客户

l  研发部

l  市场部

l  旧有系统的研发项目组

l  来自项目组内

1.3. 获取需求(How)

在明确须获取什么需求、需求的来源与获取渠道后,项目经理应选择至少一种需求获取技术获取相关的需求,作为需求分析的依据。需求获取技术包括但不限于:

1) 用户访谈

用户访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题,有针对性地进行;非结构化是只列出一个粗略的想法,根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。

用户访谈具有很好的灵活性,有较广的应用范围,但实际操作时存在许多困难,例如客户经常很忙,难以获得充足的访谈时间;客户访谈需要需求分析师有很强的沟通能力,同时也要求需求分析师有足够的相关业务领域知识。

2) 用户调查

用户调查是通过精心设计提问问题形成调查问卷,然后下发到相关人员手中,让他们填写答案,来获取用户需求。

用户调查的方法最大的缺点是缺乏灵活性,由于缺乏面多面的交流,所获取的信息量也比较有限。因此在实际工作中,我们建议可以先采用用户调查的方式获取一定量的信息,然后有针对性地开展用户访谈。

3) 现场观摩用户的工作流程,观察用户的实际操作

俗话说,“百闻不如一见”,对于一些较为复杂的流程和操作而言,是比较难以用语言和文字进行表达的,对于这种情况,可以采用到客户的工作现场,一边观察,一边听客户讲解,从而更直观的了解客户需求。

4) 从行业标准、规则中提取需求

如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则,需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档,并与相关领域的业务专家进行业务交流来了解客户的需求。

这种方法要求需求分析师有一定的行业从业经验,能够了解行业的发展动向,这对从技术出身的需求分析师来说是一个巨大的考验。

5) 文档考古

对于一些数据流比较复杂的、工作表单较多的项目,有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究,考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告,获得所需的信息。

6) 需求讨论会

这是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它通过联合各个关键客户代表,分析人员,开发人员,通过有组织的会议来讨论需求。

在会议之前,应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。在会议开始之后,先针对材料所列举的问题进行逐项专题讨论,然后对原有系统、类似系统的不足进行开放性交流,并在此基础上对新的解决方案进行构思,在此过程中将所有的想法、问题和不足记录下来,形成一个要点清单,作为后续需求分析的依据。

7) 原型法

原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”,以可视化的形式展现给用户,及时征求用户意见,从而明确无误地确定用户需求。同时,原型也可用于征求内部意见,作为分析和设计的接口之一,可方便于沟通。原型法主要价值是可视化,强化沟通,降低风险,节省后期变更成本,提高项目成功率。

原型的基本步骤:

1)  根据客户原始需求、项目建议书、市场需求或合同要求,确定系统要做什么,即系统的边界、主要业务或功能、系统的接口;

2)  根据这些需求,形成系统原型。对于所形成的原型的基本要求包括:

l  体现主要的功能;

l  提供基本的界面风格;

l  展示比较模糊的部分,以便于确认或进一步明确,防患于未然。

l  原型最好是可运行的,至少在各主要功能模块之间能够建立相互连接。

3)  进行原型评价并获取系统的需求,原型评价可以从几个方面进行:

l  在公司内部演示、评审,进一步获取内部信息,并求得共识

l  与用户进行演示与交流,挖掘用户需求,从而确定软件的目标和需求

4)  根据原型评价的意见修改原型,直到求得共识

原型法的优点是:1)鼓励业务管理者的积极参与;2)有助于解决业务管理者之间的差异;3)能给业务管理者一个对最终系统的直观感受;4)周期短;5)成本低;6)用户较满意。

但原型法也有缺点,主要为:1)导致人们认为最终系统将很快产生;2)对系统操作权限的说明较弱;3)不适合于开发大系统;4)开发过程管理困难。

1.4. 需求获取资料的保管

根据所采用的需求获取技术,在需求获取过程中将产生不同的记录和原始资料,项目组应将这些记录纳入开发库进行配置管理,并且整理生成项目的原始需求文档。需求获取的记录与资料包括但不限于:

l  用户访谈的访谈纪要;

l  需求研讨会的会议纪要;

l  相关的政策法规文件,业务规则文件以及行业标准文件;

l  需求原型。

2. 需求分析

    在完成需求获取所得到的记录与资料的分析与整理后,项目经理应组织软件的需求分析工作,建立各需求元素之间的关系,明确分配给软件的需求、需求的分类、需求的优先级等。

需求分析的方法种类繁多,但常见的需求分析方法主要是结构化分析方法和基于用例的需求分析方法。

2.1. 结构化分析方法

结构化分析方法的主要特点是“自顶向下、逐层分解”,它把系统看作一个过程的集合体,利用图形等半形式化的描述方式表达需求,对问题进行分析,描述工具有:

l 数据流图(Data Flow Diagram,DFD):数据流图是一种图形化的系统模型,它在一张图中展示信息系统的主要需求,即输入、输出、处理过程、数据存储。

l 数据字典(Data Dictionary,DD):数据字典技术是一种有效表达数据格式的手段,它是对所有与系统相关的数据元素的一个有组织的列表和精确、严格的定义,从而使用户和系统分析员对于输入、输出、存储成分和中间计算机有共同的理解。

l 结构化语言:结构化语言是结构化编程语言与自然语言的有机结合,可以采用顺序结构,分支机构、循环结构等机制,来说明加工的处理流程。

l 判定表和判定树:判定表是一种处理逻辑的表格表示方法,其中包括决策变量,决策变量值、参与者或公式;而判定树则使用像树枝一样的线条对过程逻辑进行图表化的描述。判定表和判定树用来描述复杂决策逻辑,要远远优于使用结构化语言。

l 实体-关系图(Entity RelationshipDiagram,E-R图):E-R图可以用来描述数据的存储需求,包括数据实体,数据实体的属性以及它们之间的关系等。

结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法,它不仅是需求分析计划,也是完成需求规格化的有效技术手段,使用结构化分析方法时可遵循下列活动:

1)  建立系统的物理模型

首先,画出系统得数据流图,说明系统的输入、输出数据流,说明系统的数据流情况,以及经历了哪些处理过程。在这个数据流图中,可以包括一些非计算机系统中数据流及处理过程的名称,如部门名、岗位名、报表名等。这个过成可以帮助分析人员有效地理解业务环境。

2)  建立系统的逻辑模型

在物理模型建立之后,接下来的工作就是画出相对于真实系统的等价逻辑数据流图。将所有自然数据流图转换为等价的逻辑流。

3)  划清人机界限

最后,确定在系统逻辑模型中,哪些部分将采用自动化完成,哪些部分仍然保留手工操作,从而清晰的划清系统的范围。

2.2. 基于用例的分析方法

从定义中我们得知用例是由一组用例实例组成的,用例实例也称为“使用场景”,是用户使用系统的一个实际的、特定场景。用例是应用程序开发中的一个关键技术,主要用来捕获系统的高层次(High Level)用户功能性需求。用例分析技术是一种需求合成技术,它利用现有的需求获取技术从客户、原有系统、文档中找到需求,记录下来,然后从这些零散的需求、特性中进行整理、提炼,从而建立用例模型。

使用用例分析方法时可遵循以下步骤:

1)       识别系统参与者,确定谁会直接使用该系统。参与者是同系统交互的所有事物,该角色不仅可以由人承担,还可以是其它系统、硬件设备、甚至是时钟。

2)       合并需求获得用例。找到所有参与者之后,根据需求获取所得到的用户需求,定义每个参与者希望系统做什么,参与者希望系统作的每件事将成为一个用例。

3)       绘制用例图。将所识别的参与者以及所定义的用例通过用例图的形式整理出来,以获得例模型的框架。

4)       细化用例描述。用例描述包括以下几个部分:

l 用例名称;

l 用例参与者;

l 用自然语言对用例进行简要的描述;

l 描述参与者何时使用该用例,即用例的触发条件;

l 描述在一般情况下,参与者使用该用例时会发生什么事情,即用例的基本过程;

l 在基本过程的基础上,考虑一些可变情况,把他们创建为扩展用例;

3. 需求定义

需求定义的目的是根据需求获取和需求分析的结果,进一步定义软件需求,产生《需求规格说明书》。

3.1. 标识需求

为了确保需求的易跟踪、易修改,需求分析师应通过需求编号的方式唯一标识每一个软件需求,明确需求的跟踪粒度,并体现于需求规格说明书

3.2. 定义需求的优先级

需求分析师应确定每个需求的优先级并写入需求规格说明书,需求的优先级的评价

标准如下:

级别定义

判断标准

采取措施

满足以下任意一条时:

1)              需求实现的紧急程度为特急或紧急

2)              国家或行业法律法规、标准要求的,客户明确要求的,满足正常业务必须的。

对于这些需求在项目实施过程中需重点投入资源,优先实现,只有在这些需求上达成一致意见,软件才会被接受;必须完美地实现。通常这类需求在当前版本必须实现。

满足以下任意一条时:

1)            客户隐含要求,对正常业务影响程度不大

2)            需求实现的紧急程度为中

3)            支持必要的系统操作,实现这些需求将增强产品的性能,是产品最终所要求的。

这些需求必须被实现,但如果项目实施中出现进度、资源等方面的冲突时,如果有必要,可以延迟到下一版本;需要付出努力,但不必做得太完美。

满足以下任意一条时:

1)            功能或质量上的附加功能;

2)            实现这些需求会使产品更完美,若不实现也不影响产品的功能与性能,属于锦上添花;

3)            需求实现的紧急程度为低;

实现或不实现均可;可以在项目组有较足够的时间时考虑这些需求的实现

优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时,能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是:当接受一个新的高优先级的需求或者其它项目环境变化时,删除低优先级的需求,或者把它们推迟到下一版本中去实现。

3.3. 编写《需求规格说明书》

需求分析师在需求分析过程中根据分析步骤逐步编制形成《需求规格说明书》。编写需求规格说明书应遵循以下规则:

l  相关的需求都得到了识别与描述,以确保需求的完整性;

l  各个需求之间不冲突,算法之间不相互矛盾,以确保需求的一致性;

l  正确描述系统需求,引用的资料有正规的出处,以确保需求的正确性;

l  定义必要的术语,适当结合图形、结构图等方式进行描述,以确保需求无二义性;

l  使用较好的文档结构与需求标识,使需求能够方便地与其它工作产品相对应,以确保需求易于追溯;

l  确保所描述的需求可以通过适当的手段得到验证,即需求的可测试性;

l  考虑了各个层次的需求,确定了需求的优先级,以确保需求的可行性。

《需求规格说明书》可以包括但不局限于:

l  需求描述约定

l  系统概述,如系统功能、业务描述、数据流程描述、用户的特点、运行环境要求、设计与实现上的限制等

l  功能需求描述

l  非功能性需求,如系统性能要求、***备份与恢复要求、系统日志等。

l  外部接口说明,如软硬接口、通信接口等

l  其它需求描述

l  功能列表等

4. 需求确认

需求确认是指项目组和客户(或客户代表)共同对《需求规格说明书》进行评审,双方对需求达成共识后做出承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”。

4.1. 需求评审

应对所形成的需求文档进行评审,以便作为下一阶段工作的基础。需求评审的方式分为“技术评审会议”。

项目组根据需求分析的进展情况,采用“组内评审”的方式分阶段对需求分析的阶段成果进行评审,分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了需求返工的风险,提高了评审的质量。组内评审要求:

l  评审组长:项目经理;

l  评审组成员:需求分析师、系统分析师、测试工程师,适当邀请组外专家参与;

l  输入:《需求规格说明书》初稿

l  输出:会议纪要

l  检查单:需求评审检查单

项目组只有在完成组内评审、并完成问题修改与验证后,方可向公司提出技术评审会议申请。当需要召开技术评审会议时,由项目组向项目管理部门提出需求技术评审申请和组内评审会议纪要,项目管理部门完成文档规范性、完整性检查,并确认已经通过内部评审后,提交评审管理部门,由评审管理部门组织按“技术评审会议”的方式实施需求评审。技术评审会议要求如下:

l  评审组织部门:评审管理部门

l  评审组成员:

a)     项目组代表

b)     测试组代表

c)     公司的技术专家与业务专家

d)    实施组代表

e)     客户或客户代表

f)      系统关联组代表

g)     QA工程师

l  输入:需求规格说明书以及相关文档

l  输出:评审报告

l  检查单:需求评审检查单

关于“技术评审会议”的要求详见《评审规程》。

4.2. 需求承诺

项目经理将评审通过的《需求规格说明书》提交给客户(或客户代表)、系统关联项目组进行确认,确认的方式可以是以下方式之一:

l  直接签字:由承诺方在评审报告上直接签字或盖章确认

l  邮件方式:由项目经理将《需求规格说明书》与评审报告通过邮件发送给接收方,并明确确认通过的准则(如:如果在一周内未予以回复则默认为确认通过);

l  发送会议纪要函:如果承诺方参加了评审会议并在会上达成了共识,则可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等,并通过纪要函的方式发送给承诺方。

4.3. 建立需求基线

项目的需求规格说明书经过评审与确认后,应根据《配置管理过程》的要求建立需求基线。

5. 需求变更

对一个软件项目来说,无论最初的需求分析有多么明确,开发过程中的需求变化也还是不可避免的。这主要有以下几种原因:

1.       软件所应用的外部环境发生变化;

2.       随着用户对软件的熟悉和应用,又提出新的需求;

3.       项目组进行需求分析时未能彻底分析用户的需求,或分析错误;

4.       用户在开始时不能很全面的知道所需软件的功能。

5.1. 需求变更申请

需求变更由变更申请人通过填写《软件变更申请表》向项目组提出进行。

当项目组接收到项目管理部门的《软件变更申请表》时,应先根据要求进行需求的评估,判断需求的类型、分析需求变更影响到的范围、估算需求实现的工作量(含需求、设计、编码、测试、用户文档编写)、预计可以完成的时间等内容。若估算的开发工作量大于10人月时,项目组可以根据《项目立项过程》的要求向项目管理部提出项目立项申请;若小于10人月,且评估结果与申请部门达成共识,则开发项目组根据《计划变更规程》实施变更,若无法达成共识,则提交研发部进行最终裁定。

5.2. 需求变更的实施

项目组根据《计划变更规程》中的要求实施变更。

在变更完成后,若需要发布新的需求基线,项目组应根据《配置管理过程》中“基线发布”的要求重新建立需求基线,并通知相关的人员。

6. 需求跟踪

对一个软件项目来说,当需求确定下来以后,应该保证在软件设计过程中每个需求都被实现,且项目的其它工作产品与需求保持一致。因此,一个比较好的方法就是建立一种需求双向跟踪机制。双向跟踪即:

l 正向跟踪:当发生需求变更时,通过从需求向后追溯到下游相关工作产品,可分析出这些关联项是否需要变更,从而达到追溯的目的;

l  逆向跟踪。通过从下游工作产品回溯到需求,可分析需求是否得到满足,从而达到回溯的目的。

进行需求双向跟踪的一个简单的方法是建立一个映射,从需求到设计,从设计到编码,以及从编码到测试用例,把每个需求都映射到对应的位置。这个映射可以用需求跟踪矩阵来实现。

6.1. 建立需求跟踪矩阵

当《需求规格说明书》通过评审之后,项目经理应组织根据确定的需求跟踪的粒度编制《需求跟踪矩阵》。项目经理指定人员对需求跟踪矩阵进行个人复查,确保跟踪粒度合理、跟踪项适用。

6.2. 需求跟踪矩阵的维护与使用

随着软件设计、编码、以及测试开发的不断推进,项目经理应指定专人在项目的各个阶段产品形成时,将相关的信息填入需求跟踪矩阵,建立阶段工作产品与需求的对应关系,并由项目经理指定人员对其完整、正确、一致性进行确认。对于已纳入需求跟踪矩阵的相关工作产品产生的变更,则由项目经理在每次变更完成后根据变更修改需求跟踪矩阵的对应关系,在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。

在项目实施过程中,项目组可以利用需求跟踪矩阵实施相关的控制,如:

l  利用需求跟踪矩阵,审核所有定义的需求是否已经在相关产品中得到实现;

l  当发生需求变更时,可以利用需求跟踪矩阵受需求变更影响的其它工作产品,确保不忽略每个受到影响的系统元素;

l  当相关的工作产品产生变更时,可以向前追溯到与其相关的需求与其它工作产品,从而判断是否需要对这些关联产品进行变更;

在开发过程中,可以对所有定义的需求的当前开发状态进行跟踪。



分享到: 新浪微博 腾讯朋友 收藏本页
发表评论  查看完整评论  

相关内容

推荐文章
合作网站内容