软件需求讲义第一部分_第1页
软件需求讲义第一部分_第2页
软件需求讲义第一部分_第3页
软件需求讲义第一部分_第4页
软件需求讲义第一部分_第5页
已阅读5页,还剩26页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件需求讲义第一部分第一页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-2

道可道,非常道

--老子道是可以被阐述的,但可以阐述的道不是真正的道。换句话说就是,我们可以发现并阐述万物的道,但我们永远也无法得知真正的道是什么。也有人以为道是可以意会而不可言传的。第二页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-3引言上世纪软件危机的出现原因:1.软件本身具有的特点有关;2.缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制。很多问题都是在需求分析阶段埋下的。由此逐渐形成了需求工程第三页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-4内容概要软件需求的基本概念需求工程与需求工程过程需求获取与需求分析需求文档与需求质量验证软件需求管理第四页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-5第一部分软件需求的基本概念需求问题 需求的层次第五页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-6第1章 需求问题需求是软件项目成败的关键所在。越早发现需求错误,越早改正它,其代价越小需求是系统必须具有的能力。好需求的特征:无歧义、完整、一致、可检验、确定、可跟踪的,正确的,可行的和必要的。第六页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-7从谚语开始中国有句谚语:“好的开始就等于成功的一半”西方的谚语是:“Garbagein,garbageout!”

即:无用输入无用输出即说:从项目一开始,就要有正确的用户需求。第七页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-81.软件开发的目标软件开发的目标,简单而言,就是满足用户的需要。问题是:如何将用户提出的要求,变为软件需求,并在此基础上成功的开发出软件系统。第八页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-92.项目失败与成功的原因*三种最经常使项目“遇到困难”的因素是:缺乏用户介入:占所有项目的13%不完整的需求和规格说明:占所有项目的12%不断改变的需求和规格说明:占所有项目的12%三种项目最主要的“成功因素”是:用户介入:占所有成功项目的16%高层管理的支持:占所有成功项目的14%需求陈述清晰:占所有成功项目的12%*[StandishGroup,1994]第九页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-102-8原则*WalkerRoyce指出了一些作为软件管理过程框架的理论基础的“基本原理”。即2-8原则。80%的工程活动是由20%的需求消耗的80%的软件成本是由20%的构件消耗的*[Royce,1998]

第十页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-113.需求在项目中的作用在项目开发中,所有的涉众(Stakeholder)都对需求分析阶段备感兴趣。未真正明白这些问题就开始编码,结果没有人对产品满意。第十一页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-124.需求错误的代价在生命周期的不同阶段修复缺陷的相对成本第十二页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-13需求缺陷造成的成本增加随着需求缺陷被发现和修正的阶段变化,开发成本呈急剧扩大的趋势。提高成本的几个方面:重新进行需求规格说明重新设计重新编码重新测试改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版本。纠正活动——消除由于不准确的特定系统的错误造成的危害,可能涉及到赔偿客户损失。报废——包括对于已经完成的代码、设计和测试,当发现它们是根据不正确的需求进行的时候,这些工作成果不得不被丢弃。收回有缺陷的软件产品以及相关的用户手册。产品赔偿或保修的成本。重新安装新版本的成本。重新建档的成本。第十三页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-145.高质量的需求过程带来的好处

在开发后期和整个维护阶段的重做的工作大大减少了。让用户积极参与需求收集过程能使产品更富有吸引力,而且能建立起更加忠实的客户关系。用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”(期望差异)。将确定的系统需求明确地分配到各软件子系统,确保软硬件系统功能匹配适当。有效的变更控制也能降低需求变更带来的负面影响。将需求编写成清晰、无二义性的文档将会极大地有利于系统测试,确保产品质量。第十四页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-156.需求定义[IEEE1997]IEEE软件工程标准词汇表定义需求为:用户解决问题或达到目标所需的条件或能力。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。一种反映上面(1)或(2)所描述的条件或能力的文档说明。第十五页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-16需求定义[Thayer,Dorfman.1997]MerlinDorfman和RichardH.Thayer提出了一个包容且更为精练的定义:用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。第十六页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-177.好的需求应具有的特性无歧义性完整性一致性可检验性确定性可跟踪性正确性可行性必要性第十七页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-18第2章需求的层次需求是多层次的,包括业务需求、用户需求、功能需求和非功能需求。需求路线图:涉众需要—〉系统的特性—〉建立软件需求第十八页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-19软件需求包括不同的层次软件需求包括不同的层次:业务需求、用户需求、功能需求和非功能需求。第十九页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-202.1业务需求表示某个组织或客户高层次的目标。在项目前景文章中给于说明。来自:项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。第二十页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-212.2.用户需求描述用户的具体目标,或者用户要求系统必须能完成的任务。用例、场景描述表达用户的需求。第二十一页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-222.3功能需求开发人员必须在产品中实现的软件工程,用户使用这些功能完成任务,满足业务需求。功能需求通过对系统特性的描述表现的。系统特性:指一组逻辑上相关的功能需求,表示系统为用户提供的某项功能,满足业务目标。功能需求记录在软件需求规格说明书(SRS)里。SRS(SoftwareRequirementsSpecification)完整的描述了软件系统的预期特性。第二十二页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-232.4.非功能需求描述了系统展现给用户的行为与执行操作。包括产品遵从的标准、规范和合约,外部界面的具体细节、性能要求、设计或实现的约束条件及质量属性。非功能需求是解决“如何是这个系统在实际环境中运行”第二十三页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-24软件的6个质量特征[ISO9126]第二十四页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-25软件的非功能性需求可靠性可用性有效性可维护性可移植性功能性第二十五页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-26用户的权利法则(User’sBillofRights)[Karat1998]加强了可用性的概念用户总是对的。如果系统使用有问题,那么系统就是问题所在,而不是用户。用户有权进行简易安装和卸载软件和硬件系统,而不会产生任何负面的影响。用户有权要求系统达到承诺的性能。用户有权获得易于使用的指导(用户指南、在线或上下文帮助、出错信息),从而理解和使用系统,达到既定目标,并能从系统发生的问题中有效地恢复。用户有权控制系统,并且能使系统响应其要求。用户有权要求系统提供有关正在进行的任务及进展的清晰、准确而可理解的信息。用户有权要求所有有关正确使用软件或硬件的系统信息。用户有权知道系统的能力限制。用户有权与技术提供商联系,并得到合理而有用的帮助。用户应该是软件和硬件的主人,而不是相反。产品应该简单而直观,易于使用。第二十六页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-27约束约束定义为:对系统的设计或开发系统过程的限制。它不影响系统的外部行为,但必须被遵守执行以符合技术上、商业上的要求。约束主要来自于几个方面:设计选择的约束、加在开发过程上的约束以及规章制度和标准。设计选择的约束是指当出现一种以上的设计选择时,选择的内容带来的约束。一般情况下,应该由设计人员,而不是需求分析人员来做选择。第二十七页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-282.5.需求路线图需求路线图:反应了从用户要求到软件需求的一般路径。即从问题领域(PD)到解决方案领域(SD)。需求金字塔第二十八页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-29涉众需求为开发团队提供更好地确定系统的定义和实现所需的全部信息。是整个需求的关键。不容易把握,原因是用户需求描述经常是模糊的。需要把涉众需求转化为系统行为-------建立系统的特性或特征(feature)。第二十九页,共三十一页,编辑于2023年,星期三西安工业大学计算机学院2011© 1-30特征(feature)特征(f

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论