文档介绍：该【软件需求分析笔试题库 】是由【1485173816】上传分享，文档一共【38】页，该文档可以免费在线阅读，需要了解更多关于【软件需求分析笔试题库 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。软件需求分析题库
软件需求分析课程组编
2021年4月
目录
一、单项选择题………………………………………………2
二、填空题……………………………………………………5
三、判断题……………………………………………………9
四、名词解释题………………………………………………11
五、问答题……………………………………………………14
六、案例分析题………………………………………………28
1
软件需求分析****题集
一、单项选择题
1、软件生产中产生需求问题的最大原因在于对应用软件的〔
〕理解不透彻或应用不
坚决。
〔A〕复杂性〔B〕目的性
〔C〕模拟性〔D〕正确性
2、需求分析的目的是保证需求的〔
〕。
〔A〕目的性和一致性〔B〕完整性和一致性
〔C〕正确性和目的性〔D〕完整性和目的性
3、系统需求开发的结果最终会写入〔
〕。
〔A〕可行性研究报告
〔C〕用户需求说明
4、现实世界中的〔
〔B〕前景和范围文档
〔D〕系统需求规格说明
〕构成了问题解决的根本范围,称为该问题的问题域。
〔A〕属性和状态〔B〕实体和状态〔C〕实体和操作〔D〕状态和操作
5、功能需求通常分为三个层次,即业务需求、用户需求和〔
〕。
〔A〕硬件需求〔B〕软件需求
〔C〕质量属性
〔D〕系统需求
6、比拟容易发现的涉众称为初始涉众,又称为〔
〕,通常包括客户、管理者和相关
的投资者。
〔A〕关键涉众〔B〕涉众基线
〔C〕普通涉众
〔D〕一般涉众
7、如果在最终的物件〔FinalArtifact〕产生之前,一个中间物件〔MediateArtifact〕被
用来在一定广度和深度范围内表现这个最终物件,那么这个中间物件就被认为是最终物件在
该广度和深度上的〔
〕。
〔A〕模拟
〔B〕构造
〔C〕原型
〔D〕模型
8、按照使用方式进展分类,原型可分为:演示原型、〔
〕、试验原型和引示系统原
型。
〔A〕非操作原型〔B〕系列首发原型〔C〕选定特征原型〔D〕严格意义上的原型
9、按照功能特征进展分类,原型可分为:〔〕、非操作原型、系列首发原型和选定
特征原型。
〔A〕拼凑原型〔B〕样板原型〔C〕纸上向导原型〔D〕严格意义上的原型
10、按照开发方法进展分类,原型可分为:演化式原型和抛弃式原型,其中抛弃式原
型又被细分为〔
〕。
〔A〕演示原型和试验原型
〔C〕探索式原型和实验式原型
〔B〕系列首发原型和选定特征原型
〔D〕样板原型和纸上向导原型
11、原型的需求内容可以从三个纬度上分析:即〔
〕。
〔A〕外观、角色和实现
〔C〕本钱、技术和实现
〔B〕开发、实现和作用
〔D〕需求、作用和角色
12、当用户无法完成主动的信息告知,或及需求工程师之间的语言交流无法产生有效
的结果时,有必要采用〔
〕。
〔A〕民族志
13、以下〔
〔A〕突现
14、以下〔
〔A〕全局
〔B〕观察法
〔C〕话语分析
〔D〕任务分析
〔D〕模糊
〔D〕即时
〕不是情景性的重要性质?
〔B〕涉身
〔C〕完善
〕是情景性的重要性质?
〔B〕开放〔C〕交互
2
15、以下〔
〕不是需求获取常见的模型驱动方法?
〔A〕面向目标的方法
〔C〕基于用例的方法
〔B〕基于场景的方法。
〔D〕基于采样的方法
16、以下〔
〕属于定量硬数据?
〔A〕工作手册
17、以下〔
〔B〕规章手册〔C〕统计报表
〔D〕备忘录
〕属于定性硬数据?
〔A〕数据收集表
〔B〕月报表
〔C〕年报表
〔D〕规章手册
18、功能目标可以分为(
〔A〕平安目标和可用性目标
〔C〕软目标和硬目标
)。
〔B〕满足型目标和信息型目标
〔D〕维护目标和实现目标
19、在表达软目标的分解和细化时使用的ANDContribution链接和ORContribution链
接,Contribution的作用是〔
〔A〕积极的〔B〕消极的
20、AND链接将一个父目标连接到一系列细化的子目标,意思是如果能够满足所有细
〕。
〔C〕积极的或消极的
〔D〕不能确定
化的子目标,那么将〔
〕父目标。
〔A〕无法确定
〔B〕阻碍
〔C〕不能满足
〔D〕足以满足
21、OR链接是将一个父目标连接到一系列细化的子目标,意思是如果能够满足所有细
化子目标中的〔
〕,那么将足以满足父目标。
〔A〕每一个〔B〕任何一个
〔C〕特定的〔D〕某一个
22、以下选项中,〔
〔A〕行为者
23、面向目标方法的目标分析阶段的主要任务是〔
〕不是在目标模型中使用的其他模型元素。
〔B〕场景
〔C〕操作
〔D〕概念
〕。
〔A〕获取目标
〔B〕确定解决方案
〔C〕建立目标模型
〔D〕发现问题和缺陷
24、场景的分类框架将场景方法从场景的〔
〕4个方面进展了分类和描述。
〔A〕形式、目的、内容和生命周期
〔C〕描述、目的、内容和形式
〔B〕外观、目的、内容和生命周期
〔D〕描述、外观、目的和内容
25、场景的形式是指场景的表达模式,从形式上分为两个方面:〔
〕
〔A〕内容和目的〔B〕内容和生命周期〔C〕描述和外观〔D〕描述和目的
26、描述场景所使用的表示法要符合正规性要求,一般可使用非形式化语言、半形式
化语言和形式化语言。在实践中,〔
〕是主要的描述方式。
〔B〕非形式化的自然语言
〔D〕非形式化的设计语言
〔A〕形式化的程序语言
〔C〕形式化的图形工具
27、外观是指场景被表达出来时的效果,主要有〔
〔A〕静态、动态和构造化〔B〕线性、非线性和交互
〔C〕静态、动态和动静结合〔D〕静态、动态和交互
28、场景的内容是指场景所表达的知识类型。它被分为6个不同的方面。以下〔
〕三种类型。
〕
不是场景的内容。
〔A〕主要关注点〔B〕环境范围〔C〕目的〔D〕抽象层次
29、需求工程利用场景的目的可能有三种:即:〔
〕。
〔A〕描述、探索和解释
〔C〕描述、探索和发现
〔B〕描述、表示和探索
〔D〕表示、解释和证明
30、使用解释性场景在需求分析时能够〔
〕,或者被用于进展需求的验证。
〔A〕提高模型的复杂性〔B〕降低模型的复杂性
3
〔C〕提高预见性
31、以下〔
〔D〕降低编程量
〕不是场景方法在需求工程中的应用。
〔A〕帮助进展详细的需求分析
〔B〕编写系统需求规格说明
〔C〕结合面向目标的方法,指导需求获取活动的开展
〔D〕组织需求获取得到的信息
32、以下〔
〕是组织场景时可用的场景关系。
〔A〕合取关系
〔B〕定性关系〔C〕定量关系
〔D〕演绎关系
33、及其他的场景方法相比,用例最大的特点是采用了〔
〕的描述方式。
〔A〕静态非构造化文本
〔C〕静态构造化文本
〔B〕动态非构造化文本
〔D〕动态构造化文本
〕三种。
34、用例之间的关系主要有〔
〔A〕包含、扩展和简化
〔C〕包含、多态和继承
〔B〕合取、析取和扩展
〔D〕包含、扩展和泛化
35、分析的活动主要包括识别、定义和构造化,它的目的是获取某个可以转换为知识的
事物的信息,这种分析活动被称为〔
〔A〕需求信息获取
〕。
〔B〕建立软件系统解决方案
〔D〕建立需求分析模型
〔C〕需求信息转化
36、〔
〕是建模最为常用的两种手段。
〔A〕具体和抽象
〔B〕抽象和分解
〔C〕分解和细化
〔D〕抽象和细化
37、抽象通过强调本质的特征,〔
〕了问题的复杂性。
〔A〕调整
〔B〕防止
〔C〕增加〔D〕减少
38、需求分析仅仅需要描述解决方案,不需要探索实现细节的情况下,分析模型又是
〔
〕的,尤为适用。
〔A〕形式化
〔B〕半形式化
〔C〕构造化
〔D〕非构造化
39、上下文图描述系统及环境中外部实体之间的界限和联系。它从现实世界的角度说明
了系统的〔
〕,并确定了所有的输入和输出。
〔A〕环境及外观
40、〔
〔B〕边界和联系〔C〕边界和环境〔D〕输入和输出
〕是构造化分析方法的核心技术,它说明系统的输入、处理、存储和输出,以
及它们如何在一起协调工作。
〔A〕数据流图DFD〔B〕实体联系图ERD〔C〕状态转换图〔D〕上下文图
41、构造化、信息工程和面向对象三种方法学下的需求分析技术都是〔
〔A〕面向问题域〔B〕面向解系统〔C〕面向设计〔D〕面向需求
42、使用面向问题的技术对问题世界的建模就被称为〔
〔A〕前期〔B〕中期〔C〕后期〔D〕全过程
43、使用面向解系统的技术对软件系统解决方案的描述称为〔
〔A〕前期〔B〕中期〔C〕后期〔D〕全过程
〕的。
〕需求阶段的分析。
〕需求阶段的分析。
44、需求分析活动的一个重要任务是进展〔
〕,明确用户需求的隐含信息,展开为
明确的对软件系统的行为期望,即系统需求。
〔A〕需求整理
〔B〕需求细化〔C〕需求获取
〔D〕需求分析
45、在分层构造中,DFD定义了三个层次类别的DFD图:〔
〔A〕1层图〔B〕底层图〔C〕上下文图〔D〕顶视图
46、因为数据存储是系统内部的功能实现,所以在将系统视为黑盒的情况下,上下文
〕、0层图和N层图。
图中不会出现〔
〕。
4
〔A〕实体
〔B〕数据存储实例
〔C〕需求信息
〔D〕过程处理
47、数据建模技术能够弥补过程建模在〔
〕方面的缺陷,它描述数据的定义、结
构和关系等特性。
〔A〕需求分析
〔B〕数据转换〔C〕数据说明
〔D〕数据分析
48、。概念实体是一种抽象概念,不考虑概念背后的物理存在,所以通常不包含及之相
关联的其他〔
〕。
〔A〕模型
〔B〕特征〔即属性〕
〔C〕关系〔D〕处理
49、在ERD建模中,实体通常所指的就是〔
〔A〕逻辑实体〔B〕概念实体〔C〕物理实体
50、ERD中属性是实体的特征,不是数据。属性会以一定的形式存在,这种存在才是
〕。
〔D〕进程实体
数据,被称为属性的〔
〕。
〔A〕域
〔B〕实例
〔C〕说明
〔D〕值
51、ERD中关系的度数〔Degree〕是指参及关系的实体数量,是度量关系〔
〕的
一个指标。
〔A〕模型
52、ERD中关系的基数分为最大基数和最小基数。最大基数又被称为〔
〔A〕键约束〔B〕参及约束〔C〕自然约束〔D〕一般约束
53、在实体之间建立关系时,可能会产生一些附带的实体,被称为关联实体,最常见
〔B〕复杂度
〔C〕准确度
〔D〕属性值
〕。
的形式是〔
〕。
〔A〕逻辑实体
〔B〕进程实体〔C〕概念实体
〔D〕自然实体
54、在实现ERD及过程模型同步的技术中,〔
〕是一种较为常见的技术。
〔A〕用例图
55、以下〔
〔A〕属性
〔B〕数据流图
〔C〕功能/实体矩阵
〔D〕微规格说明
〕不是用例模型中的关系?
〔B〕关联
〔C〕泛化
〔D〕包含
56、系统边界是指一个系统所包含的系统成分及系统外事物的分界限。用例模型使用
一个〔
〕来表示系统边界,以显示系统的上下文环境。
〔A〕圆形框
〔B〕菱形框
〔C〕虚线框〔D〕矩形框
57、UML使用的行为模型有三种,即:〔
〕。
〔A〕交互图、状态图和顺序图
〔C〕交互图、状态图和活动图
〔B〕顺序图、通信图和时间图
〔D〕交互概述图、通信图和时间图
58、工程的前景和范围文档、用户需求文档都被视为属于〔
〕,重点都是用户的现
实世界。
〔A〕开发文档
〔B〕需求文档〔C〕前景文档
〔D〕用户文档
59、系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口
需求规格说明文档和人机交互文档一起被用于系统开发的目的,都被认为是开发文档。
〔A〕开发文档
60、以下〔
〔B〕需求文档〔C〕过程文档
〔D〕用户文档
〕不是需求规格说明文档的读者?
〔A〕工程管理者
〔B〕编程人员
〔C〕销售商
〔D〕律师
二、填空题
1、传统的需求分析方法都是从设计领域转入分析领域的。
2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进展巧
妙的功能安排。
3、面向普通用户的纯工具型软件进展分析的主要目的是进展方案权衡,寻找一套切实
5
有效的功能配置。
4、应用型软件分析阶段的主要目的是发现人们利用软件的原因〔目的〕,找出需要软件
解决的问题,理解应用环境中的领域知识,保证功能的模拟性。
5、需求工程是所有需求处理活动的总和,它收集信息、分析问题、整合观点、记录需
求并验证其正确性,最终反映软件被应用后及其环境互动形成的期望效应。
6、软件需求开发用来确定系统需求中应该由软件满足的局部,将其映射为软件行为,
产生软件需求规格说明。
7、约束是不受解系统影响,却会给解系统带来极大影响的问题域特性。
8、优秀的需求应该具备7个特性,即完整性、正确性、准确性、可行性、必要性、无
歧义和可验证。
9、所有对软件系统的开发和应用具有发言权和决定权的人统称为涉众。
10、按照媒介载体进展分类,原型可分为:样板原型和纸上向导原型。
11、演示原型主要被用在工程启动阶段。
12、演示原型都是被用来展示用户想象中的系统视图,所以它要能够表现用户界面的重
要特征。
13、,如果一个问题的技术解决方案是不清晰的,演示原型也可以被用来展现相应的细
节功能以使用户确信该问题解决的可能性。
14、通常来说,如果用户需求出现了模糊、不清晰、不完整等具有一定不确定性的特征,
就可以考虑使用原型方法。
15、角色是指原型物件在用户工作中的价值,也就是说它为什么对用户是有用的。
16、外观是指用户对原型物件的具体感觉体验,即用户在使用原型物件时会看到什么、
听到什么和感觉到什么。
17、实现是指原型物件完成功能的细节技术和方法。
18、使用演化式原型方法,在开发时就需要注意原型的强健性和代码的质量。
19、使用实验式开发方法,需要实现多种技术方案,考察重要的系统的质量属性。
20、选择使用探索式开发方法,需要尽可能地考虑各种不同的设计选项,比拟不同选项
下的用户反响。
21、原型方法的最大优点是能够及早地解决系统开发中的不确定性,从而降低软件工程
失败的风险。
22、航空调度、证券交易、医疗手术控制等复杂的协同问题都具有突现的情景性。
23、民族志的一个主要应用目的就是研究和解决复杂的协同问题。
24、复杂的工作总会同时存在着正常流程和异常流程,异常流程大多是一些特殊情况下
的处理,限定了异常处理的上下文环境,即异常处理具有局部的情景性。
25、有很多重要工作的进展需要用户具备一定的认知,认知要求已经成了用户工作必备
的局部,即工作具有涉身的情景性。
26、采样观察是最简单的观察方法,应用目的是发现异常流程,验证用户所述知识和实
际的一致性,以及发现默认知识。
27、时间采样允许需求工程师建立指定的时间间隔来观察用户的活动情况。
28、文档审查主要获取对象包括相关产品的需求规格说明、硬数据和客户的需求文档。
29、文档分析通常是数据建模方法的一个根底局部,它是通过检查采集的硬数据来确定
潜在的需求。
30、如果当前存在一份客户的需求文档,就可以使用需求剥离技术,从需求文档中抽取
单个的需求并参加到新的需求文档之中。
31、需求工程师可以使用模型驱动方法来进展信息的整理和归类,其中模型驱动方法所
6
建立的模型是进展信息整理和归类的很好的框架依据。
32、模型驱动方法的模型是在前期需求阶段的分析中建立的。
33、目标模型的一个核心要素是元素之间的关系,称为链接。
34、目标模型的链接有两类:一类是目标之间的链接;另一类是目标及其他模型元素之
间的链接。
35、面向目标方法的处理过程可以分为三个阶段:目标获取、目标分析〔即目标模型的
建立〕和目标实现。
36、目标实现阶段的主要任务是收集及目标相关的需求信息,讨论可能的候选解决方案,
确定最终的系统详细需求和解决方案。
37、场景具有重点描述真实世界的特征,它利用情景、行为者之间的交互、事件随时间
的演化等方式来表达性地描述系统的使用。
38、静态外观的场景被展现为一个或者数个描述性的文本或者图片。
39、动态外观的场景会被以动态的方式展现出来,人们可能会要求按时序向前或者向后
浏览场景,也可能会要求跳转到场景的某一个时刻进展观察。
40、交互外观的场景提供交互性,它允许用户在一定程度上控制和改变场景的变化时序
或者效果。
41、具体场景,又称为实例场景,是对个别行为者、事件、情节的细节描述。
42、抽象场景,又称为类型场景,是以经历中的类别和抽象概念来描述事实。
43、探索性场景可以用来进展需求获取和需求建模及分析。
44、每个用例是对相关场景集合的表达性的文本描述,这些场景是用户和系统之间的交
互行为序列,帮助实现用户的目的。
45、用例是场景方法中的一种,是静态的构造化文本描述。
46、在高层的功能需求获取完备之前,用例的产生方式中不允许使用功能分解方式。
47、单个用例描述了系统的功能片段,系统的所有用例基于一定的关系组织起来,建立
用例模型,就可以描述整个系统的功能。
48、原有用例和新建立的抽象用例的关系即为包含关系。
49、在需求工程中,主要产生三类重要的文档:工程前景和范围文档、用户需求文档以
及需求规格说明。用例文档通常被用来代替用户需求文档,起到记录、交流领域信息和用户
期望的作用。
50、需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差
距。需求分析就是用来解决这个差距的需求工程活动。
51、需求分析的根本任务是:建立分析模型并创立解决方案。
52、分解将单个复杂和难以理解的问题分解成多个相对更容易的子问题,并掌握各子
问题之间的联系。
53、基于软件构建单位及其之间的关系建立的模型,用来说明软件逻辑上的构建方式
和实现方式,由于它使用的组元及其关系都是软件的元素,因此它是来自于软件的模型,称
为计算模型。
54、模型语言的三要素:语法、语义、语用。其中语用给出了一个模型元素描述的更
宽广的上下文,以及影响该模型元素意义的约束和假定。
55、互相之间建立了语义联系的多个模型,集成在一起通常被称为视图。
56、需求分析方法主要有:构造化方法、信息工程方法和面向对象方法。其中面向对
象方法是目前工业界使用的主流方法。
57、信息工程和构造化方法的本质差异在于解决问题的策略不同。
58、前期需求阶段分析的重点是理解问题世界,因此它关注的是整个问题世界,注重
7
于系统的环境、开发组织的业务背景、涉众的特征以及目标等等,软件系统只是整个背景下
的一个要素。
59、后期需求阶段分析关注的是解系统解决方案的建立,因此它以软件系统为中心,
注重于分析系统的内部功能以及它及环境的互动,是对系统功能的详细信息的分析。
60、以软件复用为核心,建立产品族的方法被称为产品线。
61、需求协商活动既包括对目标冲突的处理,也包括对需求细节冲突的处理。
62、微规格说明被用来描述DFD过程分解构造中最底层过程的处理逻辑。
63、DFD中所有的外部实体联合起来构成了软件系统的外部上下文环境,它们及软件
系统的交互流就是软件系统及其外部环境的接口,这些接口联合起来定义了软件系统的系统
边界。
64、数据流是指数据的运动,它是系统及其环境之间或者系统内两个过程之间的通信
形式。
65、DFD的0层图中的每个过程都可以进展分解,被分解的过程称为父过程,分解后
产生的提醒更多细节的DFD图称为子图。
66、DFD的0层图通常被用来作为整个系统的功能概图。
67、为了保证DFD图的可理解性,0层图应该被描述的简洁、清晰,所以在描述复杂的
系统时,0层图中不应出现太过具体的过程和数据存储。
68、DFD中对0层图的过程分解产生的子图称为1层图。
69、数据建模建立的模型称为数据模型,是问题域和解系统共享的知识集合,通常能
够反映企业业务的核心知识。
70、数据模型的内容是问题域和解系统所共享的知识模型,可以用问题域的语言来解
释,也可以用解系统的语言来解释,还可以用介于问题域和解系统之间的中立语言来解释。
71、在需求工程中,数据建模建立的是概念数据模型和逻辑数据模型,不涉及物理数
据模型。
72、ERD的逻辑实体是对概念实体的细化,拥有完整的特征描述。
73、数据建模中对行为和事件的建模需要是为了了解它们在某些时刻的快照或者运行
环境信息,而不是它们所表达出来的功能和达成的效果,所以称这类实体为进程实体。
74、ERD中属性就是可以对实体进展描述的特征,一系列属性的存在集成起来就可以
描述一个实体的实例。
75、ERD中属性取值的受限制范围称为域〔Domain〕。
76、ERD为实体指定一个属性或多个属性的组合,可以用来唯一地确定和标识每个实
例,这些属性或属性的组合称为实体的标识符,又称为键。
77、一个实体可能有多个键,这些键都被称为候选键。
78、通常人们从多个候选键中选择和使用固定的某一个键来进展实例的标识,这个被
选中的候选键被称为主键,没有被选做主键的候选键被称为替代键。
79、实体实例大多数属性的值都是需要从现实中获取的,称为存储属性。
80、有些实体实例的属性的值是可以由其他属性的值计算得出的,称为导出属性。
81、关系是存在于一个或多个实体之间的自然业务联系。
82、只有一个实体参及的关系存在于实体的不同实例之间,称为一元关系,又称为递
归关系。
83、ERD中关系的基数分为最大基数和最小基数。最小基数又被称为参及约束。
84、ERD中一个实体在关系中的最大基数是指,对关系中任意的其他实体实例,该实
体可能参及关系的最大数量。
85、ERD中一个实体在关系中的最小基数是指,对关系中任意的其他实体实例,该实
8
体可能参及关系的最小数量。
86、ERD中被关系影响的实体主要是弱实体和关联实体。
87、用例模型的根本元素有四种:用例、参及者、关系和系统边界。
88、UML行为模型是用例模型的实现,以更加详细的方式说明用例所描述的系统行为。
89、UML行为模型的活动图是依据处理流程进展的用例实现。
90、UML行为模型的交互图通常描述的是单个用例的典型场景。
91、接口需求规格说明文档是对整个系统中需要软、硬件协同实现局部的详细描述。
92、优秀的需求规格说明文档应该具备:正确性、无歧义、完备性、一致性、根据重
要性和稳定性分级、可验证、可修改、可跟踪等特性。
93、需求验证常见方法有:需求评审、原型及模拟、测试用例开发、用户手册编制、
利用跟踪关系和自动化分析。
94、评审又被称为同级评审,是指由作者之外的其他人来检查产品问题的方法。
95、在系统验证中,评审是主要的静态分析手段,所以评审也是需求评审的一种主要
方法。
96、需求基线的维护主要包括配置管理和状态维护。
97、需求跟踪是以软件需求规格说明文档为基线,在向前和向后两个方向上,描述需
求以及跟踪需求变化的能力。
98、从需求向后回溯〔前向跟踪的两种联系之一〕说明软件需求来源于哪些涉众的需
要和目标。
99、后向跟踪是指需求被定义到软件需求规格说明文档之后的演化过程。
100、后向跟踪包括两种联系:从需求向前跟踪和回溯到需求的跟踪。
三、判断题
1、需求工程包括需求获取和需求开发两个方面。〔×〕
2、需求验证是需求工程中最后一个活动。〔×〕
3、软件系统能够及问题域进展交互和相互影响的原因在于,软件系统中的某些局部对问
题域中的某些局部具有模拟特性。〔√〕
4、规格说明是问题域为满足用户需求而提供的解决方案,规定了解系统的行为特征。〔×〕
5、业务需求具有明显的目的性和较高的抽象性,经过明确和细化的处理,可以直接转化
为系统需求。〔×〕
6、需求开发的一些特性决定了需求开发过程只能是一个简单的线性增量过程。〔×〕
7、对于需求不确定性比拟小的工程,用户参及可以取得比拟好的效果,但对于需求不确
定性比拟大的工程,用户参及反而可能带来阻碍作用。〔×〕
8、按照构建技术进展分类,原型可分为:水平原型和垂直原型。〔√〕
9、严格意义上的原型主要被用在需求分析阶段。〔√〕
10、要完成一样的功能,构建抛弃式原型比构建演化式原型所花费的代价要大得多。〔×〕
11、水平原型方法仅仅实现选定功能实现的所有层次,能够处理较大范围的功能。〔×〕
12、垂直原型方法会触及选定功能所有层次中的某些特定层次,处理的功能范围通常较
小。〔×〕
13、建立外观原型时重在原型的用户界面和交互方式,原型的功能和技术实现细节就会
被简化处理。〔√〕
14、如果选择的开发方法是实验式或者探索式开发方法,应该尽量花费最小的代价,争
取最快的速度,忽略或简化不重要的功能处理。〔√〕
15、原型修正主要依据评估人员的反响,可以忽略事先的原型调整方案。〔×〕
9