软件工程基础(胡思康)第2章课件.pptx

软件需求工程,Chapter2,实际项目经验表明：用户自身对将要开发的系统也并不是完全理解，对需求目标的陈述带有主观片面性、模糊性、不一致性，甚至还会出现错误；用户不会把需求按照功能、性能、行为、约束等特性对需求分门别类。,软件需求工程,只有运用系统的方法学，并借助需求分析提供的方法和工具，才能把软件系统功能、性能的总体陈述转化为具体的软件需求规格说明，奠定软件开发的基础。,软件需求工程,软件需求实际上就是准确回答“系统必须做什么”的问题。这一阶段还不能确定系统如何实现，而是确定系统必须完成的任务是什么，用户操作流程是什么顺序，系统约束条件如何规定。,软件需求工程,定义软件的使用领域和必须满足的约束,5,4,2,任务,确定系统功能、性能、领域等内容,基本的需求分析任务,3,1,确定软件与其他成分间的接口和通信,建立数据模型、功能模型和行为模型,最终定义需求规格说明书、并经过技术审查和管理复审，用作评价确认测试和质量评估的依据,需求分析的任务,系统中最主要、最基本的需求是功能需求。功能体现计算机能在多大程度上辅助用户完成任务，是用户体验中最重要的部分。,恰当的给用户提出将来系统可能进行的扩充和修改,需求分析的任务,数据从哪里来（收集过程），到哪里去（存储过程），系统内部如何操作和转换这些数据，如果表示数据，如何共享数据等问题。数据分析将数据从物理实体映射为逻辑实体，分析逻辑数据间的连接、视图模型。,需求分析的任务,把问题域中的问题转换成信息领域问题。结构化方法采用数据流图、数据字典等图形工具定义。面向对象方法采用例图、类-对像图。,需求分析的任务,基线是进行需求变更的界线。在需求分析的基线定义之前，能够随时进行需求变更，若在基线定义之后变更，则需要重新进行审查和复审。,需求分析的原则,功能是否有约束，系统如何使用更能符合用户的操作习惯。在需求评审中，软件人员需要在用户的配合下，对需求规格说明进行管理复审，以确保和用户对需求规格说明的理解达成一致。,需求分析的原则,通过用户对流程的描述，将有关概念和内容连接起来，如信息、组织结构、处理规则、操作流程等，使得对问题的定义既有宏观描述，也有微观解释。,需求分析的原则,设计模式重用（需求阶段考虑的重点）和代码重用。,需求分析的原则,例如：增量开发模型中迭代过程的增量选择，主要就是通过需求分析优先级来确定的,需求分析的原则,立即通知所有相关人员，并积极讨论变更带来的影响和组织新的实施方案。,需求分析的内容,描述系统提供的服务和在特定条件下的行为。包括系统登录、输入、响应、输出、异常等，有时还需要特别说明系统不应该做什么。通过需求分析，划分出系统必须完成的所有功能。完整性（尽量得到所有用户提出的服务）和一致性（功能需求不能有相互矛盾之处）。,需求分析的内容功能需求,“简历信息自动获取系统”基本业务功能用户管理功能数据管理功能,需求分析的内容功能需求,规定了软件必须满足的时间上或空间上的约束，通常包括系统响应时间、主存容量、存储容量、安全性、压力等方面的需求。“简历信息自动获取系统”提取简历信息准确性的要求对系统安全性的要求对系统可靠性的要求,需求分析的内容性能需求,具体应用范围。“简历信息自动获取系统”简历文本内容符合一般简历的要求，包括姓名、年龄、专业等必要信息，否则该简历文本会被系统自动放弃。,需求分析的内容领域需求,与软件系统有关的外在约束，如法律需求、道德需求、外部数据交换需求、预期需求等。“简历信息自动获取系统”随着互联网文件格式标准和企业发展的需要，对以XML格式或企业提供的简历模版编写的简历，系统预期将要能自动获取信息。,需求分析的内容其他需求,需求工程中的参与人员,需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。可行性研究：最初的计划阶段-确定问题是否能够解决。其目的不是确定问题如何去解决，而是确定问题是否值得去解（技术可行性、操作可行性、经济可行性、法律可行性）。,需求工程过程中的活动,需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。需求获取：通过获取技术（对系统领域知识有一定了解的前提下），得到用自然语言描述的问题陈述和功能陈述。,需求工程过程中的活动,需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。需求分析与建模：以需求获取文档为基础，逐步细化需求中的软件功能，找出系统各元素间的依赖和调用关系、接口特性和设计上的性能约束。之后用软件开发方法提供的图形工具，用形式化或半形式化的定义来描述初步需求。将目标系统的物理模型转换为详细的逻辑模型，形成最终的软件需求规格说明书和初步的用户手册。,需求工程过程中的活动,需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。需求评审：进行技术审查和管理复审，再次确保所采纳的技术方案在技术上是可行的，在操作上是符合用户习惯的，在经济上是有效的，在法律上是合法的。,需求工程过程中的活动,需求工程的迭代模型,需求工程的管理贯穿整个需求工程的全过程。在需求工程管理过程中存在两大难题：一是需求确认困难；二是需求不断变更。,需求工程的管理,对传统的需求变更管理过程来说，主要包括软件配置、软件基线和变更审查。软件配置的目的是确保所做的工作是可回朔的，能够恢复原来工作的文档、代码等内容，也能跟踪目前工作结果的来龙去脉。需要进行软件配置的内容称为软件配置项，主要有两类：一是属于产品自身需要的内容，如开发文档、代码、数据等；二是为软件产品服务的内容，如进度计划、人员安排、报告等。,需求工程的管理需求变更,对传统的需求变更管理过程来说，主要包括软件配置、软件基线和变更审查。软件基线由一组软件配置项组成。当软件配置项处于稳定状态后（如需求文档经过评审以后），就确定了这组软件配置项的基线。在后续的开发过程中，软件配置项发生变更，则这一变更须通过变更审查并确定，变更才能记录在软件配置项中，并通知与之有关的人员。,需求工程的管理需求变更,需求获取是需求分析的前提，没有完整、正确的获取用户需求，就不能保证软件产品质量。因此，软件人员与用户交流需要好的方法，以便能达成共识。,需求获取技术,需求工程的管理需求变更,个别会谈：会谈的双方是分析员、用户以及系统领域专家。用户提供对系统功能、性能等方面的需求；领域专家提供系统背景知识、领域需求等方面的知识。在这个过程中，分析员学习和掌握系统背景知识，保证需求获取的正确性。,需求获取技术个别会谈和小组会议,小组会议：对于系统的不同用户，由于操作流程的不同，使用功能的不同，对软件运行环境要求的不同，他们对系统的需求也不尽相同。小组会议保证各方需求获取的完整性、一致性。,需求获取技术个别会谈和小组会议,谈话提纲用户背景系统背景维护,需求获取技术个别会谈和小组会议,分析员给用户提供规范的问卷表，帮助用户明晰问题的主旨。P40表2-1,需求获取技术问卷调查,分析员实际观察用户的手工操作过程，体验用户在工作中所遇到的不便和困难。用户环境就是将来系统运行的场景，用户的一次手工操作过程就是一个用例。防止场景陷阱。,需求获取技术面向用例的场景分析,快速原型技术的基本思想是：在系统开发时期就让用户尽早地接触系统，对系统原型进行评估，指出不足之处并提出修改意见。分析员和开发人员按照用户的需求修改原型或重新开发原型，最终得到满足用户需求的软件系统。,需求获取技术快速原型技术,快速原型法有两种不同类型：抛弃型原型法和演化型原型法。演化型原型法：构造一个功能简单但满足一定质量的系统原型，通常这个原型是最终系统的核心部分，然后通过不断地增加功能，修改原型中存在的不足，最后得到符合用户需求的、高质量的软件系统。,需求获取技术快速原型技术,快速原型法有两种不同类型：抛弃型原型法和演化型原型法。抛弃型原型法：构造一个功能简单且质量要求不高的系统原型，针对这个原型，用户和设计人员提出意见、不足和错误，形成新的需求和设计方案。据此不用原有模型而重新设计更加完整、准确、一致、可靠的软件原型。如此往复迭代，最终得到符合用户需求的、高质量的软件系统,需求获取技术快速原型技术,结构化分析的核心是数据。数据包括在分析、设计和实现中涉及的概念、术语、属性等所有内容，并把这些内容定义在数据字典中。围绕数据字典，完成功能模型、数据模型和行为模型的结构化建模过程。,结构化分析概述,主要描述数据建模过程，刻画系统的静态状态，它包括实体的属性和属性间的关系,完成对功能、操作流程的抽象和分解，完成功能建模。通过将复杂问题自顶向下逐层分解，把操作流程由物理过程抽象为逻辑过程，完成对问题的分解和抽象，最终解决问题,是系统的行为建模，通过外部事件的触发，导致系统采取相应操作,数据建模需要回答以下几个问题：系统中有哪些数据对象？数据对象具有哪些属性？数据对象间有什么关系？数据对象分别处于系统的哪些功能或流程中？在面向对象建模中，从数据对象里能抽象出更高层次的对象吗？或者数据对象能组合吗？在面向对象建模中，从数据对象里能细化出更具体的数据吗？或者数据对象能分解吗？,面向数据的数据建模,实体关系模型（ER）是结构化建模的可视化图形工具，它描述数据对象（实体）、对象属性和对象间关系。,面向数据的数据建模,软件系统中涉及的概念、术语、属性，或需求描述中的名词、主谓结构短语都能作为候选数据对象。如外部实体（电子简历文件）、事件（生成各部门视图）、事物（简历检索结果）、角色（各部门的不同用户）、组织单位（企业内部）、结构（简历库）等对象。这些对象分别用一组属性来定义。在结构化数据建模中，数据对象是属性的集合。而在面向对象建模中，数据对象是属性和行为的集合，更体现了对象是动静相结合的有机体。,面向数据的数据建模数据对象,属性是对象的静态特征，通常是系统需求描述中的名词。在ER模型的模型元素中，用矩形表示实体、圆矩形表示属性、并用无向边将对象与属性相连接。,面向数据的数据建模属性,关系表明了数据对象间的关联关系。基数则表明数据对象在关系上的数量约束。关系用菱形表示，它通常是一个动词或动宾短语。三种基数关系（1：1，1：N，M：N）。关系也可以具有属性。,面向数据的数据建模关系和基数,面向数据的数据建模实例,用户,简历,部门,工号*,姓名*,所属部门编号*,权限*,参加工作时间*,专业*,特长,编号*,姓名*,性别*,年龄*,专业*,手机,特长,编号*,名称*,职责*,隶属*,管理,隶属,N,1,查看,M,N,数据流图（DFD）是结构化建模中最流行的功能建模工具，描述从数据输入、数据转换到数据输出的全过程。能对DFD图分层，分层的DFD更进一步刻画了系统的功能分解。,面向数据的功能建模,面向数据的功能建模,面向数据的功能建模-DFD图基本图形符号,面向数据的功能建模-DFD图基本图形符号,如果数据加工中不同的数据流同时“流”向一个数据加工，或当数据加工间同时输出多条数据流时，需要用下图所示的图例来定义语义信息更明确的DFD图。,面向数据的功能建模-DFD图基本图形符号,面向数据的功能建模,DFD图可以用来表示任何抽象级别的系统功能，随着系统功能和信息的逐渐增加，DFD图通过分解来逐层细化用户需求。分解步骤如下：确定系统的外部信息源、数据源或与外部系统的接口。画出顶层（0层）DFD图。第一次精化：划分系统的子系统。逐层求精：对各子系统进一步精化。,面向数据的功能建模实例,简历信息自动获取和查询系统数据源：企业各部门用户；数据终点：企业各部门用户（简历查询结果的显示）主要数据流：简历、查询信息；数据存储：原始简历库、简历库；主要处理过程：简历的自动获取、简历查询；,面向数据的功能建模实例,0层DFD图,部门用户,简历自动获取和查询系统,部门用户,F1原始简历库,F2简历库,简历文件,简历,查询信息,登录信息,简历,面向数据的功能建模实例,第一步求精：1层DFD图,部门用户,部门用户,F1原始简历库,F2简历库,简历文件,简历,查询信息,登录信息,简历,1登录,F3用户信息库,权限,2自动获取简历信息,权限,3查询,查询信息,简历,面向数据的功能建模实例,逐步求精：对各系统进一步精化,F1原始简历库,F2简历库,简历文件,2.1电子收集电子简历,2.2读取电子简历,权限,2.3分析关键词,简历,简历文件,简历文件,2.4自动获取简历信息,关键词,面向数据的功能建模实例,逐步求精：对各系统进一步精化,F2简历库,3.1分析查询信息,3.2查询,查询信息,3.3生成查询结果,简历,关键词权限,关键词,简历,面向数据的功能建模RDF图注意事项,对DFD图中各部分元素的命名切忌用空洞的名词，这样不仅会给系统设计带来歧义，而且难以确定数据的结构和组织方式。命名时应遵循以下原则：,面向数据的功能建模RDF图注意事项,用名词或名词短语，避免使用空洞、无意义的词汇；尽量使用需求描述中的已有词和领域术语；命名出现困难时，考虑是否是数据流划分是否正确，并重获需求；顶层DFD图中的加工名就是软件项目的名字；分层DFD图中，数据存储一般局限在某一层或少数几层中。,面向数据的功能建模RDF图注意事项,逐层细化DFD图时，还要注意以下几点：父图和子图的平衡关系：父子图（上下层图）中的输入、输出必须保持一致，不能随意修改数据流。DFD图的编号：按层次进行，体现对系统加工过程中自顶向下的分解。平衡规则：所有子图中涉及的外部环境，需要与顶层图的外部环境保持一致。,面向状态的行为建模,状态转换图（StatusTransitionDiagram，STD）通过描述系统状态及引起状态转换的事件来表示系统行为。STD图同时也反映了事件执行的行为。STD图主要由状态、转换和事件的图形符号构成。,面向状态的行为建模,状态是可观察到的行为，是同一数据对象在系统的不同运行时刻所具有的行为属性值，是事件触发后一系列动作的结果。,面向状态的行为建模,由一个状态转换到另一个状态的关联就是状态转换，它表明状态变换是有序变换过程，用有向箭头表示。状态变换是由事件或条件触发的，因而箭头上应说明事件名称或触发条件。如果状态间转换没有事件触发，则前一状态结束信息就是转换到下一状态的触发条件。,面向状态的行为建模,事件是指在某一时刻发生的事情，是触发状态转换的条件或一系列动作。在中间状态的符号中，活动即是事件。STD图定义了3个标准事件，它们都没有参数：entry事件：用于说明转换到该状态的特定动作；exit事件：用于说明触发该状态的特定动作；do事件：用于说明处于当前状态时执行的动作。,面向状态的行为建模案例,检索Do：连接简历库,验证用户Do：连接用户信息库验证,查询输入Do：要求事物,主窗口Do：要求事物,主窗口Do：要求事物,等待用户登录,关键词,检索成功,显示查询数据,检索失败,显示无效信息,数据字典DD（DataDictionary）,数据字典以结构化方式定义了在数据建模、功能建模和行为建模过程中涉及到的所有数据信息、控制信息。DD的定义形式多种多样：词条描述、定义式和Warnier图的定义方式。,数据字典DD（DataDictionary）,定义式（BF范式）-适用于定义的数据或控制信息具有良好的数据结构的情况。,数据字典DD（DataDictionary）-案例,简历信息自动获取和查询系统,简历=编号+姓名+性别+年龄+专业+手机号码+特长用户=工号+姓名+所属部门编号+权限+参加工作时间+专业+特长+简历部门=编号+姓名+职责+隶属+管理姓名=2汉字字符8注：姓名最多为8个汉字性别=男|女年龄=18.120专业=2汉字字符20手机=13|5|89数字9特长=2字符1024权限=0|1|2工号=1|2|3|4|5|6|7|8|97数字7编号=2数字3关键词=1姓名|性别|年龄|专业|爱好N,数据字典DD（DataDictionary）,词条描述详细说明了数据和控制信息在系统内的传播途径。它分为数据流词条、数据元素词条、加工词条和存储文件词条等内容的定义。P50图2-21,数据字典DD（DataDictionary）-实例,简历信息自动获取和查询系统,名字：原始简历库别名：简历文件数据库描述：保存原始的电子简历文件定义：电子文件格式=pdf+doc+wps+txt+html,名字：简历库别名：简历信息数据库描述：保存从原始简历文件中提取的信息定义：简历=姓名+性别+年龄+专业+手机号码+特长,数据字典DD（DataDictionary）,Warnier图，是描述信息层次结构的一种工具。类似于一种结构式语言，它用到下列三种符号:顺序执行选择执行循环执行,数据字典DD（DataDictionary）,用Warnier图形工具描述的超市收银员一天的工作流程。,上班刷卡,收银业务,结算,下班刷卡,初始化单笔业务,结束单笔业务,n,清点货物,收款,取一件商品,扫描商品信息,m,银行卡,现金,加工逻辑,加工逻辑也称为过程说明，用于描述DFD加工部分的流程或算法。加工逻辑的形式主要有“过程描述语言”、“判定树”、和“判定表”等。过程描述语言（PDL）也称为伪代码语言（PL），它是一种介于自然语言和形式化语言之间的结构化语言。,加工逻辑,顺序结构选择结构if条件表达式thenBLOCKif条件表达式thenBLOCK1elseBLOCK2Select表达式case值1：BLOCK1；case值2：BLOCK2；case值NBlockN；endselect,加工逻辑,循环结构while（条件表达式）BLOCK;DoBLOCK;while(条件表达式)；RepeatBLOCK;until(条件表达式);程序注释。用符号“/”或“/*/表示对程序语句的注释P52图2-25,需求评审,在需求工程完成之前，必须编写软件需求规格说明和数据规格说明，形成初步的用户手册，并按照评审标准对软件需求过程和规格说明进行评审，目的是发现并消除其中存在的遗漏、错误和不足，使得规格说明符合标注及规范的要求。通过了评审的软件需求规格说明和数据规格说明将成为基线配置项，并纳入需求管理过程。主要包括：软件需求规格说明和软件数据需求说明等文档。