第2章-软件需求工程.ppt

上传人:聆听****声音 文档编号:10307360 上传时间:2023-05-25 格式:PPT 页数:73 大小:1.38MB
下载 相关 举报
第2章-软件需求工程.ppt_第1页
第1页 / 共73页
第2章-软件需求工程.ppt_第2页
第2页 / 共73页
第2章-软件需求工程.ppt_第3页
第3页 / 共73页
第2章-软件需求工程.ppt_第4页
第4页 / 共73页
第2章-软件需求工程.ppt_第5页
第5页 / 共73页
第2章-软件需求工程.ppt_第6页
第6页 / 共73页
第2章-软件需求工程.ppt_第7页
第7页 / 共73页
第2章-软件需求工程.ppt_第8页
第8页 / 共73页
第2章-软件需求工程.ppt_第9页
第9页 / 共73页
第2章-软件需求工程.ppt_第10页
第10页 / 共73页
第2章-软件需求工程.ppt_第11页
第11页 / 共73页
第2章-软件需求工程.ppt_第12页
第12页 / 共73页
第2章-软件需求工程.ppt_第13页
第13页 / 共73页
第2章-软件需求工程.ppt_第14页
第14页 / 共73页
第2章-软件需求工程.ppt_第15页
第15页 / 共73页
第2章-软件需求工程.ppt_第16页
第16页 / 共73页
第2章-软件需求工程.ppt_第17页
第17页 / 共73页
第2章-软件需求工程.ppt_第18页
第18页 / 共73页
第2章-软件需求工程.ppt_第19页
第19页 / 共73页
第2章-软件需求工程.ppt_第20页
第20页 / 共73页
亲,该文档总共73页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

第2章-软件需求工程.ppt

《第2章-软件需求工程.ppt》由会员分享,可在线阅读,更多相关《第2章-软件需求工程.ppt(73页珍藏版)》请在冰点文库上搜索。

第2章-软件需求工程.ppt

软件需求工程,2,第二章,高等教育出版社高等教育电子音像出版社,软件需求作为软件生存周期的第一个阶段,其重要性越来越突出,到20世纪80年代中期,逐步形成了软件工程的子领域需求工程。

20世纪90年代后,需求工程成为软件界研究的重点之一。

从1993年起,每两年举办一次需求工程国际研讨会(ISRE);1994年起,每两年举办一次需求工程国际会议(ICRE)。

一些关于需求工程的工作小组相继成立,使需求工程的研究得到了迅速进展。

2.1软件需求工程的基本概念,对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程需求工程。

1.什么是软件需求工程?

2.软件需求工程的任务是什么?

3.需求工程过程4.软件需求分析方法,软件需求的重要性,软件需求无疑是当前软件工程中的关键问题,没有需求就没有软件。

美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。

分析失败的原因发现,与需求过程相关的原因占了45%,而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因,各占13%和12%。

未完成,完成未实施,完成,软件需求的困难,软件需求是软件工程中最复杂的过程之一。

应用领域的广泛性,它的实施无疑与各个应用行业的特征密切相关。

非功能性需求建模技术的缺乏,及其与功能性需求有着错综复杂的联系,大大增加了需求工程的复杂性。

沟通上的困难,由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景,给需求工程的实施增加了人为的难度。

软件需求,软件需求的内容,一、软件需求内容,功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。

它与软件系统的类型、使用系统的用户等相关,有时需要详细描述系统的功能、输入/输出、异常等,有时还需要声明系统不应该做什么。

领域需求它是由软件系统的应用领域所决定的特有的功能需求,或是对功能的约束。

传统需求分析,在传统软件工程生存周期中,涉及需求的阶段称作需求分析。

一般来说,需求分析的作用是:

定义软件的范围及必须满足的约束;确定软件的功能和性能及与其他系统成分的接口;建立数据模型、功能模型和行为模型;最终提供需求规格说明,并用于作为评估软件质量的依据。

二、需求工程的活动,需求工程是系统工程和软件工程的一个交叉分支,涉及软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。

它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。

它也提供现实需求和软件能力之间的桥梁。

需求工程,需求工程的基本活动包括:

获取需求;深入实际,在充分理解用户需求的基础上,获取系统需求。

需求分析与建模:

进行需求建模、对模型或原型进行分析。

确认需求:

确保需求说明准确、完整地表达系统的主要特性。

进化需求:

客户的需要总是不断(连续)增长的,进化需求是必要的。

一、需求获取(requirementelicitation)是需求工程的主体。

缺乏领域知识,应用领域的问题常常是模糊的、不精确的;存在默认的知识,如难以描述的常识问题;存在多个知识源,且多个知识源之间可能有冲突;客户可能的偏见,如不能提供或不想告知你所需要了解的事情。

非常困难,主要原因有:

需求获取技术,需求获取的方法一般有:

1.面谈法重要而直接、简单的需求获取技术。

2.问卷调查法是对面谈法的补充。

3.需求专题讨论会最有力的需求获取技术。

有利于培养高效团队。

4.观察用户的工作流程适用于用户无法准确表达需求的情况。

5.原型化方法6.基于用例的方法,还有知识工程方法等,如:

场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。

面谈的对象主要有用户和领域专家:

1)面谈前的准备要充分;2)面谈后注意认真分析总结;3)注意掌握面谈的人际交流技能。

需求获取技术,需求获取的方法一般有:

1.面谈法重要而直接、简单的需求获取技术。

2.问卷法调查法是对面谈法的补充。

3.需求专题讨论会最有力的需求获取技术。

有利于培养高效团队。

4.观察用户的工作流程适用于用户无法准确表达需求的情况。

5.原型化方法6.基于用例的方法,是从多个用户中收集需求信息的有效方式,一般问卷设计形式:

1)多项选择问题;2)评分问题;3)排序问题。

需求获取技术,需求获取的方法一般有:

1.面谈法重要而直接、简单的需求获取技术。

2.问卷法调查法是对面谈法的补充。

3.需求专题讨论会最有力的需求获取技术,有利于培养高效团队。

4.观察用户的工作流程适用于用户无法准确表达需求的情况。

5.原型化方法6.基于用例的方法,由开发方和用户方共同召开需求主题沟通会,操作步骤:

开发方根据双方制定的需求调研计划确定会议内容;会后开发方整理出需求调研记录提交给用户方确认;如果此主题还有未明确的问题则再次沟通,否则开始下一主题;所有需求都沟通清楚后,开发方根据历次需求调研记录整理出用户需求说明书,提交给用户方确认签字。

因此系统应该具备以下功能:

基本数据维护功能基本业务功能数据库管理功能信息查询功能,例:

有一个大学图书管理系统,该系统除了一般的图书管理功能外,还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。

1.功能需求基本数据维护功能提供使用者录入、修改并维护基本数据的途径。

基本数据包括读者的信息、图书资料的相关信息,可以对这些信息进行修改,更新。

基本业务功能读者借、还书籍的登记管理功能,随时根据读者借、还书籍的情况更新数据库系统,如果书籍已经借出,可以进行预留操作以及书籍的编目、入库、更新等操作。

数据库管理功能对所有图书信息及读者信息进行统一管理维护的功能,对书籍的借还也要进行详细的登记,以便协调整个图书馆的运作。

信息查询功能提供对各类信息的查询功能,如对本图书馆的用户借书信息、还书的信息、书籍源信息、预留信息等进行查询,对其他图书馆的书籍、资料源信息的查询功能。

2.非功能需求系统安全性需求:

为保证系统安全性,对本图书馆的各项功能进行分级、分权限操作,对各类用户进行确认。

对其他图书馆借阅图书和文献资料服务控制访问范围:

如限IP、限用户等。

对系统可用性的需求:

为了方便使用者,要求对所有交互操作提供在线帮助功能。

对系统查询速度的需求:

要求系统在20s之内响应查询服务请求。

对系统可靠性的需求:

要求系统失败发生率小于1%。

3.领域需求例如:

对“大学图书管理系统”,提出一些与图书管理的业务相关的需求:

图书编目要求按照中国图书馆分类法进行;由于版权限制,某些文献资料只能在图书馆规定的阅览室阅读,并限制复制和打印。

第一条需求是遵循我国图书管理的规定,执行对图书的分类管理的标准。

而第二条需求则是版权法对图书馆文献资料的保护的需要,描述了对一类文献资料有限制的使用和服务。

二、需求分析与建模,需求分析和建模又包含三个层次的工作。

1.需求分析2.需求建模(分为企业建模、功能需求建模和非功能需求建模等)3.需求规格说明不同的描述方式,主要对收集到的需求进行提炼、分析和认真审查,确保所有参加人员取得共识。

找出错误、遗漏和不足,建立完整的分析模型。

需求分析常用技术,为了降低软件的复杂度,便于对问题的分析和理解,常采用以下技术:

1.分解将大问题分解为小问题,通常是自顶而下、不断细化的过程。

2.抽象抓住问题的本质特性,从不同抽象层次进行分析,提出解决问题的方案。

3.多视点注意从各类开发人员和不同用户的角度考虑问题,才能获得对系统的全面、完整的需求。

三、需求的有效性验证,

(一)需求验证的重要性.由于需求是软件开发的第一阶段,直接影响后面各阶段的开发。

.需求的可变性必须进行验证。

做什么,怎么做,三、需求的有效性验证,

(二)需求验证的内容1.有效性检查指功能需求是否符合用户所提出的需求。

2.一致性检查系统功能描述及约束是否一致。

3.完备性检查是否包含所有系统用户的需求和约束。

4.可检验性检查能否设计出一组验证方法,确定了检验的标准。

四、需求管理,需求管理贯穿需求分析全过程,包括:

记录所有需求的变化,四、需求管理,需求管理的所有活动中,最重要的是“需求变更管理”,包括:

问题分析和变更描述,变更分析和成本计算,变更实现,需求管理过程需要CASE(Computer-AidedSoftwareEngineering)工具支持。

1.传统的变化管理基本内容包括软件配置、软件基线(softbaseline)和变化审查。

软件基线是软件文档或源码(或其他产出物)的一个稳定版本,它是进一步开发的基础。

它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。

建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。

需求变更管理方法,2.新的管理方法软件家族法即软件产品线方法,该方法是源于工业界产品线的概念,关注于一个软件企业如何组织一组具有共性特征的,相似产品的生产,并应用软件复用的相关原理与技术。

多视点方法它用于管理不一致性,并进行关于变化的推理。

是从多个视点出发在软件工具的协助下对需求描述,进行自动需求建模,从而提高需求模型的完整性。

需求变更管理方法,具有一组可管理的公共特性的软件密集型系统的集合(也就是软件产品线是一个集合,这个集合中的元素都有一组可以管理的公共特性),这些系统满足特定的市场需求或者任务的需要,并且按预定义的方式从一个公共的核心资产集开发得到。

即这些产品的内部结构必须是有联系的,实际上是基于同样的基础机构,按照一定的约束,采用类似的措施进行建造的。

需求工程过程,2.2需求分析方法,功能分解方法将系统看作若干功能模块的集合,每个功能又可以分解为子功能,子功能还可继续分解,分解的结果即是系统的雏形。

存在问题1.需要人工完成2.无法对描述的准确度进行验证。

3.难以适应需求的变化。

1客房预定系统2前台接待系统3前台收银系统4账务系统5管家系统6电话系统7客房系统8合约系统9经理系统10总经理系统11密码管理系统12报表系统13账务报表,酒店管理系统,例:

按照功能分解为以下子系统:

例:

盘存/销售系统,用户提出系统应有以下功能:

计算买主订单准备销售报表建立买主文件和应收账发票运行更新的盘存文件产生托运单和包装单保证库存及时订货,计算销售记录1.1.1,产生销售报表1.1.2,核对买主贷方金额1.1.3,2.2需求分析方法,结构化分析方法是一种以数据、数据的封闭性为基础,从问题空间到某种表示的映射方法,由数据流图(DFD图)表示。

2.2需求分析方法,面向对象的分析方法面向对象分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型。

信息建模法是从数据的角度对现实世界建立系统的信息模型,基本工具是E-R图。

是由实体、属性和关系组成的网络图。

E-实体,是一个或一组对象;R-关系,实体之间联系或交互作用。

注意:

信息建模与面向对象分析的区别!

2.2.1结构化分析方法,分解:

对于一个复杂的系统,为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决(如右图)。

一、SA法的基本思想“分解”和“抽象”,抽象:

分解可以分层进行,即先考虑问题最本质的属性,暂把细节略去,以后再逐层添加细节,直至涉及到最详细的内容,这种用最本质的属性表示一个系统的方法就是“抽象”。

基本思想与步骤,三、SA法的描述方法1.分层的数据流图(DFD图)2.数据词典3.描述加工逻辑的结构化语言、判定表及判定树,二、SA法的步骤,深入调查研究,分析用户需求,用DFD图描述,分析系统需求,用DFD图描述,修改完善DFD图,增添功能,顾客,出版社,验证订单,汇总订单,订单,出版社订单,图书目录文件,正确订单,一批订单,出版社档案文件,画图步骤:

1.确定外部实体及输入、输出数据流。

2.确定分解顶层的加工。

3.确定使用的文件。

4.用数据流将各部分连接起来,形成数据封闭。

注意:

标注各加工框及数据流名称。

例:

图书预订系统(顶层DFD图),三、数据流图,数据流图(DataFlowDiagram,DFD)是描述系统中数据流程的图形工具,它描述了将系统的逻辑输入转换为逻辑输出所需的加工处理过程。

辅助的图例:

数据流图的图符基本图形符号:

顶层,中间层,底层,先全局后局部,先整体后细节,先抽象后具体。

0图,1图,2图,1.1图,2.1图,2.2图,分层DFD图,需求案例分析,案例一医院病房监护系统(采用结构化分析方法)案例二网上竞拍系统(采用基于用例的方法),一、问题的描述在医院ICU病房里,将病症监视器安置在每个病床,对病人进行监护。

监视器将病人的组合病症信号实时地传送到中央监护系统进行分析处理。

在中心值班室里,值班护士使用中央监护系统对病人的情况进行监控,监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析,当病症出现异常时,系统会立即自动报警,并打印病情报告和更新病历。

根据医生的要求随时打印病人的病情报告,系统还定期自动更新病历。

案例一医院病房监护系统,经过初步的需求分析,得到系统功能要求:

1.监视病人的病症(血压、体温、脉搏等)。

2.定时更新病历。

3.病情出现异常情况时报警。

4.随机地产生某一病人的病情报告。

医院病房监护系统,监视病情,更新病历,2.2.3实例:

医院病房监护系统,请分析软件系统需求!

1.监视病员的病症采集病症信号(血压、体温、脉搏等)。

组合病症信号。

将模拟病症信号转换为数字信号(A/D转换)。

2.定时更新病历将病症信号进行格式化并加入更新日期、时间。

更新病历库中病人的信息。

可人工设定更新病历的时间间隔。

二、系统功能需求,局部监视,更新日志,3.病情出现异常情况时报警根据标准病症信号库中的值,判断是否报警。

将报警信号转换为各种模拟信号(D/A转换)。

实时打印病情报告,立即更新病历。

4.随机地产生某一病员的病情报告,二、系统功能需求,产生病情报告,非功能需求,1.监视器与网络的可靠性要求,涉及人的生命安全。

2.效率需求中对时间、空间的需求,所采集的病症信号数据量大。

3.互操作需求如要求监视器采样频率可人工调整等。

4.对病人病历的隐私的要求。

顶层DFD图,医院病房监护系统分层DFD图,顶层确定了系统的范围,其外部实体为病人和护士。

护士,病人,护士,第二层:

加工“中央监视”分解,医院病房监护系统二层DFD图,第一层:

医院病房监护系统顶层DFD图,医院病房监护系统分层DFD图,紧急报告,加工分解的原则自然性:

概念上合理、清晰。

均匀性:

理想的分解是将一个问题分解成大小均匀的几个部分。

分解度:

一般每一个加工每次分解最多不要超过个子加工,分解应分解到基本加工为止。

三、画分层DFD图的基本原则,数据守恒与数据封闭原则数据守恒是指加工的输入/输出数据流是否匹配,即每一个加工既有输入数据流又有输出数据流。

数据封闭是对整个系统而言。

合理使用文件当文件作为某些加工之间的交界面时,文件必须画出来,一旦文件作为数据流图中的一个独立成份画出来了,那么它同其他成分之间的联系也应同时表达出来。

注意,DFD图不是流程图,不表示软件的控制流程。

三、画分层DFD图的基本原则,子图与父图的“平衡”父图中某个加工的输入/输出数据流应该同相应子图的输入/输出相同(相对应),分层数据流图的这种特点称为子图与父图“平衡”。

四、分层DFD图的改进,DFD图必须经过反复修改,才能获得最终的目标系统的DFD图。

可从以下方面改进DFD图:

1.检查数据流的正确性数据守恒子图、父图的平衡文件使用是否合理。

特别注意输入/输出文件的数据流。

2.改进DFD图的易理解性简化加工之间的联系(联系越少,独立性越强,易理解性越好)。

改进分解的均匀性。

适当命名(各成分名称无二义性,准确、具体)。

分层数据流图只是表达了系统的“分解”,为了完整地描述这个系统,还需借助“数据词典”和“小说明”对图中的每个数据和加工给出解释。

对数据流图中包含的所有元素的定义的集合构成了数据词典。

词典中可有以下四种类型的条目:

五、数据词典(DD),数据流文件数据项加工,A.数据流条目给出某个数据流的定义,通常是列出该数据流的各组成数据项。

例如:

报名单姓名单位名年龄性别课程名常用符号:

、()、,C.数据项条目数据项条目给出某个数据单项的定义,通常是数据项的值类型,允许的取值范围。

B.文件条目给出某个文件的定义,文件的定义通常是列出文件记录的组成数据流。

例如:

订单文件订单编号顾客名称产品名称订货数量交货日期,D.加工条目加工类条目就是“加工小说明”。

一般应该单独列出。

六、加工说明,结构化语言判定表判定树,对DFD图中每一个基本加工都必须有一个小说明给出该加工的精确描述。

小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。

加工逻辑是其中最基本的部分,指用户对这个加工的逻辑要求。

对基本加工说明有三种描述方式:

结构化语言是介于自然语言和形式语言之间的一种半形式语言,是自然语言的一个受限制的子集。

一般分为两层结构:

外层语法较具体,为控制结构(顺序、选择、循环),内层较灵活,表达“做什么”。

(一)结构化语言,例如,外层可为以下结构:

1.顺序结构2.选择结构IFTHEN-ELSE;CASE-OF-ENDCASE;3.循环结构WHILE-DO;REPEAT-UNTIL,判定表是一种二维的表格,常用于较复杂的组合条件(与结构化语言比较)。

(二)判定表,特点:

可处理较复杂的组合条件,但不易理解,不易输入计算机。

通常由四部分组成:

条件框条件定义。

操作框操作的定义。

条件条目各条件的取值及组合。

操作条目在各条件取值组合下所执行的操作。

例如:

对商店每天的营业额所收税率,例:

一图书销售系统,其中一加工为“优惠处理”,条件是:

顾客的营业额大于1000元,同时必须信誉好,或者虽然信誉不好,但是20年以上的老主顾。

判定表应用举例,特点:

描述一般组合条件较清晰,易理解。

不易输入计算机。

如上例,(三)判定树,1992年由Jacobson提出了Usecase的概念及可视化的表示方法Usecase图,并加入由他提出的面向对象的软件工程(OOSE)。

Usecase的概念受到了IT界的欢迎,被广泛应用到了面向对象的系统分析中。

基于用例的需求方法,已成为面向对象的分析方法的主流。

用例模型被推荐为获取和识别需求的首选工具!

基于用例的方法,2.2.2面向对象的分析方法(OOA),Usecase图,采用“基于用例的方法”来识别和获取需求,是从外部的角度来看系统功能,建立系统的Usecase模型。

描述外部执行者(Actor)所理解的系统功能。

即待开发系统的功能需求。

用例表示一个子系统,或者系统一个独立的功能。

角色表示外部的“执行者”。

ATM机验证储户身份的Usecase图,创建用例模型的工作包括:

定义系统、确定执行者和用例、描述用例、定义执行者和用例之间,用例间的关系、确认模型。

2.2.2面向对象的分析方法(OOA),案例二网上竞拍系统随着Internet技术的发展和互联网的日益普及,互联网用户中约1/4的用户使用Internet进行通信或经贸活动。

电子商务总额每年可达到6万亿美元。

网上竞拍系统就是一个在互联网上模拟拍卖环境的典型的范例。

可实现从展示产品、相互竞价到最后产品成交等一系列功能;用户可以轻松实现在线商品的拍卖和竞标。

一、竞拍平台1.竞拍者资格审查2.竞拍规则设定3.竞拍过程控制,二、拍卖商品信息发布确定发布的商品信息对商品信息操作,三、拍卖步骤及在线帮助四、网上支付系统五、用户管理,用户需求,系统需求,1.执行用户系统是通过网络提供给商品的销售者和购买者一个交易平台,因此所有上网用户都是本系统的用户,具体又分为商品购买者和商品销售者、系统管理员。

考虑到一般用户既可能是商品购买者也可能是商品销售者,所以将用户分为:

非会员用户和会员用户。

非会员未注册的用户,只能在网站上浏览商品,不能参与竞标,也不能提供物品出售。

会员已注册的用户,可以直接参与拍卖或竞标。

系统需求,2.用例分析系统功能提供高效的内容丰富的Web拍卖商业服务;展示产品、相互竞价、产品成交。

实现拍卖商品种类的更新和消息的发布。

实现个人物品流通和网上信息发布、留言。

初步确定以下功能:

1)会员注册2)会员天地3)商品分类浏览4)查找商品5)拍卖商品6)购买商品7)网上支付,系统需求,进一步确定以下功能:

1)会员注册(填写用户账号、用户名、密码、Email等)2)会员天地(查看并修改个人信息,交易记录,收邮件,信用评价等)3)商品分类浏览(浏览、更新、最新商品推荐等)4)查找商品(按关键字查找、输出打印商品信息)5)拍卖商品(包括商品上架:

提供商品信息:

商品名称、类别、图片、起拍价格、新旧程度、使用时间等,编辑商品,商品下架)6)购买商品(即出价参与竞标,拍卖结束时按照竞价规则获得商品),7)网上支付(通过银行网络系统进行交易,设置多种支付方式)增加执行者“银行”8)收藏商品(可添加收藏,取消收藏,修改收藏)9)会员管理(查看会员信息,封锁会员账号,激活会员账号)10)商品类别管理(添加商品类别,编辑商品类别,删除商品类别)11)交易管理(查看交易,查看交易报表,关闭交易,退款管理,申诉管理)12)公告栏管理(添加公告,修改公告,删除公告),建立UseCase模型,1.精度要求本系统所涉及的所有交易数据,均按实数保存,在处理时保留小数点后2位。

2.时间特性要求操作响应时间:

满足普通人员的操作要求。

查询运行时间:

满足普通人员的查询要求。

更新处理时间:

数据库在网络无故障的情况下,插入一条数据和更新一条数据的数据库操作响应时间控制在2s/条之内。

数据传输时间:

数据交换过程控制在10s内。

非功能需求,非功能需求,3.故障处理能力要求当出现错误时,要求以对话框形式向用户说明,并用一览表方式列出各类可能的错误或故障出现时,系统的处理方法和补救措施。

4.灵活性需求要求当用户需求,如操作方式、运行环境、结果精度、数据结构及其他软件接口等发生变化时,或增加新模块时,不会修改原有的模块。

5.安全性采用用户名及密码,对用户授权使用。

支付过程中的安全性由银行网上支付系统保证。

改进的UseCase模型,需求工程小结,软件需求工程,是软件开发人员与用户密切配合,充分交换意见,获得对需求一致意见的过程。

在开发者一方,参与工作的主要角色是系统分析员和系统工程师等,负责沟通用户和开发人员的认识和见解,起着桥梁作用。

需求工程阶段的最终任务是要完成目标系统的需求规格说明,确定系统的功能、非功能需求和性能,为后阶段的开发打下基础。

本阶段常用的有SA法、原型法、OOA法等。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 自然科学 > 物理

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2