03软件需求工程

上传人:陈** 文档编号:188188218 上传时间:2023-02-18 格式:PPTX 页数:59 大小:873.02KB
收藏 版权申诉 举报 下载
03软件需求工程_第1页
第1页 / 共59页
03软件需求工程_第2页
第2页 / 共59页
03软件需求工程_第3页
第3页 / 共59页
资源描述:

《03软件需求工程》由会员分享,可在线阅读,更多相关《03软件需求工程(59页珍藏版)》请在装配图网上搜索。

1、上节回顾 增量模型 喷泉模型 Agile敏捷开发 XP编程 分析与设计的方法:结构化、面向对象 项目工作量(软件成本)的估算方法 专家估算法(Pert-delphi)货币的时间价值 投资回收期/率123发展史:发展史:软件需求作为软件生命周期的一个阶段,软件需求作为软件生命周期的一个阶段,其重要性越来越突出,到其重要性越来越突出,到20世纪世纪80年代中期,逐步形成了年代中期,逐步形成了软软件工程的子领域件工程的子领域需求工程。需求工程。90年代后,需求工程成为软件界研究的重点之一。从年代后,需求工程成为软件界研究的重点之一。从1993年起,每两年举办一次需求工程国际研讨会(年起,每两年举办一

2、次需求工程国际研讨会(ISRE),1994年起,每两年举办一次需求工程国际会议(年起,每两年举办一次需求工程国际会议(ICRE)。一些关于需求工程的工作小组相继成立,使需求工程的研。一些关于需求工程的工作小组相继成立,使需求工程的研究得到了迅速进展。究得到了迅速进展。4内容摘要内容摘要1.1.什么是需求工程什么是需求工程?2.2.什么是软件需求工程?什么是软件需求工程?3.3.软件需求的重要性软件需求的重要性4.4.软件需求的困难软件需求的困难5.5.软件需求内容软件需求内容6.6.需求工程的活动需求工程的活动51)软件需求的基本概念软件需求的基本概念 软件需求软件需求是指用户对是指用户对目标

3、软件系统目标软件系统在功能、行为、在功能、行为、性能、设计约束等方面的期望。宽泛地讲,需求来源性能、设计约束等方面的期望。宽泛地讲,需求来源于用户的一些于用户的一些“需要需要”,这些,这些“需要需要”被分析、确认被分析、确认后形成完整的文档,该文档详细地说明了产品后形成完整的文档,该文档详细地说明了产品“必须必须或应当或应当”做什么。做什么。通过对问题及其环境的理解与分析,为问题涉及的信通过对问题及其环境的理解与分析,为问题涉及的信息、功能及系统行为建立模型,将用户需求精确化、息、功能及系统行为建立模型,将用户需求精确化、完全化,最终形成需求规格说明,这一系列的活动即完全化,最终形成需求规格说

4、明,这一系列的活动即构成软件开发生命周期的构成软件开发生命周期的需求分析阶段需求分析阶段。1 什么是需求工程什么是需求工程1 什么是需求工程什么是需求工程2)需求工程需求工程(RE)的的概念概念 是指应用已证实有效的技术、方法进行需求分析,确定客户是指应用已证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特需求,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。征的一门学科。需求分析专家需求分析专家 Alan Davis 把需求工程定义为把需求工程定义为“直到(但不直到(但不包括)把软件分解为实际架构构件之前的所有活动包括)把软件分解为实际

5、架构构件之前的所有活动”RE通过合适的工具和记号系统地描述待开发系统及其行为特通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。进给予支持。672.什么是软件需求工程?什么是软件需求工程?需求工程需求工程RE可分为可分为系统需求工程系统需求工程(如果是针对由软硬件共同(如果是针对由软硬件共同组成的整个系统)和组成的整个系统)和软件需求工程软件需求工程(如果仅是专门针对纯软(如果仅是专门针对纯软件部分)。件部分)。需求工程需求工程6个阶段:需求获取、需求分析与协调、系统建模、个阶段

6、:需求获取、需求分析与协调、系统建模、需求规约、需求验证、需求管理。需求规约、需求验证、需求管理。8软件需求无疑是当前软件工程中的关键问题,软件需求无疑是当前软件工程中的关键问题,没有需求就没有需求就没有软件。没有软件。需求的重要性需求的重要性Frederick BrooksFrederick Brooks在他在他19871987年经典文章年经典文章“No Silver BulletNo Silver Bullet”中阐中阐述了需求的重要性:述了需求的重要性:开发软件系统最困难的部分就是准确说明开发什么。最困难的开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求

7、,包括所有面向用户、面向机概念性工作是编写出详细的需求,包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错,将会给系统带来器和其它软件系统的接口。此工作一旦做错,将会给系统带来极大的损害,并且以后对它修改也极为困难。极大的损害,并且以后对它修改也极为困难。需求是产品的根源,需求工作的优劣对产品影响最大。就像一条需求是产品的根源,需求工作的优劣对产品影响最大。就像一条河流,如果源头被污染了,那么整条河流也就被污染了。河流,如果源头被污染了,那么整条河流也就被污染了。国内软件业的痼疾:人们并不清楚究竟该做什么,但却一直忙碌国内软件业的痼疾:人们并不清楚究竟该做什么,但却一直忙碌不停地开

8、发。不停地开发。3.软件需求的重要性软件需求的重要性93.软件需求的重要性软件需求的重要性 美国于美国于1995年开始对全国范围内的年开始对全国范围内的8000个软件项目进行个软件项目进行跟踪调查。跟踪调查。分析失败的原因发现,分析失败的原因发现,与需求过程相关的原因占了与需求过程相关的原因占了45%,而其中,而其中缺乏最终用户的缺乏最终用户的参与以及不完整的需求又是两参与以及不完整的需求又是两大首要原因,大首要原因,各占各占13%和和12%。未完成未完成完成未实施完成未实施104.软件需求的困难软件需求的困难软件需求是软件工程中最复杂的过程之一:软件需求是软件工程中最复杂的过程之一:应用领域

9、的广泛性应用领域的广泛性,它的实施无疑与各个应用行业,它的实施无疑与各个应用行业的特征密切相关。的特征密切相关。非功能性需求建模技术的缺乏非功能性需求建模技术的缺乏及其与功能性需求有及其与功能性需求有着错综复杂的联系,大大增加了需求工程的复杂性。着错综复杂的联系,大大增加了需求工程的复杂性。沟通上的困难,沟通上的困难,由于系统需求分析各方面人员有不由于系统需求分析各方面人员有不同的着眼点和不同的知识背景,给需求工程的实施同的着眼点和不同的知识背景,给需求工程的实施增加了人为的难度。增加了人为的难度。客户说不清楚需求;客户说不清楚需求;需求自身经常变动;需求自身经常变动;分析人员或客户理解有误。

10、分析人员或客户理解有误。11真正的软件需求获取如此困难(漫画)真正的软件需求获取如此困难(漫画)12 需求工程需求工程是系统工程和软件工程的一个交叉分支,涉是系统工程和软件工程的一个交叉分支,涉及到软件系统的目标、软件系统提供的服务、软件系统的及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需精确规格说明以及系统进化之间的关系。它也提供现实需求和软件能力之间的桥梁。求和软件能力之间的桥梁。系统目标系统目标系统服务系统服务软件约束软件约束运行环境运

11、行环境5.软件需求内容软件需求内容13软软 件需件需 求求用用 户需户需 求求系系 统需统需 求求功能功能需求需求非功能非功能需求需求领域领域需求需求由客户管理员、由客户管理员、用户等提出用户等提出软件需求的内容软件需求的内容5.软件需求内容软件需求内容14功能需求功能需求领域需求领域需求15非功能需求非功能需求产品需求产品需求机构需求机构需求外部需求外部需求互操作互操作需求需求道德道德需求需求立法立法需求需求性能性能需求需求空间空间需求需求交付交付需求需求实现实现需求需求标准标准需求需求隐私隐私需求需求安全性安全性需求需求可用性可用性需求需求效率效率需求需求可靠性可靠性需求需求可移植可移植性

12、需求性需求非功能需求非功能需求16因此系统应该具备以下因此系统应该具备以下:基本数据维护功能基本数据维护功能 基本业务功能基本业务功能 数据库管理功能数据库管理功能 信息查询功能信息查询功能1718192021 Herb Krasner定义了需求工程的五阶段生命周期定义了需求工程的五阶段生命周期:需求定义和分析、需求决策、形成需求规格、需求:需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理实现与验证、需求演进管理 Matthias Jarke和和Klaus Pohl提出了三阶段周期提出了三阶段周期的说法:获取、表示和验证的说法:获取、表示和验证 本书将软件需求工程细分为:本

13、书将软件需求工程细分为:需求获取、需求需求获取、需求分析与协商、系统建模、需求规约、需求验证分析与协商、系统建模、需求规约、需求验证和和需求需求管理管理六个阶段。六个阶段。6.需求工程的活动需求工程的活动 22需求工程中的活动可分为两大类需求工程中的活动可分为两大类:一、需求开发一、需求开发二、需求管理二、需求管理6.需求工程的活动需求工程的活动 23一、一、需求开发需求开发 需求开发需求开发的任务是的任务是准确地定义未来系统的目标,确定为了满足用户的需求准确地定义未来系统的目标,确定为了满足用户的需求系统必须系统必须做什么做什么。用。用需求规格说明书需求规格说明书规范的形式准确地表达用户的规

14、范的形式准确地表达用户的需求。需求。需求开发需求开发的目的是通过调查与分析,获取用户需求并定义产品需求。的目的是通过调查与分析,获取用户需求并定义产品需求。(1 1)需求获取)需求获取的目的是的目的是深入实际,深入实际,通过各种途径通过各种途径,在充分理解用户需在充分理解用户需求的基础上,求的基础上,获取用户的需求信息获取用户的需求信息。(2 2)需求分析、协商与建模)需求分析、协商与建模的目的是对各种需求信息进行分析,消除的目的是对各种需求信息进行分析,消除错误,刻画细节等。错误,刻画细节等。(3 3)需求规格说明)需求规格说明目的是根据需求获取和需求分析的结果,进一步定目的是根据需求获取和

15、需求分析的结果,进一步定义准确无误的产品需求,产生义准确无误的产品需求,产生需求规格说明书需求规格说明书。系统设计人员。系统设计人员将依据将依据需求规格说明书需求规格说明书开展系统设计工作。开展系统设计工作。(4 4)需求验证)需求验证是指开发方和客户共同对需求文档进行评审,双方对需是指开发方和客户共同对需求文档进行评审,双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。确保求达成共识后作出书面承诺,使需求文档具有商业合同效果。确保需求说明准确、完整地表达系统的主要特性。需求说明准确、完整地表达系统的主要特性。24需求获取需求获取非常困难非常困难,主要原因有:,主要原因有:缺乏领域

16、知识缺乏领域知识,应用领域的问题常常是模糊的、不应用领域的问题常常是模糊的、不精确的;精确的;存在默认的知识存在默认的知识,如难以描述的常识问题;如难以描述的常识问题;存在多个知识源存在多个知识源,且多知识源之间可能有冲突;且多知识源之间可能有冲突;客户可能的偏见客户可能的偏见,如不能提供或不想告知你所需,如不能提供或不想告知你所需要了解的事情。要了解的事情。25需求获取技术需求获取技术1.1.面谈法面谈法 重要而直接,简单的重要而直接,简单的需求获取技术。需求获取技术。2.问卷法调查法问卷法调查法 是对面谈法的补充。是对面谈法的补充。3.3.需求专题讨论会需求专题讨论会 最有力的最有力的需求

17、获取技术。有利需求获取技术。有利 于于 培养高效团队。培养高效团队。4.观察用户的工作流程观察用户的工作流程 适用于用户无法准确表达适用于用户无法准确表达需求的情况。需求的情况。5.原型化方法原型化方法6.基于用例的方法基于用例的方法 还有知识工程方法等如:场记分析法、卡片分还有知识工程方法等如:场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。类法、分类表格技术和基于模型的知识获取等。26需求获取技术需求获取技术1.1.面谈法面谈法 重要而直接,简单的重要而直接,简单的需求获取技术。需求获取技术。2.问卷法调查法问卷法调查法 是对面谈法的补充。是对面谈法的补充。3.3.需求专题讨论

18、会需求专题讨论会 最有力的最有力的需求获取技术。有利需求获取技术。有利 于于 培养高效团队。培养高效团队。4.观察用户的工作流程观察用户的工作流程 适用于用户无法准确表达适用于用户无法准确表达需求的情况。需求的情况。5.原型化方法原型化方法6.基于用例的方法基于用例的方法27需求获取技术需求获取技术 1.1.面谈法面谈法 重要而直接,简单的重要而直接,简单的需求获取技术。需求获取技术。2.问卷法调查法问卷法调查法 是对面谈法的补充。是对面谈法的补充。3.3.需求专题讨论会需求专题讨论会 最有力的最有力的需求获取技术。有利需求获取技术。有利 于于 培养高效团队。培养高效团队。4.观察用户的工作流

19、程观察用户的工作流程 适用于用户无法准确表达适用于用户无法准确表达需求的情况。需求的情况。5.原型化方法原型化方法6.基于用例的方法基于用例的方法28需求获取技术需求获取技术1.1.面谈法面谈法 重要而直接,简单的重要而直接,简单的需求获取技术。需求获取技术。2.问卷法调查法问卷法调查法 是对面谈法的补充。是对面谈法的补充。3.3.需求专题讨论会需求专题讨论会 最有力的最有力的需求获取技术。有利需求获取技术。有利 于于 培养高效团队。培养高效团队。4.观察用户的工作流程观察用户的工作流程 适用于用户无法准确表达适用于用户无法准确表达需求的情况。需求的情况。5.文献考古文献考古 还有知识工程方法

20、等如:场记分析法、卡片分还有知识工程方法等如:场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。类法、分类表格技术和基于模型的知识获取等。29 需求分析阶段需求分析阶段主要对收集到的需求进行提炼、主要对收集到的需求进行提炼、分析和认真审查,对模型或原型进行分析和认真审查,对模型或原型进行分析,分析,进行进行需需求建模求建模。确保所有参加人员取得一致共识。找出错。确保所有参加人员取得一致共识。找出错误、遗漏和不足,误、遗漏和不足,建立完整的分析模型建立完整的分析模型。301 1、确定系统的综合要求、确定系统的综合要求 系统功能要求系统功能要求这是最主要的需求,确定系统必须完成的所有功能

21、。这是最主要的需求,确定系统必须完成的所有功能。系统性能要求系统性能要求应就具体系统而定,例如可靠性、联机系统的响应时应就具体系统而定,例如可靠性、联机系统的响应时间、存储容量、安全性能等。间、存储容量、安全性能等。系统运行要求系统运行要求主要是对系统运行时的环境要求,如系统软件、数据主要是对系统运行时的环境要求,如系统软件、数据库管理系统、外存和数据通信接口等。库管理系统、外存和数据通信接口等。将来可能提出的要求将来可能提出的要求对将来可能提出的扩充及修改作预准备。对将来可能提出的扩充及修改作预准备。2 2、分析系统的数据要求、分析系统的数据要求 软件系统本质上是信息处理系统,因此,必须考虑

22、:软件系统本质上是信息处理系统,因此,必须考虑:数据数据 (需要哪些数据、数据间联系、数据性质、结构)(需要哪些数据、数据间联系、数据性质、结构)数据处理数据处理 (处理的类型、处理的逻辑功能)(处理的类型、处理的逻辑功能)3 3、导出系统的逻辑模型。、导出系统的逻辑模型。4 4、修正系统的开发计划、修正系统的开发计划通过需求对系统的成本及进度有了更精确的估算,通过需求对系统的成本及进度有了更精确的估算,可进一步修改开发计划。可进一步修改开发计划。31当前当前系统系统目标目标系统系统物理物理模型模型逻辑逻辑模型模型逻辑逻辑模型模型物理物理模型模型模型化模型化抽象化抽象化具体化具体化实例化实例化

23、怎怎么么做做做做什什么么当前当前系统系统目标目标系统系统需需求求定定义义321必须能够表示和理解问题的必须能够表示和理解问题的信息域信息域2必须能够定义软件将完成的功能必须能够定义软件将完成的功能3必须能够表示软件的行为必须能够表示软件的行为(作为外部事件的结果作为外部事件的结果)4必须划分描述数据、功能和行为的模型,从而可必须划分描述数据、功能和行为的模型,从而可以分层次地揭示细节以分层次地揭示细节5分析过程应该从要素信息移向细节信息分析过程应该从要素信息移向细节信息33信息域:包括信息域:包括信息内容、信息流、信息内容、信息流、以及以及信息结构信息结构。信息内容信息内容表示了单个数据和控制

24、对象,目标软件所有处理的信表示了单个数据和控制对象,目标软件所有处理的信息集合由它们构成。息集合由它们构成。信息流信息流表示了数据和控制在系统中流动时的变化方式,输入对表示了数据和控制在系统中流动时的变化方式,输入对象被变换为中间信息象被变换为中间信息(数据和数据和/或控制或控制),然后进一步被变换为输,然后进一步被变换为输出出 信息结构信息结构表示了各种数据和控制项的内部组织表示了各种数据和控制项的内部组织 数据或控制项将被组织为数据或控制项将被组织为n维表还是树形结构?维表还是树形结构?在结构的语境内,什么信息是和其他信息相关的?在结构的语境内,什么信息是和其他信息相关的?信息包含在单个结

25、构中,还是使用不同的结构?信息包含在单个结构中,还是使用不同的结构?在某信息结构中的信息如何和在另一个结构中的信息相关?在某信息结构中的信息如何和在另一个结构中的信息相关?34 除了上面提到的除了上面提到的操作性分析原则操作性分析原则,Davis提出提出了一组针对需求工程的了一组针对需求工程的指导性原则指导性原则:在开始建立分析模型前,先充分理解问题。在开始建立分析模型前,先充分理解问题。开发原型,使得用户能够了解如何进行人机交互。开发原型,使得用户能够了解如何进行人机交互。记录每个需求的起源及原因。记录每个需求的起源及原因。使用多个需求视图。建立数据、功能和行为模型,为软使用多个需求视图。建

26、立数据、功能和行为模型,为软件工程师提供三种不同的视图。件工程师提供三种不同的视图。给需求赋予优先级。给需求赋予优先级。努力删除歧义性。努力删除歧义性。35 功能分解方法功能分解方法 面向数据流的结构化分析方法面向数据流的结构化分析方法(SA)面向数据结构的分析方法面向数据结构的分析方法 信息建模法信息建模法 面向对象的分析方法面向对象的分析方法(OOA)36 将系统看作若干功能模块的集合,每个功能又可将系统看作若干功能模块的集合,每个功能又可以分解为子功能以分解为子功能,子功能还可继续分解子功能还可继续分解,分解的结果即分解的结果即是系统的雏形。是系统的雏形。存在问题存在问题1.1.需要人工

27、完成需要人工完成2.2.无法对描述的准确度进行验证。无法对描述的准确度进行验证。3.3.难以适应需求的变化。难以适应需求的变化。问题空间问题空间功能功能子功能子功能映射映射371客房预定系统客房预定系统 2前台接待系统前台接待系统 3前台收银系统前台收银系统 4帐务系统帐务系统 5管家系统管家系统 6电话系统电话系统 7客历系统客历系统 8合约系统合约系统 9经理系统经理系统 10总经理系统总经理系统 11密码管理系统密码管理系统 12报表系统报表系统 13帐务报表帐务报表38盘存盘存/销售系统销售系统 1.0.01.0.0销售处理销售处理 1.1.01.1.0盘存处理盘存处理 1.2.01.

28、2.0例:例:盘存盘存/销售系统销售系统,用户提出,用户提出,系统应具有以下功能系统应具有以下功能:计算买主订单计算买主订单 准备销售报表准备销售报表 建立买主文件和应收帐发票建立买主文件和应收帐发票 运行更新的盘存文件运行更新的盘存文件 产生托运单和包装单产生托运单和包装单 保证库存及时订货保证库存及时订货计算销售计算销售记录记录 1.1.1产生销售产生销售报表报表 1.1.2核对买主核对买主贷方金额贷方金额 1.1.3验证库存验证库存量级量级 1.2.1产生货运产生货运订单订单 1.2.2执行买主执行买主汇票汇票 1.2.3产生盘存产生盘存报表报表 1.2.439结构化分析方法是结构化分析

29、方法是面向数据流面向数据流的需求分析方法,的需求分析方法,是是20世纪世纪70年代末由年代末由Yourdon,Constaintine及及DeMarco等人提出和发展,并得到广泛的应用。它等人提出和发展,并得到广泛的应用。它适合于分析大型的数据处理系统,特别是企事业管适合于分析大型的数据处理系统,特别是企事业管理系统。理系统。SA法也是一种建模的活动,主要是根据软件内法也是一种建模的活动,主要是根据软件内部的数据传递、变换关系,自顶向下逐层分解,描部的数据传递、变换关系,自顶向下逐层分解,描绘出满足功能要求的软件模型。绘出满足功能要求的软件模型。40面向对象的分析方法面向对象的分析方法 面向对

30、象的分析方法面向对象的分析方法(OOA)的关键是识别问题域内的关键是识别问题域内的对象的对象,分析它们之间的关系分析它们之间的关系,并建立起三类模型。并建立起三类模型。信息建模法信息建模法 是从数据的角度对现实世界建立系统的信息模型是从数据的角度对现实世界建立系统的信息模型,基基本工具是本工具是ERER图。是由实体、属性和关系组成的网络图。是由实体、属性和关系组成的网络图。图。E-E-实体,是一个或一组对象;实体,是一个或一组对象;R-R-关系,关系,实体之间联系或交互作用。实体之间联系或交互作用。41 协商的过程就是讨论需求冲突,找出每协商的过程就是讨论需求冲突,找出每个人都满意的折衷方案个

31、人都满意的折衷方案 协商不是简单的逻辑或技术上的争论协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素要注意组织和行政方面的因素 不一致的目标不一致的目标 责任的丧失或转移责任的丧失或转移 组织文化组织文化 组织管理态度和士气组织管理态度和士气 部门差异部门差异 42 通常会议是解决冲突最快的方式通常会议是解决冲突最快的方式 参加者应该包括发现冲突、遗漏或重叠的分参加者应该包括发现冲突、遗漏或重叠的分析员,以及可以解决发现的问题的项目相关析员,以及可以解决发现的问题的项目相关人员人员 会议应该讨论那些非正式讨论不能解决的问会议应该讨论那些非正式讨论不能解决的问题题 通常会议分为三个阶

32、段:通常会议分为三个阶段:叙述阶段叙述阶段 讨论阶段讨论阶段 决策阶段决策阶段 43 在软件需求分析阶段,所创建的模型,要在软件需求分析阶段,所创建的模型,要着重于描述系统要着重于描述系统要做什么做什么,而不是,而不是如何去如何去做做 目标软件的模型不应涉及软件实现细节目标软件的模型不应涉及软件实现细节 典型分析建模方法典型分析建模方法结构化分析结构化分析(传统建模方法传统建模方法)面向对象分析面向对象分析44计算机世界计算机世界现实世界现实世界结结构构化化开开发发方方法法结构化结构化分析分析结构化结构化设计设计结构化结构化编程编程OOAOODOOP面面向向对对象象开开发发方方法法模型的作用模

33、型的作用45面向对象分析模型的组成结构面向对象分析模型的组成结构使用实例使用实例(Use Case)(Use Case)操作、操作、属性、属性、协作者协作者46加加工工说说明明控制说明控制说明数数据据对对象象说说 明明数据字典数据字典(DD)结构化分析模型的组成结构结构化分析模型的组成结构47结构化分析模型的元素结构化分析模型的元素 数据字典数据字典(DD)(DD):模型核心模型核心(中心库中心库)数据流图数据流图(DFD)(DFD)指明数据在系统中移动时如何被变换指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能描述对数据流进行变换的功能;DFDDFD中每个功能的描述包含在加工规约

34、中每个功能的描述包含在加工规约(小说明小说明)。E-RE-R图图(ERD)(ERD)状态变迁图状态变迁图(STD)(STD)指明作为外部事件的结果指明作为外部事件的结果,系统将如何系统将如何 动作。动作。48 采用原始模板,在你的组织中要为编写采用原始模板,在你的组织中要为编写软件需求文档定义一种标准模板软件需求文档定义一种标准模板 指明需求的来源指明需求的来源 为每项需求注上标号制定一种惯例来为为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号每项需求提供一个独立的可识别的标号或记号或记号 记录业务规范记录业务规范49需求规约的原则需求规约的原则 1从现实中分离功能,即描述

35、要从现实中分离功能,即描述要“做什么做什么”而不是而不是“怎怎样实现样实现”。2要求使用要求使用面向处理面向处理的规约语言(或称系统定义语言),的规约语言(或称系统定义语言),讨论来自环境的各种刺激可能导致系统做出什么样的功讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应,来定义一个能性反应,来定义一个行为模型行为模型,从而得到,从而得到“做什么做什么”的规约。的规约。3如果被开发软件只是一个基于计算机的系统中的一个如果被开发软件只是一个基于计算机的系统中的一个元素,那么整个大系统也包括在规格说明的描述之中。元素,那么整个大系统也包括在规格说明的描述之中。4规约必须包括系统运行环境。规

36、约必须包括系统运行环境。50需求规约的原则需求规约的原则(续续)5规约必须是一个认识模型,而不是设计或实现的模型。规约必须是一个认识模型,而不是设计或实现的模型。6规约必须是可操作的,以便能够利用它决定对于任意规约必须是可操作的,以便能够利用它决定对于任意给定的测试用例,已提出的解决方案是否都能满足规约。给定的测试用例,已提出的解决方案是否都能满足规约。7规约必须允许不完备性并允许扩充。规约必须允许不完备性并允许扩充。8规约必须局部化和松散耦合。它所包括的信息必须局规约必须局部化和松散耦合。它所包括的信息必须局部化,这样当信息被修改时,只要修改某个单个的段落部化,这样当信息被修改时,只要修改某

37、个单个的段落(理想情况)。同时,规约应被松散地构造(即松耦(理想情况)。同时,规约应被松散地构造(即松耦合),以便能够很容易地加入和删去一些段落。合),以便能够很容易地加入和删去一些段落。51需求规约需求规约IEEE/ANSI830-1993 简化大纲简化大纲.引言 A.系统参考文献B.整体描述C.软件项目约束.信息描述 A.信息内容表示B.信息流表示:数据流 控制流.功能描述 A.功能划分 B.功能描述:处理说明 限制局限 性能需求 设计约束 支撑图 C.控制描述 控制规约 设计约束.行为描述 A.系统状态 B.事件和响应.检验标准 A.性能范围B.测试种类C.期望的软件响应D.特殊的考虑.

38、参考书目.附录52引言:引言:陈述软件目标,在基于计算机的系统语境内进行描述。信息描述:信息描述:给出软件必须解决问题的详细描述,记录信息内容和关系、流和结构。功能描述:功能描述:描述解决问题所需的每个功能。其中包括,为每个功能说明一个处理过程;叙述设计约束;叙述性能特征;用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。行为描述:行为描述:描述作为外部事件和内部产生的控制特征的软件操作。检验标准:检验标准:描述检验系统成功的标志。即对系统进行什么样的测试,得到什么样的结果,就表示系统已经成功实现了。它是“确认测试”的基础。参考书目:参考书目:包含了对所有和该软件

39、相关的文档的引用,其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。附录:附录:包含了规约的补充信息,表格数据、算法的详细描述、图表以及其他材料。53需求验证目的是要检验需求是否能够反映用户的意愿需求验证目的是要检验需求是否能够反映用户的意愿一一)需求验证的重要性需求验证的重要性.由于需求分析是软件开发的第一阶段,直接影响后面各阶由于需求分析是软件开发的第一阶段,直接影响后面各阶段的开发。段的开发。.需求的可变性必须进行验证。需求的可变性必须进行验证。二二)需求验证的内容需求验证的内容1.有效性检查有效性检查指功能需求是否符合用户所提出的需求。指功能需求是否符合用户所提出的需求。2.

40、2.一致性检查一致性检查系统功能描述及约束是否一致。系统功能描述及约束是否一致。3.3.完备性检查完备性检查是否包含所有系统用户的需求和是否包含所有系统用户的需求和约束。约束。4.4.可检验性检查可检验性检查是否能设计出一组验证方法。是否能设计出一组验证方法。54需求开发过程需求开发过程 可行性研究可行性研究需求获取需求获取和分析和分析需求描述需求描述需求有效性需求有效性验证验证可行性报告可行性报告系统模型系统模型用户需求和用户需求和系统需求系统需求需求文挡需求文挡55二、需求管理二、需求管理需求管理是一组用于帮助项目组在项目进展中的任何时候去需求管理是一组用于帮助项目组在项目进展中的任何时候

41、去标识、控制和跟踪需求的活动标识、控制和跟踪需求的活动 需求管理需求管理的目的是在客户与开发方之间建立对需求的共同理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。解,维护需求与其它工作成果的一致性,并控制需求的变更。需求管理贯穿需求分析全过程,包括需求管理贯穿需求分析全过程,包括:需求管理需求管理变更控制变更控制 建议变更建议变更 分析影响分析影响 交流交流 合并合并 测量需求的稳测量需求的稳定性定性版本控制版本控制 定义需求文档定义需求文档版本版本 确定单个需求确定单个需求文档版本文档版本需求跟踪需求跟踪 建立与维护建立与维护“需求跟踪矩阵

42、需求跟踪矩阵”,确保产品,确保产品依据需求文档依据需求文档进行开发。进行开发。需求状态跟踪需求状态跟踪 定义需求状态定义需求状态 跟踪所有需求跟踪所有需求状态状态56 需求管理的所有活动中,最重要的是需求管理的所有活动中,最重要的是需求变更管理,包括需求变更管理,包括:问题分析和变问题分析和变更描述更描述变更分析和成变更分析和成本计算本计算变更实现变更实现修正后的修正后的需求需求识别出的识别出的问题问题 需求管理过程需要需求管理过程需要CASE(Computer Aided Software Engineering)工具支持。工具支持。二、需求管理二、需求管理57系统分析员的主要能力系统分析员

43、的主要能力 在整个系统分析活动中,系统分析员起着关键的在整个系统分析活动中,系统分析员起着关键的作用,其本人应该具备作用,其本人应该具备 熟悉计算机技术;熟悉计算机技术;了解用户业务领域的相关知识;了解用户业务领域的相关知识;能在用户和开发人员之间借助于数据概念进行交流。能在用户和开发人员之间借助于数据概念进行交流。同时从个人素质上,分析师应善于从原始材料中抽象出逻辑概念,将同时从个人素质上,分析师应善于从原始材料中抽象出逻辑概念,将其重新整理之后成为各种逻辑成分,并根据各种逻辑成分综合出问题其重新整理之后成为各种逻辑成分,并根据各种逻辑成分综合出问题的解决办法,并善于用模型说话;的解决办法,并善于用模型说话;能从冲突或者混淆中吸取恰当事实的能力;能从冲突或者混淆中吸取恰当事实的能力;能弄清用户环境的能力;能弄清用户环境的能力;能为用户系统恰当配置软硬件的能力能为用户系统恰当配置软硬件的能力 能较好地用书面和口头形式进行沟通的能力能较好地用书面和口头形式进行沟通的能力 有有“从树木见森林从树木见森林”的能力。的能力。58需求工程小结需求工程小结演讲完毕,谢谢观看!

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

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!