书签 分享 收藏 举报 版权申诉 / 25
上传文档赚钱

类型软件需求工程第二部分软件需求开发课件.ppt

  • 上传人(卖家):晟晟文业
  • 文档编号:4533529
  • 上传时间:2022-12-17
  • 格式:PPT
  • 页数:25
  • 大小:107KB
  • 【下载声明】
    1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
    2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
    3. 本页资料《软件需求工程第二部分软件需求开发课件.ppt》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
    4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
    5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
    配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    软件 需求 工程 第二 部分 开发 课件
    资源描述:

    1、2022-12-17第第十七十七章章 超越需求开发超越需求开发王王 如如 龙龙第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 2/25学习目标学习目标在学完本章内容之后,你应该能够:在学完本章内容之后,你应该能够:1)了解做好从需求到项目规划转换的意义与方法;了解做好从需求到项目规划转换的意义与方法;2)分析从需求到设计、编码、测试的关系与区别;分析从需求到设计、编码、测试的关系与区别;3)掌握从需求到设计、编码、测试的过程控制原则掌握从需求到设计、编码、测试的过程控制原则与方法。与方法。第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WR

    2、LSQE-WRL 3/2517.0 做好需求做好需求转化的意义和作用转化的意义和作用一个软件开发项目最终可发行的是满一个软件开发项目最终可发行的是满足客户需求和期望的软件系统。足客户需求和期望的软件系统。需求是从产品概念通向用户满意之路需求是从产品概念通向用户满意之路的最本质的一步。的最本质的一步。把软件需求转化为健壮的设计和合理把软件需求转化为健壮的设计和合理的项目规划是项目成功的基本保证。的项目规划是项目成功的基本保证。第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 4/2517.0 做好需求做好需求转化的意义和作用转化的意义和作用 软件开发人员与客户

    3、、用户对需求的理解不软件开发人员与客户、用户对需求的理解不同、对系统的要求不同、甚至由于利益关系的同、对系统的要求不同、甚至由于利益关系的不同,将影响转化工作的顺利进行。不同,将影响转化工作的顺利进行。需求分析人员与软件设计和编码人员在对系需求分析人员与软件设计和编码人员在对系统的理解角度、认识水平、掌握的技术,甚至统的理解角度、认识水平、掌握的技术,甚至在年龄、工作经历、和所处地位的差别,将影在年龄、工作经历、和所处地位的差别,将影响转化工作的顺利进行。响转化工作的顺利进行。第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 5/2517.0 做好需求做好需

    4、求转化的意义和作用转化的意义和作用基线基线需求需求项目计划项目计划设计和代码设计和代码测测 试试l根据需求确定项目的规模根据需求确定项目的规模l根据产品规模进行评估根据产品规模进行评估l当需求改变时更新计划当需求改变时更新计划l使用需求优先级驱动迭代使用需求优先级驱动迭代l让开发人员评审需求让开发人员评审需求l根据质量属性决定体系结构设根据质量属性决定体系结构设计计l将需求分配给各组件将需求分配给各组件l跟踪需求到设计和代码跟踪需求到设计和代码l尽早开始测试设计尽早开始测试设计l用需求驱动系统测试用需求驱动系统测试l让用户开发验收测试让用户开发验收测试l跟踪需求到测试跟踪需求到测试图图17-1

    5、 需求推动项目规划、设计、编码和测试活动需求推动项目规划、设计、编码和测试活动P209第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 6/2517.1 从需求到项目规划从需求到项目规划由于需求定义了项目预期的成果,所以项目由于需求定义了项目预期的成果,所以项目规划、预测和进度安排都必须以软件需求为基规划、预测和进度安排都必须以软件需求为基础。础。但是,请大家牢记,最重要的项目成果是交但是,请大家牢记,最重要的项目成果是交付满足业务目标的系统,而不一定是根据最初付满足业务目标的系统,而不一定是根据最初的项目规划实现所有初始需求的系统。的项目规划实现所有初始需

    6、求的系统。P210第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 7/2517.1 从需求到项目规划从需求到项目规划项目团队到底应该在需求工程中投入多项目团队到底应该在需求工程中投入多少时间和精力,是一个必须解决的问题少时间和精力,是一个必须解决的问题。对小型项目而言,团队在需求工程上所对小型项目而言,团队在需求工程上所发费的故障量应该占项目的发费的故障量应该占项目的1215。相当多的证据表明,花一些时间理解需相当多的证据表明,花一些时间理解需求实际上可以加速项目的开发进度。求实际上可以加速项目的开发进度。P210第第 17 章章 超越需求开发超越需求开发

    7、SQE-WRLSQE-WRLSQE-WRL 8/2517.1 从需求到项目规划从需求到项目规划欧洲的一份研究表明,产品开发较快的欧洲的一份研究表明,产品开发较快的团队,与产品开发较慢的团队相比,在团队,与产品开发较慢的团队相比,在需求阶段所投入的时间和工作量更多一需求阶段所投入的时间和工作量更多一些。些。P210投入的工作量投入的工作量投入的时间投入的时间开发较快的项目开发较快的项目1417开发较慢的项目开发较慢的项目79表表17-1 对需求工作的投入可以加速项目的开发对需求工作的投入可以加速项目的开发第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 9/2

    8、517.1 从需求到项目规划从需求到项目规划l需求和预估需求和预估 可以根据文本需求、分析模型、原型或用户界面来可以根据文本需求、分析模型、原型或用户界面来估计软件产品的规模;估计软件产品的规模;虽然软件的规模没有规定的度量标准,但可以采用虽然软件的规模没有规定的度量标准,但可以采用如下一些方法来进行度量:如下一些方法来进行度量:l需求的数量;需求的数量;l功能点和特性点的数量;功能点和特性点的数量;l图形用户界面(图形用户界面(GUI)元素的数量、类型和复杂度;)元素的数量、类型和复杂度;l用于实现特定需求所需的源代码行数;用于实现特定需求所需的源代码行数;l对象类的数量或其他面向对象系统的

    9、衡量标准。对象类的数量或其他面向对象系统的衡量标准。P211第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 10/2517.1 从需求到项目规划从需求到项目规划l需求和进度安排需求和进度安排 许多软件工程实行许多软件工程实行“从右到左的进度安排从右到左的进度安排”,这,这种方式常常不能按时完成项目。种方式常常不能按时完成项目。在做出详细的规划和约定之前定义软件需求是更现在做出详细的规划和约定之前定义软件需求是更现实的。实的。进度进度范围范围成本成本需需求求进度进度范围范围成本成本需需求求图图17-2 两种不同的进度安排两种不同的进度安排P212第第 17

    10、章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 11/2517.1 从需求到项目规划从需求到项目规划l需求和进度安排需求和进度安排 对于复杂的系统,软件仅是最终产品的一部对于复杂的系统,软件仅是最终产品的一部分时,只有在系统需求(产品级需求)产生以分时,只有在系统需求(产品级需求)产生以后,才能建立高层的进度安排。后,才能建立高层的进度安排。将系统需求分解并分配到各个不同的软硬件将系统需求分解并分配到各个不同的软硬件子系统中,有利于进度的安排和执行。子系统中,有利于进度的安排和执行。必须根据市场需求、销售计划、客户服务要必须根据市场需求、销售计划、客户服务要求以及产品

    11、开发计划等的为基础建立起一致的求以及产品开发计划等的为基础建立起一致的产品发行日期。产品发行日期。P213第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 12/2517.1 从需求到项目规划从需求到项目规划l 需求和进度安排需求和进度安排 正确的项目规划需要以下元素:正确的项目规划需要以下元素:n根据对需求的清楚理解来估计产品规模的大小;根据对需求的清楚理解来估计产品规模的大小;n根据历史记录了解开发小组的工作效率;根据历史记录了解开发小组的工作效率;n需要一张综合的任务列表,以便完整地实现和验需要一张综合的任务列表,以便完整地实现和验证每一特性或用例;证

    12、每一特性或用例;n 相当稳定的需求;相当稳定的需求;n 项目团队的经验。项目团队的经验。P213第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 13/2517.2 从需求到设计和编码从需求到设计和编码 需求和设计之间存在差别,需求开发和规格说需求和设计之间存在差别,需求开发和规格说明应该强调对预期系统外部行为的理解和描述。明应该强调对预期系统外部行为的理解和描述。必须让设计者和开发者参与需求审查以判断需必须让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。求是否可以作为设计的基础。直接从需求规格说明跳到编码阶段,其可能的直接从需求规格说明跳到编

    13、码阶段,其可能的结果只能是结构性很差的一个软件。结果只能是结构性很差的一个软件。在构造软件之前,应该仔细考虑构造系统的最在构造软件之前,应该仔细考虑构造系统的最有效的方法。有效的方法。P213第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 14/2517.2 从需求到设计和编码从需求到设计和编码 分析模型代表了用户和开发小组对正在解决分析模型代表了用户和开发小组对正在解决的问题的理解,而设计模型则描绘了应该如何的问题的理解,而设计模型则描绘了应该如何构造系统。构造系统。如果在需求分析之后立刻进行编码,那么必定如果在需求分析之后立刻进行编码,那么必定会出现代

    14、码重复。而且设计上的返工比编码返会出现代码重复。而且设计上的返工比编码返工可能要效率高一些。工可能要效率高一些。以需求为基础,反复设计将产生优良成果,用以需求为基础,反复设计将产生优良成果,用不同的方法进行设计可以精细化最初的概念。不同的方法进行设计可以精细化最初的概念。P213第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 15/2517.2 从需求到设计和编码从需求到设计和编码在开始实现产品之前,虽然不需要为整个产在开始实现产品之前,虽然不需要为整个产品开发完整的、详细的设计,但是,应该先对品开发完整的、详细的设计,但是,应该先对每一个组件进行设计,然

    15、后再对其进行编码。每一个组件进行设计,然后再对其进行编码。当项目难度很大、涉及的接口和交付复杂、当项目难度很大、涉及的接口和交付复杂、开发人员经验不足时,最能体现设计规划的好开发人员经验不足时,最能体现设计规划的好处。处。P215第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 16/2517.2 从需求到设计和编码从需求到设计和编码如下的建议对所有的项目类型都有益:如下的建议对所有的项目类型都有益:l 为子系统和组件开发一个坚固的体系结构,这一体系结构为子系统和组件开发一个坚固的体系结构,这一体系结构在产品改进的过程中可以保持不变;在产品改进的过程中可以保

    16、持不变;l明确需要创建的对象类或功能模块,定义他们的接口、职明确需要创建的对象类或功能模块,定义他们的接口、职责以及与其他单元的协作;责以及与其他单元的协作;l对并行处理系统,要理解计划执行的线程或对并发进程的对并行处理系统,要理解计划执行的线程或对并发进程的功能分配;功能分配;l 根据强内聚、松耦合和信息隐藏的设计原则,定义每个代根据强内聚、松耦合和信息隐藏的设计原则,定义每个代码单元的预期功能码单元的预期功能 ;l 确保设计满足所有的功能需求,但不包括不必要的功能;确保设计满足所有的功能需求,但不包括不必要的功能;l确保设计能适应可能出现的异常条件;确保设计能适应可能出现的异常条件;l确保

    17、设计能达到所陈述的性能、健壮确保设计能达到所陈述的性能、健壮 性、可靠性和其他一性、可靠性和其他一些质量属性的目标。些质量属性的目标。P215第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 17/2517.3 从需求到测试从需求到测试测试和需求工程是一种相互促进的关系,好的需求测试和需求工程是一种相互促进的关系,好的需求工程可以生存更好的测试,工程可以生存更好的测试,好的测试分析可以生存好的测试分析可以生存更好的需求。更好的需求。需求是系统测试的基础,对产品的测试应该根据需需求是系统测试的基础,对产品的测试应该根据需求文档中所记录的产品的预期行为来进行,而

    18、不应该求文档中所记录的产品的预期行为来进行,而不应该根据设计或编码来测试。根据设计或编码来测试。产品可以正确地展示基于代码的测试用例所描述的产品可以正确地展示基于代码的测试用例所描述的所有行为,但这并不意味着产品正确地实现了用户或所有行为,但这并不意味着产品正确地实现了用户或功能性需求。功能性需求。应该让测试人员参与需求审查,这样可以确保需求应该让测试人员参与需求审查,这样可以确保需求是可以验证的并可以作为系统测试的基础。是可以验证的并可以作为系统测试的基础。P216第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 18/2517.3 从需求到测试从需求到测

    19、试 当每个需求都稳定之后,系统测试人员应该编写以当每个需求都稳定之后,系统测试人员应该编写以测试用例为主的测试计划,通过测试、审查,演测试用例为主的测试计划,通过测试、审查,演示或分析来验证需求。示或分析来验证需求。根据需求中的逻辑描述,利用诸如因果图等分析技根据需求中的逻辑描述,利用诸如因果图等分析技术来获得测试用例,这将会揭示需求的二义性、遗漏术来获得测试用例,这将会揭示需求的二义性、遗漏或隐含的其它条件和其它问题。每个需求应至少由一或隐含的其它条件和其它问题。每个需求应至少由一个测试用例来测试。个测试用例来测试。有经验的测试人员可以根据他们对产品的预期功能、有经验的测试人员可以根据他们对

    20、产品的预期功能、用法、质量特性和特有行为的理解,概括出纯粹基于用法、质量特性和特有行为的理解,概括出纯粹基于需求的测试。需求的测试。P216第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 19/2517.3 从需求到测试从需求到测试 基于基于SRS的测试适用于许多测试设计策略如的测试适用于许多测试设计策略如动作驱动、数据驱动、逻辑驱动、事件驱动和动作驱动、数据驱动、逻辑驱动、事件驱动和状态驱动等。状态驱动等。从正式的从正式的SRS中很容易自动生成测试用例,中很容易自动生成测试用例,但是对于更多的由自然语言描述的但是对于更多的由自然语言描述的SRS,必须必须

    21、手工开发测试用例。手工开发测试用例。比起结构化分析图,对象模型更易于自动生比起结构化分析图,对象模型更易于自动生成测试用例。成测试用例。P216第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 20/2517.3 从需求到测试从需求到测试 在开发的进展过程中,通过详细的软件功能需求仔在开发的进展过程中,通过详细的软件功能需求仔细推敲来自使用实例的需求,并最终转化成单个代码细推敲来自使用实例的需求,并最终转化成单个代码模块的规格说明。模块的规格说明。针对需求的测试必须在软件结构的每一层进行,而针对需求的测试必须在软件结构的每一层进行,而不只是在用户层进行。不只

    22、是在用户层进行。即使有些模块功能在整个软件产品中对用户都不可即使有些模块功能在整个软件产品中对用户都不可见,但是每个模块功能必须满足其自身的需求或规格见,但是每个模块功能必须满足其自身的需求或规格说明要求。说明要求。因此,针对用户需求来测试系统是系统测试的必要因此,针对用户需求来测试系统是系统测试的必要但非充分条件。但非充分条件。P217第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 21/2517.3 从需求到成功从需求到成功 如果不以高质量的需求作为项目规划、软件如果不以高质量的需求作为项目规划、软件设计和系统测试的基础,那么在试图开发优秀设计和系统测

    23、试的基础,那么在试图开发优秀产品的过程中将浪费大量的人力和物力。产品的过程中将浪费大量的人力和物力。需求分析是项目成功的基础,软件开发的过需求分析是项目成功的基础,软件开发的过程犹如盖房子,如果地基没有做好,那么房子程犹如盖房子,如果地基没有做好,那么房子盖完之后的第一件事就是拆房子,而不是测试盖完之后的第一件事就是拆房子,而不是测试房子。房子。所以需求到成功的关键是要通过规划、软设所以需求到成功的关键是要通过规划、软设计和测试不断确定需求的正确性。计和测试不断确定需求的正确性。P217第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 22/2517.3 从

    24、需求到成功从需求到成功 正确把握需求开发的深度与广度,避免陷入畸形分析正确把握需求开发的深度与广度,避免陷入畸形分析的陷阱,是需求开发必须注意的另一面;的陷阱,是需求开发必须注意的另一面;必须理解到,客户最关心的是结果,当需求开发组花必须理解到,客户最关心的是结果,当需求开发组花费大量的时间创建不必要的文档、举行各种形式上的会费大量的时间创建不必要的文档、举行各种形式上的会议和评审,而并不解决任何实际问题时,会引起客户甚议和评审,而并不解决任何实际问题时,会引起客户甚至设计人员的困惑和不满,最终导致项目被取消。至设计人员的困惑和不满,最终导致项目被取消。努力在精确的规格说明与可将产品失败的风险

    25、努力在精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择,是降至可接受程度的编码之间做出明智的选择,是需求开发人员的必须掌握的基本功。需求开发人员的必须掌握的基本功。P217第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 23/25本章小结本章小结 由于需求定义了项目预期的成果,所以项目规划、预测和进由于需求定义了项目预期的成果,所以项目规划、预测和进度安排都必须以软件需求为基础。度安排都必须以软件需求为基础。软件项目可能经常不能达到预定的目标软件项目可能经常不能达到预定的目标的主要原因不在技的主要原因不在技术上而在管理上。术上而在管

    26、理上。需求估算有多种方法,但都离不开经验的积累。需求估算有多种方法,但都离不开经验的积累。需求和设计之间存在差别,需求开发和规格说明应该强调对需求和设计之间存在差别,需求开发和规格说明应该强调对预期系统外部行为的理解和描述。预期系统外部行为的理解和描述。必须让设计者和开发者参与需求审查以判断需求是否可以作必须让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。为设计的基础。必须针对必须针对SRS来测试整个软件,而不是针对设计或编码。来测试整个软件,而不是针对设计或编码。把软件需求转化为健壮的设计和合理的项目规划是项目成功把软件需求转化为健壮的设计和合理的项目规划是项目成功的基本保证。的基本保证。第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 24/25第第3 3次作业次作业推荐读物推荐读物第第 17 章章 超越需求开发超越需求开发SQE-WRLSQE-WRLSQE-WRL 25/25l需求的开发是需求成功的基本保证。需求的开发是需求成功的基本保证。l关注与开发非功能需求比功能需求关注与开发非功能需求比功能需求更重要。更重要。l需求的获取、分析、编写和验证必需求的获取、分析、编写和验证必须建立有效的过程和实用的模板。须建立有效的过程和实用的模板。谢谢大家谢谢大家

    展开阅读全文
    提示  163文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:软件需求工程第二部分软件需求开发课件.ppt
    链接地址:https://www.163wenku.com/p-4533529.html

    Copyright@ 2017-2037 Www.163WenKu.Com  网站版权所有  |  资源地图   
    IPC备案号:蜀ICP备2021032737号  | 川公网安备 51099002000191号


    侵权投诉QQ:3464097650  资料上传QQ:3464097650
       


    【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。

    163文库