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