软件需求管理部分完整版.ppt
- 文档编号:18858511
- 上传时间:2024-02-01
- 格式:PPT
- 页数:59
- 大小:732.50KB
软件需求管理部分完整版.ppt
《软件需求管理部分完整版.ppt》由会员分享,可在线阅读,更多相关《软件需求管理部分完整版.ppt(59页珍藏版)》请在冰点文库上搜索。
1需求开发面临的特殊难题需求:
是一新件或系开发针对个软统开发项目的情,目有也零起点目况这种项时称为项(green-fieldproject)。
大多的主要精力集中于数组织存的维护现遗留系,或者统为已有的商品建业产构新的版本;其他也很少是零始建一新组织从开构个系,而是统对商用品行集成、定制现货产进和充,扩以足自己的需要。
满开始捕获信息缺少精确的需求文,那人就必行档么维护员须进逆向工程,通代理解系,此看作是过码来统将软件考古学(softwarearchaeology)。
建一包含前系部分的需求表示可到以构个当统达下3有用的目:
个标消除知,使的人能更好地理解所做识鸿沟将来维护员的更。
变收集前系的一些信息前系在以前缺乏良当统当统好的面文。
书档提供一指,表明前的系集系功能的个标当统测试对统覆盖率。
定义质量需求件的量性和性能目是解方案软质属标选择决时所要考的用需求的另一方面。
虑户个我们至少要研究下面几个属性:
性能易使用性灵活性互操作性完整性尽早地而且要经常地设定优先级客户和开发人员协同工作,共同选定功能实现的顺序,这样增量开发才会取得成功。
开发团队的目标是,可用的功能和将对量的改有律地交到用手中,因质进规户此,人必了解每次增量开发员须开发计些功能。
划实现哪5设定需求优先级每一受源限制的件目都个资软项必要求须对的品功能定相先。
产义对优级定先设优级有助于目理解冲突、安排项经决段性交付,且做出必要的取舍。
阶并定需求先的重要性,提出一讨论设优级个简的先分方案,介更格的单优级划并绍严基于价、成本和值风险的先分析方案。
优级需求和进度安排注意:
不要迫于压力而许下自己明知道不可能做到的诺言,这是避免最后两败俱伤的秘诀。
需求管理8需求管理的原则和实践需求管理包括在目程中需求定项开发过维护约的完整性、准确性以及保持需求定是最新约约定的所有活,如所示。
动图需求管理变更控制建议变更分析影响做出决策交流合并测量需求的稳定性版本控制确定需求文档版本确定单个需求文档版本需求跟踪定义对其它需求的连接链定义对其它系统元素的连接链需求状态跟踪定义需求状态跟踪需求每一个状态软件需求管理软件需求管理需求管理所要完成的任务需求管理模型管理变更需求风险管理需求跟踪需求管理工具需求管理所要完成的任务需求管理的首要任在于使人和用方务开发员户双对于需求都有一明确的。
个认识需求模型是最品的抽象化表。
实际终产现用需求的足程度是衡量劣的准。
户满设计优标秀的需求分析非常精确致地用需求作优应当细对户出描述,同也最大程度地予方案者充时应该给设计分的余地。
发挥目行任分,整体任化对开发项进务划将开发务细为多子模,而使些子模能平行而无个块从这块够开发需太多的干。
预需求管理在周期中是自始至存在的。
需求管开发终理必始保持更新。
须终需求管理同目管理是密不可分的。
项需求管理的任务明确需求并达成共识;建立关联,根据不同需求设计相应解决办法;进行系统优化,提出设计方案;监控和解决可能出现的问题以及需要做出的改变;控制不同开发任务的开展;对最终产品做出评测;监控可能出现的重复开发;提出项目实施时间表;确定最终用户界面。
里程碑与项目管理一项需求的满足就意味着一块里程碑的确立。
里程碑构造机制的基本方法之一就是进程管理。
需求管理在开发周期中是自始至终存在的。
需求管理必须始终保持更新,它构成了技术管理的基础。
需求管理同项目管理是密不可分的。
需求管理模型不同的需求合起,成了一套完整的需求组来构模型。
需求管理的一重要工作就是在项整目的不个项同任之建立系。
务间联需求管理包括在工程展程中持需求定进过维约集成性和精确性的所有活。
动需求管理的程域。
关键过领需求管理的步。
骤需求管理的主要活动控制对需求基线的变动。
保持项目计划与需求一致。
控制单个需求和需求文档的版本情况。
管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。
跟踪基线中需求的状态。
需求开发与需求管理的分界中程在线信息产业培训网需求基线管理为何需要:
繁的需求更破坏的频变会开发节奏,使整目的度陷入混和失控个项开发进乱的,而且成一“救火”式的工状态会变个队作,整天都在理突事件处发.主要思想:
所有在的、的需求行将现将来进先估,然后分解成不同的,每次优级评为组迭代都其中先最高的部分行选择优级进开发,然后在迭代完成之前,工作不开发响应变更,些入的需求就是需求基的这划项线组成部分需求基线管理-操作思路我们应该在分析的基础上,将需求整合成为用例或功能项,然后对其进行优先级、依赖性进行综合性评估优先级判断:
业务人员确定业务决定,技术人员确定技术决策;“满意度/不满意度”模型依赖性是指对于某些功能,在实现上有必须的依赖关系,即当某些功能没有实现时,另外的功能无法开始,这就需要对其进行调整需求变更管理需求变更是一定存在的,而需求变更管理并不是指逃避它,更不是说要避免它,它实际上是希望控制变更在基线内的需求不响应变更,为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应,了解需求变更的关键意图、新产生的工作量,从而良好地进行重新计划,以便能够有效地解决其对整个开发带来的麻烦对待软件项目管理的组织必须确保做到以下几点:
在提交提议的需求变更之前要对其进行仔细的评估。
请合适的人员就需求变更做出周全合理的业务决策。
将已批准的变更传达给受此影响的所有人员。
项目以一致的方式将需求变更包含进来。
采用一致的变更控制方法,就可以避免相关问题,避免开发工作的返工和浪费时间等情况的发生。
变更控制委员会变更控制委员会,有时也称为配置控制委员会(configurationcontrolboard,CCB),已被证实是软件开发领域公认的最佳实践(McConnell1996)。
CCB是由人组成的团体,可以由一个小组担任,也可以由多个不同的小组担任,这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现。
CCB也决定所报告的缺陷中哪些需要纠正,什么时候纠正。
CCB可以评审和批准对项目中任何基线工作产品所做的变更,项目需求文档只是其中的一个样例。
CCB的组成CCB的成员应该能代表需要参与制定决策的所有小组,当然这些决策制定只能是在CCB的权力范围之内。
可考虑从下面这些部门中选择CCB代表:
项目或程序管理部门产品管理或需求分析部门开发部门测试或质量保证部门市场或客户代表编写用户文档的部门技术支持或帮助部门配置管理部门CCB规章CCB规章描述了CCB的目的、权力范围、成员构成、运作规程和决策的制定过程等(Sorensen1999)。
CCB的权力范围规定了哪些决策由CCB决定,哪些决策则必须上报给高一级CCB或者由管理层来决定。
1.制定决策决策制定过程的描述应该确定:
CCB成员或主要角色的人数,这是制定决策的法定人数。
所采用的决策规则是投票、少数服从多数、协商决定或其他方法。
CCB规章CCB主席是否可以否决CCB的集体决策。
级别高的CCB或其他人是否必须认可CCB做出的决策。
2.交流状态CCB做出决策之后,应该指派专人对变更数据库中的变更请求状态进行更新。
3.重新协商原先的约定在接受一个重大的需求变更之前,为了适应这一变更,需要同管理部门和客户重新协商原先的约定(Humphrey1997)。
协商的内容可能包括,要求推迟产品交付时间,要求增派人手,或者要求推迟实现尚未实现的优先级较低的需求等。
变更需要付出代价:
影响分析对软件实施大的功能增强,则需要进行影响分析(impactanalysis)。
但是,即使是小的变更请求,也可能潜伏着难以预料的复杂性。
影响分析是需求管理的一个关键方面(Arnold和Bohner1996)。
通影行分析,可以准确地理解提的更过对响进议变所涉及到的,有助于目就批准些提问题项团队哪议做出周全合理的策。
业务决影响分析:
通过对所提议的变更进行检查,确定可能必须创建、修改或废弃哪些部分,并估计与实现这些变更相关的工作量。
影响分析的过程影响分析有3个方面:
1.理解进行变更可能涉及的问题。
变更常常会产生大量的连锁反应,产品包括的功能太多会降低其性能,甚至会到令人难以接受的地步。
2.确定如果团队将提议的变更包括到产品中,可能必须对哪些文件、模型和文档进行修改。
3.确定实现变更所需执行的任务,并估计完成这些任务所需的工作量。
注意:
跳过影响分析并不能改变任务的规模,只会使规模令人感到惊奇,而软件方面令人惊奇却很少是好消息。
影响分析报告模板图是一个推荐的报告模板,表示对每个需求变更造成的潜在影响的分析结果。
如果采用标准模板,CCB成员就可以轻松地找到他们所需的信息,作出合理的决策。
变更请求ID号:
_标题:
_描述:
__分析人员:
_日期:
_优先级评估:
相对收益:
_(19)相对损失:
_(19)相对费用:
_(19)相对风险:
_(19)计算出的最终优先级:
_(相对于其他待处理的需求)估计的总工作量:
_劳动小时数估计损失的工作量:
_劳动小时数(用于废弃的工作)估计对进度的影响:
_天额外的成本影响:
_美元质量影响:
_受影响的其他需求:
_受影响的其他任务:
_集成问题:
_生存期费用问题:
_检查可能要变更的其他组件:
_需求的化是永恒的。
因而,于需求更变对变应该正确待,量其面影降低。
对尽将负响需求更可能自解方案提供商、客或品变来决户产供商等外部因素,也可能源于目部。
应来项组内更都是有代价的,估一下更的代价及变应该评变其目的影。
对项响在需求更生之前量少需求更,以需变发尽减变将求更的降低到最低。
切忌在目变带来风险项设计之前消除需求更。
试图变需求变更的原因因竞争、成本等因素,工期已经确定且极不合理.用户在需求期提不出需求、或用户的需求不明确.项目组对业务不熟悉、或者没有与用户密切结合、需求分析工作不细致.项目组没有很好地实施需求管理.需求变更的恶性循环时间紧迫压缩需求过程产品不满足需求变更需求维护工作量增加项目资源恶化需求过程的恶性循环需求变更的因素需求变更的原因对需求的理解存在分歧系统实施时间过长用户业务需求改变系统正常升级需求变更的代价减少需求变更客户主管人员最终用户相关人员系统分析人员合理性建议减少提出需求变更的几率和客户的充分交流交流交流交流提出需求需求变更的过程管理认识到变更不可避免,为变更制订计划。
确认需求基线。
建立控制变更的唯一渠道。
使用变更控制系统来捕获变更。
分层次地管理变更。
基于配置管理的需求管理基于配置管理的需求管理避免需求在未授权情况下变更,或在有潜在破坏性的情况下不受限制地随意变更。
保护队需求文档的修正。
方便对文档以前版本的检索或重建。
支持系统以增量的方式改进基线。
避免对文档的同时更新和冲突。
基线管理需求基线(requirementbaseline)是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。
基线:
已经通过正式评审和批准的某规约或产品,它可以作为进一步开发的基础,并且只能通过正式的变化控制过程的改变。
IEEE基线是一个软件配置管理的概念。
在软件工程的范围内,基线是软件开发中的里程碑,其标志是有一个或多个软件配置项的交付,且已经经过正式技术评审而获得认可。
配置管理组或委员会(CCB)按照需求基线,对整个项目的进程进行控制和把握。
需求状态的变化开始被建议被批准被实现被交付被验证被丢弃被拒绝评审通过评审未通过设计完成编码完成单元测试取消取消集成测试完成用户测试接收需求管理过程注意如果项目中无人负责执行需求管理活动,那么就不要指望需求管理能够运作。
需求版本控制版本控制是管理需求格明和其他目文必不可少的规说项档一方面。
个需求文的每一版本都必惟一地出。
档个须标识来了量少混、冲突和,指派一人为尽减乱误传应该个专门负更新需求,确保只要需求有所更就相地改其版责并变应变本。
标识号最的版本控制机制是,根据准定,每一件简单标约对个软需求格明版本行手工。
规说进标识有一更的技,可以把需求文存在版本控制还种复杂术档储工具中。
版本控制最有用的方法是将需求存在商需求管理工具储业的据中。
数库需求属性应该考虑为每个需求指定如下一些属性:
需求创建的日期。
需求的当前版本号。
创建需求的作者。
负责确保该需求得到满足的人员。
需求的拥有者或一组涉众列表。
需求状态。
需求的最初来源。
创建需求的理由。
需求涉及的子系统。
需求涉及的产品版本号。
使用的验证方法或验收测试的标准。
需求实现的优先级。
需求的稳定性。
注意如果选择的需求属性太多,那么开发团队会望而生畏,结果是他们绝不可能提供所有需求的全部属性值,也无法有效地使用这些属性信息。
跟踪需求状态表列出了若干可能的需求状态。
有些跟踪人员还添加了另外两个状态:
“已设计(Designed)”和“已交付(Delivered)。
状态状态定义定义已提议已提议(Proposed)(Proposed)该需求已被有相应权限的人提出该需求已被有相应权限的人提出已批准已批准(Approved)(Approved)该需求已经被分析,它对项目的影响已进行了估计,并且已经被分配到某一特定版本该需求已经被分析,它对项目的影响已进行了估计,并且已经被分配到某一特定版本的基线中。
关键涉众已同意包含这一需求,软件开发团队已承诺实现这一需求的基线中。
关键涉众已同意包含这一需求,软件开发团队已承诺实现这一需求已实现已实现(Implemented)(Implemented)实现这一需求的代码已完成了设计、编码和单元测试。
这一需求已被跟踪到相关的设实现这一需求的代码已完成了设计、编码和单元测试。
这一需求已被跟踪到相关的设计元素和编码元素计元素和编码元素已验证已验证(Verified)(Verified)已在集成产品中确认了这一需求的功能实现是正确的。
这一需求已被跟踪到相关的测已在集成产品中确认了这一需求的功能实现是正确的。
这一需求已被跟踪到相关的测试用例。
这一需求目前可以被认为是已完成了试用例。
这一需求目前可以被认为是已完成了已删除已删除(Deleted)(Deleted)已批准的需求又从需求基线中取消了。
要解释清楚为什么要删除这一需求,以及是谁已批准的需求又从需求基线中取消了。
要解释清楚为什么要删除这一需求,以及是谁决定删除的决定删除的已否决已否决(Rejected)(Rejected)需求已被提议,但并不计划在下一版本中实现它。
要解释清楚为什么要否决这一需求需求已被提议,但并不计划在下一版本中实现它。
要解释清楚为什么要否决这一需求,以及是谁决定否决的,以及是谁决定否决的评估需求管理的工作量如果跟踪在需求管理上投入了多少工作量,我们就可以估工作量是太少,是正合适,或者是评还太多,且可以前程和未的做出相并对当过来计划的整。
应调将下面这些活动中所投入的工作量加起来,就可以算出需求管理的工作量:
提交需求更和提新的需求。
变议估已提的更,包括行影分析。
评议变进响更控制委的活。
变员会动更新需求文或据。
档数库向受影的小或人需求更。
响组个传达变跟踪告需求。
并报状态收集需求的跟踪信息。
需求风险管理44所就是可能目的成功某些失或谓风险给项带来损威的情。
胁况由于需求在软件项目中具有十分重要的地位,所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们。
典型的需求风险包括:
误解需求。
用户的参与不恰当。
项目范围和目标不确定或随意进行变更。
对需求不断进行变更等。
软件风险管理基本原理对外部实体的依赖就是一种常见的风险来源。
项目管理一直面临各种风险的挑战:
估不准确、管理评人拒人的准确估、目不了解以及员绝开发员评对项状态行了人整等原因所引起的。
进员调风险技术风险威胁着高度复杂或很前沿的开发项目。
知识的缺乏是风险的另一种来源,另外还有参与者对所用的技术或项目应用领域经验不足。
经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。
风险管理的要素管理风险(riskmanagement)就是使用某些工具和步把目限制在一可接受的范。
骤项风险个围内风险管理提供了一种标准的方法,可以指出风险因素并将其编写成文档,评估这些风险的潜在威胁,并提出减少这些风险因素的战略。
风险管理包括图所示的这些活动。
风险评估(riskassessment)是一个对项目进行检查以确定潜在风险领域的过程。
风险避免(riskavoidance)是处理风险的一种方法,也就是尽量不要做冒险的事。
风险管理评估避免控制识别分析优先级管理计划解决方案监控编写项目风险文档图展示了一个模板,用于对单个风险编写文档。
制定风险管理计划对于小型项目,可以把控制风险的计划包括在软件项目管理计划内。
但对一个大型项目,则应该编写一个单独的风险管理计划,详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。
这一计划还应该包括风险管理活动的角色和职责。
要建立起周期性进行风险监控的措施。
注意:
不要想当然地以为,在识别出了风险并采取了降低风险的相应活动之后,风险就会处于您的控制之下。
接下来还要实行风险管理活动。
与需求有关的风险无足够用户参与用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划风险管理是我们的好帮手即使不能控制项目可能遇到的所有风险,风险管理也能帮助我们看清形势,做出合理的决策。
风险管理的措施明确你当前项目面临的一些与需求有关的风险,不要把当前的问题当作风险,一定要是那些还未发生的事情。
将风险因素编写成文档,为每项风险推荐至少一种可能的降低风险的方法。
风险管理的措施召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。
需求跟踪需求跟踪提供了一个表明与合同或说明一致的方法。
更进一步,需求跟踪可以改善产品质量,降低维护成本,而且很容易实现重用。
需求跟踪链使你能跟踪一个需求使用期限的全过程。
通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求。
需求跟踪的定义需求跟踪的定义IEEE,1994开发过程的两个或多个产品之间能够建立关系的程度,尤其是那些具有前后关系或主从关系的产品。
例如,某个给定组件的需求和设计的匹配程度。
软件开发产品中每个元素能够建立其存在理由的程度;例如,数据流图中的每个元素定位它所满足需求的程度。
商业需求管理工具以数据库为核心的产品以文档为核心的方法使用需求管理工具的益处项目需求的收集工作做得很好,也应该使用自动化工具帮助您在开发过程中管理这些需求。
随着时间的推移,团队成员对需求细节的记忆会逐渐变得模糊,这时使用需求管理工具的益处就得到了最大程度的体现。
下面介绍这种工具可以帮助我们完成哪些任务:
管理版本和变更项目应该定义需求基线,基线就是某一版本的产品要实现的需求的集合。
存储需求属性应该为每个需求记录一些描述性属性,要清楚地标出各种版本的产品要实现的需求基线。
使用需求管理工具的益处进行影响分析通过确定某一提议的变更可能影响哪些其他系统元素,这些联系链可以帮助分析这一变更对某一特定需求将产生的影响。
跟踪需求状态将需求保存在数据库中就可以知道产品指定了多少离散的需求。
访问控制需求管理工具可以定义单个用户或用户组的访问权限,并通过到数据库的Web接口与地域上分散的团队共享信息。
与涉众沟通有些需求管理工具允许团队成员通过电子联系方式来讨论需求问题。
重用需求将需求保存在数据库中,就可以方便地在多个项目或子系统中重用这些需求。
需求管理工具的功能大多数需求管理工具都与Word有某种程度的集成,一般情况下,是在Word菜单栏中添加了一个专门的工具菜单。
这些工具的输出能力包括以用户指定的专门格式或表格格式报告生成需求文档的能力。
产品有一个共同的趋势,就是尽量与应用程序开发所用的其他工具相集成,如图所示。
选购需求管理产品时,要考虑它是否能与所用的其他工具交换数据。
测试管理工具项目跟踪工具版本控制工具需求管理工具变更请求工具项目评估工具设计建模工具
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 管理 部分 完整版