07软件需求之需求管理Word下载.docx
- 文档编号:20655662
- 上传时间:2023-01-24
- 格式:DOCX
- 页数:33
- 大小:157.52KB
07软件需求之需求管理Word下载.docx
《07软件需求之需求管理Word下载.docx》由会员分享,可在线阅读,更多相关《07软件需求之需求管理Word下载.docx(33页珍藏版)》请在冰豆网上搜索。
●标识需求、项目计划和工作产品之间的不一致性;
●采取纠正措施。
1.2需求管理的实践
为了实现需求管理,很多标准都提供了参考实践(下面的需求管理实践的描述参考了GJB5000A-2008“需求管理(ReqM)”过程域的描述)。
1,实践1:
获得对需求一致的理解
这是一个简单的目标,也是一个明确的目标。
需要建立某些项目管理方法并且在组织中共享这种方法,这样才可能以一致的、可重复的方法达到这个目标。
例如:
给利益相关人评审和理解需求的机会,然后对需求进一步澄清。
一旦达成协议,需求的基线版本就可以发布了,如下图所示。
在这个过程中,一般有五个事情要做:
1)用文档记录需求
用文档记录需求似乎是个不言而喻的事情,但问题是我们的需求文档书写的怎么样?
是不是容易阅读?
是不是图文并茂?
是不是把握了重点?
功能需求、非功能需求、约束条件是不是描述的准确全面?
更重要的,需求是不是以可测试的方式来描述,特别是质量属性?
文档的格式很重要,它反映了书写着是不是重视,如果UML图形符号用的不对,可能立刻就暴露出书写者的水准不够,或者不认真。
需求书写的认真和正规,立即就可以引起评审者的重视。
2)识别利益相关人
关键是要识别,到底谁对需求感兴趣,利益相关人是与需求有直接关系的人:
批准需求的人、审查需求的人、使用需求工作的人。
我们与这些人一起工作,以确信获得了正确的需求集合,并能够最终满足顾客的需要。
3)分配需求已对其评审
我们并不是强迫人们去理解需求。
我们工作是保证所有的人都有机会去理解需求。
为了培育这样的机会,就可能制定一种分发机制(电子邮件、打印的副本等),可能还需要不时分发更新的版本,建立一种分发流程也可能是好想法。
4)给评审一定的时间
利益相关人需要获得对需求充分的理解,那就需要有充足的时间来理解需求,因此需要留有时间,而不是急冲冲的开个评审会。
5)鼓励反馈意见
如果利益相关人觉得他们的评论得到重视,他们就可能会出色的完成需求评审工作。
鼓励反馈并给利益相关人提供反馈的方式,例如电子邮件、问题日志和任何有利于记录问题的形式。
典型工作产品:
●辨别合适的需求提供者的准则;
●需求的评价和验收准则;
●对照准则分析需求的结果;
●达成一致的需求集。
2,实践2:
获得对需求的承诺
前一个实践处理与需求提供者一起得出对需求的共识,而这一个实践则处理项目参与者之间的协议和承诺,项目参与者是负责执行实现需求必要括动的那些人。
需求演化贯穿整个项目,在需求演化过程中,要确保项目参与者对当前的、经批准的需求作出承诺,以及对在项目计划、活动和工作产品中所发生的更改作出承诺。
事实上这是一个让很多人感觉困惑的问题。
承诺之所以重要有几个原因:
●它创建了一个认可的气氛,人们已经同意工作可以继续了。
●它意味着外界的反馈意见:
要求批准需求的人有机会不批准需求,因为他认为需求还没有达到可以继续工作的地步。
●承诺建立了多数人共识的一种可见的途径,它向管理层和顾客证明,项目组确实可以在一起工作。
很多人认为承诺就是顾客在需求上确认签字。
但为什么很少有人能够寻求到这个签字呢?
这牵涉到对于需求的理解。
最初的需求并不是结果,它只是一个基线,也就是在现在我们的认识水平下,我们已经达成了共识,项目可以开始了。
签字并不等于冻结需求,因为我们的都认可随着项目进展,我们对问题会有新的看法,如果需求没有变化,那也不需要需求管理了。
这个观点,应该在需要签字的表格中表达清楚。
这种沟通非常重要,当批准需求的人面对着一个陌生的复杂的解决方案,我们常常会发现他们在批准和发布需求的时候犹豫不决。
因为他们觉得需求一旦发布,自己就没有了任何发言机会了。
项目管理者应该充分表达这样的观点,通过确保需求管理过程是一个持续的、迭代的过程,并且有充足的机会调整和调节需求(在项目计划中已经预留了这种调整的时间),这种顾虑完全可以消除。
在这个结合点上的管理目标是建立一个需求基线。
需求基线将起到公共出发点的作用,并且作为未来所有迭代的基准集。
如果利益相关人觉得需求可以容纳未来的变更,那他们将很愿意提交这个基线版本,并且帮助我们“获得批准签名”。
承诺有多种方式,最传统的就是签名,白纸黑字是好东西,它表明了承诺的最明确的途径。
但也可能有多种形式,电子邮件、口头认可也未尝不可,但都不如签名好。
关键是要表达清楚,签字并不等于冻结需求,它只是表明目前我们已经达成了共识,项目可以进行下去了。
●需求影响评估;
●对需求和需求更改的承诺的记录。
3,实践3:
需求变更控制
项目期间,需求可因多种理由更改。
当需要更改和工作进展而产生附加的需求时,可能不得不对现有需求进行更改。
如何有效且高效地管理这些附加需求及其更改是很重要的。
为了有效地分析这些更改的影响,必须知道每个需求的来源,并记录每个更改的理由。
尽管如此,项目经理可能还希望跟踪适当的、反映需求更改程度的测量项,以便判定是否要实施新的控制或修正现有的控制。
软件变更通常有两种不同的类型:
功能变更与缺陷修补(Bug-Fix)。
1)功能变更
功能变更是为了增加与删除某些功能,这种变更必须通过某种正式的变更评价过程,以评估变更需要的成本和对软件系统其它部分的影响,如果变更的代价比较小,而且对其它部分的影响也比较小,通常就可以批准这个变更。
反之,如果变更的代价比较大,则必须权衡利弊,如果同意这种变更,就需要进一步确定到底由谁来支付变更所需要的费用。
如果是客户要求变更,则客户就应该支付这笔费用,否则就需要进行效益分析,以确定是否值得做这种变更。
因此,功能变更往往涉及到软件额外费用问题。
2)缺陷修补
缺陷修补是为了修复漏洞需要进行的变更,在项目前期,它是必须进行的,通常不需要从管理的角度对这类变更进行审查和批准。
在项目后期,如果发现错误的阶段在造成错误的阶段后面,则必须遵照标准的变更控制过程来进行。
如果进行修补,则必须把这个变更正式计入文档,把所有受到这个变更影响的文档都进行修改。
变更请求管理的复杂程度与变更的类型有关。
首先,需要审批变更申请。
由需求变更申请人撰写《需求变更申请书》,递交给项目经理。
需求变更申请书必须阐述变更原因、变更内容以及此变更对项目造成的影响。
项目经理和客户共同审批《需求变更申请书》,如果任何一方不同意变更,则退回变更请求,项目按原需求文档执行;
如果双方都同意变更则进入变更请求管理流程阶段。
项目经理组织CCB小组实施变更请求管理流程,具体步骤如下:
1)变更请求提交
项目经理把需求变更申请人撰写的《需求变更申请书》递交给CCB小组。
2)变更请求接收
CCB组长指定接收和处理变更请求的责任人,检查变更请求的内容是否清晰、完整、正确,包括:
●是否已存在重复请求或误解。
●对变更请求赋予唯一的标识符。
●建立变更跟踪记录。
在请求接收后,必须对这些请求进行评估。
3)变更请求评估
CCB小组成员对请求的特征作出决定,确定变更影响的范围和修改的程度。
需要考虑:
提出请求客户的重要性、对市场的可能影响、对开发部门的影响、对成本的影响、对销售人员和客户支持人员的影响等。
4)变更请求决策
CCB小组根据评估对变更请求作出决定,包括:
立即实施、推迟实施、不实施。
如果决定推迟实施和不实施,则通知需求变更申请人并阐明理由,变更请求过程结束。
如果决定立即实施,则转下一步。
5)变更请求实现
项目经理指定相关人员对需求文档进行变更,标识新的需求版本,同时获取需求承诺。
6)变更请求验证
项目经理要求相关人员验证变更是否满足需要。
7)变更请求完成
不论实现或者不实现变更,均关闭请求循环。
●需求状态;
●需求数据库;
●需求决策数据库。
4,实践4:
维护需求的双向可追溯性
对每一层的产品分解,要维护需求的双向可追溯性。
当需求受到良好的管理时.就可建立从源需求到较低层需求和从较低层需求回到它们的源需求的双向可追溯性。
这种双向可追溯性有助于确定己处理所有源需求,并且所有较低层需求能够被追溯到有效的来源。
1)需求跟踪动机
需求跟踪提供了一个表明与合同或说明一致的方法。
它可以改善产品质量,降低维护成本,而且很容易实现重用。
项目中的需求跟踪能力有如下好处:
●帮助审核确保所有需求被应用。
●在需求发生增、删、改时可以确保不忽略每个受到影响的系统元素。
●使得维护时能正确、完整地实施变更。
●在重新设计时,可以列出传统系统中将要替换的功能,记录它们在新系统的需求和软件组件中的位置。
●在设计新系统时发现旧系统相关资源。
功能设计、相关需求、代码、测试等。
●减小风险,使部件互连关系文档化,减少关键成员离开项目带来的风险。
2)需求跟踪能力链
下图说明了四类跟踪能力。
客户需求可向前追溯到需求,这样就能区分出开发过程中或开发结束后由于需求变更受到影响的需求。
这也确保了需求规格说明书包括所有客户需求。
同样,可以从需求回溯相应的客户需求,确认每个软件需求的源头。
如果用用例的形式来描述客户需求,图的左半部分就是用例和功能性需求之间的跟踪情况。
下图说明了许多能在项目中定义的直接跟踪能力联系链。
3)需求跟踪能力矩阵
表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。
下表展示了这种矩阵。
一种需求跟踪能力矩阵
用例
功能需求
设计元素
代码
测试实例
UC-28
catalog.query.sort
Class
catalog.sort()
search.7
catalog
search.8
UC-29
catalog.query..import
catalog..import()
catalog.validate()
search.13
search.14
每个功能需求向后连接一个特定的用例,向前连接一个或多个设计、代码和测试元素。
设计元素可以是模型中的对象。
加上更多的列项就可以拓展到与其它工作产品的关联,例如在线帮助文档。
包括越多的细节就越花时间,但同时很容易得到相关联的软件元素。
这样的跟踪能力联系链可以定义各种系统元素类型间的一对一,一对多,多对多关系。
4)需求跟踪的基本处理步骤
应用需求跟踪能力来管理工程时,可以考虑下列步骤:
●首先要决定定义哪几种联系链。
●选择使用的跟踪矩阵的种类。
●确定对产品哪部分维护跟踪能力信息。
并不是处处需要跟踪,而是由关键的核心功能、高风险部分或将来维护量大的部分开始做起。
●通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链。
●制定标记性的规范,用以统一标识所有的系统元素,达到可以相互联系的目的。
●确定提供每类联系链信息的个人。
●培训项目组成员,使其接受需求跟踪能力的概念和了解重要性、这次活动的目的、跟踪能力数据存储位置、定义联系链的技术。
●一旦有人完成某项任务就要马上更新跟踪能力数据,即立刻通知相关人员更新需求链上的联系链。
●在开发过程中周期性地更新数据,以使跟踪信息与实际相符。
5,实践5:
标识项目工作与需求之间的不一致性
检查需求与项目计划和工作产品之间的不一致,并启动纠正措施来纠正它们。
●记录不一致性的文档,包括一致性的来源、条件和理由;
●纠正措施。
2.验证与确认的基本概念
验证(Ver)和确认(Val)是软件工程重要的组成部分,也软件产品质量控制的重要手段。
它来自于这样一个理念:
“质量从来都不是偶然达到的,它总是智慧工作的结果”。
1,验证与确认的定义
在实践中,验证与确认关系比较紧密,容易给人以误解,因此首先必须给出明确的定义。
●验证:
是确保所选的工作产品满足指定的要求。
为了实现验证,需要定义一套验证测试方法,用于按指定的要求检验工作产品。
验证一般还会要求同行评审,这是一种在早期排除缺陷的方法,可以对正在开发和维护的工作产品进行有价值的深入考察,而且其有效性已经得到了证明。
●确认:
是按顾客需求增量式地确认产品已经达到了要求。
确认可以在运行环境或仿真环境中进行,也可以通过正式评审。
确认活动使用与验证类似的方法,例如:
测试、分析、审查、演示或模拟。
最终用户与其他利益相关方需要共同参与确认活动。
确认和验证活动常常并发进行,或者是不断交替进行的,其工作方式也有很多类似之处,并可以使用相同环境的一些部分,这很容易造成某些误会,因此必须明确这两者的区别。
要注意到确认和验证的根本区别在于目标。
验证的目标在于发现问题和解决问题,所强调的是过程。
其关注的是工作产品是否合适地反映了指定的需求,并尽早发现隐含的缺陷。
从方法上来说:
验证大部分使用非正式的评审方法(同行评审、走查、质量关),验证的结果可能是一张问题表,用于提醒相关人员修正缺陷。
换句话说,验证确保“你正确地做了”。
确认的目标在于确定工作产品是否正确,强调的是结果。
确认证实所提供的产品符合预定的要求。
确认大多数使用正式评审,其结果是被接受的阶段或最终产品,这个结果往往作为重要的基线存在。
换句话说,确认则确保“你做了正确的东西”。
2,利于早期发现问题降低成本
验证和确认强调早期、持续,而不是后期一步到位,但为什么要这么做呢?
如果提前针对验证和修改过程中花费一些金钱,将在后期的测试、维护和客户支持中节省更多的时间。
如果组织建立了有效的验证程序,并对质量进行跟踪控制的话,这种付出就是值得的,总的回报远远超过这一个过程的支出。
人们早已认识到,验证与确认有利于早期发现缺陷,可以减少项目的总体成本和工作量,而且加快了交付进度。
缺陷如果进入到了后期测试阶段,就可能需要执行多项测试来确定错误,并要进行额外的工作来获得测试信息,一旦发现遗漏的缺陷,正在生产过程中的程序员必须放下手上的工作,集中精力来修正错误,并确定其正确性,结果使总体工作效率大大下降。
所有的研究都表明后期修复错误成本的增加非常巨大,越早发现错误,修正它的成本就越低。
下面的图表达了这个关系。
、
但令人费解的是,验证经常是强行推行的,没有人对它的非经济价值提出异议,但在一个混乱的进度表和拙劣的管理模式下,验证在经济上的好处往往并不能被人感觉出来。
令人欣慰的是,过去20年中,人们收集了很多数据证明了验证的好处,例如,WattsHumphrey的研究发现,需求期间的1个小时能修正的错误,到设计阶段变成3-6小时,到编码阶段是10小时,到测试活动就变成15-40小时,到验收阶段是30-70小时,到操作阶段就是40-1000小时,成本相应大幅的增加。
3,同行复审
验证的重要手段就是同行复审(也称之谓走查),它除了经济效益以外还有非经济收益,包括可以抵消任务中与人有关的问题:
●同行复审可以发现无关的部分,而测试不能。
复审可以遵循所有的分支路径,而测试不能测试所有路径,在不频繁进入的路径中,经常会留下错误。
●不同的思维方式、个性和生活经历,有助于发现各种问题,仅凭一个人的视角,往往很难发现问题。
●当开发人员知道具有同级人员复审这样一张安全网的时候,会激发更多的创造性,并且在灵感闪现的时候,能够更加现实。
●工作与人员分离,复审者可以把精力放在发现问题上。
●由于复审需要合适的“块”,强化了开发人员模块化的思考方式,并利用高内聚低耦合的知识,提升整体上的质量。
●在开发人员复审环境中,人们可以通过别人的工作,吸取他人的有益设想,并进行传播,有人认为这是复审的最重要的结果。
●增加了团队的一致性,确立了事实上的团队行为标准。
●项目经理能够知道产品的真实状态,有时开发人员认为很重要的事情,尽管没有恶意,但这个行为可能会破坏项目。
经验表明,在开发过程中进行同行复审,有助于减少人力资源的投入,大大减少了测试工作量,以及设计和编码的重复工作量,结果是从整体上节约了成本,还缩短了进度。
4,需求的质量关
在我们对验证有比较深入理解的基础上,让我们花一点时间来考虑需求质量控制的方法,毕竟这需要投一些工作量来确保需求的正确性。
在前面大量工作的基础上形成的“需求规格说明”,并不是最后评审过的包括版本号、发布日期以及批准签名的正式版本,而仅仅是正在形成正式基线版本之前的一项或者多项需求的集合,不论它以什么形式存在,甚至包括头脑中的需求。
以每项需求为单位的验证措施也称之为质量关,其意义在于能够帮助我们早期发现错误。
需求质量关实际上是一个关卡,防止不受欢迎的需求进入规格说明。
每项需求都必须尽过验证测试,以判断它的正确性和合适性,不受欢迎的需求包括:
不完整的、不可追踪的、不一致的、无关的、不正确的、二义性的、不可行的、属于解决方案的、镀金的或者蔓延的需求。
被拒绝的需求将被返回给提供者。
3.需求验证测试的步骤
需求验证测试需要有一套检查方法来确保“你正确地做了”。
事实上也需要一个检查单来逐项检查需求编写的质量。
很多人认为只要需求能表达清楚问题就可以了,殊不知很多后期发现的需求歧义,都是由于前期编写上的缺陷造成的。
正确的需求编写非常重要,应该保证每个人读到同一本需求应该得到同一个结论,而不是各自不同的结论。
3.1测试需求的完整性
我们可以把需求项框架看作是针对单项需求的一个分格的容器,每一个是这项需求的一个组成部分,前面建议大家使用的需求收集卡片,可以用来帮助测试需求的完整性,下面展示的卡片是一个完整需求的例子,需求分析师已经注明这项需求与其它需求没有冲突,这项需求应该通过完整性检查。
需求编号:
75
需求类型:
9
事件/用例编号:
6
描述:
如果一个气象站传送数据失败,产品将发出警告。
理由:
传送数据失败,可能表明该气象站失效并需要维护,并且用于预测结冰的数据可能不完整。
来源:
George,Shaw,道路工程。
验收标准:
对每个气象站,当每小时记录下来的各类读数个数,不在制造商规定的范围之内时,产品将通知用户。
顾客满意度
顾客不满意度
冲突
3
5
无
优先级:
版本1
支持材料:
Rosa气象站规格说明书。
历史:
GBS在2005-07-28提出。
1,测试是否存在遗漏部分
完整性的第一项测试就是把需求与框架中出现的组成部分进行比较,尽管不是每项需求都有所有的组成部分,但如果缺少某些部分,应该有很好的理由才行。
通过多年的实践,我们发现这些组成部分是有价值的,有助于说清楚一项需求和它的理由,它们或者是度量方法,或者是解释,或者是指向其他信息,或者是将在项目的一些阶段用到的需求,所以强烈建议只要适合该项信息的需求,都加入进来。
但有时候并不是所有部分都是需要的,比如有的时候描述本身就说明了为什么这项需求很重要,再加上理由就没什么意义了。
有时候如果有清晰可读的验收标准,描述也可以去掉。
有时候也可能没有支持材料。
很自然,如果缺少了一个组成部分,原因应该是它不必要,而不是它太难写或者应为没有注意到。
如果缺少某个组成部分是因为还在调查它,可能性是等待某个人的回答,那么就需要在需求上注明,例如:
2008-10-05等待用户方工程师提供支持材料的细节。
完整性测试指出每项需求都应该具备所有相关的组成部分,否则应该记录下他们没有完成或者不能完成的原因。
2,测试是否对所有利益相关方都有意义
对需求的组成部分满意以后,应该确保每个组成部分都增加了需求的含义,促进共同的理解,爱因斯坦说过:
“每件事都应该尽可能的简单,而不是简单一点”。
这意味着需求的编写要尽可能清晰、言简意赅,但必须确保写下的需求包含了所需要的信息。
例如有这样的部分:
可以问一下有没有可能导致误解的部分,比如可以这样问:
“这会让我们产生误解吗?
”“Rosa气象站规格说明书是不是只有一个版本?
”这样的问题有助于我们更精确的表达我们的意思,修改后的结果如下:
2007-1-22日发布的Rosa气象站规格说明书1.1版。
3.2测试需求的可追踪性
我们经常会发现,队伍在向后面传递口令的时候,到最后传递的结果是面目全非。
软件开发与这个情况类似,每个阶段都需要作某些转换,在转换的过程中,开发所涉及的众多人员中的某个人可能误解需求、错误的使用需求、或者搅乱需求。
因此很重要的一件事情就是,能够把最初的需求与最后提交的产品中实现该需求的部分联系起来,或者换句话说,就是要把开发过程的开始到它结束之间保持联系,确保指定的需求就是最后实现的需求,下图展示了需求的各个部分与它们实现之间的联系。
这是一个典型的需求知识模型,展示了需求规格说明元素之间的联系,这种联系对于开发过程中追踪个个组件是必需的。
“产品范围”与一些“产品用例”连在一起,每个“产品用例”有一系列的需求。
一项原子需求可以是一个“限制条件”、一项“功能性需求”或者一项“非功能性需求”。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 07 软件 需求 管理
![提示](https://static.bdocx.com/images/bang_tan.gif)