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
信息遗漏也是一类常见的问题，包括明显的信息遗漏和不明显的信息遗漏。
明显的信息遗漏，其主要原因在于项目的范围定义不当，可以通过加强对业务需求的 处理得以解决。
不明显的信息遗漏，是因为相关信息难以发现，只能靠需求工程师的经验来加以避免。 ④不必要的需求。 产生不必要需求的原因主要是：
其一是用户将一些不必要的需求作为和开发人员谈判的筹码，然后通过自己对不必要 需求的要求而在和开发人员的谈判当中取得真正想要的利益，例如金钱。对此问题，唯一需 要的就是开发人员代表的谈判技巧。
其二是用户在交流中，总是害怕信息有所遗漏，并因此产生不利后果，因此用户总是倾 向于表达各种各样的需要。要解决这个问题，就需要开发人员在进行用户需求的获取之前， 先定义明确的业务需求，然后根据业务需求进行用户需求的过滤和选择。
其三是需求开发人员“画蛇添足”，添加“用户肯定会喜欢”的功能，该类功能既会造
成项目额外的耗费，又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用户为 中心。
⑤不切实际的期望。
不切实际的期望也是实践中常见的需求定义问题，而且它在很大程度上影响着项目的 成败。
面对不切实际的期望，要求软件开发者提供可行性、成本等足够的技术参考信息，帮 助用户对其进行取舍和调整。
3、简要说明需求获取活动的过程。 答：
（1）收集和应用背景资料，建立初始的知识框架。分析涉众的高层次问题，总结出系 统的业务需求。
（2）设计一个高层次的解决方案，并确定解决方案需要具备的系统特性。高层次的解 决方案和系统特性定义了项目的前景和范围。
（3）在项目的业务范围内，需求工程要寻找相关的涉众，并分析和涉众选择。
（4）对组织里存在大量的表格、单据等与业务相关的硬数据进行采样，它们是需求获 取活动中一个重要的信息来源。
（5）针对某一次具体的需求获取活动，要依据项目范围确定主题和内容，涉众特征和 硬数据，从而确定信息来源。获取方法通常只有综合内容、来源和系统环境三者才能做出正 确的决定。
在内容、来源和方法都确定之后，需求工程师就可以开展具体的获取活动，获取用户 需求和问题域特性。
获取得到的具体信息要记录下来，以获取笔录的形式进行保存。
4、简述涉众识别的基本过程。 答：
涉众识别的基本过程如下：
①将初始涉众集中起来，进行一次头脑风暴，尽可能地列出一个涉众类别列表。
②对上一步产生的涉众类别列表进行分析，判断它们和软件系统的相关性，找出其中的 键涉众类别。
③为上一步的各个关键涉众类别选择代表，集中起来进行进一步的头脑风暴，列出新的
15