《软件需求分析》习题集 - 图文

《软件需求分析》习题集

《软件需求分析》课程组编

2012年 4月

目 录

一、单项选择题………………………………………………2 二、填空题……………………………………………………5 三、判断题……………………………………………………9 四、名词解释题………………………………………………11 五、问答题……………………………………………………14 六、案例分析题………………………………………………28

1

《软件需求分析》习题集

一、单项选择题

1、软件生产中产生需求问题的最大原因在于对应用软件的（ 坚决。

（C）模拟性（D）正确性

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

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

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

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

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

（C）用户需求说明 （D）系统需求规格说明 4、现实世界中的（ ）构成了问题解决的基本范围，称为该问题的问题域。

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

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

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

6、比较容易发现的涉众称为初始涉众，又称为（ ），通常包括客户、管理者和相关 的投资者。

（A）关键涉众（B）涉众基线 （C）普通涉众 （D）一般涉众

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

8、按照使用方式进行分类，原型可分为：演示原型、（ ）、试验原型和引示系统原 型。

（A）非操作原型（B）系列首发原型（C）选定特征原型（D）严格意义上的原型 9、按照功能特征进行分类，原型可分为：（ ）、非操作原型、系列首发原型和选定 特征原型。

（A）拼凑原型（B）样板原型（C）纸上向导原型（D）严格意义上的原型

10、按照开发方法进行分类，原型可分为：演化式原型和抛弃式原型，其中抛弃式原 型又被细分为（ ）。

（A）演示原型和试验原型

（C）探索式原型和实验式原型

（B）系列首发原型和选定特征原型 （D）样板原型和纸上向导原型

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

（A）外观、角色和实现 （B）开发、实现和作用 （C）成本、技术和实现 （D）需求、作用和角色

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

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

13、以下（ ）不是情景性的重要性质？

（D）模糊 （A）突现 （B）涉身 （C）完善

14、以下（ ）是情景性的重要性质？

（D）即时 （A）全局 （B）开放 （C）交互

2

）理解不透彻或应用不

（A）复杂性（B）目的性

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

（A）面向目标的方法 （B）基于场景的方法。 （C）基于用例的方法 （D）基于采样的方法

）属于定量硬数据？ 16、下列（

（A）工作手册 （B）规章手册 （C）统计报表

17、下列（ ）属于定性硬数据？ （A）数据收集表

（B）月报表

（C）年报表

（D）备忘录 （D）规章手册

18、功能目标可以分为 ( )。 （A）安全目标和可用性目标 （B）满足型目标和信息型目标 （C）软目标和硬目标 （D）维护目标和实现目标

19、在表达软目标的分解和细化时使用的 AND Contribution链接和 OR Contribution链 接，Contribution的作用是（ ）。

（A）积极的 （B）消极的 （C）积极的或消极的 （D）不能确定

20、AND链接将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细 化的子目标，那么将（ ）父目标。 （A）无法确定 （B）阻碍 （C）不能满足 （D）足以满足

21、OR链接是将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细 化子目标中的（ ），那么将足以满足父目标。

（A）每一个（B）任何一个 （C）特定的（D）某一个

22、下列选项中，（ ）不是在目标模型中使用的其他模型元素。 （A）行为者 （B）场景 （C）操作 （D）概念 23、面向目标方法的目标分析阶段的主要任务是（ ）。

（A）获取目标 （B）确定解决方案 （C）建立目标模型 （D）发现问题和缺陷 24、场景的分类框架将场景方法从场景的（ ）4个方面进行了分类和描述。 （A）形式、目的、内容和生命周期 （B）外观、目的、内容和生命周期 （C）描述、目的、内容和形式 （D）描述、外观、目的和内容 25、场景的形式是指场景的表达模式，从形式上分为两个方面：（ ）

（A）内容和目的（B）内容和生命周期（C）描述和外观（D）描述和目的

26、描述场景所使用的表示法要符合正规性要求，一般可使用非形式化语言、半形式 化语言和形式化语言。在实践中，（ ）是主要的描述方式。

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

（D）非形式化的设计语言 （C）形式化的图形工具 ）三种类型。 27、外观是指场景被表达出来时的效果，主要有（

（A）静态、动态和结构化 （B）线性、非线性和交互 （C）静态、动态和动静结合（D）静态、动态和交互

28、场景的内容是指场景所表达的知识类型。它被分为 6个不同的方面。下列（ 不是场景的内容。

（A）主要关注点 （B）环境范围 （C）目的 （D）抽象层次 29、需求工程利用场景的目的可能有三种：即：（ ）。 （A）描述、探索和解释 （B）描述、表示和探索 （C）描述、探索和发现 （D）表示、解释和证明

），或者被用于进行需求的验证。 30、使用解释性场景在需求分析时能够（ （A）提高模型的复杂性 （B）降低模型的复杂性

3

）

（C）提高预见性 （D）降低编程量 31、下列（ ）不是场景方法在需求工程中的应用。 （A）帮助进行详细的需求分析 （B）编写系统需求规格说明

（C）结合面向目标的方法，指导需求获取活动的开展 （D）组织需求获取得到的信息

）是组织场景时可用的场景关系。 32、下列（

（A）合取关系 （B）定性关系 （C）定量关系 （D）演绎关系

）的描述方式。 33、与其他的场景方法相比，用例最大的特点是采用了（

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

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

（A）包含、扩展和简化 （B）合取、析取和扩展 （C）包含、多态和继承 （D）包含、扩展和泛化 35、分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的 事物的信息，这种分析活动被称为（ ）。

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

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

36、（ ）是建模最为常用的两种手段。

（A）具体和抽象 （B）抽象和分解 （C）分解和细化 37、抽象通过强调本质的特征，（ ）了问题的复杂性。 （A）调整

（B）避免

（C）增加 （D）减少

（D）抽象和细化

38、需求分析仅仅需要描述解决方案，不需要探索实现细节的情况下，分析模型又是 （ ）的，尤为适用。 （A）形式化 （B）半形式化 （C）结构化 （D）非结构化

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

40、（ ）是结构化分析方法的核心技术，它表明系统的输入、处理、存储和输出，以 及它们如何在一起协调工作。

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

）的。 41、结构化、信息工程和面向对象三种方法学下的需求分析技术都是（

（A）面向问题域 （B）面向解系统 （C）面向设计 （D）面向需求 42、使用面向问题的技术对问题世界的建模就被称为（ ）需求阶段的分析。 （A）前期 （B）中期 （C）后期 （D）全过程

43、使用面向解系统的技术对软件系统解决方案的描述称为（ ）需求阶段的分析。 （A）前期 （B）中期 （C）后期 （D）全过程

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

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

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

45、在分层结构中，DFD定义了三个层次类别的 DFD图：（ ）、0层图和 N层图。 （A）1层图 （B）底层图 （C）上下文图 （D）顶视图

46、因为数据存储是系统内部的功能实现，所以在将系统视为黑盒的情况下，上下文 图中不会出现（ ）。

4

（A）实体 （B）数据存储实例 （C）需求信息 （D）过程处理

）方面的缺陷，它描述数据的定义、结 47、数据建模技术能够弥补过程建模在（

构和关系等特性。

（A）需求分析 （B）数据转换 （C）数据说明 （D）数据分析

48、。概念实体是一种抽象概念，不考虑概念背后的物理存在，所以通常不包含与之相 关联的其他（ ）。 （C）关系 （D）处理

）。 49、在 ERD建模中，实体通常所指的就是（

（A）逻辑实体 （B）概念实体 （C）物理实体 （D）进程实体

50、ERD中属性是实体的特征，不是数据。属性会以一定的形式存在，这种存在才是 数据，被称为属性的（ ）。 （A）域 （B）实例 （C）说明 （D）值

51、ERD中关系的度数（Degree）是指参与关系的实体数量，是度量关系（ 一个指标。

）的

（A）模型

（B）特征（即属性）

（A）模型 （B）复杂度 （C）精确度 （D）属性值

52、ERD中关系的基数分为最大基数和最小基数。最大基数又被称为（ ）。 （A）键约束 （B）参与约束（C）自然约束 （D）一般约束

53、在实体之间建立关系时，可能会产生一些附带的实体，被称为关联实体，最常见 的形式是（ ）。

（A）逻辑实体 （B）进程实体 （C）概念实体 （D）自然实体

）是一种较为常见的技术。 54、在实现 ERD与过程模型同步的技术中，（

（A）用例图 （B）数据流图 （C）功能／实体矩阵 （D）微规格说明 55、下列（ ）不是用例模型中的关系？ （A）属性 （B）关联 （C）泛化 （D）包含 56、系统边界是指一个系统所包含的系统成分与系统外事物的分界线。用例模型使用 一个（ ）来表示系统边界，以显示系统的上下文环境。 （A）圆形框 （B）菱形框 （C）虚线框 （D）矩形框

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

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

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

），重点都是用户的现 58、项目的前景和范围文档、用户需求文档都被视为属于（

实世界。

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

59、系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口 需求规格说明文档和人机交互文档一起被用于系统开发的目的，都被认为是开发文档。

（A）开发文档 （B）需求文档 （C）过程文档 60、下列（ ）不是需求规格说明文档的读者？ （A）项目管理者 二、填空题

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

2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进行巧 妙的功能安排。

3、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡，寻找一套切实

5

（D）用户文档 （D）律师

（B）编程人员 （C）销售商

有效的功能配置。

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

5、需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需 求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。

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

7、约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。

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

9、所有对软件系统的开发和应用具有发言权和决定权的人统称为涉众。 10、按照媒介载体进行分类，原型可分为：样板原型和纸上向导原型。 11、演示原型主要被用在项目启动阶段。

12、演示原型都是被用来展示用户想象中的系统视图，所以它要能够表现用户界面的重 要特征。

13、，如果一个问题的技术解决方案是不清晰的，演示原型也可以被用来展现相应的细 节功能以使用户确信该问题解决的可能性。

14、通常来说，如果用户需求出现了模糊、不清晰、不完整等具有一定不确定性的特征， 就可以考虑使用原型方法。

15、角色是指原型物件在用户工作中的价值，也就是说它为什么对用户是有用的。 16、外观是指用户对原型物件的具体感觉体验，即用户在使用原型物件时会看到什么、 听到什么和感觉到什么。

17、实现是指原型物件完成功能的细节技术和方法。

18、使用演化式原型方法，在开发时就需要注意原型的健壮性和代码的质量。 19、使用实验式开发方法，需要实现多种技术方案，考察重要的系统的质量属性。 20、选择使用探索式开发方法，需要尽可能地考虑各种不同的设计选项，比较不同选项 下的用户反馈。

21、原型方法的最大优点是能够及早地解决系统开发中的不确定性，从而降低软件项目 失败的风险。

22、航空调度、证券交易、医疗手术控制等复杂的协同问题都具有突现的情景性。 23、民族志的一个主要应用目的就是研究和解决复杂的协同问题。

24、复杂的工作总会同时存在着正常流程和异常流程，异常流程大多是一些特殊情况下 的处理，限定了异常处理的上下文环境，即异常处理具有局部的情景性。

25、有很多重要工作的进行需要用户具备一定的认知，认知要求已经成了用户工作必备 的部分，即工作具有涉身的情景性。

26、采样观察是最简单的观察方法，应用目的是发现异常流程，验证用户所述知识和实 际的一致性，以及发现默认知识。

27、时间采样允许需求工程师建立指定的时间间隔来观察用户的活动情况。

28、文档审查主要获取对象包括相关产品的需求规格说明、硬数据和客户的需求文档。 29、文档分析通常是数据建模方法的一个基础部分，它是通过检查采集的硬数据来确定 潜在的需求。

30、如果当前存在一份客户的需求文档，就可以使用需求剥离技术，从需求文档中抽取 单个的需求并加入到新的需求文档之中。

31、需求工程师可以使用模型驱动方法来进行信息的整理和归类，其中模型驱动方法所

6

建立的模型是进行信息整理和归类的很好的框架依据。

32、模型驱动方法的模型是在前期需求阶段的分析中建立的。 33、目标模型的一个核心要素是元素之间的关系，称为链接。

34、目标模型的链接有两类：一类是目标之间的链接；另一类是目标与其他模型元素之 间的链接。

35、面向目标方法的处理过程可以分为三个阶段：目标获取、目标分析（即目标模型的 建立）和目标实现。

36、目标实现阶段的主要任务是收集与目标相关的需求信息，讨论可能的候选解决方案， 确定最终的系统详细需求和解决方案。

37、场景具有重点描述真实世界的特征，它利用情景、行为者之间的交互、事件随时间 的演化等方式来叙述性地描述系统的使用。

38、静态外观的场景被展现为一个或者数个描述性的文本或者图片。

39、动态外观的场景会被以动态的方式展现出来，人们可能会要求按时序向前或者向后 浏览场景，也可能会要求跳转到场景的某一个时刻进行观察。

40、交互外观的场景提供交互性，它允许用户在一定程度上控制和改变场景的变化时序 或者效果。

41、具体场景，又称为实例场景，是对个别行为者、事件、情节的细节描述。 42、抽象场景，又称为类型场景，是以经验中的类别和抽象概念来描述事实。 43、探索性场景可以用来进行需求获取和需求建模与分析。

44、每个用例是对相关场景集合的叙述性的文本描述，这些场景是用户和系统之间的交 互行为序列，帮助实现用户的目的。

45、用例是场景方法中的一种，是静态的结构化文本描述。

46、在高层的功能需求获取完备之前，用例的产生方式中不允许使用功能分解方式。 47、单个用例描述了系统的功能片段，系统的所有用例基于一定的关系组织起来，建立 用例模型，就可以描述整个系统的功能。

48、原有用例和新建立的抽象用例的关系即为包含关系。

49、在需求工程中，主要产生三类重要的文档：项目前景和范围文档、用户需求文档以 及需求规格说明。用例文档通常被用来代替用户需求文档，起到记录、交流领域信息和用户 期望的作用。

50、需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差 距。需求分析就是用来解决这个差距的需求工程活动。

51、需求分析的根本任务是：建立分析模型并创建解决方案。

52、分解将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子 问题之间的联系。

53、基于软件构建单位及其之间的关系建立的模型，用来说明软件逻辑上的构建方式 和实现方式，由于它使用的组元及其关系都是软件的元素，因此它是来自于软件的模型，称 为计算模型。

54、模型语言的三要素：语法、语义、语用。其中语用给出了一个模型元素描述的更 宽广的上下文，以及影响该模型元素意义的约束和假定。

55、互相之间建立了语义联系的多个模型，集成在一起通常被称为视图。

56、需求分析方法主要有：结构化方法、信息工程方法和面向对象方法。其中面向对 象方法是目前工业界使用的主流方法。

57、信息工程和结构化方法的本质差别在于解决问题的策略不同。

58、前期需求阶段分析的重点是理解问题世界，因此它关注的是整个问题世界，注重

7

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

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

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

涉众类别列表。如果新列出的涉众类别列表趋于稳定，就可以结束涉众识别过程。如果新列 出的涉众类别列表有了新的发现，就提交新的涉众类别列表，转向第②步。

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

（1）金字塔结构

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

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

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

在某个话题讨论结束的时候，使用金字塔结构的提问顺序也是有用的。 （2）漏斗结构 在这种结构中，会见者使用演绎的方法，以一般的、开放式的问题开始，然后用封闭式 的问题缩小可能的答复。这种面谈结构可看做是漏斗型。

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

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

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

（3）菱形结构

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

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

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

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

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

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

①及时、有力地响应用户需求的变化。 ②减少返工。

③帮助控制不完整需求所带来的风险。

16

④可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤。 ⑤减少开发成本，提高经济效益。

⑥增加开发者之间的交流，帮助确定技术解决方案的可行性。 ⑦有效地识别风险和解决风险，帮助进行风险管理。 ⑧提高用户在软件开发中的参与程度。

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

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

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

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

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

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

⑥需求的可行性值得怀疑，即具体需求的可满足性存在着不确定性。 8、试比较原型开发方法的三种类型。 答：（划线部分为必答要点）

（1）探索式

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

（2）实验式

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

（3）演化式

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

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

17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11、试比较两种采样观察法的优劣。 答：

（1）时间采样 时间采样的优点：

①在于可以减少在任何某个单独时间段内进行观察时可能发生的偏差，将偶尔才发生 的事件看做是重要的业务事件。

②时间采样还可以只选取频繁发生的活动中一个代表样本进行观察，节省时间和成本。 时间采样的缺点：

①时间采样是以分段方式收集观察的数据，无法为某些长事件提供充分的观察时间。 ②一些很少发生（或不经常发生）但又非常重要的事件可能得不到观察，因为它们没 有出现在采样的时间之内。 （2）事件采样

18

事件采样通过有目的地选取整个事件进行观察，而不是随机采样时间段。 事件采样的优点：

事件采样为观察所提供的是在一个真实背景下的完整行为，所以不会遗漏重要的事件 或者重要事件的某些片断。

事件采样的缺点：

事件采样的不足之处在于它不能获得频繁发生事件的代表性样本。

从正反两方面考虑这两种方法，当决定要对用户活动的内容、时机、原因和方式进行 观察时，应该鼓励热衷于观察的分析员使用时间采样和事件采样相结合的方法。

12、简述民族志法及其优缺点。 答：

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

优点： （1）民族志最大的优点是它能够得到信息的深度理解。

（2）民族志的第二个优点是能够让真实世界的社会性因素可见化。

（3）通过民族志得到的知识是真实的知识，它可以打破人们已有的一些错误假设和错 误观念，能够避免一些更严重后果的发生。

缺点：

（1）民族志的一个主要缺点是需要耗费很多的时间。

（2）民族志的另一个缺点是调研结果很难传递到开发过程。

13、下图描述了火车管理系统的目标模型片段，试分析该目标模型关系。

19

解答：

输入病人信息

接待员

安排预约

登录

医生

输入医疗信息

护士

输入护理病人（诊断）的信

息

打印病历

查询病人诊断结果

查询病史

打印病人诊断结果

3、从下面的事件中，你可以替 Jeannine总结出哪些教训?

投资经理 Jeannine对一个新的投资跟踪系统具有强烈的需求。她需要做出快速决策来 考虑可能进行的投资和撤销投资，耽误一个小时就可能给公司造成几千美元的损失。

最后她放弃了使用公司的信息系统，因为公司的信息系统没有给予她的请求足够高的 服务优先级。她找到软件开发商，购买了一套看似可以满足她要求的软件。但高层管理人员 不同意使用，而且还遇到了其他一些问题。

首先，财务审计员重新评估了公司的投资策略和投资政策。Jeannine并不知道这一点， 于是新的系统没有计人正在被考虑的新政策。

她自己的职员抵制这个系统产生的有关投资和撤销投资的建议。虽然新系统使用了公 司信息系统现有的文件结构，但她却发现她的职员两年前就放弃使用那些文件了，因为那些 文件没有包括全面分析可选替代投资方案所需的数据。她的职员也批评新系统的设计，说很 小的操作错误就会把系统带入“混乱”状态，而且很难恢复过来。

她的一些下级经理坚持要有图形形式的报告，而新系统无法产生这些报告。

最后的问题是，Jeannine不能确定新系统是否可以进行适当的修改(数据库结构修改和 程序修改)以满足新的需求而不用重写所有的程序。而且她的老板也不能肯定是否会出资请 一位顾问来解决这些问题。

解答：

（1）她没有仔细认真地分析问题：

（2）她没有及时跟相关人员交流信息，没能把握住有价值信息： （3）她没能及时跟公司员工交流，引用过时的文件结构； （4）她没有仔细研究分析新引进的系统的性能需求是否满足： （5）她没有仔细研究新引进的系统的功能需求是否满足； （6）她没有仔细研究引进的系统的质量属性，对外接口是否满足。

4、根据下列描述，说明新的直接销售和财务处理系统的业务需求有哪些?

Especially for You Jewelers是大学城的一个小珠宝零售商。在过去的两年里，EspeciaIly for You在它的商业方面经历了极大的发展，可是，它的财务业绩却与它的发展不同步。现 在的事务处理系统部分手动、部分自动，不能有效地追踪客户账单和收据，Especially for You

30

难以确定为什么它的成本这么高。此外，Especially for You频繁地实行特价以吸引顾客。它 不知道这些特价是否有利可图，是否带来其他的销售。Especially for You也想增加回头客， 所以它需要一个客户数据库。Especially for You想按照一个新的直接销售和财务处理系统以 帮助解决这些问题。

解答：业务需求如 BR。

BRl：实现客户账单和收据的有效追踪；

BR2：实现产品特价时的利润和相关销售情况检查； BR3：实现一个客户数据库。

5、你被任命为替换学生财务资助项目的项目经理。你想开发一个工作陈述来定义项目 范围并降低范围蔓延的风险。财务资助部门的主管坚持要你 15个月、600 000美元的预算内 替换他现有的系统就可以了。他说这就是你需要知道的全部，不需要浪费时间开发一个工作 陈述了。省略工作陈述的风险是什么?你将如何说服主管?

解答：

省略工作陈述的风险是不能明确项目的前景和范围。如果省略了工作陈述的话，你就 不能和用户进行很好的沟通与交流，这样，项目的问题也就不能明确，即，开发人员无法与 涉众对问题达成共识；无法明确问题，也就无法发现正确的业务需求，无法定义良好的解决 方案及系统特性，继而无法明确项目的前景和范围，这样就会造成项目的不稳定甚至失败！ 6、某大银行的一位银行卡办公室的收账经理 Liz遇到了一个问题。她每周都收到一份 过期未付款的账户名单。这份报告已经从两年前的 250个账户增加到现在的 1 250个账户。 为了确定那些严重拖欠债务的账户，Liz需要通读这份报告。严重拖欠债务的账户由几个不 同的规则确定，每个规则都要求 Liz检查客户的一项或几项数据。过去半天的工作量现在增 加到了每周三天。即使在确定了严重拖欠债务的账户后，如果没有查阅该账户三年内的历史 资料，Liz也不能做出最后的信用决定(例如严厉的催款电话、断绝信用或将这个账户转给一 个收账代理)。另外，Liz需要报告所有账户中过期未付款的、拖欠债务的、严重拖欠债务的 和呆死账的比例。目前的报告中并没有给她提供这个信息。

假设现在需要你来开发一个软件，解决 Liz面对的难题。那么你认为 Liz现在遇到的问 题有哪些?你希望新的软件应该达成哪些业务目标 ?你怎样设计软件的高层解决方案和系统 特性?

解答：

Liz现在遇到的问题有： （1）工作量的增加；

（2）客户账户的历史数据；

（3）问题账户所占比例没有显示… 新的软件应该达成的业务目标有： （1）能够快速查询客户账户；

（2）能够分析一个客户是否为问题账户；

（3）能够给出一个问题账户的三年内的历史数据： （4）能够计算问题账户所占比例… 软件的高层解决方案和系统特性：

（1）建立一个数据库系统用来存放客户账户信息；

（2）根据特定的判定问题账户的算法检索辨别出问题账户； （3）工作人员能够检查该账户的三年内的历史数据；

31

（4）即时显示问题账户所占比例…

7、职工福利和工资顾问遇到了一些问题。她的工作是为雇员提供他们的福利建议。公 司刚刚磋商了一个新的医疗保险方案，这个方案要求雇员从 7个保健组织和首选的供应商方 案中进行选择。保健组织和供应商按照雇员的分类、贡献、免赔额、受益人、服务内容和允 许的服务提供商而各不相同，目的是尽可能为雇员提供最灵活的福利，用以使公司的花费极 小化并控制付给保险商的费用（这将对公司被收取的后续保险费产生一定的影响）。

这个顾问被请来为雇员选择最合适的保险方案。她目前以手工方式答复这些请求。但 目前的选择比新计划中的选择要直接得多。她需要解释新的选择：它们包括什么，不包括什 么，它们的费用和可能费用是多少，具有什么优缺点。但是，雇员对新计划不信任，这种情 况迫使她需要向雇员提供更多具体的建议和答复。

她可能不得不为许多雇员逐步建立假定情境——可能的最坏假定情境。这种假定将要 根据每个雇员的收入、婚姻和家庭状况、目前的健康风险等进行个人定制。在逐步建立一些 样本假定时，她发现：

①从信息系统部门获得工资和个人数据需要一天时间。

②雇员数据存储在许多文件夹中，而且并不总是被正确地更新。当冲突数据变得很明 显时，除非解决了矛盾，否则就不可能继续她的工作。

③计算复杂。为一个雇员创建投资和退休假定常常需要花费一整天或更长时间。 ④有些人担心保险计划会被提供给未授权的个人，例如以前的配偶或者非直系亲属。 ⑤计算中可变条件的复杂性导致经常出错，很多错误可能一直未被发现。

假设现在需要你来开发一个软件，解决职工福利和_T资顾问的问题。那么你认为她现 在遇到的问题有哪些?你希望新的软件应该达成哪些业务目标 ?你怎样设计软件的高层解决 方案和系统特性?解决方案有哪些重要的约束?

解答：

她现在遇到的问题有：

（1）不能有效地从信息部门获得工资和个人数据： （2）雇员数据太过分散，而且不能及时正确地更新； （3）计算复杂；

（4）雇员信息不能得到及时有效正确的更新； （5）计算中可变条件的复杂性。 新的软件应该达到的业务目标有：

（1）减少从信息部门获得工资和个人数据的时间；

度量标准（Scale）：一次从信息部门获得工资和个人数据的时间： 计量方法（Meter）：检查信息部门数据库日志； 理想标准：减少 50％；一般标准：减少 30％；最低标准：减少 20％： （2）集中雇员数据，并且正确更新； （3）降低计算的复杂性；

（4）及时有效正确地更新雇员信息： （5）降低计算中可变条件的复杂性。 软件的高层解决方案和系统特性：

（1）高层解决方案：

①由软件从信息部门的数据库中检索出工资和个人数据，减少所需信息获取的时 间；

②由软件来分析雇员数据的各种特征，及早识别出数据所在位置；或由软件集

32

中处理雇员数据，及早识别出不准确的或没有及时更新的数据，提交人工处 理或自行更新；

③由软件来处理投资和退休假定的计算的复杂过程；

④由软件来分析个人数据的准确性，及早识别出不准确的个人信息，提交人工 处理；或定时更新数，提高数据的准确性；

⑤由软件来处理计算中可变条件的复杂性，降低出错率。 （2）系统特性：

①根据信息部门提供的数据库查询工资和个人数据； ②根据原始数据重新整理数据并更新； ③提交查询信息；

④创建投资和退休假定的计算过程；

⑤通过公司的内联网访问系统，根据个人情况更新信息； ⑥模拟计算中可变条件的变化； ⑦提供最灵活的福利方案。 重要的约束有：

8、为下面的每一个涉众描述选项试举一例，说明对这些选项进行描述的必要性和忽略 这些选项描述可能造成的风险：个人特征、工作特征、地理和社会特征、关注点和兴趣、目 标期望、被影响程度、力量程度。

解答：

（1）涉众个人特征和工作特征的描述可以帮助更好的确定功能需求： （2）涉众的输赢条件和受影响程度可以帮助解决涉众之间的需求冲突；

（3）涉众的重要性、影响力、关注点和兴趣取向可以用来发现项目的潜在风险：

33

9、Phil Ittup是系统分析员团队中的一员，他受委任去与组织成员面谈，为系统研究收 集材料。企业称为 Fall Back工业，它有 5个管理层人员。此外，生产、会计、营销、系统、 物流和高层管理是将受到所建议的系统影响的职能区域。每个阶层大约有 40人。生产层共 有 80人，会计层有 35人，营销层有 42人，系统层有 10人，物流层有 28人。高层管理有 5人。Phil应该怎样选择面谈对象?为什么?

解答： （1）选择面谈对象的时候采用随机抽样，从 5个阶层以及生产、会计、营销、系统、物 流各选择 2-3名客户参与面谈。高层管理均要参加面谈。因为在选择面谈的时候要力争均衡 的收集用户的需求，因此要涉及各方面受系统影响的人。

采样的规则：控制人数（4～8）。

（2）高层管理的人最先面谈。然后是系统层。其余层的面谈对象根据实际情况可以先 后安排面谈的时间，不一定要分先后顺序。

跟高层管理人员进行面谈，采用漏斗结构，因为各个高层管理人员对各自管理 的层 次从大体上有准确的把握，有助于开发人员首先获取对项目的广度方面的认识，也能获取一 些较为详细的信息。跟具体部门人员进行面谈，采用菱形(必要时，金字塔)结构，因为这种 面谈较为具体，问题常为封闭式问题，这样有助于分析人员获得深度认识。

基本规则：

（1）先业务需求，后用户需求，所以先领导后普通； （2）开始漏斗，领导漏斗 （3）普通用户菱形，必要时金字塔 面谈结构及其特点：见教材。

10、Maverick公司是一家有 15年历史的国内货物运输公司，假设你的小组担当 Maverick 公司的系统分析与设计团队，为 Maverick公司的所有业务设计一个计算机化或者增强设计 计算机化的项目。Maverick主要进行卡车零运，管理人员按照实时处理（Just In Time）原则 工作。在这个原则指导下，他们建立了包括发货人、收货人和承运公司的伙伴关系，目的是 准时运输和交付牛产线上需要的材料。Mavetrick主张用 626台拖拉机托运货物，它拥有 45 000平方英尺的仓库和 21 000平方英尺的办公场地。

（1）制定分析：Maverick公司的信息需求时，应当收集的硬数据列表。（提示：想象 一下该公司要开展的工作，应该会有哪些登记表格）。

（2）设计一种采样机制，使得小组在不必查看这家公司 15年来产生的所有文档的情 况下，形成对该公司的清晰认识。

解答： （1）描述发货人、收货人和承运公司的伙伴关系的表

发货及收货的时间表 货物的中转表

拖拉机和仓库的使用情况表 参考硬数据的类型：见教材。

（2）将这 15年公司的情况用图表表达出来，形成对 15年以来公司状况的认识，获取 生产情况的时候将大致相同的年份列出来，采样时候只需要在大致相同的年份中抽取一份作 为样本。

参考采样规则：见教材。

34

本文来源：https://www.bwwdw.com/article/udff.html