需求工程小黑指北-习题集（带答案和解析）（上）

一、单项选择题 

1、   软件生产中产生需求问题的最大原因在于对应用软件的（  C  ）理解不透彻或应用不坚决。  

（A） 复杂性  （B）目的性   （C）模拟性  （D）正确性  

2、   需求分析的目的是保证需求的（ B   ）。  

（A） 目的性和一致性   （B）完整性和一致性  

（C）正确性和目的性   （D）完整性和目的性  

3、   系统需求开发的结果最终会写入（  D  ）。  

（A） 可行性研究报告   （B）前景和范围文档  

（C）用户需求说明       （D）系统需求规格说明  

4、   现实世界中的（ B   ）构成了问题解决的基本范围，称为该问题的问题域。  

（A） 属性和状态 （B）实体和状态 （C）实体和操作 （D）状态和操作  

5、   功能需求通常分为三个层次，即业务需求、用户需求和（  D  ）。  

（A） 硬件需求  （B）软件需求   （C）质量属性   （D）系统需求  

6、   如果在最终的物件（Final Artifact）产生之前，一个中间物件（Mediate Artifact）被用来在一定广度和深度范围内表现这个终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的（  C  ）。  

（A） 模拟      （B）构造       （C）原型        （D）模型  

7、   按照开发方法进行分类，原型可分为：演化式原型和（  C ）原型。

（A） 演示原型         （B）纸面原型

（C）抛弃式原型     （D）样板原型

8、   按照涉及的功能进行分类，原型可分为：水平型原型和（ C  ）原型。

（A） 屏幕流原型    （B）情景串联原型

（C）垂直型原型     （D）深度模拟原型

9、   原型的需求内容可以从三个纬度上分析：即（ A   ）。  

（A） 外观、角色和实现       （B）开发、实现和作用  

（C）成本、技术和实现       （D）需求、作用和角色  

10、当用户无法完成主动的信息告知，或与需求工程师之间的语言交流无法产生有效的结果时，有必要采用（   B ）。  无法主动告知——需要被动得知——被观察——观察法

（A） 民族志   （B）观察法   （C）话语分析   （D）任务分析  

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

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

（C）基于用例的方法       （D）基于采样的方法  

12、功能目标可以分为 (  B  )。  

（A） 安全目标和可用性目标     （B）满足型目标和信息型目标  

（C）软目标和硬目标                 （D）维护目标和实现目标  

13、面向目标方法的目标分析阶段的主要任务是（ C   ）。  

（A） 获取目标              （B）确定解决方案     

（C）建立目标模型       （D）发现问题和缺陷  14、描述场景所使用的表示法要符合正规性要求，一般可使用非形式化语言、半形式化语言和形式化语言。在实践中，（   B ）是主要的描述方式。  实践中一般都靠说来完成，说话属于非形式化的自然语言。

（A）形式化的程序语言     （B）非形式化的自然语言  

（C）形式化的图形工具     （D）非形式化的设计语言  

15、下列（ B   ）不是场景方法在需求工程中的应用。  

（A） 帮助进行详细的需求分析

（B） 编写系统需求规格说明  

（C） 结合面向目标的方法，指导需求获取活动的开展  

（D） 组织需求获取得到的信息  

16、与其他的场景方法相比，用例最大的特点是采用了（  C  ）的描述方式。  用例无动作，但有固定结构。

（A） 静态非结构化文本       （B）动态非结构化文本  

（C）静态结构化文本         （D）动态结构化文本  

17、用例之间的关系主要有（  D  ）三种。  

（A） 包含、扩展和简化       （B）合取、析取和扩展  

（C）包含、多态和继承       （D）包含、扩展和泛化  

18、分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息，这种分析活动被称为（   D ）。  所有的目的、目标、任务都是建模。

（A） 需求信息获取           （B）建立软件系统解决方案  

（C）需求信息转化           （D）建立需求分析模型  

19、（    B）是建模 为常用的两种手段。  

（A） 具体和抽象   （B）抽象和分解   （C）分解和细化   （D）抽象和细化  

20、抽象通过强调本质的特征，（  D  ）了问题的复杂性。  问题无法避免，只能尽量减少。

（A） 调整   （B）避免   （C）增加   （D）减少  

21、需求分析仅仅需要描述解决方案，不需要探索实现细节的情况下，分析模型又是（  B  ）

的，尤为适用。  

（A） 形式化   （B）半形式化   （C）结构化   （D）非结构化  

22、22、上下文图描述系统与环境中外部实体之间的界限和联系。它从现实世界的角度说明了系统的（ C   ），并确定了所有的输入和输出。  

（A）环境与外观   （B）边界和联系  （C）边界和环境   （D）输入和输出  

23、（  A ）是结构化分析方法的核心技术，它表明系统的输入、处理、存储和输出，以及它

们如何在一起协调工作。  

（A） 数据流图 DFD  （B）实体联系图 ERD  （C）状态转换图  （D）上下文图

24、需求分析活动的一个重要任务是进行（  B ），明确用户需求的隐含信息，展开为明确的

对软件系统的行为期望，即系统需求。  

（A） 需求整理   （B）需求细化   （C）需求获取   （D）需求分析  

25、下列（  A  ）不是用例模型中的关系？  

（A） 属性     （B）关联   （C）泛化    （D）包含  

26、系统边界是指一个系统所包含的系统成分与系统外事物的分界线。用例模型使用一个

（   D ）来表示系统边界，以显示系统的上下文环境。  

（A） 圆形框   （B）菱形框    （C）虚线框   （D）矩形框  

27、UML 使用的行为模型有三种，即：（ C   ）。  

（A） 交互图、状态图和顺序图   （B）顺序图、通信图和时间图  

（C）交互图、状态图和活动图   （D）交互概述图、通信图和时间图  

28、项目的前景和范围文档、用户需求文档都被视为属于（  D  ），重点都是用户的现实世界。  用户的世界就是用户文档，开发为目的就是开发文档。

（A） 开发文档   （B）需求文档   （C）前景文档   （D）用户文档  

29、系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口需求规

格说明文档和人机交互文档一起被用于系统开发的目的，都被认为是( A )。  用户的世界就是用户文档，开发为目的就是开发文档。

（A） 开发文档   （B）需求文档   （C）过程文档   （D）用户文档  

30、下列（  C ）不是需求规格说明文档的读者？  

（A） 项目管理者   （B）编程人员   （C）销售商   （D）律师  

  

二、填空题

1、   传统的需求分析方法都是从设计领域转入分析领域的。  

2、   应用型软件分析阶段的主要目的是发现人们利用软件的原因（目的），找出需要软件解决的问题，理解应用环境中的领域知识，保证功能的模拟性。  

3、   需求工程是所有需求处理活动的总和，它包括需求开发和需求管理两个部分。  

4、   软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。

5、   优秀的需求应该具备 7 个特性，即完整性、正确性、精确性、可行性、必要性、无歧义和可验证。  

6、   所有对软件系统的开发和应用具有发言权和决定权的人统称为涉众。  

7、   按照媒介载体进行分类，原型可分为：样板原型和纸上向导原型。  

8、   演示原型主要被用在项目启动阶段。  

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、需求协商活动既包括对目标冲突的处理，也包括对需求细节冲突的处理。  

57、用例模型的基本元素有四种：用例、参与者、关系和系统边界。  

58、UML 行为模型是用例模型的实现，以更加详细的方式说明用例所描述的系统行为。  

59、UML 行为模型的活动图是依据处理流程进行的用例实现。  

60、UML 行为模型的交互图通常描述的是单个用例的典型场景。  

61、接口需求规格说明文档是对整个系统中需要软、硬件协同实现部分的详细描述。  

62、优秀的需求规格说明文档应该具备：正确性、无歧义、完备性、一致性、根据重要性和稳定性分级、可验证、可修改、可跟踪等特性。  

63、需求验证常见方法有：需求评审、原型与模拟、测试用例开发、用户手册编制、利用跟踪关系和自动化分析。  

64、评审又被称为同级评审，是指由作者之外的其他人来检查产品问题的方法。  

65、需求基线的维护主要包括配置管理和状态维护。  

66、需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。  

67、从需求向后回溯（前向跟踪的两种联系之一）说明软件需求来源于哪些涉众的需要和目标。  

68、后向跟踪是指需求被定义到软件需求规格说明文档之后的演化过程。  

后向跟踪包括两种联系：从需求向前跟踪和回溯到需求的跟踪。

 

  

三、判断题 

1、   需求工程包括需求获取和需求开发两个方面。（×）  

2、   需求验证是需求工程中最后一个活动。（×）  

3、   软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟特性。（√）  

4、   规格说明是问题域为满足用户需求而提供的解决方案，规定了解系统的行为特征。

（×）

5、   业务需求具有明显的目的性和较高的抽象性，经过明确和细化的处理，可以直接转化为系统需求。（×）  

6、   需求开发的一些特性决定了需求开发过程只能是一个简单的线性增量过程。（×）  

7、   对于需求不确定性比较小的项目，用户参与可以取得比较好的效果，但对于需求不确定性比较大的项目，用户参与反而可能带来阻碍作用。（×）  

8、   按照构建技术进行分类，原型可分为：水平原型和垂直原型。（√）  

9、   严格意义上的原型主要被用在需求分析阶段。（√）  

10、要完成相同的功能，构建抛弃式原型比构建演化式原型所花费的代价要大得多。（×）  

11、水平原型方法仅仅实现选定功能实现的所有层次，能够处理较大范围的功能。（×）  

12、垂直原型方法会触及选定功能所有层次中的某些特定层次，处理的功能范围通常较小。

（×）  

13、建立外观原型时重在原型的用户界面和交互方式，原型的功能和技术实现细节就会被简化处理。（√）  14、如果选择的开发方法是实验式或者探索式开发方法，应该尽量花费最小的代价，争取最快的速度，忽略或简化不重要的功能处理。（√）  

15、原型修正主要依据评估人员的反馈，可以忽略事先的原型调整计划。（×）

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

17、由于文档是来自于当前计算机或手工系统的产物，因此它是正确的，也正是客户所需要的。（×）  

18、成功的需求获取任务不仅要求成功地执行每一次具体的需求获取行为，还要求成功地处理多次获取行为之间的关系。（√）  

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

20、场景被人们广泛接受的原因是因为人们更倾向于会对真实事件和真实事物的描述产生反应。（√）  

21、描述场景时所使用的常见媒介形式主要有：叙述性的自由文本、结构化文本。强限制文本、表格、图表、图像等。（√）  

22、描述性场景的目的是为了记录已经得到的需求，即整理每次需求获取行为中得到的信息。（√）  

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

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

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

26、用例是在对现实世界的探索中或者是在对需求规格说明的解释中产生的，是通过功能分解的方式创建的。（×）  

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

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

29、抽象一方面要求人们关注重要的信息，同时又不能忽略次要的内容。另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节。（×）  

30、由于计算模型的形式化特征不适合于需求工程阶段，因此计算模型不适合用于需求分析中的建模。（√）  

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

32、由于模型需要描述的内容太过复杂的，因此分析模型对模型语言语用的要求不可能太高。（×）  

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

34、在“结构化方法－信息工程方法－面向对象方法”的发展历程中，每一种后来的方法在吸收了前面方法的重要思想的同时也替代前面的方法。（×）  

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

（√）  

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

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

38、UML 行为模型的状态图是以状态机模型的方式进行的用例实现。状态图只能用来实现单个用例。 （×）  

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

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

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

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

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

  

四、名词解释题 

1、   需求工程：需求工程是软件工程的一个分支，它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。  

  

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

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

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

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

  

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

  

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

  

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

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

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

 

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

  

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

  

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

  

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

  

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

 

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

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

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

  

  

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

  

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

  

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

在向前和向后两个方向上，描述需求以及跟踪需求变化的能力，分为前向跟踪（Pre-

Traceabmty）和后向跟踪（Post-Traceability）两种。 

  

五、问答题 

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

答：  

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

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

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

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

  

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

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

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

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

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

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

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

②模糊和歧义的需求。  

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

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

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

③信息遗漏。  

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

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

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

④不必要的需求。  

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

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

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

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

⑤不切实际的期望。  

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

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

  

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

答：  

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

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

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

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

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

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

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

  

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

答：   

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

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

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

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

  

 

  

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

答：  

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

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

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

②减少返工。  

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

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

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

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

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

  

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

答：    

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

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

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

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

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

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

  

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

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

（1）探索式  

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

（2）实验式  

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

（3）演化式  

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

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

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

Prototype）。  

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

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

  

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

答：  

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

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

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

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

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

  

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

答：  

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

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

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

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

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

 

 

  

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

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

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

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

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

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

况，要区分用户需求的优先级，优先迭代级别高的需求，保证项目 终 大程度地满足了用户的需求。  

  

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

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

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

①明确冲突的因素，避免情绪上的冲突。需求分析人员应该从技术上发现和描述冲突背

后的本质原因，并帮助避免和解决涉众在协商中间可能产生的情绪冲突（Emotional conflict）。

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

（Rationales）。

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

 

 

  

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(待确定)的问题都已经解决，或者已经对每个待确定问题的解决过程、计划解决的目标日期和由谁来解决等编制了文档。  

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

  

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

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

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

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

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

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

⑤改变项目文化，使得需求的作用得到重视和有效发挥。需求管理可以为项目涉众带

来很多的好处，使得项目涉众认识到需求在项目工作中的重要性，并依照需求开展工作。  

  

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

需求管理的重要任务有：  

①交流涉众的需要。  

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

③驱动设计和实现工作。  

④控制变更。  

⑤将需求分配到子系统。  

⑥测试和验证 终产品。  

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

⑧辅助项目管理。  

  

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

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

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

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

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

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

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

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

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

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