软件需求分析笔试题库(3)

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、上下文图以黑盒看待和描述系统的方式使它非常适合描述系统的应用环境、定义系

10

统的边界,这正是 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）：范围指出当前项目是要解决产品长远规划中的哪一部分,范围声明 它为项目划定了需求的界线。

11

6、用户参与（User Involvement）：是以用户为中心的设计方法的核心思想,它要求开 发者建立和用户的直接联系,尽早地关注于用户和用户的任务执行过程,通过及时获得用户 的反馈来调整软件设计,以完成高质量的设计。另一方面,用户参与就是反对通过和市场人 员、管理者等中间媒介来了解用户,因为这些间接的联系会减少或歪曲用户的信息。 7、硬数据：表格和文档资料是用户对实际业务进行加工和抽象之后的结果,是一种精 化过的知识。这些文档资料被称为硬数据。硬数据分为定量硬数据和定性硬数据两种类型。 8、结构化面谈：结构化面谈指在面谈的过程中,会见者会完全按照事先的问题和结构 来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息,一些 统计性倾向信息的获取也可以使用结构化面谈。

9、半结构化面谈：半结构化面谈指在面谈的过程中,事先需要根据面谈内容准备面谈 的问题和面谈结构。但在面谈过程中,会见者可以根据实际情况采取一些灵活的策略。半结 构化面谈是在需求获取中应用最多的一种面谈类型,能够处理大部分的需求获取任务。 10、非结构化面谈：在非结构化面谈的过程中,没有事先预定的议程安排。在比较极 端的情况下,会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地,就 某个主题开展会谈。

11、头脑风暴（Brainstorming）：是一种特殊的群体面谈方式,它的目的不是发现需求, 而是“发明”需求,或者说是发现“潜在”需求。它鼓励参与者在无约束的环境下进行某些 问题的自由思考和自由讨论,以产生新的想法。它是需求获取中用于“发明”需求的方法, 但它会增加需求的数量。

12、原型：原型是一个系统,它内化了（Capture）一个更迟系统（Later System）的本 质特征。原型系统通常被构造为不完整的系统,以在将来进行改进、补充或者替代。” 13、严格意义上的原型：严格意义上的原型主要被用在需求分析阶段,是开发者在建 立系统信息模型的同时建立的原型,通常被用来阐明用户界面或者系统功能的某些特定方 面,帮助人们及时地澄清问题。

14、场景：场景是对系统和环境行为的局部描述,或者说场景是对行为或者事件序列 的描述,序列中的行为和事件是系统需要完成的一个任务的特殊示例。

（也可以说,场景是用户为了达到某个目标而和软件系统发生的行为交互序列,是开 发者描述软件功能和需求的一种重要形式。）

15、情境性：情景性是指某些事件只有和它们发生时的具体环境联系起来,才能得到 理解,它也是用户无法完成主动信息告知的主要原因。

16、民族志：民族志是由人类学家最早提出来的,用来理解原始社会（Primitive Societies） 的社会机制。它要求人类学家花费长期的时间（通常是数年）在被研究的社会中生活并且仔 细观察该社会中的实际活动,得到第一手的观察数据。对这些观察数据的分析可以揭示被研 究社会的社会结构、组织方法和具体活动。

12

17、模型驱动法：模型驱动法是一类以定义明确的模型为理论基础,依据模型指导和 组织活动开展的需求工程方法。

18、用例驱动法：用例是一种场景的文本化表现方式,使用叙述性的文本来描述场景。 以用例为核心,围绕用例开展活动的软件开发方法被称为用例驱动的软件开发方法。 19、企业建模：企业建模是以使用产品的组织团体为系统的环境,进行分析。它主要 用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等。企业建模 利用企业的目标、任务、策略、资源等来刻画组织的行为,并依此来发现组织开发系统的目 的,建立系统的业务需求。

20、过程建模：过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程 的集合,其中一些由人来执行,另一些由软件系统来执行。过程建模使用的主要技术有上下 文图、数据流图、微规格说明和数据字典等。

21、上下文图：上下文图是 DFD最高层次的图,是系统功能的最高抽象,它将整个系 统看做是一个过程,这个过程实现系统的所有功能。上下文图中存在且仅存在一个过程,表 示整个系统。这个单一的过程通常编号为 0。

22、概念数据模型：概念数据模型是以问题域的语言解释数据模型,反映了用户对共 享事物的描述和看法,由一系列应用领域的概念组成。

23、物理数据模型：物理数据模型是对数据模型的解系统语言的解释,它描述的是共 享事物在解系统中的实现形式,是形式化的定义。

24、逻辑数据模型：逻辑数据模型是为了缓解开发人员将概念数据模型转换成物理数 据模型的困难,而使用一种介于问题域和解系统之间的中立语言来进行的数据模型的描述。 这种中立的语言使用更加倾向于用户的概念和词汇,同时使用更加倾向于解系统语言的表达 方式。

25、关系的基数：关系的基数是衡量关系复杂性的指标之一,又被称为关系的约束。 一个实体在关系中的基数定义了在关系中其他实体实例确定的情况下,该实体实例可能参与 关系的数量。

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

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

13

28、基线：基线是已经通过正式评审和批准的规格说明或产品,可以作为进一步开发的 基础,并且只有通过正式的变更控制过程才能修改它。

29、需求基线：需求基线（Requirements Baseline）就是被明确和固定的需求集合,是 项目团队需要在某一特定产品版本中实现的特征和需求集合。

30、需求跟踪：需求跟踪是一种有效的控制手段,能够在涉众的需求变化中协调系统的 演化,保持各项开发工作对需求的一致性。需求跟踪是以软件需求规格说明文档为基线,在

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

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

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

①需求工程必须说明软件系统将被应用的环境及其目标,说明用来达成这些目标的软 件功能,还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施 加的限制和约束,也即要同时说明软件需要“做什么”和“为什么”需要做。

②需求工程必须将目标、功能和约束反映到软件系统中,映射为可行的软件行为,并 对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果,是项目规划、 设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。

③现实世界是不断变化的世界,因此需求工程还需要妥善处理目标、功能和约束随着 时间的演化情况。同时,为了节省开支和进行需求规格说明的重用,需求工程还需要对目标、 功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。

2、简述常见的需求定义错误。 答：（划线部分为必答要点）

在实践和研究过程中,人们发现关于需求定义的具体的错误主要有以下几种： ①需求并没有反映用户的真实需要。

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

原因之一是用户在表达自己的需要时,可能会在潜意识下进行一定的加工。为了发现 用户的真实需求,需求工程师一定要进行问题分析,尽力发现问题背后的问题。

原因之二是在人际交流中,信息会发生自然的衰减,甚至扭曲,导致需求丁程师理解 的并非是用户所表达的。解决方法是在需求传递给开发人员之前,请提出需求的用户进行仔 细地检查和确认。

②模糊和歧义的需求。

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

无意中写出模糊和歧义的需求定义往往是因为选词造句不当,导致不同的人对同一项 需求产生了不同的理解。解决方法是为项目中重要的词汇建立一个公共的可共同理解的词汇 表,然后在词汇表的基础之上进行需求的定义。

有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户,这些 用户关于需求的目标互相冲突,需求工程师于是采用了模糊化的处理方法。正确解决方法是 在项目前景的指导下,促进用户之间的协商解决。

③信息遗漏。

14

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库软件需求分析笔试题库(3)在线全文阅读。