1、软件需求工程软件需求工程Software Requirements Engineering 第五章 软件需求与风险管理 负责C o n t o s o制药公司“化学制品跟踪系统”的项目管理人员D a v e会见他的首席程序员H e l e n和首席测试员R a m e s h。他们对新项目都很有兴趣，但他们也记得在以前一个称作“药品仿真”的项目中遇到的问题。“还记得我们直到进入测试时才发现用户对仿真程序的用户界面极为不满意吗？”H e l e n问道。“我们花了五周时间重新实现，重新测试，我可再不愿玩这样的死亡游戏了。”“的确是烦人，”D a v e附和道。“同样麻烦的是那些用户提出一大堆没人
2、用过的特性，这样的交互导致编码花费了预计时间的三倍，我们是不管好歹，编完了事，简直是废品！”“我们太匆忙了，以至没有时间写详细的需求说明”R a m e s h回忆道。“测试人员有一半的时间都在问程序员怎样才能判断他们的程序工作正常，以便能测试它。可是程序员设计的一些功能根本就不是用户所要求的。”“特别麻烦的是，要求开发药品仿真的管理者根本没有看需求规格说明就在上面签字确认了。”D a v e补充道：“于是我们不断遇到要求新的特性及各种变更，所以工程超期四个月，成本费用超出预算的一倍这也就不足为怪了。若再发生这样的事，我肯定会被解雇了。”R a m e s h建议道：“也许我们应该把在仿真项目
3、中遇到的问题一一列出来以便我们能在化学制品跟踪系统中避免重蹈覆辙。我看了篇关于软件风险管理的文章，上面介绍说我们应指出各种风险并说明了怎样才能避免它们”。“我可不那样想”D a v e坚持道：“我们已从仿真项目学到了不少，我们不会再有那些问题了。这个项目还没有达到需要用风险管理的地步。如果要把我们可能犯的错误都写下来，好像我连怎样做软件项目都不知道似的。我不想要任何消极想法影响项目。我们必须为成功而制定计划。”风险所谓风险就是可能给项目的成功带来威胁或损失的情况，而风险管理则就是指在风险给项目带来损失之前就指明，评估并对风险加以控制。在项目中，可能出现差错的事情常常比可能意想不到地正常运行的事
4、情多风险无处不在：要有风险意识防患于未然：要有预防措施软件风险管理 风险管理：就是使用某些工具或步骤把项目风险限制在一个可接受的范围内。风险管理包括的活动包括，风险评价，风险避免，风险控制等。编写项目风险文档：仅仅认识到项目面临的风险是远远不够的，应该将其编写成文档并妥善进行管理，这样有利于风险承担者了解风险情况状态。制定风险管理计划：一张风险列表还不等于一个风险管理计划。需求在软件项目总扮演着一个核心的角色1、正因为如此，精明的项目管理者会在初期就指明与需求相关的风险并积极的控制它们。2、典型的需求风险包括：对需求的误解，不恰当的用户参与，不确定或随意变更项目范围和目标等。3、项目管理者只能
5、通过与客户或客户代表（如市场人员）合作来控制需求风险。n风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些风险的战略（Wi l l i a m s，Wa l k e r，and Dorofee 1997）。风险管理包括的活动如图5-1所示。n风险评价（risk assessment）是一个检查工程项目并识别潜在风险区域的过程。n风险分级（risk prioritization）有助你通过评价每项风险的潜在危害值，优先处理最严重的风险。n风险危害值(risk exposure)包括带来损
6、失的可能性大小和潜在损失的规模。风险条目跟踪模板仅仅认识到到项目面目面临的的风险是是远远不不够的。的。应该将其将其编写写成文档并妥善成文档并妥善进行管理，行管理，这样在整个在整个项目开目开发过程中有利程中有利于于风险承担者了解承担者了解风险情况和状情况和状态。序列号：确定日期：撤消日期：描述：可能性：影响：危害值：降低风险计划：负责人：截止日期：风险条目跟踪模板n在编写风险说明时，最好采用条件结果的形式。也就是，先说明你关心的条件，接着是潜在的有害结果（如果风险成为事实）。有时，人们只说明了风险条件（如“客户不同意产品的需求说明”）或者只说明了结果（“我们只能满足某些主要的客户”）。最好将这样
7、的说明句子合并成条件结果形式的结构：“如果有些客户不赞同产品的需求说明，那我们只能满足某些主要客户的意见。”而一个条件下可能有多个结果，同时也可能出现多个条件下导致同一个结果。n模板能记录风险变为事实的可能性及对项目的消极影响，还有整个的风险危害值（可能性影响）。我用0.1（极不可能）到1.0（肯定发生）来描述可能性，用 1（无甚么影响）到1 0（有很深、很大的影响）来表示影响。将这两个因素相乘即可作为评估风险危害值的依据。n不要试图精确量化风险。你的目标是将最有威胁的风险和那些不急需处理的风险区别开来。大家可能更愿意用高、中和低来估计可能性及影响。但风险条目中至少应有一个为高的风险。n制定降
8、低风险计划来明确控制风险要采取的活动，其中一些策略是尽量降低风险发生的可能性；而另一些则是减少风险发生后带来的影响。做计划时要考虑降低风险所耗费用，千万别花费20 000美元来控制一项仅会损失10 000美元的风险。为每项风险安排一个负责人，并确定完成活动的截止日期。长期或复杂的风险可能需要具有多个阶段性成果的多步骤降低风险策略计划。n下图说明了本章开始部分介绍的“化学制品跟踪系统”小组领导者讨论的一个风险。小组凭他们以前的经验估计了风险的可能性及其影响。除非他们把其它风险因素也估计出来，否则他们并不明白风险危害值 4.2究竟有多严重。降低风险措施的前两条是通过更多的用户参与项目来减少风险发生
9、的可能性。而采用原型法则可以利用用户关于界面的早期反馈来减少风险的潜在影响。风险条目样例序列号：1确定日期：5/4/9 9撤消日期：描述：需求获取中无合适用户参与,导致测试之后用户界面的返工。.可能性：0.6影响：7危害值：4.2降低风险计划：1.在第一阶段早期就要收集易学、易用的需求。2.与产品代表一起召开J A D会议以开发需求。3.通过与产品代表和顾问的交流，开发一个包含核心功能的用户界面原型。让产品代表和其他用户来评估此原型。负责人：H e l e n截止日期：在6/1 6/9 9前完成J A D会议。与需求有关的风险需求获取1)产品视图与范围没有对产品功能达成一个清晰的共识，则很可能
10、导致项目范围的逐渐扩大。最好在项目早期写一份项目视图与范围将业务需求涵盖在内，并将其作为新的需求及修改需求的指导。2)需求开发所需时间需求开发工作应占全部工作量的1 5%不要因为工期紧张就不按要求作需求。3)需求规格说明的完整性和正确性以用户的任务为中心，应用使用实例技术获取需求。根据不同的使用情景编写需求测试用例，建立原型，使需求对用户来说更加直观，同时获取用户的反馈信息。让客户代表对需求规格说明和分析模型进行正式的评审。4)对革新产品的需求有时容易忽略市场对产品的反馈信息。故要强调市场调查研究，建立原型，并运用客户核心小组来获得革新产品任务的反馈信息。与需求有关的风险与需求有关的风险5)明
11、确非功能需求由于一般强调产品的功能性要求，非常容易忽略产品的非功能性的需求。询问客户关于产品性能、使用性、完整性、可靠性等质量特性，编写非功能需求文档和验收标准，（像在S R S中一样）作为可接受的标准。6)客户赞同产品需求如果不同的客户对产品有不同的意见，那最后必将有些客户会不满意。确定出主要的客户，并采用产品代表的方法来确保客户代表的积极参与，确保在需求决定权上有正确的人选。与需求有关的风险7)未加说明的需求客户可能会有一些隐含的期望要求，但并未说明。要尽量识别并记录这些假设。提出大量的问题来提示客户以充分表达他们的想法、主意和应关注的一切。8)把已有的产品作为需求基线在升级或重做的项目中
12、需求开发可能显得不很重要。开发人员有时被迫把已有的产品作为需求说明的来源。“只是修改一些错误和增加一些新特性”，这时的开发人员不得不通过现有产品的逆向工程(reverse engineering)来获取需求。可是，逆向工程对收集需求是一种既不充分也不完整的方法。因此新系统很可能会有一些与现有系统同样的缺陷。将在逆向工程中收集的需求编写成文档，并让客户评审以确保其正确性。9)给出期望的解决办法用户推荐的解决方法往往掩盖了用户的实际需求，导致业务处理的低效，或者给开发人员带来压力以至做出很差的设计方案。因此分析人员应尽力从客户叙说的解决方法中提炼出其本质核心与需求有关的风险 需求分析1)划分需求优
13、先级。2)带来技术困难的特性3)不熟悉的技术、方法、语言、工具或硬件平台需求规格说明1)需求理解不同理解评审的团队应包括开发人员，测试人员和客户。2)时间压力对T B D的影响将S R S中需要将来进一步解决的需求注上T B D记号，但如果这3)具有二义性的术语4)需求说明中包括了设计说做什么，而不是说怎么做。需求验证1)未经验证的需求2)审查的有效性 需求管理1)变更需求将项目视图与范围文档作为变更的参照可以减少项目范围的延伸。用户积极合作参与可把需求变更减少近一半早期发现需求错误的质量控制方法可减少以后发生变更的可能。为减少需求变更的影响，将易于变更的需求用多种方案实现，并在设计时更要注重其可修改性。2)需求变更过程未曾明确的变更过程或采用的变动机制无效或不按计划的过程来做出变更。建立变更管理的纪律和氛围，变更控制委员会，工具3)未实现的需求需求跟踪能力矩阵4)扩充项目范围对阶段递增式的生存期制定计划，在早期版本中实现核心功能，并在以后的阶段中逐步增加实现需求
