当前位置：文档库 › 软件需求分析笔试题库

软件需求分析笔试题库

《软件需求分析》题库

《软件需求分析》课程组编

2012年4月

一、单项选择题 (2)

二、填空题 (5)

三、判断题 (9)

四、名词解释题 (11)

五、问答题 (14)

六、案例分析题 (28)

《软件需求分析》习题集

一、单项选择题

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、如果在最终的物件（Final Artifact）产生之前,一个中间物件（Mediate Artifact）被用来在一定广度和深度范围内表现这个最终物件,那么这个中间物件就被认为是最终物件在该广度和深度上的（）。

（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）交互

15、下列（）不是需求获取常见的模型驱动方法？

（A ）面向目标的方法（C ）基于用例的方法（B ）基于场景的方法。

（D ）基于采样的方法

16、下列（）属于定量硬数据？

（A ）工作手册 17、下列（（B ）规章手册（C ）统计报表

（D ）备忘录

）属于定性硬数据？（A ）数据收集表（B ）月报表（C ）年报表（D ）规章手册

18、功能目标可以分为 ( （A ）安全目标和可用性目标（C ）软目标和硬目标 )。

（B ）满足型目标和信息型目标

（D ）维护目标和实现目标

19、在表达软目标的分解和细化时使用的 AND Contribution 链接和 OR Contribution 链接,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 ）降低模型的复杂性

（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层图。图中不会出现（）。

（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、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡,寻找一套切实

有效的功能配置。

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、需求工程师可以使用模型驱动方法来进行信息的整理和归类,其中模型驱动方法所

建立的模型是进行信息整理和归类的很好的框架依据。

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、前期需求阶段分析的重点是理解问题世界,因此它关注的是整个问题世界,注重

于系统的环境、开发组织的业务背景、涉众的特征以及目标等等,软件系统只是整个背景下的一个要素。

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中一个实体在关系中的最小基数是指,对关系中任意的其他实体实例,该实

体可能参与关系的最小数量。

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、原型修正主要依据评估人员的反馈,可以忽略事先的原型调整计划。（×）

16、文档审查是一种传统的需求获取方法,是专门针对文档进行的需求获取活动。（√）

17、由于文档是来自于当前计算机或手工系统的产物,因此它是正确的,也正是客户所

需要的。（×）

18、成功的需求获取任务不仅要求成功地执行每一次具体的需求获取行为,还要求成功

地处理多次获取行为之间的关系。（√）

19、软目标是一类无法清晰判断是否满足的目标,所以可以用AND和OR链接直接应

用于软目标。（×）

20、子目标的实现只能促进父目标的实现。（×）

21、AND和OR链接用于描述目标的分解和细化关系。（√）

22、目标的发现并是一个自上而下分解的过程,也就是一个不断发现和细化的过程。（×）

23、对系统的现状和背景进行分析往往能够发现重要的目标,得到一些明确的问题和缺陷,它们的反面就是系统需要实现的目标。（√）

24、场景被人们广泛接受的原因是因为人们更倾向于会对真实事件和真实事物的描述产

生反应。（√）

25、描述场景时所使用的常见媒介形式主要有：叙述性的自由文本、结构化文本。强限

制文本、表格、图表、图像等。（√）

26、在实践中,以动态的场景外观为主。（×）

27、场景内包含的知识只能是关于未来的。（×）

28、描述性场景的目的是为了记录已经得到的需求,即整理每次需求获取行为中得到的

信息。（√）

29、UML就是以用例来捕获系统所有的系统需求的。（×）

30、用例的内容只能包含有正常流程,而不能包含有异常流程。（×）

31、用例可以用于各种目的的应用,包括描述、探索和解释。（√）

32、用例是在对现实世界的探索中或者是在对需求规格说明的解释中产生的,是通过功

能分解的方式创建的。（×）

33、抽象用例是不能被实例化的,它必须被包含在其他用例中才能得以执行。（√）

34、用例间的泛化关系是指子用例继承了父用例的特征。（×）并增加了新的特征

35、抽象一方面要求人们关注重要的信息,同时又不能忽略次要的内容。另一方面也要

求人们将认知保留在适当的层次,屏蔽更深层次的细节。（×）

36、由于计算模型的形式化特征不适合于需求工程阶段,因此计算模型不适合用于需求

分析中的建模。（√）

37、具有形式化特征的计算模型是用户和开发者共同理解的模型。（×）

38、由于模型需要描述的内容太过复杂的,因此分析模型对模型语言语用的要求不可能

太高。（×）

39、软件需求分析的关键是为真实世界的问题建立模型,即问题域建模。（√）

40、在“结构化方法一信息工程方法一面向对象方法”的发展历程中,每一种后来的方

法在吸收了前面方法的重要思想的同时也替代前面的方法。（×）

41、结构化、信息工程和面向对象三种方法学下的需求分析技术都适合于需求阶段全过

程的分析任务。（×）后期

42、上下文图是DFD的一个特定层次,被用来说明系统的上下文环境,确定系统的边

界。（√）

43、外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统,但它们要

受系统的控制,开发者可以以任何方式操纵它们。（×）

44、上下文图以黑盒看待和描述系统的方式使它非常适合描述系统的应用环境、定义系

统的边界,这正是DFD在层次结构中将其置于最高层的原因。（√）

45、数据模型说明了问题域和解系统共享的事物、对共享事物的描述和共享事物之间

的关系。（√）

46、ERD关系表达的不是逻辑上的链接（例如整体部分关系）,而是实体物理上的联系。（×）

47、ERD中存在于两个实体之间的关系是最常见的关系,称为二元关系。（√）

48、ERD中子类型关系是实体间自然的业务联系,而不是人为施加的结构关系,是一

种特殊的实体间关系。（×）

49、建立功能／实体矩阵的过程可以帮助验证过程模型和数据模块的正确性,发现其中

的错误、遗漏、冗余和不一致。（√）

50、发起或触发用例的外部用户以及其他软件系统等角色被称为参与者。（√）

51、交互图是对单个用例的典型场景的实现,适合于事务性业务工作的表示。（√）

52、UML行为模型的状态图是以状态机模型的方式进行的用例实现。状态图只能用来

实现单个用例。（×）

53、OCL无法被用来描述程序的控制逻辑和工作流程。（√）

54、OCL的表达式定义可以在程序中得到直接的执行。（×）

55、软件需求规格说明文档是对部分系统功能分配给软件部分的详细描述。（×）

56、硬件需求规格说明文档是对整个系统功能当中分配给硬件部分的详细描述。（√）

57、人机交互文档是对整个系统功能中需要进行人机交互部分的详细描述。（√）

58、验证活动同样普遍存在于需求分析过程中。（×）

59、需求验证并不是一个可以一次结束的活动,它可能需要多次、反复地执行验证。（√）

60、前向跟踪是指需求在被获取到软件需求规格说明文档之前的演化过程。（×）定义

四、名词解释题

1、需求工程：需求工程是软件工程的一个分支,它关注于软件系统所应予实现的现实

世界目标、软件系统的功能和软件系统应当遵守的约束,同时它也关注以上因素和准确的软

件行为规格说明之间的联系,关注以上因素与其随时间或跨产品族而演化之后的相关因素之

间的联系。

2、需求：IEEE对需求的定义为：

①用户为了解决问题或达到某些目标所需要的条件或能力。

②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备

的条件或能力。

③对①或②中的一个条件或一种能力的一种文档化表述。

3、需求分析：需求分析是利用建模与分析技术对获取笔录的内容进行明确、整理、汇总,建立一个综合考虑问题域特性和需求的系统模型,然后根据系统模型将用户需求转化为

系统需求的需求工程活动。

4、前景（Vision）：前景描述了产品的作用以及最终的功能,它将所有涉众都统一到一

个方向上。

5、范围（scope）：范围指出当前项目是要解决产品长远规划中的哪一部分,范围声明

它为项目划定了需求的界线。

6、用户参与（User Involvement）：是以用户为中心的设计方法的核心思想,它要求开

发者建立和用户的直接联系,尽早地关注于用户和用户的任务执行过程,通过及时获得用户

的反馈来调整软件设计,以完成高质量的设计。另一方面,用户参与就是反对通过和市场人

员、管理者等中间媒介来了解用户,因为这些间接的联系会减少或歪曲用户的信息。

7、硬数据：表格和文档资料是用户对实际业务进行加工和抽象之后的结果,是一种精

化过的知识。这些文档资料被称为硬数据。硬数据分为定量硬数据和定性硬数据两种类型。

8、结构化面谈：结构化面谈指在面谈的过程中,会见者会完全按照事先的问题和结构

来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息,一些

统计性倾向信息的获取也可以使用结构化面谈。

9、半结构化面谈：半结构化面谈指在面谈的过程中,事先需要根据面谈内容准备面谈

的问题和面谈结构。但在面谈过程中,会见者可以根据实际情况采取一些灵活的策略。半结

构化面谈是在需求获取中应用最多的一种面谈类型,能够处理大部分的需求获取任务。

10、非结构化面谈：在非结构化面谈的过程中,没有事先预定的议程安排。在比较极

端的情况下,会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地,就

某个主题开展会谈。

11、头脑风暴（Brainstorming）：是一种特殊的群体面谈方式,它的目的不是发现需求, 而是“发明”需求,或者说是发现“潜在”需求。它鼓励参与者在无约束的环境下进行某些

问题的自由思考和自由讨论,以产生新的想法。它是需求获取中用于“发明”需求的方法,

但它会增加需求的数量。

12、原型：原型是一个系统,它内化了（Capture）一个更迟系统（Later System）的本

质特征。原型系统通常被构造为不完整的系统,以在将来进行改进、补充或者替代。”

13、严格意义上的原型：严格意义上的原型主要被用在需求分析阶段,是开发者在建

立系统信息模型的同时建立的原型,通常被用来阐明用户界面或者系统功能的某些特定方

面,帮助人们及时地澄清问题。

14、场景：场景是对系统和环境行为的局部描述,或者说场景是对行为或者事件序列

的描述,序列中的行为和事件是系统需要完成的一个任务的特殊示例。

（也可以说,场景是用户为了达到某个目标而和软件系统发生的行为交互序列,是开

发者描述软件功能和需求的一种重要形式。）

15、情境性：情景性是指某些事件只有和它们发生时的具体环境联系起来,才能得到

理解,它也是用户无法完成主动信息告知的主要原因。

16、民族志：民族志是由人类学家最早提出来的,用来理解原始社会（Primitive Societies）的社会机制。它要求人类学家花费长期的时间（通常是数年）在被研究的社会中生活并且仔

细观察该社会中的实际活动,得到第一手的观察数据。对这些观察数据的分析可以揭示被研

究社会的社会结构、组织方法和具体活动。

17、模型驱动法：模型驱动法是一类以定义明确的模型为理论基础,依据模型指导和

组织活动开展的需求工程方法。

18、用例驱动法：用例是一种场景的文本化表现方式,使用叙述性的文本来描述场景。以用例为核心,围绕用例开展活动的软件开发方法被称为用例驱动的软件开发方法。

19、企业建模：企业建模是以使用产品的组织团体为系统的环境,进行分析。它主要

用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等。企业建模利用企业的目标、任务、策略、资源等来刻画组织的行为,并依此来发现组织开发系统的目的,建立系统的业务需求。

20、过程建模：过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程

的集合,其中一些由人来执行,另一些由软件系统来执行。过程建模使用的主要技术有上下

文图、数据流图、微规格说明和数据字典等。

21、上下文图：上下文图是DFD最高层次的图,是系统功能的最高抽象,它将整个系

统看做是一个过程,这个过程实现系统的所有功能。上下文图中存在且仅存在一个过程,表

示整个系统。这个单一的过程通常编号为0。

22、概念数据模型：概念数据模型是以问题域的语言解释数据模型,反映了用户对共

享事物的描述和看法,由一系列应用领域的概念组成。

23、物理数据模型：物理数据模型是对数据模型的解系统语言的解释,它描述的是共

享事物在解系统中的实现形式,是形式化的定义。

24、逻辑数据模型：逻辑数据模型是为了缓解开发人员将概念数据模型转换成物理数

据模型的困难,而使用一种介于问题域和解系统之间的中立语言来进行的数据模型的描述。这种中立的语言使用更加倾向于用户的概念和词汇,同时使用更加倾向于解系统语言的表达方式。

25、关系的基数：关系的基数是衡量关系复杂性的指标之一,又被称为关系的约束。

一个实体在关系中的基数定义了在关系中其他实体实例确定的情况下,该实体实例可能参与关系的数量。

26、交互图（UML行为模型）：交互图用于描述在特定上下文环境中一组对象的交互行为,该上下文环境就是被实现用例的某个场景。所以,交互图通常描述的是单个用例的典型

场景。交互图中的每一个交互都描述了环境中的对象为了实现某个目标而执行的一系列消息交换。

27、OCL（语言）：OCL（Object Constraint Language）称为对象约束语言。OCL不是编程语言而是一种建模语言,它在保证一定表达能力的前提下,注重于语言的简洁性和抽象性。但它无法被用来描述程序的控制逻辑和工作流程,而且它的表达式定义也无法在程序中得到直接的执行。

28、基线：基线是已经通过正式评审和批准的规格说明或产品,可以作为进一步开发的

基础,并且只有通过正式的变更控制过程才能修改它。

29、需求基线：需求基线（Requirements Baseline）就是被明确和固定的需求集合,是

项目团队需要在某一特定产品版本中实现的特征和需求集合。

30、需求跟踪：需求跟踪是一种有效的控制手段,能够在涉众的需求变化中协调系统的

演化,保持各项开发工作对需求的一致性。需求跟踪是以软件需求规格说明文档为基线,在

向前和向后两个方向上,描述需求以及跟踪需求变化的能力,分为前向跟踪（Pre—Traceabmty）和后向跟踪（Post—Traceability）两种。

五、问答题

1、简述需求工程的主要任务。

答：

需求工程有以下三个主要任务：

①需求工程必须说明软件系统将被应用的环境及其目标,说明用来达成这些目标的软

件功能,还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施

加的限制和约束,也即要同时说明软件需要“做什么”和“为什么”需要做。

②需求工程必须将目标、功能和约束反映到软件系统中,映射为可行的软件行为,并

对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果,是项目规划、

设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。

③现实世界是不断变化的世界,因此需求工程还需要妥善处理目标、功能和约束随着

时间的演化情况。同时,为了节省开支和进行需求规格说明的重用,需求工程还需要对目标、

功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。

2、简述常见的需求定义错误。

答：（划线部分为必答要点）

在实践和研究过程中,人们发现关于需求定义的具体的错误主要有以下几种：

①需求并没有反映用户的真实需要。

实践表明,获取用户的真实需求是非常困难的。

原因之一是用户在表达自己的需要时,可能会在潜意识下进行一定的加工。为了发现

用户的真实需求,需求工程师一定要进行问题分析,尽力发现问题背后的问题。

原因之二是在人际交流中,信息会发生自然的衰减,甚至扭曲,导致需求丁程师理解

的并非是用户所表达的。解决方法是在需求传递给开发人员之前,请提出需求的用户进行仔

细地检查和确认。

②模糊和歧义的需求。

在实践中,人们总是会有意和无意地写出模糊和歧义的需求定义。

无意中写出模糊和歧义的需求定义往往是因为选词造句不当,导致不同的人对同一项

需求产生了不同的理解。解决方法是为项目中重要的词汇建立一个公共的可共同理解的词汇表,然后在词汇表的基础之上进行需求的定义。

有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户,这些

用户关于需求的目标互相冲突,需求工程师于是采用了模糊化的处理方法。正确解决方法是

在项目前景的指导下,促进用户之间的协商解决。

③信息遗漏。

信息遗漏也是一类常见的问题,包括明显的信息遗漏和不明显的信息遗漏。

明显的信息遗漏,其主要原因在于项目的范围定义不当,可以通过加强对业务需求的

处理得以解决。

不明显的信息遗漏,是因为相关信息难以发现,只能靠需求工程师的经验来加以避免。

④不必要的需求。

产生不必要需求的原因主要是：

其一是用户将一些不必要的需求作为和开发人员谈判的筹码,然后通过自己对不必要需求的要求而在和开发人员的谈判当中取得真正想要的利益,例如金钱。对此问题,唯一需要的就是开发人员代表的谈判技巧。

其二是用户在交流中,总是害怕信息有所遗漏,并因此产生不利后果,因此用户总是倾向于表达各种各样的需要。要解决这个问题,就需要开发人员在进行用户需求的获取之前, 先定义明确的业务需求,然后根据业务需求进行用户需求的过滤和选择。

其三是需求开发人员“画蛇添足”,添加“用户肯定会喜欢”的功能,该类功能既会造成项目额外的耗费,又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用户为中心。

⑤不切实际的期望。

不切实际的期望也是实践中常见的需求定义问题,而且它在很大程度上影响着项目的成败。

面对不切实际的期望,要求软件开发者提供可行性、成本等足够的技术参考信息,帮

助用户对其进行取舍和调整。

3、简要说明需求获取活动的过程。

答：

（1）收集和应用背景资料,建立初始的知识框架。分析涉众的高层次问题,总结出系统的业务需求。

（2）设计一个高层次的解决方案,并确定解决方案需要具备的系统特性。高层次的解决方案和系统特性定义了项目的前景和范围。

（3）在项目的业务范围内,需求工程要寻找相关的涉众,并分析和涉众选择。

（4）对组织里存在大量的表格、单据等与业务相关的硬数据进行采样,它们是需求获取活动中一个重要的信息来源。

（5）针对某一次具体的需求获取活动,要依据项目范围确定主题和内容,涉众特征和硬数据,从而确定信息来源。获取方法通常只有综合内容、来源和系统环境三者才能做出正确的决定。

在内容、来源和方法都确定之后,需求工程师就可以开展具体的获取活动,获取用户

需求和问题域特性。

获取得到的具体信息要记录下来,以获取笔录的形式进行保存。

4、简述涉众识别的基本过程。

答：

涉众识别的基本过程如下：

①将初始涉众集中起来,进行一次头脑风暴,尽可能地列出一个涉众类别列表。

②对上一步产生的涉众类别列表进行分析,判断它们和软件系统的相关性,找出其中的键涉众类别。

③为上一步的各个关键涉众类别选择代表,集中起来进行进一步的头脑风暴,列出新的

涉众类别列表。如果新列出的涉众类别列表趋于稳定,就可以结束涉众识别过程。如果新列出的涉众类别列表有了新的发现,就提交新的涉众类别列表,转向第②步。

5、试比较面谈问题组织的三种结构。

答：

（1）金字塔结构

面谈问题的归纳式组织被看做是金字塔形状。使用这种形式时,会见者以很具体的问题（通常是封闭式的问题）开始,然后逐渐提高问题的开放度,同时允许被会见者用越来越笼

统的答案来回答问题。

在主动的情况下,如果会见者认为被会见者需要对话题进行预热,可以采用金字塔结构, 通过逐步的引导使被会见者进入讨论。

在被动的情况下,如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论某个话题,也可以采用金字塔结构。

在某个话题讨论结束的时候,使用金字塔结构的提问顺序也是有用的。

（2）漏斗结构

在这种结构中,会见者使用演绎的方法,以一般的、开放式的问题开始,然后用封闭式

的问题缩小可能的答复。这种面谈结构可看做是漏斗型。

在主动的情况下,漏斗结构为开始一场面谈提供了一种容易而轻松的途径。答复者即使答错了开放式问题,也不会感到压力。

在被动的情况下,当被会见者对话题有情绪,并且需要自由表达这些情绪的时候,需要

采用漏斗型提问顺序。或者在会见者事先对事实了解不多时,也应该采用漏斗结构的问题组织方式。

使用漏斗结构的一个好处是：用这种方式组织面谈能得出很多的详细信息,以至于没有必要使用长序列的封闭式问题。

（3）菱形结构

人们在面谈中常常会将上述两种结构结合起来使用,其中菱形结构就是一种最好的结合结果。这种结构以一种非常明确的方式开始,然后考察一般问题,最后得出一个非常明确的

结论。

会见者首先提出一些简单的、封闭式的问题,为面谈过程做好铺垫。在面谈的中间阶段, 向被会见者提出明显没有“正确答案”的一般话题的看法。然后,会见者再次限制问题以获得明确的答复,这样就为会见者和被会见者提供了面谈的结束时机。

菱形结构结合了其他两种结构的长处,但是也有缺点,即所花的时间比其他任何一个都长。

6、简述软件开发中为何使用原型工具以及使用的好处。

答：

因为原型是在最终系统产生之前的一个局部真实表现,所以原型方法可以让人们在系统的开发过程中,就能够对一些具体问题进行基于实物的有效沟通,从而帮助人们尽早解决软

件开发过程中存在的各种不确定性。不确定性是指人们已经拥有的知识是不充分的,不足以预测将来的事件发展,或者不足以清晰、准确地描述某个事物。

实践证明,利用原型有如下好处：

①及时、有力地响应用户需求的变化。

②减少返工。

③帮助控制不完整需求所带来的风险。

④可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤。

⑤减少开发成本,提高经济效益。

⑥增加开发者之间的交流,帮助确定技术解决方案的可行性。

⑦有效地识别风险和解决风险,帮助进行风险管理。

⑧提高用户在软件开发中的参与程度。

7、试说明在哪些情景下原型法可以帮助需求工程师及早解决需求的不确定性。

答：

①产品以前从未存在过,而且难以可视化。这些产品属于创新性产品,它们的基本需求是潜在的,有着很大的不确定性。

②产品的用户对相关类别的产品没有经验,而且对将要采用的技术也没有经验。此时用户无法明确工作的具体细节,产品的细节需求存在着不确定性。

③用户进行自己的工作已经有一段时间了,但在完成工作的方式上仍然存在障碍。此时用户无法判断问题的解决方案是否现实可行,所以产品在整体方案的可行性上存在着不确定性。

④用户在清晰说明他们的需求方面存在困难,例如默认需求或者潜在需求。这些相关的需求是有着不确定性的需求。

⑤需求工程师在理解用户的需求上存在困难。在澄清和理解之前,这些需求存在着不确定性。

⑥需求的可行性值得怀疑,即具体需求的可满足性存在着不确定性。

8、试比较原型开发方法的三种类型。

答：（划线部分为必答要点）

（1）探索式

探索式原型法是以缺陷需求开始继而不断调整和修正需求的原型开发方式。探索式的原型方法通常要尽可能地调整各种设计选项（例如需求内容、软件化内容以及软件支持方式等）,并比较多种设计方案下的用户反馈以得到理想的用户需求。探索式的原型方法能够帮助开发者更深入地了解用户的业务、问题和期望。

（2）实验式

实验式的原型方法初始时拥有清晰的用户需求,但是开发者对这些需求的实现方法、

实现效果和可行性没有太大的把握。实验式的原型方法需要首先定义一个对原型的评估方法,确定评估的属性（例如可行性、适用性、效率、吞吐量等）,据此评估各种技术方案下的原型,明确需求的可行性和有效的技术实现方案。

（3）演化式

在演化式的原型方法中,原型的开发并不是一个独立的活动,而是整个项目的持续开

发过程中的一个部分。原型开发的初始点既有要求原型化的需求,也有项目积累下来的原型资产。积累下的原型资产所没有实现的需求,往往是清晰的需求。在开发原型时,还要能够以一个整体的方式传递给下一个原型开发过程。这个被不断传递和不断增强的原型资产将成为最终的软件系统。通过在持续开发过程中使用原型方法,可以使软件开发过程更好地处理用户需求的不断变动。

在探索式、实验式和演化式这三种原型方法中,前两种方法产生的原型往往是在经历

了很多次错误的尝试之后才产生的。这些错误的尝试过程会在最终的原型产品中留下痕迹, 原型中的一些代码是在错误的前提（错误的需求、错误的技术方案）下完成的,它们会使原型产品具有很差的质量,所以人们在得到正确的尝试之后往往会抛弃这些原型产品,另起炉

灶。为此,探索式和实验式方法产生的原型产品又被称为抛弃式原型（Throwaway Prototype）。

抛弃式原型的贡献不在于它的代码,而是它所包含的内容,它说明了正确的需求和正

确的技术方案。

因为抛弃式原型的代码是要被抛弃的,所以在建立抛弃式原型时,应该尽量花费最小

的代价,争取最快的速度。为此,原型的开发者会使用一些简易的开发工具和不成熟的构造

技术,忽略或简化一些和原型目标不相关的功能特征。

9、试述在需求获取中使用原型方法的主要步骤。

答：

在需求获取中使用原型方法的主要步骤包括：

①确定原型需求。搞清楚为什么要开发原型,拥有的起始点是什么,期望的结束标准是

什么?

②原型开发。依据原型的需求特点和开发目的,选择原型的开发方法和构建技术,建

立初始原型。

③原型评估。对上一阶段产生的原型进行评估,根据评估者的反馈判断原型是否满足

结束标准。评估者一般是用户和开发者。

④原型修正。如果已经建立的原型达到了目的,就结束原型方法过程。否则根据评估

者反馈的不足进行原型调整,调整完成后准备再次进行原型评估。

10、简述使用原型方法的主要风险。

答：

原型方法的最大优点是能够及早地解决系统开发中的不确定性,从而降低软件项目失

败的风险,但原型方法的复杂性使得它在降低风险的同时也引人了新的风险。

（1）原型方法最大的风险就是涉众看到了一个正在运行的原型,从而得出产品几乎已

经完成的结论,从而提出快速交付产品的不当要求。

（2）原型方法的另一个风险是用户可能会被原型所表现出来的非功能特性遮蔽了眼

睛,从而忽略了他们更应该重视的功能特性。

（3）原型方法的第三个风险是原型方法在澄清需求不确定性的同时也可能会掩盖一些

用户的假设,这些假设将会无从发现。,原型的开发者要仔细地分析原型的

（4）最后,还应该避免对原型开发工作投入太多的工作,使开发团队消耗了过多的时

间和过大的成本,最后被迫只能匆匆忙忙实现一个产品,甚至只是交付一个原型。

11、试比较两种采样观察法的优劣。

答：

（1）时间采样

时间采样的优点：

①在于可以减少在任何某个单独时间段内进行观察时可能发生的偏差,将偶尔才发生

的事件看做是重要的业务事件。

②时间采样还可以只选取频繁发生的活动中一个代表样本进行观察,节省时间和成本。

时间采样的缺点：

①时间采样是以分段方式收集观察的数据,无法为某些长事件提供充分的观察时间。

②一些很少发生（或不经常发生）但又非常重要的事件可能得不到观察,因为它们没

有出现在采样的时间之内。

（2）事件采样

软件需求分析考试资料

1、需求分析的最终结果是需求规格说明书。 2、需求分析中开发人员要从用户那里解决的最重要的问题是让软件做什么。 3、需求规格说明书中的内容不应该包括对算法的详细过程的描述。 4、需求规格说明书的作用不应包括软件可行性研究的依据。 5、关于面向对象方法中消息的叙述，不正确的是操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息。 6、面向对象技术中，对象是类的实例，对象有三种成分标识、属性、方法（或操作） 7、软件需求分析阶段的工作，可以分成以下四个方面对问题的识别、分析与综合、制定规格说明以及需求分析评审。 8、软件需求规格说明书的内容不应该包括对算法的详细过程的描述。 9、产品特性可以称为质量属性，在众多质量属性，对于开发人员来说重要的属性有哪些？可维护性、可移植性、可重用性、可测试性 10、求包括11个方面的内容，其中网络和操作系统的要求属于环境需求，如何隔离用户之间的数据属于安全保密需求，执行速度、相应时间及吞吐量属于性能需求，规定系统平均出错时间属于质量保证。 11、需求分析过程应该建立3中模型，他们分别是数据模型、功能模型、行为模型，以下几种图形中，数据流图（DFD）属于功能模型，实体-联系图（ERD）属于数据模型，状态转换图（STD）属于行为模型。 12、常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向对象的分析的分析方法（OOA），下列(D)不是结构化分析方法的图形工具。 A 决策树 B 数据流图C数据字典D快速原型 13、软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性，其中，探索型和实验型用完可以丢弃，而进化型围绕原型修改、增加。 14、数据流图用于描述数据的处理过程。 15、DFD 的基本符号不包括下列哪种？（A）。 A 数据字典 B 加工 C 外部实体 D 数据流 E 数据存储文件 16、DD的主要字典条目包括以下哪种（E） A 数据流B文件 C 数据项D加工E以上都是 17、常用的动态分析方法不包括以下哪种（B） A 状态迁移图 B 层次方框图 C 时序图 D Petri网 18、需求分析阶段的文档包括以下哪些（E） A 软件需求规格说明书 B 数据要求说明书 C 初步的用户手册 D 修改、完善与确定开发实施计划 E 以上都是 19、需求验证应该从下述几个方面进行验证：（C） A 可靠性、可用性、易用性、重用性 B 可维护性、可移植性、可重用性、可测试性 C 一致性、现实性、完整性、有效性 D 功能性、非功能性 20、风险管理的要素包括哪些（D） A 风险评价 B 风险避免 C 风险控制 D 以上都是 21、下列描述中错误的是（D） A 每一个集成的需求变更必须能跟踪控制到一个经核准的变更请求。 B 变更过程应该做成文档，尽可能简单，当然首要的是有效性。 C 所有需求变更必须遵循过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。 D 可以从数据库中删除或修改变更请求的原始文档。

软件测试工程师笔试题及答案

测试工程师笔试题一、计算机知识（30分） 1、在Linux系统中，一个文件的访问权限是755，其含义是什么？参考答案： 755表示该文件所有者对该文件具有读、写、执行权限，该文件所有者所在组用户及其他用户对该文件具有读和执行权限。 2、Linux中，如何从root用户切换到普通用户？参考答案：su su user1 切换到user1，但切换后的当前目录还是root访问的目录 su – user1 切换到user1，并且当前目录切换到user1的根目录下（/home/user1/） 3、简述一下C/S模式和B/S模式的区别？参考答案： c/s 是客户端/服务器架构 b/s 是浏览器/服务器架构 C/S模式有以下特点: 1.C/S模式将应用与服务分离,系统具有稳定性和灵活性 2.C/S模式配备的是点对点的结构模式,适用于局域网,有可靠的安全性 3.由于客户端实现与服务器端的直接连接,没有中间环节,因此响应速度快 4.在C/S模式中,作为客户机的计算机都要安装客户机程序,一旦软件系统升级,每台客户机都要安装客户机程序,系统升级和维护较为复杂 B/S模式有以下特点： 1.系统开发、维护、升级方便每当服务器应用程序升级时，只要在服务器上升级服务应用程序即可，用户计算机上的浏览器软件不需要修改，系统开发和升级维护方便 2.B/S模式具有很强的开放性在B/S模式下，用户通过通用的浏览器进行访问，系统开放性好 3.B/S模式的结构易于扩展由于Web的平台无关性，B/S模式的结构可以任意扩展，可以从包含一台服务器和几个用户的小型系统扩展成为拥有成千上万个用户的大型系统 4.用户使用方便 B/S模式的应用软件都是基于Web浏览器的，而Web浏览器的界面是类似的。对于无用户交换功能的页面。用户接触的界面都是一致的，用户使用方便 4、Windows操作系统中PATH环境变量的作用是什么？参考答案： PATH是Windows操作系统环境变量，PATH作用是用户在命令行窗口执行一个命令，则在PATH变量设置的目录下依次寻找该命令或对应的执行文件，若找到，则执行，若没有找到，则命令行窗口返回无效命令。 5、TCP和UDP有什么区别？参考答案： TCP-有连接,所以握手过程会消耗资源,过程为可靠连接,不会丢失数据,适合大数据量交换

软件需求分析

软件需求分析目录 1．引言 1.1项目名称 1.2编写目的 1.3开发背景 2．任务概述 2.1目标 2.1.2 应用目标 2.2运行环境 3. 数据描述 4.功能要求 4.1功能划分 4.2功能描述 5.性能要求 5.1数据精确 5.2时间特性 5.3适应性 6.运行需求 6.1用户界面 6.2硬件接口 6.3软件接口

6．4故障处理 7.其他要求 8.实现代码（部分） 9.个人感想 1．引言 1．1项目名称：制作一个财务管理系统 1．2编写目的：编写财务管理系统需求分析的目的是明确所开发的软件的功能、性能、界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，方便开发工作和测试工作。现代企业围绕提高经济效益而进行财务管理所要达到的目的，是评价企业财务活动是否合理的标准。国内外关于财务管理目标的观点众多，但影响较广的主要以下几种观点：企业利润最大化、股东财富最大化、投资报酬率最大化，资本配置最优化。 1．3开发背景：随着现代社会的快速发展，各个企业公司在多方面都不断地创新与提高，财务管理作为整个公司运筹的重要组成部分之一，因此大力发展财务管理很有必要，怎样合理而有效的提高财务管理水平和工作效率--已成为企业亟需解决的问题。为帮助企业更好的实现信息化管理，各个公司成功地推出了适应现代社会发展的财务管理软件，大大提高了企业的管理水平和工作效率，使企业能够从容面对激烈的市场竟争。

2．任务概述 2．1目标 2. 1.1开发目标财务系统用于让各地市、厅局等单位或部门等的各项与财务有关的资料的维护，同时提供良好的各项资产的管理。 2. 1.2应用目标项目的目标是实现对各个部门的财务信息的分层次管理，可以对管理人员设置角色，实现对不同部门，不同操作权限的设置。 2．2运行环境 ?Windows xp操作系统 ?MyEclipse 3．数据描述共有1个表，分别为通讯录管理系统的数据库，财务上包括姓名、职位、工资等字段 4．功能要求 4．1功能划分本系统有以下功能模块： 1）登陆模块 2）数据输入功能 3）数据显示功能 4）查询功能 5）修改功能

软件需求分析习题大全

习题集一、单项选择题 1、需求分析最终结果是产生（）。 A．项目开发计划 B．可行性分析报告 C．需求规格说明书 D．设计说明书答案：C 2、需求分析中，开发人员要从用户那里解决的最重要的问题是（）。 A．让软件做什么 B．要给软件提供哪些信息 C．要求软件工作效率怎样 D．让软件具有何种结构答案：A 3、需求规格说明书的内容不应包括对（）的描述。 A．主要功能 B．算法的详细过程 C．用户界面和运行环境 D．软件性能答案：B 4、需求规格说明书的作用不应包括（）。 A．软件设计的依据 B．用户与开发人员对软件要做什么的共同理解 C．软件验收的依据 D．软件可行性研究的依据答案：D 5、下面关于面向对象方法中消息的叙述，不正确的是（）。 A．键盘、鼠标、通信端口、网络等设备一有变化，就会产生消息B．操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D．发送与接收消息的通信机制与传统的子程序调用机制不同答案：B

6、面向对象技术中，对象是类的实例。对象有三种成份：（）、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息答案：A 7、软件需求分析阶段的工作，可以分成以下四个方面：对问题的识别、分析与综合、制定规格说明以及（）。 A．总结 B．实践性报告 C．需求分析评审 D．以上答案都不正确答案:C 8、软件需求规格说明书的内容不应包括对（）的描述。 A．主要功能 B．算法的详细过程 C．用户界面及运行环境 D．软件的性能答案:B 9、产品特性可以称为质量属性，在众多质量属性中，对于开发人员来说重要的属性有哪些（B ） A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性 10、需求包括11个方面的内容，其中网络和操作系统的要求属于（B ），如何隔离用户之间的数据属于（C），执行速度、相应时间及吞吐量属于（D ），规定系统平均出错时间属于（A ）。 A 质量保证 B环境需求 C安全保密需求 D 性能需求

需求分析师岗位的工作职责描述

需求分析师岗位的工作职责描述需求分析师负责产品开发阶段推动工作：跟进产品开发进度，配合解决开发过程中的问题及涉及到的环境资源，确保产品按计划完成。以下是OK的需求分析师岗位的工作职责描述。职责： 1、参与需求调研分析工作，收集用户需求，进行需求合理性和可行性判断，判断用户需求与现在产品或已规划产品的关系，并对用户进行引导; 2、参与软件项目的需求分析，关注业务的逻辑与设计的合理性; 3、深度挖掘分析用户需求，能从用户的表面需求分析出用户深层次的实际需求，并提出相应的改进方案; 4、与开发测试团队一起参与项目系统的开发流程，负责需求开发与跟踪，完成需求变更的控制与管理; 5、对新项目产品规划设计及服务流程设计负责; 任职要求：

1、计算机相关专业，大专及以上学历; 2、1年以上需求分析经验，有开发经验者优先; 3、掌握需求分析规划工具，熟练使用axure等原型设计工具; 4、具备优秀的分析判断能力和方案设计能力; 5、具有良好的团队合作精神，工作认真负责，有责任心; 职责： 1、开展需求调研，完成调研报告和需求规格说明书 2、向开发工程师提供咨询、指导、解释业务需求，向用户汇报系统功能; 3、和分析客户需求，对其分类汇总和实现预估，提出需求分析报告和实现计划要求; 任职资格：

1、具有较强的沟通能力，逻辑思维能力和文档编写能力; 2、掌握需求分析方法，熟悉需求管理和研发过程管理; 3、熟练掌握界面原型、业务流程等制作工具; 4、熟练掌握SQL，能够对ORACLE，MYSQL等数据库进行DML操作; 5、具备人力资源相关系统需求开发经验优先; 职责： 1、参与需求调研工作和产品定义评估。业务需求讨论和设计工作。 2、可以和客户沟通需求，能够引导客户，获取需求，进行需求分析，进行原型设计，编写用户需求和产品需求; 3、能够基于产品对软件需求进行管理，能够对需求进行验证满足度。

软件测试需求分析完整版

软件测试需求分析 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

软件系统测试需求分析模版产品名称： _____ 项目承担部门：_______________________________ 本文档使用部门：撰写人：_______________________________ _______________________________ 完成日期： _____ 评审负责人:评审日期：_______________________________ _______________________________ 目录

修订历史记录 1概述测试需求分析的目的测试需求分析的目的是明确应测什么，了解测试规模、复杂程度与可能存在的风险，其核心是产品质量符合用户明确的或者隐含的需求程度。测试需求分析的依据 1)待测软件系统相关的需求文档，如《xxx系统软件需求规格说明》； 2)待测软件系统相关的设计文档，如《XXX系统设计文档》； 3)GB/《软件工程产品质量第1部分：质量模型》； 4)GB/T 《软件工程软件产品质量要求与评价(SQuaRE) 商业现货(COTS) 软件产品的质量要求和测试细则》； 5)软件系统相关的协议、规范； 6)待测软件系统业务行标。测试需求分析的方法 1)列出软件开发需求中具有可测试性的开发需求； 2)对1）中的每一条开发需求，形成可测试的分层描述的测试需求；

3)对2）形成的测试需求，从GB/《软件工程产品质量第1部分：质量模型》由定义的软件内部/外部质量模型来确定软件产品的质量需求； 4)对3）所确定的质量要求，分析测试执行时需要实施的测试类型； 5)建立测试需求跟踪矩阵，对需求进行管理。 1.4定义 [列出测试需求说明书中用到的专业术语的定义和外文首字母词组的原词组、缩写词和符号。] 2软件产品说明项目背景 [简要介绍产品的项目背景，行业、主要承担业务等。] 项目需求说明填写相关信息或相关文档，如详见《XXX系统需求说明文档》。项目整体设计说明填写相关信息或相关文档，如详见《XXX系统总体设计》。 3测试需求分析原始需求原始需求是从用户需求、产品包需求、系统需求、测试经验库、协议规范等需求来源中提取的经过整理的输入集合。本文的原始需求亦即经过整理成文的业务需求，将每一条需求对应的系统、业务需求编号、业务需求说明及相关文档注明。其中系统名称为被测系统名称；需求版本号为业务需求版本号；业务需求的编号和业务需求名称引用需求分析文档编号及名称，描述引用需求分析文档描述。产品测试需求列表

软件工程考试题库

类型一： 1. 软件定义时期包括两个阶段，它们是（可行性研究）和（需求分析）两个阶段。 2. 数据流图有（4）种基本符号，数据流图中，箭头表示（数据流）。 3. 数据流图有变换型结构和（事务）型结构两种类型。 4. 4个人之间的通信量是（6） 5. 评定模块的独立性的标准是耦合和内聚。（耦合）是对软件内部块间联系的度量，按照由弱到强的顺序，可以把它分为（7）类。其中，最弱的是（非直接耦合），最强的是（内容耦合） 6.程序结构的复杂性度量值V（G）取决于程序控制流的复杂程度。顺序结构的V（G）值为（1），选择结构的为（2）。 7. 在模块结构图中，（扇入）是指直接调用该模块的模块数 8.模块的独立性可用耦合和内聚的高低来评定，设计较好的模块要求（内聚）高、耦合（低）。 9. 语句覆盖测试技术是（白盒测试）方法的一种 10. 等价类划分技术是属于（黑盒测试）方法的 11. 按维护的起因，可以将维护活动分为4类：（改正性维护）、（适应性维护）、完善性维护和预防性维护。完善性维护占总维护量的（50%以上）。 12．软件项目的可行性研究要进行一次（简化的、压缩的）需求分析。 13、系统流程图用于可行性分析中的（当前运行系统）的描述。 14、程序的三种基本控制结构的共同特点是（只有一个入口和一个出口） 15、维护中，因误删除一个标识符而引起的错误是（编码）副作用。 16、（技术评审）是以提高软件质量为目的的技术活动。 17、面向对象方法学的出发点和基本原则是尽可能模拟人类习惯的思维方式，分析、设计和实现一个软件系统的方法和过程，尽可能接近于人类认识世界解决问题的方法和过程。因此面向对象方法有许多特征，如软件系统是由对象组成的；（把对象划分成类，每个对象类都定义一组数据和方法）；对象彼此之间仅能通过传递消息互相联系；层次结构的继承。 18、原型化方法是用户和设计者之间执行的一种交互构成，适用于（需求不确定性高的）系统。 19．在下列工具与环境中（结构的基于图形CASE ）属于较早期的CASE。20．Putnam成本估算模型是一个（动态多变量）模型。 21．在McCall软件质量度量模型中，（适应性）属于面向软件产品修改。 22．ISO的软件质量评价模型由3层组成，其中用于评价设计质量的准则是（SQDC ）23．软件复杂性度量的参数包括（规模） 24．对象实现了数据和操作的结合，使数据和操作（封装）于对象的统一体中。25．软件调试技术包括（演绎法） 26．瀑布模型的存在问题是（缺乏灵活性） 27．软件测试方法中的静态测试方法之一为（计算机辅助静态分析） 28．软件生命周期中所花费用最多的阶段是（软件维护） 29．第一个体现结构化编程思想的程序设计语言是（PL/1语言） 30．程序的三种基本控制结构是（顺序、选择和重复） 31．在详细设计阶段，经常采用的工具有（PAD ） 32．详细设计的结果基本决定了最终程序的（质量） 33．需求分析中开发人员要从用户那里了解（软件做什么） 34．结构化程序设计主要强调的是（程序易读性）

软件测试工程师笔试理论题库1

理论题库 1 2 3 4 5 6 7 8 9 10 C C DBC C D A B D B C 11 12 13 14 15 16 17 18 19 20 C D B B C B B D A D 21 22 23 24 25 26 27 28 29 30 D B B A A AC C D D C 31 32 33 34 35 36 37 38 39 40 B C D C DBC D A C C D 41 42 43 44 45 46 47 48 49 50 BAA B ADD B B A D B B D 51 52 53 54 55 56 57 58 59 60 C D B D C B A C A B 61 62 63 64 65 66 67 68 69 70 C B A D A C B B C C 71 72 73 74 75 76 77 78 79 80 A A D D D A D B D B 81 82 83 84 85 86 87 88 89 90 B A D C D B C B C B 91 92 93 94 95 96 97 98 99 100 A B B A BA AD A C A C 单选题 1．是常见的接受电子邮件协议。A．HTTPS B.ET C.POP3 D.DNS

2．系统中有四个作业，它们的到达时间、运行时间、开始时间、完成时间和周转时间如表1所示，该系统采用的作业调度算法是。表1 作业到达时间计算时间（分）开始时间完成时间周转时间（分） J1 8:00 60 8:00 9:00 60 J2 8:10 20 9:10 9:30 80 J3 8:20 10 9:00 9:10 50 J4 8:40 15 9:30 9:45 65 A、先来先服务 B、短作业优先 C、响应比高者优先 D、不能确定 3．数据库系统实现数据独立性是因为采用了 (1) 。当两个子查询的结果 (2) 时，能够执行并、交、差操作。 SELECT语句中“SELECT DISTINCT”表示查询结果中 (3) 。 (1) A、层次模型 B、网状模型 C、关系模型 D、

软件测试需求分析报告

软件系统测试需求分析模版产品名称：_____ 项目承担部门：_______________________________ 本文档使用部门：撰写人：_______________________________ _______________________________ 完成日期：_____ 评审负责人: 评审日期：_______________________________ _______________________________

目录目录 (2) 修订历史记录 (3) 日期 (3) 版本 (3) 说明 (3) 作者 (3) 1概述 (4) 1.1测试需求分析的目的 (4) 1.2测试需求分析的依据 (4) 1.3测试需求分析的方法 (4) 1.4 定义 (5) 2 软件产品说明 (5) 2.1项目背景 (5) 2.2项目需求说明 (5) 2.3项目整体设计说明 (5) 3测试需求分析 (5) 3.1原始需求 (5) 3.2产品测试需求列表 (6) 3.3测试类型确定 (11) 3.4测试环境要求 (12) 4测试规格评估 (12) 4.1 测试类型评估 (12) 4.2测试用例密度 (13) 4.3 需求覆盖率 (13)

修订历史记录

1概述 1.1测试需求分析的目的测试需求分析的目的是明确应测什么，了解测试规模、复杂程度与可能存在的风险，其核心是产品质量符合用户明确的或者隐含的需求程度。 1.2测试需求分析的依据 1)待测软件系统相关的需求文档，如《xxx系统软件需求规格说明》； 2)待测软件系统相关的设计文档，如《XXX系统设计文档》； 3)GB/T16260.1-2006《软件工程产品质量第1部分：质量模型》； 4)GB/T 25000.51-2010《软件工程软件产品质量要求与评价(SQuaRE) 商业现货(COTS) 软件产品的质量要求和测试细则》； 5)软件系统相关的协议、规范； 6)待测软件系统业务行标。 1.3测试需求分析的方法 1)列出软件开发需求中具有可测试性的开发需求； 2)对1）中的每一条开发需求，形成可测试的分层描述的测试需求； 3)对2）形成的测试需求，从GB/T16260.1-2006《软件工程产品质量第1部分：质量模型》由定义的软件内部/外部质量模型来确定软件产品的质量需求； 4)对3）所确定的质量要求，分析测试执行时需要实施的测试类型； 5)建立测试需求跟踪矩阵，对需求进行管理。

软件需求分析考试题

一、单选题（每空1分，共20分，请在备选答案中选择唯一一个正确的选项） 1、产品特性可以称为质量属性，在众多质量属性中，对于开发人员来说重要的属性有哪些（B ） A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性 2、需求包括11个方面的内容，其中网络和操作系统的要求属于（B），如何隔离用户之间的数据属于（C），执行速度、相应时间及吞吐量属于（D），规定系统平均出错时间属于（A ）。 A 质量保证B环境需求C安全保密需求 D 性能需求 3、需求分析过程应该建立3种模型，它们分别是数据模型、功能模型、行为模型。以下几种图形中，（B）属于功能模型，（A）属于数据模型，（C）属于行为模型。 A 实体-联系图(ERD) B 数据流图(DFD) C 状态转换图(STD) D鱼骨图 4、常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向对象的分析方法（OOA），下列(D)不是结构化分析方法的图形工具。 A决策树B数据流图C数据字典D快速原型 5、软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。其中，（B）和（C）用完就可以丢弃，而（A）围绕原型修改、增加。 A 进化型 B 探索型C实验型 D 以上都是 6、（D）用于描述数据的处理过程。 A 数据字典B决策树C决策表 D 数据流图 7、DFD的基本符号不包括下列哪种（A） A 数据字典 B 加工 C 外部实体 D 数据流 E 数据存储文件 8、DD的主要字典条目包括以下哪种（E） A数据流B文件 C 数据项D加工E以上都是 9、常用的动态分析方法不包括以下哪种（B） A 状态迁移图 B 层次方框图C时序图 D Petri网 10、需求分析阶段的文档包括以下哪些（E） A 软件需求规格说明书B数据要求说明书C初步的用户手册D修改、完善与确定软件开发实施计划E以上都是 11、需求验证应该从下述几个方面进行验证：（C） A 可靠性、可用性、易用性、重用性B可维护性、可移植性、可重用性、可测试性 C一致性、现实性、完整性、有效性D 功能性、非功能性 12、风险管理的要素包括哪项（D） A风险评价B风险避免C风险控制D以上都是 13、下列描述中错误的是（D） A每一个集成的需求变更必须能跟踪到一个经核准的变更请求。 B变更过程应该做成文档，尽可能简单，当然首要的是有效性。 C所有需求变更必须遵循过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。 D可以从数据库中删除或修改变更请求的原始文档。二、填空题（每空2分，共30分） 1、软件开发的生命周期包括（需求分析）、软件设计、代码实现、（测试）、（实施）、维护，共六个阶段。

需求分析师笔试题有参考答案

需求分析师笔试题考号：姓名：一．单项选择题（每题2分） ◆在项目立项阶段应该进行需求定义，此时定义的需求属于需求三个层次中的（1）A：它不应该包括的内容是（2）C。（1） A.业务需求 B.用户需求 C.软件需求 D.设计约束（2） A.用上下文关系图表示的项目范围 B.包含的主题域及主题域之间的关系 C.业务活动的详细事件流 D.系统涉及的业务事件 ◆根据下面所示的构件图能够得知，接口提交采购申请是（3）C实现的，客服管理子系统共使用了（4）D接口。（3） A.门店管理子系统 B.客服

管理子系统 C.采购管理子系统 D.无法确定（4） A.1个 B.2个 C.3个 D.4个 ◆以下关于需求定义的描述中，正确的是（5） D；对于酒店管理系统而言，以下各个选项中，（6）C最不适合表示为业务事件。（5） A.上下文关系图能够清晰地界定出系统与人的职责边界 B.鱼骨图和帕累托图是来界定系统范围的 C.项目涉众（stakeholder）就是将使用系统的用户 D.需求定义的产物主要包括项目目标、范围以及需求大纲的初稿（6） A.入住 B.换房 C.付款 D.续房 ◆在需求捕获的过程中，用户经常会制定解决方案而不是阐述需求，有效识别这一情况的措施是（7）A：以下措施中，（8）A是用来克服用户非正事心理的。（7） A.询问用户提出需求的理由

B.提前向用户提供访谈计划 C.利用原型来及时验证用户的需求 D.让用户介绍工作场景（8） A.选择打扰较少的访谈场所 B避免向用户提出过细的问题 C.让用户以介绍工作场景为主 D.经过业务流程图确认访谈正确的对象 ◆在下面关于需求验证任务的描述中，不正确的是（9）D：需求验证属于需求工程中的（10）A范畴。（9） A.需要核查功能描述的正确性 B.需要核查功能描述的清晰性 C.需要明确需求的完整性 D.除管理者外的用户不能参与评审（10） A.需求开发 B.需求管理C需求文档化 D.需求跟踪 ◆根据下面的活动图，最可能是不合适的用例的是（11）D，理由是（12）。

软件测试工程师笔试题有答案

软件测试笔试题（含答案） 1.请写出一个你工作经历中的一个功能点测试用例，例如：用户页面登陆 2.请在以下两个项目当中，选择一个，考虑如何进行用例设计：a.杯子 b.有弹簧的圆珠笔杯子：需求测试:查看杯子使用说明书界面测试:查看杯子外观功能度：用水杯装水看漏不漏；水能不能被喝到安全性：杯子有没有毒或细菌可靠性：杯子从不同高度落下的损坏程度可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用软件开发网兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等易用性：杯子是否烫手、是否有防滑措施、是否方便饮用用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等压力测试：用根针并在针上面不断加重量，看压强多大时会穿透强度测试: 杯子加包装(有填充物),在多高的情况摔下不破损有弹簧的圆珠笔：功能测试：圆珠笔按下是否能正常写字，写字太重会不回缩回去，继续按会不会弹回去性能测试：圆珠心弹出弹回的快慢

负载测试：一直按，弹簧能接受多少次的升缩兼容性测试：换其他的笔芯能不能行强度测试：用力过度会怎样可恢复性测试：如果弹簧压久了，是否可恢复等等 GUI测试：笔的外观，拿笔的舒适性安全性：考虑对笔芯的保护，是否对使用者造成危害等等 3.白箱测试和黑箱测试是什么?什么是回归测试? 白箱测试是在看懂程序代码和设计方案的前提下，进行软件的测试。这种测试注重于源代码的覆盖率，同时需要测试者具备较高的技术水平。白箱测试的优点是可以对代码有详细的审查，能找出隐藏在代码中的错误，从而确保高质量的代码；缺点是很多时候不能看完所有的代码，不能找出欠缺的代码，同时白箱测试和用户如何使用软件无关。黑箱测试的优点是测试者无需熟悉软件内部结构，并且根据蓝图在早期就可以制定测试方案，并不依赖于开发者的工作进展，而且黑箱测试简单易行，对测试者的技术要求不高；但是，黑箱测试主要是功能上的测试，只能覆盖只有一小部分的输入，不能保证程序的所有部分都被测试到。回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致

《软件需求分析》单选填空判断答案

《软件需求分析》习题集《软件需求分析》课程组编 2012年4月

目录一、单项选择题 (2) 二、填空题 (5) 三、判断题 (9)

《软件需求分析》习题集一、单项选择题 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、如果在最终的物件（Final Artifact）产生之前，一个中间物件（Mediate Artifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的（）。（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）交互

软件测试工程师面试题汇总(华为篇)

软件测试工程师面试题汇总（华为篇） 1、怎么来设计测试方案根据测试需求（包括功能需求和非功能性需求），识别测试要点，识别测试环境要求，安排测试轮次，根据项目计划和开发计划做整体的测试安排。被测试的特性：通过对需求规格说明书进行分析，列出本次测试需要进行测试的各部分特性（如要测试的功能需求、性能需求、安全性需求等等）。不被测试的特性：由于资源、进度等方面原因，本次测试不列入测试范围的特性。测试组网图：进行本次系统测试所需要的软硬件设备、配置数据及相互间的逻辑、物理连接。今后测试执行时需要依据这个组网图来进行环境的搭建。 2、如果给你一个B/S系统你怎么来进行测试此题答案还可用于回答测试流程，测试流程题亦可参考15题。阅读系统需求，充分理解需求，记录问题，并与项目需求人员充分沟通。编写测试需求，包括系统功能和非功能测试要点、罗列测试类型、测试进度、质量要求等。制定测试计划，包括熟悉测试业务、设计测试用例、执行测试用例、进行测试小结、编写测试报告，任务颗粒度一般应小于5人天编写测试用例，根据测试方案设计用例，即便没有明确的性能和安全测试要求，也应识别进行此两项测试。执行软件测试。进行测试小结，如果测试持续时间较长，每个版本间隙总结本轮测试。编写测试报告，总结测试过程，汇总度量数据。 3、怎么进行工作流的测试把握需求，找准结点，理清流程，画出流转图，弄清节点间的数据流转，设计测试用例的时候必须覆盖所有可能的流程。工作流：如果问到有没有做过，根据对工作流的了解情况回答，如果比较了解，可以把参与的某个项目中说上一些有工作流的，如果不是很了解就说没有做过，但是学习过相关知识。 4、做性能测试的时候都需要关注哪些参数并发访问量，服务器响应时间（最小、平均、最大）并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。 5、客户没给性能指数，怎么开展性能测试如果客户没有提出明确的性能指标，可以按照惯例和经验设置，需要和项目经理协商，一般由项目经理确认，质量保证负责给出建议。举例说一个Server端程序，要求峰值时CPU和MEM消耗在75％以下，而一个页面的访问响应时间一般认为

软件测试流程规划

软件测试流程规划一、引言本文档规范了软件测试过程中的整体流程，明确了软件测试从开始到结束的各个阶段，以及在各阶段中的负责人、具体工作内容和必需的输入输出文档。另外，本文还介绍了各测试阶段需要的测试工具、测试点和测试步骤，并提供了各类测试文档的参考模板。二、测试流程概述 1、流程介绍一般来讲，软件测试是伴随着项目的立项而开始的。也就是说，软件项目一旦确立，测试工作也就开始了。在测试的过程中，前后要经过以下主要环节：需求分析—>制定测试计划—>搭建测试环境—>测试用例设计—>测试执行—>BUG回归测试—>测试总结—>软件发布对于以上流程环节，一般而言，需求分析属于需求分析人员的工作范畴，环境搭建、用例设计、测试执行以及回归测试等属于测试人员的工作范畴，测试负责人负责制定测试计划以及对各个环节的跟踪、实施、管理等。 2、流程图功能测试项目开始需求阶段测试计划测试阶段性能测试用户界面测试兼容性测试安全性测试接口测试测试总结软件发布

在这个阶段，主要是对于需求的收集、分析以及评估。 1.由需求分析人员统一收集需求，并整理成文档格式转发给项目经理、开发经理和测试经理； 2.项目经理召集开发经理、测试经理和需求分析人员进行会议讨论，了解具体每个需求的实际含义，并且明确各需求的有效性和可用性； 3.小组会议讨论，确定最终实现的需求和功能点，并整理出重点需求； 4.项目经理根据会议讨论结果编写需求说明，并且再次召集小组开会讨论，对需求说明进行修复、完善，并最终确定《需求规格说明书》。负责人：项目经理输入文档：需求说明文档输出文档：《需求规格说明书》四、测试计划阶段作为测试的起始步骤和重要环节，测试计划是对测试全过程的组织、资源、原则等进行规定和约束，并制定测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析和管理需求。用一句话概括就是：测试计划是从管理角度对整个测试活动进行规划和控制。测试计划的主要内容可分以下几个方面： 1.测试概述（介绍项目测试的范围、目的以及组织形式） 2.测试进度（测试时间周期的安排） 3.测试策略（包括测试环境、测试工具及测试方法） 4.需求跟踪（确定系统测试项与需求之间的对应关系） 5.测试通过失败标准（指明测试何时通过何时结束） 6.测试挂起恢复标准（指明当测试过程无法进行下去时测试活动挂起以及恢复的标准） 7.资源分配（工作量的统计以及工作任务的安排） 8.应交付测试工作产品（明确测试需要提交的各类工作文档） 9.风险评估（预估测试存在的风险）测试经理根据项目的总体进度、发布时间以及需求规格说明、开发计划制定相应的测试计划，完成后提交给项目经理。项目经理组织讨论会，连同开发经理、测试经理以及各模块负责人，对测试计划进行评审并确定。负责人：测试经理输入文档：《需求规格说明书》、《软件开发计划》输出文档：《软件测试计划》

软件课程设计需求分析

普通话考试报名及成绩查询系统需求分析项目名称：普通话考试报名及成绩查询系统撰写人：专业：指导老师： 2012年3月19日

摘要网络技术的飞速发展正无时无刻影响着人们的工作、在教育体系中,网络的应用也成为现代教育发展的基础.网络教育逐渐发展起来,校园网建设逐步成熟,基于Web的也伴随着网络技术的发展应运而生.它即简化了传统的考试模式,节约人力物力,也可以有效利用校园网资源,辅助教学. 该系统采用了目前流行的B/S模式,即浏览器、应用服务器、数据库服务器三层体系结构，后台数据库采用SQL Server 2005,客户端采用IE浏览器和服务器连接,最终形成了基于 B/S模式的在线考试系统.该系统具备了以下功能:学生信息管理、成绩查询等功能. 论文以基于B/S模式的在线考试系统为研究对象,按照软件工程的开发思想,用UML来构建在线考试系统模,后台采用数据库相结合. 际需求出发,论述了开发普通话等级考试报名及成绩查询系统的背景、目的及意义,讨论了开发系统的关键技术,并通过UML分析对系统设计及实现。设计思路和方法采用瀑布模型开发，用统一建模语言 UML进行描述，经历了文献检索，需求分析，分析模型设计，数据模型设计，构建级设计，系统部署，系统测试六个个环节。。实现了用户登录、注册功能，出题组卷功能，考试评卷功能以及用户信息查询功能。关键词：普通话等级考试报名及成绩查询系统； SQL SERVER2005

目录一．摘要 (2) 二．背景 (5) 三．简介 (5) 1.设计目的 (5) 2.开发环境 (5) 3.程序功能 (6) 4.系统实际需求特点 (6) 四．整体规划思路 (6) 五．整体性需求分析 (6) 六．功能需求 (9) 1.业务规则 (9) 2.普通话等级考试报名及成绩查询系统登录 (10) 七．数据库设计 (12) 1.概念模型设计 (12) 2.数据表结构 (12) 八．系统结构设计 (14) 九．对性能的规定 (15) 1.灵活性 (15)