需求工程复习题下

八、名词解释

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

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

5、 范围（scope）：范围指出当前项目是要解决产品长远规划中的哪一部分，范围声明它为项目划定了需求的界线。

6、 用户参与（User Involvement）：是以用户为中心的设计方法的核心思想，它要求开发者建立和用户的直接联系，尽早地关注于用户和用户的任务执行过程，通过及时获得用户的反馈来调整软件设计，以完成高质量的设计。另一方面，用户参与就是反对通过和市场人员、管理者等中间媒介来了解用户，因为这些间接的联系会减少或歪曲用户的信息。

7、 结构化面谈：结构化面谈指在面谈的过程中，会见者会完全按照事先的问题和结构来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息，一些统计性倾向信息的获取也可以使用结构化面谈。

8、 半结构化面谈：半结构化面谈指在面谈的过程中，事先需要根据面谈内容准备面谈的问题和面谈结构。但在面谈过程中，会见者可以根据实际情况采取一些灵活的策略。半结构化面谈是在需求获取中应用 多的一种面谈类型，能够处理大部分的需求获取任务。

9、 非结构化面谈：在非结构化面谈的过程中，没有事先预定的议程安排。在比较极端的情况下，会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地，就某个主题开展会谈。

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

11、原型：原型是一个系统，它内化了（Capture）一个更迟系统（Later System）的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。”

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

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

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

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

15、企业建模：企业建模是以使用产品的组织团体为系统的环境，进行分析。它主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等。企业建模利用企业的目标、任务、策略、资源等来刻画组织的行为，并依此来发现组织开发系统的目的，建立系统的业务需求。

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

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

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

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

20、需求跟踪：需求跟踪是一种有效的控制手段，能够在涉众的需求变化中协调系统的演化，保持各项开发工作对需求的一致性。需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力，分为前向跟踪（Pre[1]Traceabmty）和后向跟踪（Post-Traceability）两种。

九简答题

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

答：

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

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

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

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

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

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

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

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

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

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

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

②模糊和歧义的需求。

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

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

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

③信息遗漏。

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

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

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

④不必要的需求。

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

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

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

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

⑤不切实际的期望。

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

面对不切实际的期望，要求软件开发者提供可行性、成本等足够的技术参考信息，帮助用户对其进行取舍和调整。

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

答：

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

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

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

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

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

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

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

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

答：

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

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

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

③为上一步的各个关键涉众类别选择代表，集中起来进行进一步的头脑风暴，列出新的涉众类别列表。如果新列出的涉众类别列表趋于稳定，就可以结束涉众识别过程。如果新列出的涉众类别列表有了新的发现，就提交新的涉众类别列表，转向第②步。

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

答：

（1）金字塔结构

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

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

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

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

（2）漏斗结构

在这种结构中，会见者使用演绎的方法，以一般的、开放式的问题开始，然后用封闭式的问题缩小可能的答复。这种面谈结构可看做是漏斗型。

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

在被动的情况下，当被会见者对话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提问顺序。或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。

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

（3）菱形结构

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

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

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

14

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

答：

因为原型是在 终系统产生之前的一个局部真实表现，所以原型方法可以让人们在系统的开发过程中，就能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软件开发过程中存在的各种不确定性。不确定性是指人们已经拥有的知识是不充分的，不足以预测将来的事件发展，或者不足以清晰、准确地描述某个事物。

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

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

②减少返工。

③帮助控制不完整需求所带来的风险。 ④可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤。

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

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

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

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

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

答：

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

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

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

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

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

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

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

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

（1）探索式

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

（2）实验式

实验式的原型方法初始时拥有清晰的用户需求，但是开发者对这些需求的实现方法、实现效果和可行性没有太大的把握。实验式的原型方法需要首先定义一个对原型的评估方法，确定评估的属性（例如可行性、适用性、效率、吞吐量等），据此评估各种技术方案下的原型，明确需求的可行性和有效的技术实现方案。

（3）演化式

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

在探索式、实验式和演化式这三种原型方法中，前两种方法产生的原型往往是在经历了很多次错误的尝试之后才产生的。这些错误的尝试过程会在 终的原型产品中留下痕迹，原型中的一些代码是在错误的前提（错误的需求、错误的技术方案）下完成的，它们会使原型产品具有很差的质量，所以人们在得到正确的尝试之后往往会抛弃这些原型产品，另起炉灶。为此，探索式和实验式方法产生的原型产品又被称为抛弃式原型。

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

因为抛弃式原型的代码是要被抛弃的，所以在建立抛弃式原型时，应该尽量花费 小的代价，争取 快的速度。为此，原型的开发者会使用一些简易的开发工具和不成熟的构造技术，忽略或简化一些和原型目标不相关的功能特征。

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

答：

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

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

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

③原型评估。对上一阶段产生的原型进行评估，根据评估者的反馈判断原型是否满足结束标准。评估者一般是用户和开发者。

④原型修正。如果已经建立的原型达到了目的，就结束原型方法过程。否则根据评估者反馈的不足进行原型调整，调整完成后准备再次进行原型评估。

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

答：

原型方法的 大优点是能够及早地解决系统开发中的不确定性，从而降低软件项目失败的风险，但原型方法的复杂性使得它在降低风险的同时也引人了新的风险。

（1） 原型方法 大的风险就是涉众看到了一个正在运行的原型，从而得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求。

（2） 原型方法的另一个风险是用户可能会被原型所表现出来的非功能特性遮蔽了眼睛，从而忽略了他们更应该重视的功能特性。

（3） 原型方法的第三个风险是原型方法在澄清需求不确定性的同时也可能会掩盖一些用户的假设，这些假设将会无从发现。，原型的开发者要仔细地分析原型的

（4）最后，还应该避免对原型开发工作投入太多的工作，使开发团队消耗了过多的时间和过大的成本， 后被迫只能匆匆忙忙实现一个产品，甚至只是交付一个原型。

15、简述场景应用和处理生命周期的 5 种情况。

答：

场景的生命周期关注场景的处理和应用，也就是关注场景在整个需求工程中是如何被捕获、修改和演化的。

实践中发现的场景应用和处理可以概括为 5 种情况：

①从当前系统中捕获和建立关于现在的场景，它们描述问题域的状态和问题。

②在当前的系统中分析问题和期望，捕获、分析和建立关于未来的场景。

③在当前的系统中分析问题和期望，捕获、分析和建立关于未来的场景，并依据场景对解决方案的描述，建立需求模型。

④依据已经建立的需求规格说明解释和建立关于未来的场景，然后为场景中描述的解决方案建立需求模型。

⑤依据需求规格说明所描述的解决方案，建立需求模型，同时建立能够验证解决方案的场景。 后，使用场景来验证需求模型的正确性。

16、简要说明结构化分析方法的局限性。

答：

结构化分析方法也有自身的局限性。

首先，虽然有了功能实体矩阵、实体生命历史和事件实体矩阵等分析技术，但是数据需求和处理需求的联接仍然不是一个容易的工作。

其次，结构化分析向结构化设计的过度(数据流图到结构图)中间有着难以处理的鸿沟。

再次，结构化分析过于重视对已有系统的建模，而这常常是难以实现的。

17、请说明为何要确定需求的优先级。

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

在理想的情况下，开发者应该让 终的软件系统完美地满足用户提出来的所有需求。但是这种理想的情况并不总是会在现实中发生，甚至是很少在现实中发生。作为一项工程，软件开发总是在一定的环境限制下进行的，成本效益比是它成功的一个基本衡量标准。因此，在工程环境下，需求与需求之间并不是同等重要的，一些需求应该优于另一些需求得到更多的实现保证，这就是要确定需求优先级的原因。在实践中，确定优先级的活动尤为重要的情况有：

 ①一个项目的资源（时间、人力、成本等）有限，无法满足用户的所有需求。此时项目管理者就需要确定一种 佳方案，在既定的成本下取得 大的效益。需求优先级就是项目管理者进行此项工作的重要基础。

 ②项目采用了分阶段的开发方式。为了 大化地体现项目的成本效益，项目应该在第一阶段就交付用户 重要和 紧急的需求，并将用户 不重要和 不紧急的需求放在开发的后一个阶段。这就需要通过确定需求优先级的方式来划分需求的重要性和紧急性等级。

 ③在项目的开始阶段，并不能明确所有的用户需求，或者无法保证会 终满足所有的用户需求。这个情况是实践中 为常见的情况，迭代式的开发基本都属于这种情况。对这种情况，要区分用户需求的优先级，优先迭代级别高的需求，保证项目 终 大程度地满足了用户的需求。

18、请说明需求分析人员在需求协商当中应该予以确保的三个原则。

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

需求分析人员在需求协商当中应该予以确保的三个原则是：

①明确冲突的因素，避免情绪上的冲突。需求分析人员应该从技术上发现和描述冲突背后的本质原因，并帮助避免和解决涉众在协商中间可能产生的情绪冲突。

②明确冲突的解决空间。需求分析人员应该引导涉众之间的协商，在涉众协作中发现和明确各种可能的解决方式、论据和理由

• 确定最佳解决方案。需求分析人员应该提供足够的技术信息支持，帮助涉众在既有的解决空间内达成 佳的解决方案。

25、 请说明为什么要编写需求规格说明文档？答：（划线部分为必答要点）

（1）编写需求规格说明文档的必要性：在一个复杂软件系统的开发中，编写需求规格说明文档是非常必要的。

一方面，清晰、明确、结构化的文档可以将软件系统的需求信息和解决方案更好的传递给所有的开发者。

另一方面，文档可以拓展人们的知识记忆能力。

（2）编写需求规格说明文档的他好处：

①需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。开发者和客户可以使用它作为合同协议的重要部分，涉众也可以利用它在相互间达成一致。

②需求规格说明文档可以成为项目开发活动的一个重要依据。它可以作为软件估算和项目进度安排的基础，也可以作为开发人员判断设计、测试等工作的进行是否正确的依据。

③在需求规格说明文档的编写过程中，可以尽早的发现和减少可能的需求错误，从而减少项目的返工，降低项目的工作量。

④需求规格说明文档可以成为有效的智力资产。这个智力资产可以帮助新加入的团队成员更快的融入项目，可以帮助更好地将软件产品移交给新客户，也可以帮助开发者更好地进行其他类似项目或者后续增强项目的开发。

26、 试比较编写需求规格说明文档所使用的三种语言。

答：（划线部分为必答要点）需求工程师在描述需求规格说明文档时使用的语言分为三类：

①非形式化语言，即自然语言。

②半形式化语言，比自然语言具有更丰富的语义和更严格的语法同时又没有严格到完全基于数学方法的语言，例如 ERD、DFD、UML 等图形语言。

③形式化语言，基于数学的语言，例如 VDM、Z 语言等。

自然语言具有复杂的规则和多样化的表达方式，所以它的表达能力 为强大。而且自然语言属于普通人的语言，每个人都熟知其规则、表达方式和特点，所以非常利于用户的理解。但同时自然语言也具有松散、模糊、歧义、凌乱等不好的特性。这使得它无法被机器所理解，它所描述的信息内容也无法准确地映射为机器行为。

形式化语言是基于数学方法的语言，具有数学的表示法特性。使用形式化语言描述的信息内容是可以进行逻辑一致性推导和证明的，所以它能够保证信息的正确性。而且形式化的信息描述能够被机器所理解，它所描述的信息内容可以准确地映射为机器行为。但是形式化描述的信息要求读者具备谓词演算方面的知识，这对普通的用户而言显然要求过高，以至于大多数用户无法读懂以形式化方法描述的信息。形式化方法所能描述的内容也是有限的，具体的有限性因形式化方法的不同而各异。

半形式化语言是介于自然语言和形式化语言之间的描述语言。一方面，半形式化语言具有严格的语法，定义方式比自然语言更加严格，这使得它可以避免自然语言模糊、松散、歧义、凌乱等不好的特性。另一方面，半形式化语言具有丰富的语义，使用规则比形式化语言更复杂和多样，这使得它具有比形式化方法更强的表达能力。但是，丰富的语义使得半形式化语言的语法无法严格到可以等价于数学方法的程度，所以它描述的信息还需要进行额外的处理才能够被机器所理解或者准确地映射为机器行为。同时，严格的语法限制也使得半形式语言的表达能力无法达到自然语言的程度。而且因为具有独特的语法和语义，所以半形式语言对普通用户而言无异于一门全新的语言，它所描述的信息很难被用户所理解。

自然语言采用了以文本为主的描述方式；形式化语言也是使用以文本为主的描述方式；半形式化语言采用了以图形为主的描述方式，因为：

①半形式化语言的语法限制使得它用于信息描述的基本元素是有限的，这个有限性使得它以限定文本或者限定图形符号为描述方式成为可能。

②半形式化语言追求表达语义的丰富性，而在这一点上图形符号是胜过限定文本的，所以人们倾向于选择使用图形符号的描述方式。

在进行需求规格说明文档的编写时，用户倾向于使用自然语言，因为其他两种类别的语言难以理解。开发人员倾向于使用半形式语言和形式化语言，因为自然语言的表达不够严格和准确。形式化语言在实践中的应用很少，因为需求规格说明对语言的语义和表达能力有着较高的要求，而这恰恰是形式化语言有所欠缺的。

为了让需求规格说明文档的内容能够同时满足用户和开发人员的需要，需求工程师在实践中更多时候会综合使用自然语言、半形式化语言和形式化语言。

27、简述评审的过程并说明何时可以结束评审？答：（划线部分为必答要点）

常见的评审过程可以分为 6 个阶段：

（1） 规划阶段（Planning），作者和仲裁者共同制定审查计划，决定审查会议的次数，安排每次审查会议的时间、地点、参与人员、审查内容。

（2） 总体部署阶段（Overview），作者和仲裁者向所有参与审查会议的人员描述待审查材料的内容、审查的目标以及一些假设，并分发文档。

（3） 准备阶段（Preparation），审查人员各自独立执行检查任务。在检查的过程中，他们可能会被要求使用检查清单、场景等检查方法，记录下来检查中发现的问题，以准备开会讨论或者提交给收集人员。

（4） 审查会议阶段（Inspection Meeting），通过会议讨论，识别、确认和分类发现的错误。在审查会议结束时，还可以根据审查发现的问题严重程度来确定软件需求规格说明文档是可以在修正后接受，还是需要在修正后再次进行评审。

（5） 返工阶段（Rework），作者修改发现的缺陷。

（6） 跟踪阶段（Follow-up），仲裁者要确认所有发现的问题都得到了解决，所有的错误都得到了修正。仲裁者还要判断修正后的文档是否已满足审查的结束标准，如果不满足就需要再次进行评审。

若满足下列情况，审查工作可以结束。

①审查期间审查人员提出的所有问题都已解决。

②文档中和相关的工作产品中的所有更改都已正确完成。

③修订过的文档已经进行了拼写检查。

④所有标识为 TBD(待确定)的问题都已经解决，或者已经对每个待确定问题的解决过程、计划解决的目标日期和由谁来解决等编制了文档。

⑤文档已经在项目的配置管理系统中作了登记。

21

28、简述需求管理的主要作用。

答：（划线部分为必答要点）在实践中发现的需求管理的作用有：

①增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解。需求管理将需求基线纳入了项目的知识管理，能够帮助项目涉众更好地获得并理解这些知识，从而增强了项目涉众对需求(尤其是复杂需求)的掌握。

②增进了项目涉众之间的交流。需求管理为项目涉众提供了一个共同的需求理解，从而有助于项目涉众之间的交流，减少了可能的误解和交流偏差。

③减少了工作量的浪费，提高了生产力。需求管理能够更加有效地处理需求的变更，减少因此产生的返工工作，从而提高了项目的生产率。

④准确反映项目的状态，有助于项目决策。需求管理收集的需求跟踪信息能够更加准确地反映项目的进展情况，从而帮助项目管理者更好地掌握项目状态，做出更加符合实际情况的合理决策。

⑤改变项目文化，使得需求的作用得到重视和有效发挥。需求管理可以为项目涉众带来很多的好处，使得项目涉众认识到需求在项目工作中的重要性，并依照需求开展工作。

29、 简述需求管理的重要任务

答：

需求管理的重要任务有：

①交流涉众的需要。

②将需求应用、实施到解决方案。

③驱动设计和实现工作。

④控制变更。

⑤将需求分配到子系统。

⑥测试和验证 终产品。

⑦控制迭代式开发中的变化。

⑧辅助项目管理。

30、 简述如何进行需求变更控制？

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

需求开发是一个获取、明确并定义需求的过程，但需求并不是在需求开发结束之后就会恒定不变的。

为了解决需求变化给项目带来的影响，需要正确地处理需求变化，首先要认识到在很多情况下，需求的变化是正当和不可避免的：

①问题发生了改变。软件被创建的目的在于解决用户的问题，可是随着时间的发展，形势可能会发生变化，导致用户的问题也发生了变化。原来的问题可能因为各种原因不解自破，或者用户将原来的主要问题降为次要问题，而将原来的次要问题升级为主要问题等。所有这些都意味着软件的需求应该发生变化，否则创建的软件将会减小甚至失去服务用户的作用。

②环境发生了改变。软件是通过与其周围环境进行交互的方式来解决用户的问题的。如果软件的环境发生了改变（例如法律变化、业务变化等），那么即使用户的问题依旧，软件的需求也应该发生改变。否则， 终的软件将不能像设想的那样有效地解决用户的问题，因为旧有的模式已经无法和新的环境形成有效互动。

③需求基线存在缺陷。需求开发的理想结果当然是建立一个完全无缺陷的需求基线，但这是不可能达到的目标。因为需求工程的复杂性，需求开发得到的需求基线总是或多或少的会遗留下一些缺陷。当这些缺陷在开发或者使用中暴露出来时，必须予以及时解决。

④用户变动。在开发和使用中，软件产品的用户可能发生的人员更替，这时新的用户就可能会提出和原有用户不同的要求。在维护期间和比较长的开发周期中往往会发生这类变更。

⑤用户对软件的认识变化。随着对软件开发和使用的直接参与，用户会对软件领域有越来越多的了解，这时他们也往往会提出越来越多、越来越具体的需求，其中就夹杂着对原有需求的修改要求。在一个全新的领域或者为一个没有软件经验的企业开发软件时，这种情况非常常见。

⑥相关产品的出现。在产品开发的过程中，可能会有竞争产品、类似产品或者需要交互的其他产品等相关产品出现，这时往往需要开发者根据相关产品的新鲜知识，变更原有的软件需求和开发计划。

十、案例题