第2章需求工程.ppt
- 文档编号:8786186
- 上传时间:2023-05-15
- 格式:PPT
- 页数:41
- 大小:181KB
第2章需求工程.ppt
《第2章需求工程.ppt》由会员分享,可在线阅读,更多相关《第2章需求工程.ppt(41页珍藏版)》请在冰点文库上搜索。
西安交通大学刘海岩,1,第2章需求工程,领域分析需求获取需求分析与建模需求规约与验证需求管理,西安交通大学刘海岩,2,2.1领域分析,1、领域分析的概念软件工程要处理两类工程:
(1)面向用户的业务过程工程
(2)面向市场的产品工程(见下图)领域(domain),就是指解决问题的范围,从最高层的角度(业务域)描述系统。
系统分析可以发生在许多不同的抽象层次:
在业务或企业级层次,可定义描述模拟整个业务的功能、结构和行为的模型;在应用层次,建模着重于特定的用户需求。
西安交通大学刘海岩,3,企业,业务域,业务域,信息系统,过程需求,信息战略计划(全局视图),业务域分析(领域视图),系统分析与设计建模,构造与集成,业务过程工程层次,西安交通大学刘海岩,4,完整产品,软件,能力,功能,过程需求,产品需求(全局视图),构件工程(领域视图),分析与设计建模,构造与集成,产品工程层次,数据,行为,硬件,西安交通大学刘海岩,5,Firesmith对软件领域分析的定义是:
领域分析指特定应用领域中公共需求的标识、分析和规约,即发现或创建那些可广泛应用的对象,其目的使它们在应用域中多个项目间能被复用。
领域分析的角色是设计和建造可复用构件(类似于制造环境中工具制造者的角色),它们被很多相似但不一定是相同的应用开发的人所使用。
Lethbridge的定义是:
领域分析是软件工程师了解背景信息的过程。
为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策,软件工程师必须了解使用该类软件的一般性商业和技术领域中足够的信息。
西安交通大学刘海岩,6,2、领域分析过程的活动
(1)定义被调查的领域中感兴趣的项从业务域、系统类型或产品范畴中分离出感兴趣的“项”。
感兴趣的项包括:
现存的应用软件的规约、设计和代码,支持软件(如GUI或数据库访问构件)以及和领域相关的构件库以及测试案例。
(2)对从领域中抽取出来的项进行分类并建立分类层次。
西安交通大学刘海岩,7,(3)收集领域中应用系统的代表性样本。
(4)分析样本中的每个应用标识候选的每个可复用对象。
指明对象被标识为可复用的理由。
定义对象的适应性。
估算在领域中复用这些对象的应用的百分率。
使用配置管理技术控制这些对象。
(5)为对象开发分析模型。
西安交通大学刘海岩,8,3、领域分析的价值领域分析除了为软件复用奠定基础外,还为较低抽象层次的一般的系统分析带来如下好处:
快速开发。
有助于集中精力关注最重要的问题,更有效地与相关人员进行交流,可以更快的确定需求。
优化系统。
了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。
会少犯错误,知道应该遵循那些规程和标准。
领域分析给出一个应用领域的总体视图,会引导出更好的抽象从而改进设计。
有了领域知识,就可以洞察新兴趋势及进一步开发的机会,有助于创建适应性更强的系统。
了解通用性和特殊性,有助于创建出具有更好的可重用性和更宽的销售市场的软件。
西安交通大学刘海岩,9,专家提出,没有坚实的领域分析,任何重大的软件项目都不应该进行。
对应用领域的深入理解能极大的提高成功的几率。
许多非常成功的软件产品的开发人员以前都在业务领域工作过段时间,对实际需要有着深切的感受。
一旦对领域有了真正的理解,就可进行某一个项目(或产品)的需求分析,包括定义待解决的问题以及开发什么软件来解决它。
然而,领域分析永远也不应该结束:
开发人员有责任在开发过程中不断增进他们的理解,后续版本的系统扩充通常需要对子领域进行进一步的领域分析。
西安交通大学刘海岩,10,2.2需求获取,1、需求(requirements)的概念
(1)需求的定义Jones定义为用户所需要的软件必须达到的目标和能力。
Lethbridge定义为需求是关于系统将要完成什么工作的一段描述,它们必须经过所有相关人员的认可,其目的是彻底的解决用户的问题。
需求是一段描述:
意思是每个需求是相对短小简明的一段信息,表现为一个事实。
它可以是一段话或用各种图表示。
一组需求的集合成为需求文档。
关于系统将要完成什么工作:
需求描述了系统应当完成的任务,不描述系统将如何实现。
必须经过所有相关人员的认可:
意指需求必须经过评审,才能成为正式的需求。
其目的是彻底的解决用户的问题。
有助于解决用户的问题,该需求才有存在的价值。
西安交通大学刘海岩,11,业务需求,项目范围文档,用户需求,用例文档,功能需求,质量属性,其他非功能需求,设计约束,需求规约,非功能需求,系统需求,需求组成的全景图,
(2)需求的组成,对系统、产品高层次的目标要求。
用户使用产品必须要完成的任务,西安交通大学刘海岩,12,其中:
业务需求:
反映组织机构和客户对系统、产品高层次的目标要求。
用户需求:
从用户使用的角度给出需求的描述。
如一个小型超市需要一个商品的查询系统。
业务需求:
进货人员需要查询商品库存以便保证及时进货;收款员需要查询商品的销售价格以便结账;经理需要查询商品的销售及盈利情况。
用户需求:
这三类用户怎样去查询系统,查询哪些信息,还需要哪些操作。
西安交通大学刘海岩,13,系统需求:
从系统或技术的角度描述为实现业务需求和用户需求而提供的服务以及所受到的约束。
功能性需求:
描述系统应该做什么,即为用户和其它系统完成的功能。
非功能性需求:
产品必须具备的属性或品质。
设计约束:
设计与实现必须遵循的标准、约束条件。
如运行平台、协议、选择的技术、编程语言和工具等。
(3)需求的描述自然语言、结构化语言、PDL图形化表示(使用RationalRose、MicrosoftVisio、EnterpriseArchitect等工具)数学描述(形式化语言描述),西安交通大学刘海岩,14,2、需求工程过程,需求工程是一个包括创建和维持系统需求文档所必需的一切活动的过程。
它包含了如下活动:
系统可行性研究、需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理(管理需求工程的变更)。
可行性研究,需求获取和分析,需求描述,需求有效性验证,可行性研究报告,系统模型,用户需求和系统需求,需求规约,需求工程过程,需求管理,西安交通大学刘海岩,15,可行性研究是需求工程过程的开始。
在较短的时间内作出结论。
集中回答以下问题:
(1)系统是否符合组织机构的总体目标。
系统不支持这些目标,就没有价值。
(2)系统是否可能在现有的技术条件、预算和时间限制内完成。
(3)系统能否与已经存在的系统集成。
该活动要广泛收集信息并评估,回答一些有关的问题,写出研究报告,得出结论:
系统是否值得开发?
给出具体的意见和建议。
可能对系统高层需求、功能范围、预算和时间安排提出修改意见。
西安交通大学刘海岩,16,需求获取与需求分析的区别需求获取是开发人员与客户或用户一起对应用领域进行调查研究,收集系统需求的过程。
需求分析是将获取到的需求准确的理解、求精,并将其转化为完整的需求定义(包括建模),进而生成需求规约的过程。
需求获取和分析的难度项目相关人员通常并不真正知道希望计算机做什么,让他们清晰的表达出需要系统做什么是件困难的事,他们或许提出不切实际的要求。
西安交通大学刘海岩,17,项目相关人员用自己的语言表达需求,这些语言包含很多工作中的专业术语和专业知识。
系统分析员没有这些知识和经验,而他们又必须了解这些需求。
不同的项目相关人员有不同的需求,可能以不同的方式表达,分析人员必须发现所有潜在的需求资源,而且能发现这些需求的相容或冲突之处。
经济和业务环境决定了分析是动态的,需求在分析过程中会发生变更。
个别需求的重要程度会改变,新的需求会从新的项目相关人员那里得到。
西安交通大学刘海岩,18,需求获取技术,建立由客户(用户)、系统分析员、领域专家参加的联合小组。
需求获取的方法:
个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。
获取的需求的表达方式:
(1)需求列表需求与系统的特殊视角或环境的关系
(2)业务流程图(状态/活动图)(3)用例(Use-Case)/场景(Scenario)/用户故事(userstory)/视点(viewpoint)的描述(4)数据流图(5)实体关系图(6)用例图、类图、活动图、时序图、状态图等。
西安交通大学刘海岩,19,视点可以理解为:
1、数据源或数据池(SA、SD方法)2、一个表示框架(系统模型)3、服务的接收者(系统的外部成分)特别适用于交互式系统的需求导出。
用例Jacobson说“用例帮助定义系统之外存在什么(参与者)以及系统应该完成什么”。
把系统分成一组逻辑的、互相联系较少的部分,每一部分都描述了系统与外部角色交互所提供的服务,即用例的集合代表了所有将会在系统需求中出现的交互。
因此容易从使用的角度理解系统应达到的功能。
而“用户故事”是某种形式的简化版用例。
场景场景是用例的具体描述。
一个用例封装了一组场景,每个场景就是一个单个线程。
西安交通大学刘海岩,20,例1:
列出图书馆系统与以下参与者(角色)交互的最小用例集:
借阅者、借书员、图书管理员、会计系统。
借阅者:
按题目查询书籍按作者查询书籍按主题查询书籍预定已被其他人借出的书籍查询借阅者的个人信息并列出借阅的书籍,西安交通大学刘海岩,21,借书员:
所有借阅者的用例,再加上为借阅者查找某一书籍登记已归还的书籍续借一本书登记缴纳的罚款添加新的借阅者更新借阅者的个人信息(地址、电话号码等)图书管理员:
所有借阅者和借书员的用例,再加上添加藏书删除藏书改变系统中对已有书籍的记录信息会计系统(独立运行)获得借阅者支付的超期罚款,西安交通大学刘海岩,22,例2:
一个SafeHome系统,系统激活的基本用例用自然语言陈述如下:
(参考教材1)房主观察控制面板以确定是否系统已准备好接收输入。
如果系统未准备好,房主必须物理地关闭门/窗户,以便使“准备好”指示灯亮。
房主使用键盘输入4位密码,系统将密码与存储在配置库中的有效密码比较,如果密码不正确,控制面板鸣叫一次并复位等待再次输入。
如果密码正确,控制面板等待进一步的动作。
房主选择键入“stay”(仅激活外部的传感器)或“away”(激活所有的传感器)以启动系统。
当激活时,房主可观察到一个红色指示灯。
西安交通大学刘海岩,23,用例:
房主激活监测场景:
1、房主:
观察控制面板。
2、房主:
输入密码。
3、房主:
选择“stay”或“away”。
4、房主:
观察红色指示灯显示系统已被打开。
异常:
1、控制面板未就绪。
2、密码不正确。
3、密码不识别。
未解决的问题:
1、是否有不使用密码激活系统的方式。
2、控制面板是否还应显示附加的文字信息。
3、房主输入密码的时间有无约束。
4、在系统真正激活之前有无办法关闭系统。
西安交通大学刘海岩,24,2.3需求分析与建模,需求分析是发现、规约和求精的过程,指开发人员准确的理解用户的需求,通过分析,将不规范的需求陈述转化为完整的需求定义,并产生需求规格化说明的过程。
获取的需求可能有模糊的、冗余的、有冲突的或不易理解的地方,需要用文字和图形描述不同视图以揭示更深的、易混淆的问题,确保与所有风险承担者达成共识。
西安交通大学刘海岩,25,需求分析活动具有以下任务:
(1)分析需求的可行性:
允许的成本、性能;与其他需求的冲突;外界因素的依赖和技术障碍等。
(2)对于渐增式开发要确定需求的优先级别,以便确立产品版本。
(3)建模:
模型能突出或强调某些关键的系统特征。
使用文本和图表形式的组合,以相对容易理解和能直接评审正确性、完整性和一致性的方式来描述数据(信息)、功能和行为的需求。
图形化的表示分析模型可以增强对软件需求的理解,也为软件设计奠定了基础。
(4)生成需求规格说明。
西安交通大学刘海岩,26,在过去的数年中,人们提出了许多种分析建模的方法,其中两种在分析建模领域占有主导地位:
第一种是结构化分析(StructuredAnalysis,SA),70年代末由DeMarco等人提出,这是传统的建模方法。
该方法不是被所有的使用者一致地使用的单一方法,众多科学家对其进行了扩充,因此它是发展了超过30年的一个混合物。
另一种方法是面向对象的分析,如Coad-Yourdon方法、Booch方法、Rumbaugh方法、Jacobson方法等。
具体的建模方法有:
西安交通大学刘海岩,27,上下文模型(ERD、包图)面向流的建模:
数据流图(DFD/CFD)数据建模:
实体关系图(ERD)基于场景的建模:
用例图、顺序图、活动图基于类的建模:
类图、包基于行为的建模:
Petri网、状态图、顺序图、协作图、活动图,西安交通大学刘海岩,28,Sommerville认为模型可以从以下角度去描述:
1、从外部看,它是对系统上下文或系统环境建模。
(见下页图)2、从行为上看,它是对系统运行行为建模。
3、从结构上看,它是对系统体系结构和系统数据的结构建模。
有如下系统模型的实例(ppt30):
西安交通大学刘海岩,29,上下文模型(定义了系统的边界),西安交通大学刘海岩,30,1、数据处理模型如数据流图,说明系统的不同阶段数据如何被处理。
2、组成模型实体关系图,说明一个实体与另外实体间的关系或如何由其他实体组成。
3、体系结构模型说明构成整个系统的那些主要的子系统。
4、分类模型如对象模型,说明对象间怎样具有共同特性。
5、激励-响应模型说明系统对来自内部和外部的事件的响应。
具体分析建模的方法请见第3章。
西安交通大学刘海岩,31,2.4需求规约与验证,1、软件需求规约(SoftwareRequirementsSpecification,SRS)SRS是需求分析阶段的产品,是所有其他开发和管理活动的基础。
对系统开发过程中其他活动的影响:
项目经理根据它制定或修改开发计划。
设计人员根据它进行系统设计。
测试人员根据它编写测试计划,设计测试用例。
产品发布人员根据它编写产品介绍和用户文档。
培训人员根据它编写培训教程。
西安交通大学刘海岩,32,需求规约的结构:
1998年的IEEE标准为需求规约提出了以下结构,组织机构内部可以基于此标准扩展:
(1)引言需求文档的目的、产品范围、文档约定(缩写词与缩略语)、参考文献、文档的其余部分概览
(2)综合描述产品前景、产品功能与优先级、用户特征、运行环境、设计与实现上的约束、假设和依赖性,西安交通大学刘海岩,33,(3)需求描述a.功能需求b.数据需求:
与功能有关的数据定义和数据关系c.性能需求:
响应时间、容量要求、用户数等d.外部接口:
用户界面、软硬件接口、通信接口e.设计约束:
软件支持环境、报表、数据命名等f.软件质量属性(可维护性、可靠性、可移植性、可用性、安全性等等)g.其他需求这一节是文档中最实质性的部分,由于在机构组织的实践中存在极大的变数,对这一节定义的标准结构可以进行增删。
(4)附录(词汇表、硬件与数据库的描述、模型、待定问题列表等)(5)索引,西安交通大学刘海岩,34,计算机软件文档编制规范(GB/T8567-2006)需求规格说明模版,1.范围1.1标识文件状态(草稿/正式发布/正在修改);文件标识;当前版本;作者1.2系统概述(名称、功能、性能、上下文关系、用户、开发者)1.3文档概述(类型、描述方法、预期读者)1.4基线2.引用文件3.需求概述3.1系统目标3.2运行环境3.3用户特点4.功能需求5.外部接口需求6.数据7.故障处理,西安交通大学刘海岩,35,2、需求验证需求验证的重要性:
如果在后续的开发或当系统投入使用时才发现需求规约中的错误,就会导致更大代价的返工。
由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。
假设需求阶段引入1个错误的需求,设计时对这个需求需要510条设计实现,1条设计需要510条程序,1条程序需要35种测试组合测试。
原始需求,正确的规格说明错误的规格说明,正确的设计错误的设计对错误需求的设计,正确的编码错误的编码对错误设计的编码对错误需求的编码,正确功能测试到的错误没有测试到的错误,一个错误的需求,纠正成本100元,10纠正成本1000元,10,5,西安交通大学刘海岩,36,对需求规约需执行以下类型的检查:
(1)有效性检查检查不同用户使用不同功能的有效性。
(2)一致性检查在文档中,需求不应该冲突。
(3)完备性检查需求文档应该包括所有用户想要的功能和约束。
(4)现实性检查检查保证能利用现有技术实现需求。
西安交通大学刘海岩,37,验证技术:
(1)需求评审:
由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。
正式会议要有严格的评审程序,要有会议记录,开发组根据缺陷建议修改需求说明并重审。
(2)利用原型检验系统是否符合用户的真正需要。
(3)对每个需求编写概念性的测试用例。
(4)编写用户手册。
用浅显易懂的语言描述用户可见的功能。
(5)自动的一致性分析。
可用CASE工具检验需求模型的一致性。
西安交通大学刘海岩,38,2.5需求管理,需求管理是对系统需求控制的过程。
完成需求规约并不代表需求工程过程的结束,不可避免的遇到需求的变更。
原因是:
大型系统拥有不同的用户群体,就有不同的需求和优先级。
互相有冲突或矛盾,需求规约所做出的某些平衡随着经验的积累可能要改变。
客户和最终用户的需求可能不一致。
业务和技术环境的变化引起需求的变化。
需求导出的同时启动了需求管理规划,一旦形成了需求文档的草稿,需求管理的活动就开始了。
西安交通大学刘海岩,39,1、需求管理规划,需求管理是标识、控制和跟踪需求的活动。
需要确定以下内容:
需求标识每个需求有一个唯一的标识符,以便可被其他需求交叉索引。
变更管理对变更带来的影响和成本进行评估。
跟踪策略定义需求之间的关系以及需求和设计之间的关系,并做出记录以及维护方法。
CASE工具支持管理中对大量信息的加工,如需求存储、变更管理、可跟踪性管理等。
西安交通大学刘海岩,40,需求和需求之间、需求和设计之间有许多关系。
在需求和引起该需求潜在的原因之间也有许多关系。
当变更发生时,必须追踪这些变更对其他需求和系统设计的影响。
需要维护的3类可跟踪性信息是:
源可追踪性信息连接到提出该需求的相关人员或基本原理。
需求可追踪性信息连接文档中彼此依赖的需求,用来评估一个变更会对多少需求产生影响以及引发的需求变更的范围和程度。
设计可追踪性信息连接需求到其实现的设计模块。
用来评估变更对设计与实现的影响。
可追踪性信息可用矩阵来表示。
西安交通大学刘海岩,41,2、需求变更管理,需求管理规划制定策略和程序,而需求变更管理负责分析变更以及评估变更带来的影响。
一个变更管理过程有3个基本阶段:
(1)问题分析和变更描述对识别出的需求问题或变更提议进行分析并检查它的有效性,以产生更明确的变更提议。
(2)变更分析和成本计算使用可追踪信息和系统需求的一般知识评估被提议的变更所产生的影响。
变更的成本计算不仅估计对需求文档的修改,在适当的时候还要估计设计和实现的成本,并产生对此变更是否执行的决策。
(3)变更实现需求规约以及系统设计和实现在必要时都要作修改。
建立一个好的需求文档的格式,使得变更不会带来大量文字的修改。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 工程