《软件项目管理原理与实践》 课件 第2章 软件项目需求工程.pdf
《《软件项目管理原理与实践》 课件 第2章 软件项目需求工程.pdf》由会员分享,可在线阅读,更多相关《《软件项目管理原理与实践》 课件 第2章 软件项目需求工程.pdf(127页珍藏版)》请在咨信网上搜索。
1、第2章软件项目需求工程 21概述O 2.1.1 需求定义O 2.1.2 需求类型 2.2需求开发和管理过程O 2.2.1 需求获取o 2.2.2 需求分析o 2.2.3 需求规格说明o 2.2.4 需求验证o 2.2.5 需求变更管理o 2.2.6 可测试性需求2 2.3需求获取方法O 2.3.1 访谈和调研o 2.3.2 专题讨论会o 2.3.3 头脑风暴o 2.3.4 场景串联 2.4需求分析建模方法O 2.4.1 用例分析方法o 2.4.2 原型分析方法o 2.4.3 结构化分析方法 2.5需求管理工具O 2.5.1 需求管理工的功能o 2.5.2 常用需求管理工具3Why Are Re
2、quirements Important in Software Engineering?为什么需要,将用在何处?在构造任何工程制品之前,人们都要弄清楚为什 么需要,将用在何处?O这些问题与一个工程制品的需求相关,其答案就代表了构造这个工 程制品的意图。O软件也是一种工程制品,在开发软件之前,也必须先了解清楚需求,充分理解设计、使用软件的意图。软件需求,是指用户对目标软件系统在功能、行 为、性能、设计约束等方面的期望。O通过对应问题及其环境的理解、分析,为问题涉及的信息、功能、系统行为建立模型,将用户需求精确化、完全化,最终形成需求规 格说明,这一系列的活动即构成软件开发生命周期的需求分析阶段
3、O软件需求工程是要把一个定义不足的问题,转换为一个定义良好的 问题,以便能够找到问题的解决方案。5-UJ 1 s sPROJECTCONTRACTSTAKEHOLDERStools SO FTWARE userneedsREQUIREMENTSVALIDATION ENGINEERING 山 specificationMANAGEMENT CONDITION 匕 os6e需求分析是介于系统分析和软件设计阶段之 间的桥梁。O 一方面,需求分析以系统规格说明、项目规划作为分析 活动的基本出发点,并从软件角度对它们进行检查、调O另一方面,需求规格说明又是软件设计、实现、测试直 至维护的主要基础。O良
4、好的分析活动有助于避免或尽早剔除早期错误,从而 提高软件生产率,降低开发成本,改进软件质量。软件 项目需求是软件开发后继阶段的基础。7reguimgntx engNbcrWg j|8用户的需求变更在软件项目管理过程中,项目经理经常面对 用户的需求变更。如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来 越低落,将直接导致项目成本增加、质量下降及项目交 付日期推后。因此,项目组必须拥有需求管理策略。9什么是软件需求软件项目需求管理已经成为软件工程中最为 关键的问题。我在开始设计软件 之前,需要知道你的需求 J我正想让你来 设计我的软件首先,你要 实现
5、什么?我的意思是,你 正在用这个软件 实现什么?10软件项目需求管理软件项目需求管理,使软件系统分析工程师 能够结合软件项目实际,提出切实有效的项 目需求管理策略,解决其在管理软件项目需 求分析时所面临的实际问题,从而降低软件 开发成本提升软件产品的质量,提高软件企 业竞争力。软件需求的抽象层次软件需求可以分为4个抽象层次,分别是原 始问题描述、用户需求、系统需求和软件设计描述。I I原始问题描述用户需求-原始问题空间X_解决方案空间系统需求软件设计描述12PROJECT REQUIREMENTSPROJECTNo:MA-015-02FULL PROJECTNAME:Project Orion
6、DATE:PROJECTMANAGER:A SmithREQUIREMENT LISTIDREQUIREMENT DESCRIPTIONREQUESTED BYCATEGORYPRIORITYACCEPTANCE CRITERIAGive each requirem ent a unique ID.The feature,function,condition or capability that is required from the project,product,service or result.The stakeholder who requested the requirement
7、.The category or grouping of the requirement for example:functional,technical,operational,KPI(result metric),transitional.The priority of the requirement for example:Pl,P2,P3 or MoSCoW(Must hove,should have,could have,wont hove).The criteria that the requirement must have for it to be accepted by th
8、e project stakeholders.REQUIREMENTS DEFINITIONS 13j2二需求工程的重要性需求工程的重要性,体现在下面3个方面:O(1)Brooks在他1987年经典文章没有银弹中,阐 述了需求的重要性。开发软件系统最困难的部分就是准 确说明开发什么。最困难的概念性工作,是编写出详细 的需求,包括所有面向用户、面向机器和其它软件系统 的接口。此工作一旦做错,将会给系统带来极大的损害,并且以后对它修改也极为困难。O(2)需求是产品的根源,需求工作的优劣对产品影响 最大。O(3)世界软件业的痼疾:人们并不清楚究竟该做什么,但却一直忙碌不停地开发。了解客户、最终用户、
9、间 接用户的概念。15需求工程(Requirement Engineering)O指应用已证实有效的技术、方法进行需求分析,确定客 户需求,帮助分析人员理解问题并定义目标系统的所有 外部特征的一门学科。需求工程需求获取需求分析需求开发利益相关者咨 询、评论和语 境规范化对系统的理解对需求省略、冗 余、不一致性的 识别需求验证系统的结构化 文档记录16概述171.1概述 需求分析是介于系统分析和软件设计阶段之 间的桥梁。一方面,需求分析以系统规格说明、项目规划作为分析 活动的基本出发点,并从软件角度进行检查、调整;O另一方面,需求规格说明又是软件设计、实现、测试、维护的主要基础。良好的分析活动,
10、有助于避免或尽早 剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。18 需求,并不是软件系统特有的概念。O任何一件产品、服务在生产之前,都需要首先弄清人们 为什么需要它,用于何处,其次,是设计的产品通过什 么形式和功能来满足这些需求。需求(Requirement)在IEEE软件工程标准 词汇表(1997)中定义为:o用户解决问题或达到目标所需的条件或能力;O系统或系统部件要满足合同、标准、规范或其它正式规 定文档所需具有的条件或能力;O 一种反应上面二点所描述的条件或能力的文档说明。_令 IEEE_19BadGoodRequirementsRequirements20Functi
11、onal Requirements-/Non-Functional Requirements2122软件需求并不是要解决软件系统“如何做”的问题,它的根本任务在于解决目标系统“做什么”的问题。O需求是连接用户和软件开发团队的桥梁,用户通过需求 描述软件产品,而需求则是软件开发团队的工作基础,所以说没有明确的需求就没有正确的软件。需求来源于用户的一些需要,这些需要被分 析、确认后形成完整的文档,该文档详细地 说明了产品必须或应当做什么。O软件需求也是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。这种期望是一种心理活动、笠统、不细软、不悔时程的描沐C232.1.1 需求定义软件需求工
12、程的关键问题包括二。不论是合同项目还是自主研发的产品,都必须开展需求 开发和需求管理活动。O开发者对待需求工程的态度可分“被动型”、“主动 型”、“领先型”三种,只有后两种才有可能开发出成 功的产品。24(1)“被动型”O指开发者被动地对待需求工程中的各项活动,能少干则少干,能偷懒则偷 懒。他们认为,需求是用户的事情而不是自己的事情。开发过程中经常发 生需求变更,导致产品迷失方向,不是半途而废就是陷入停顿的状态。(2)“主动型”O指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作 自己的职责,会想尽一切办法克服需求开发和需求管理过程中的困难,而 不是找借口推卸责任。俗话说,良好的
13、开端是成功的一半,“主动型”需 求工程是开发成功产品的必备条件。(3)“领先型”O是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求,导致用户跟着新产品跑而不是新产品围着用户转,这叫引导消费。需求工 程做到这个程度上,才能使产品立于不败之地,长盛不衰。25需求开发的主要困难与解决方案(1)应用域的知识是无边无际的,任何人都不可能了解所 有行业基础背景知识。(2)当需求分析员缺乏应用领域知识时,他该怎么办?O首先,他要有勇气做事,否则连实践的机会都没有。其次,他应当赶紧补习应用域知识。(3)相当多的开发人员习惯于被动地对待需求开发。O每当遇到麻烦、挫折时,他们会发牢骚,找出一堆用户的
14、毛病。很多开发人员错误地以为,需 求是用户的事情,不是我们的事情。我们为用户开发软件,难道用户不该告诉我们应当开发什 么吗?如果用户说不清楚需求,或者经常变更需求,这类问题是用户产生的,应当由他们自己 负责。(4)用户说不清楚需求或者需求发生变更,这些都是常见 的问题,并不是不能解决,是人们可以设法解决的。O可现实情况是开发人员把这些问题当成了借口,不愿主动攻克问题,导致需求问题扩散到整个 软件开发过程,产生太多的后患。(5)软件企业的领导应当给具有错误观念的开发人员们洗 脑。O需求分析员的天职就是在有限的时间内获取准确而细致的用户需求,如果做不到就是失职,就 不能够胜任软件系统分析工作。26
15、软件需求包括3个不同的层次与业务需求 用户需 求和功能需求。o(1)业务需求(Business Requirement)业务需求表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个软件系统,即组织希望达到的 目标。使用愿景(Visio n)和范围(Sc o pe)文档来记录业务需求,这份文档 有时也被称作项目轮廓图(Pr o j ec t Char t er)或市场需求(Mar ket Requir ement)文档。27(2)用户需求(User Requirement)。用户需求描述的是用户的
16、目标,或用户要求系统必须能 完成的任务。O用例、场景描述和事件-响应表都是表达用户需求的有 效途径。也就是说用户需求描述了用户能使用系统来做 些什么。28H,chLeve,BusinessRequirements.卜User euiied RequirementsSystem RequirementsSponsor point of viewScope of the projectBusiness ObjectivesUser point of viewUser GoalsUser inputs&Outputs kFunctional4-What t he syst em do esNon-F
17、unctional no w wel l t he syst em c c es it29(3)功能需求(Functional Requirement)O功能需求规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。o功能需求有时也被称作行为需求(Behavioral Requirement),因为习惯上总是用“应该”对其进行 描述,“系统应该发送电子邮件来通知用户已接受其预 7E o功能需求描述是开发人员需要实现什么。30(4)非功能性需求(Non-Functional Requirement)O系统需求O业务规则O软件需求规格说明O质量属性O约束Func t i
18、o nal r equir ement sNo n-f unc t io nal r equir ement sf unctiorul rvQLMvrMrti Qualitative requirements-Perf ormance-Vecurity-Re ability-UseahlityChangeabihtv/MintairQbilitv-PortabilitvBoundary conditions-StdncUrds-Technology Process31功能需求和非功能性需求功能需求和非功能性需求的区别FRNFRDif f ic ul t t o c apur e32需求管理首先
19、要针对需求做出分析,随后提 出解决方案。实施并验证结果好的需求管理,可使最终产 品更接近于解决需求,提高用户对产品的满 意度,从而使产品成为真正优质合格的产品O需求共识O根据需求设计解决办法O方案设计O必要的修改O任务划分O产品测试33,对于所建议的软件产品,获取需求是一个从 了解、理解到确定不同用户需要和限制的过 程,即要了解用户需要系统完成的任务有哪些o在这些任务中,分析者能获得用于描述系统活动的特定 软件功能需求,这些系统活动有助于用户完成他们的日 常工作任务。O获取用户需求位于软件需求三层结构的中间一层,它描 述了用户利用系统需要完成的任务。3435在整个软件项目实施过程中,需求获取可
20、能是软 件开发中最困难、最关键、最易出错及最需要沟 通、交流的重要方面。O 一旦理解并掌握了用户的实际需求,分析者、开发者就能够找到描 述这些需求的多种方法。开发方只有在掌握用户需求之后才能开始系统设 计工作。O否则,对需求定义的任何改进,设计上都必须进行大量的返工。一 个项目的目的,就是致力于开发正确的系统,要做到这一点就要足 够详细地描述需求,也就是系统必须达到的条件或能力,使用户和 开发人员在系统应该做什么,不应该做什么方面达成共识。O开发软件系统最为困难的部分就是准确说明开发什么,最为困难的 概念性工作便是编写出详细技术需求,这包括所有面向用户、面向 机器和其它软件系统的接口。3637
21、多年来,分析者总是利用情节或经历来描述 用户和软件系统的交互方式,从而获取需求,可以把这种看法系统地阐述成用使用实例 的方法进行需求获取和建模:O 一个使用实例描述了系统和一个外部与执行者的交互顺 序,这体现执行者完成一项任务并给利益相关者(Stakeholder)带来益处,执行者是指一个人,或另一 个软件应用,或一个硬件,或其它一些与系统交互以实 现某些目标的实体,执行者可以映像到一个或多个可以 操作的用户类角色。38Hd 1ELHigh levelBusiness RequirementsSponsor point of view,Scope of the projectBusiness
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件项目管理原理与实践 软件项目管理原理与实践 课件 第2章 软件项目需求工程 软件 项目 管理 原理 实践 需求 工程
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【曲****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【曲****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。