于系统的环境、开发组织的业务背景、涉众的特征以及目标等等，软件系统只是整个背景下 的一个要素。
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
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