《软件工程》第6课-需求工程与需求分析1

单击此处编辑母版标题样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,第,6,课,需求工程与,需求分析,-1,知识回顾,UML,简介,静态建模,用例图与用例模型,类图和对象图、包,动态建模,消息、状态图,时序图和协作图,活动图,物理架构建模,前馈及作业总结,只有个别组对付。,有个别人还是没有提出问题。,插班重修的要跟组长及时联系，提交前馈和作业。,前馈检查,软件需求的,3,个层次？,软件需求的,6,个特性？,需求分析的步骤？,结构化需求模型组成？,面向对象需求模型组成？,面向对象需求建模的步骤？,用例规约文档的主要内容？,讲授内容,软件需求工程,软件需求的定义,、,软件需求的特性,。,需求分析与建模,需求分析的步骤,、,迭代过程,。,需求获取的常用方法,常规的需求获取方法,、,快速原型获取需求,。,需求模型,需求模型概述,。,面向对象的需求建模,。,1.,软件需求工程,软件需求的定义,一个软件系统必须遵循的条件或具备的能力。,系统的外部行为：用户解决问题或达到目标所需的条件和能力。,系统的内部特性：为了满足合同、规范或其他规定文档所需具有的条件或能力。,软件需求三个层次,业务需求,：客户或市场对软件的高层次目标要求。,用户需求,：从用户使用角度描述软件产品必须完成的任务。,功能需求,：软件开发人员必须实现的软件功能。,软件需求的层次关系,业务需求,项目愿景与范围,用户需求,质量属性,用例模型文档,功能需求,非功能需求和约束条件,软件需求规格说明,软件需求的特性,功能性,：最重要。普通功能和全局性功能。,可用性,：指最终用户方便使用软件。,可靠性,正常运行率、平均无故障时间（,MTTF,）、平均修改时间（,MTTR,）、精确度、最高错误或缺陷率（每千行代码的错误数目）。,性能：响应时间、容量、吞吐量等。,可支持性：编码标准、命名约定、类库及工具等。,设计约束,需求工程的由来,代码编写,-,生存周期,-,需求工程（,RE,）,软件需求工程,是一门应用有效的技术和方法，合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科。,软件需求工程是一门分析、记录并维护软件需求的学科。,2.,需求分析与建模,需求分析的步骤,需求分析是迭代过程,需求获取,需求建模,规格说明,需求验证,3.,需求获取的常用方法,常规的需求获取方法,联合分析小组,用户代表、领域专家和系统分析员。,“,便利的应用规约技术,”,，,FAST,。,用户访谈,充分准备，寻找共同语言。,必须对问题的背景和系统环境有全面了解。,了解将要进行交谈的用户的个性特点及任务状况。,事先准备提问的问题。,循序渐进、逐步逼近。,问题分析与确认,多个来回，每次要及时整理。,3.,需求获取的常用方法,用快速原型法获取需求,利用各种分析技术和方法，生成一个简化的需求规格说明；,对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；,在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；,将原型提交给用户评估并征求用户的修改意见；,重复上述过程，直到原型得到用户的认可。,第四代开发技术（,4GT,）是快速原型法常用的技术。,课堂互动,如何进行需求验证？,除了书上讲的，还有什么好的方法获取需求？,4.,需求模型,建立分析模型是需求分析的首要任务。,需求模型概述,结构化需求模型,包括数据流和加工规格说明的,功能模型,。,由数据字典和,E-R,图组成的,数据模型,。,由状态转换图、控制流图和控制规格说明等组成的行为模型。,面向对象需求模型,用例模型,。,用例图和用例规约。,补充规约。,术语表。,结构化需求模型,数据字典,数据流图,判定树,判定表,PDL,加工说明,数据定义,.,E-R,图,行为模型,状态转换图,控制流图,和,控制说明,功能模型,数据模型,面向对象需求模型,用例规约,参与者,用例图,用例模型,补充规约,术语表,全局性功能、非功能需求,面向对象的需求建模,-,用例图,确定参与者,存在于系统外部、与系统交互的人、硬件、其他系统。,通过回答问题确定参与者,系统开发完成之后，有哪些人会使用这个系统？,系统需要从哪些人或其他系统中获得数据？,系统会为哪些人或其他系统提供数据？,系统会与哪些其他系统相关联？,系统是由谁来维护和管理的？,面向对象的需求建模,-,用例图,确定用例,考察每个参与者与系统的交互和需要系统提供的服务。,通过回答问题确定用例,参与者为什么要使用该系统？,参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？,参与者是否会将外部的某些事件通知给该系统？,系统是否会将内部的某些事件通知该参与者？,面向对象的需求建模,-,用例图,绘制和检查用例图,按,UML,标准画用例图,检查用例图,每个用例至少应该涉及一个参与者。,参与者和用例名称是否符合统一的命名约定和风格。,用例建模通常属于团队开发。,用例建模示例,选课系统问题陈述,开发一个学生选课系统。通过这个系统，学生可以选课和查看成绩报告单，教授可以选择所教的课和记录学生的成绩。学校保留原有的,“,课程目录,”,数据库系统来维护课程信息，但该系统的性能是有限的。所以新系统必须确保能及时访问旧系统上的数据。但新系统只能读取旧系统的课程信息，不能更新。每学期开始时，学生请求查看本学期开设的课程目录。有关课程的信息，包括教授名和所开设的系等，将帮助学生做出决定。系统允许学生每学期选择,4,门课，如果学生没有选到主要的课程，还有两门备选课程可选。每门课的学生人数限,3,到,10,人。不满,3,人的课程将被取消。另外，每个学期有一段时间让学生更改课程表。学生可在该时段内访问系统并添加,/,删除课程。某个学生的选课一旦结束，选课系统即将此学生本学期的账单信息送到财务系统。如果在选课时某门课已经人满，学生在提交信息前必须被告知。学期结束，学生可进入系统查看自己的成绩。成绩属于隐秘信息，系统必须提供额外的安全措施阻止未授权的访问。教授必须能访问系统查询他们主讲课程。他们也需要知道是哪些学生选择了自己的课程。另外，教授也能登记学生的成绩。,用例建模示例,确定参与者,确定用例,学生要注册课程；,教授要选择课程来教；,注册管理人员要维护关于教授和学生的所有信息；,财务系统要从注册系统获得学生的费用情况；,课程目录系统维护课程信息。,无论是学生，教授还是注册员都需要登陆到系统；,学生需要使用系统来选课，也能查看自己的成绩；,教授需要使用系统来选择课程，也能记录学生的成绩；,注册员必须维护学生、教授的所有信息，并在适当时候关闭注册系统；,当选择课程的过程完成后，收费系统必须获得收费信息；,学生和教授选择课程，需要启动课程目录系统。,用例建模示例,选课系统用例图,面向对象的需求建模,-,用例规约,用例规约用来描述每一个用例的功用。主要内容包括：,简要说明：作用和目的。,用文本，也可用,UML,图来辅助说明。,事件流：包括基本流和备选流，所有可能的活动。,基本流最正常的场景。每个步骤需要数字编号；主要内容用一句简短标题来概括；详细描述参与者与系统之间的交互。,备选流描述异常或偶尔发生的情况。,起点；条件；动作；恢复。,特殊需求：非功能需求和设计约束。,前置条件和后置条件：系统执行之前的状态和执行完毕后处于的状态。,用例建模示例,选课用例规约,1,简要说明,本用例允许学生选本学期提供的课程。在学期开始的添加,/,删除时期，学生可以修改或删除选择的课程。课程目录系统提供了当前学期开设的所有课程的列表。,2,事件流,2.1,基本事件流,用例开始于学生选择选课，或修改已存在的课程表。,1,）系统要求学生指出要执行的操作（创建，修改或删除课程表）,2,）一旦学生提供了所需要的信息，以下的一条子事件流将被执行,如果选择的是,“,创建课程表,”,，创建课程表子事件流将被执行,如果选择的是,“,修改课程表,”,，修改课程表子事件流将被执行,如果选择的是,“,删除课程表,”,，删除课程表子事件流将被执行,2.2,备选事件流,。,3,特殊需求,无,4,前置条件,本用例开始前学生必须已经登录进系统。,5,后置条件,如果用例成功，学生的课程表被创建，修改，删除。否则系统状态不变。,面向对象的需求建模,-,用例规约,用例模型的检查,功能需求的完备性。,模型是否易于理解。,是否存在不一致性。,避免二义性语义。,面向对象的需求建模,-,描述补充规约,用于记录在用例模型中不易描述的系统需求。,选课系统的补充规约,1,目标,本文档的目的是定义选课系统的需求。本补充规约列出了不便于在用例模型的用例中获取的系统需求。它和用例模型一起记录关于系统的一整套需求。,2,范围,本补充规约适用于选课系统，除定义了在许多用例中所共有的功能性需求以外，还定义了系统的非功能性需求，例如：可靠性、可用性、性能和可支持性等。（功能性需求在用例规约中定义。）,3,参考,无,4,功能,多个用户必须能同时执行操作。,如果某个学生所建的课程表中包含人数已满的课程，必须通知这位学生。,5,可行性,桌面用户界面应与,Windows 98/2000/XP,兼容。,6,可靠性,选课系统在每周,7,天，每天,24,小时内都应是可用的。宕机的时间应少于,10%,。,7,性能,。,面向对象的需求建模,-,术语表示,选课系统的术语表,1.,简介,这份文档是用来对一些术语进行定义的，同时将用例说明或其他文档中读者不太熟悉的术语进行解释性的描述。通常来说，这份文档对一些数据信息进行一些定义，从而使得用例规约和其他的文档显得简洁易懂。,2.,定义,这份术语表包含了选课系统中核心概念的定义。,课程：大学提供的某一门课。,开设课程：某一课程的具体安排情况，包括一周上课的天数、时间和教授。,课程目录：大学所开设的所有课程的完整目录。,教员：所有在此大学内任教的教授。,财务系统：用来处理收费信息的系统。,成绩：学生某门课程的成绩。,。,面向对象的需求建模,-,调整用例模型,用例之间是否相互独立？,多个用例之间是否有非常相似的行为或事件流？,用例事件流的一部分是否已被构建为另一个用例？包含,是否应该将一个用例的事件流插入另一个用例的事件流中？扩展,课堂互动,如何简洁而正确的确定用例？,小结,需求分析由需求获取、需求建模、规格说明和需求验证四个步骤组成。,建立需求模型是需求分析的核心，它通过各种图形及符号，可视化地从各个侧面描述系统需求。,需求规格说明书以各方共同认可的文档形式表述出来，是软件设计、系统验收的可靠依据。,面向对象的用例模型，由用例模型、补充规约和术语表一起组成。,随着人们对需求重要性的认识逐渐深入，软件需求管理应运而生。,课外任务,作业,P137,：习题,2,、习题,5,。,从教学群下载“,软件工程,课程学案,.doc,”文件完成,第,7,次课,学案内容并填写“,软件工程,课程前馈表”于本周六,17:00,前由各组组长收集（每组集成到一个文件中）通过,QQ,群及时反馈。,问题解答,如果还没有完善的软件系统，应该怎样进行需求的验证工作呢？荣婉如,建立用例模型时，在确定用例时应注意些什么问题？黄菲菲,会不会有某些用户所提出的条件，软件需求理论上可以完成，但却很难实现，请举个例子说明一下。党伟,参与者是人可以理解，参与者也可以是系统或者硬件设备这要怎么理解呢？李娜娜,怎样解释特殊需求？童磊,这节是常规需求获取方法，我认为面对面，建立小组是最有效的办法了，那不常规的有哪些？哪些有效吗？周洁莹,这种建模易于被用户理解，这种建模对程序设计人员来说