《软件需求分析》题库
《软件需求分析》课程组编
2012年 4月
目 录
一、单项选择题………………………………………………2 二、填空题……………………………………………………5 三、判断题……………………………………………………9 四、名词解释题………………………………………………11 五、问答题……………………………………………………14 六、案例分析题………………………………………………28
1
《软件需求分析》习题集
一、单项选择题
1、软件生产中产生需求问题的最大原因在于对应用软件的（ 坚决。
（A）复杂性（B）目的性 （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）民族志
13、以下（ （A）突现 14、以下（ （A）全局
（B）观察法 （C）话语分析 （D）任务分析 ）不是情景性的重要性质？
（D）模糊 （B）涉身 （C）完善 ）是情景性的重要性质？ （B）开放 （C）交互
（D）即时
）理解不透彻或应用不
2
15、下列（ ）不是需求获取常见的模型驱动方法？ （A）面向目标的方法 （B）基于场景的方法。 （C）基于用例的方法 （D）基于采样的方法 16、下列（ ）属于定量硬数据？
（A）工作手册 （B）规章手册 （C）统计报表 17、下列（ ）属于定性硬数据？
（D）备忘录
（A）数据收集表 （B）月报表 （C）年报表 （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）分解和细化 （D）抽象和细化 37、抽象通过强调本质的特征,（ ）了问题的复杂性。
（A）调整 （B）避免 （C）增加 （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、。概念实体是一种抽象概念,不考虑概念背后的物理存在,所以通常不包含与之相 关联的其他（ ）。
（A）模型 （B）特征（即属性） （C）关系 （D）处理
）。 49、在 ERD建模中,实体通常所指的就是（
（A）逻辑实体 （B）概念实体 （C）物理实体 （D）进程实体
50、ERD中属性是实体的特征,不是数据。属性会以一定的形式存在,这种存在才是 数据,被称为属性的（ ）。 （A）域 （B）实例 （C）说明 （D）值
51、ERD中关系的度数（Degree）是指参与关系的实体数量,是度量关系（ 一个指标。
）的
（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）项目管理者 （B）编程人员 二、填空题
1、传统的需求分析方法都是从设计领域转入分析领域的。
2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进行巧 妙的功能安排。
3、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡,寻找一套切实
5
（D）用户文档
（C）销售商 （D）律师
有效的功能配置。
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
答：
图中,火车管理系统主要有三个高层的软目标：服务更多的旅客（ServeMorePassengers）、 尽可能降低成本（Costs,类型 Min）和安全运输（SafeTransport）。
对 ServeMorePassengers的工作可以同时从增加新班次(NewTracksAdded)和提高原有班 次效率上着手。提高原有班次效率则可以通过提高列车运行速度（TrainSpeed,类型 Max） 或者缩短班次间隔（DistanceBetweenTrains,类型 Min）来实现。
降低成本的实现可以考虑降低新投资（ DvlptCosts,类型 Min）或者降低运营成本 （OperationCosts,类型 Min）。而增加新班次（NewTracksAdded）的目标要求可能会增加降 低新投资目标的实现困难。
在实现安全运输的措施中,有三个是必须达到的： ①要保持安全的车距（WCS—DistBetweenTrains,类型 Maintain）。
②列车的速度要保持在轨道能够承受的范围内（TrackSegmentSpeedLimit ,类型 Maintain）。
③列车不要进入已经关闭的站台（TrainEnteringClosedGate,类型 Avoid）。 14、下图是为一个会议安排系统建立的目标模型,请分析说明该目标模型。
20
答：
图中所示的目标模型。系统有两类行为者,一类是会议的发起人 Meeting Initiator,另 一类是会议的参加者 Meeting Participant。
在会议的参加者中,又有一些比较特殊的人员,它们的参加与否对会议的成败有着至 关重要的影响,因此被单独列为一类行为者 Important Participant。
Meeting Initiator成功安排会议的目标是让 Meeting Participant（尤其是 Important Participant）出席会议（Attends Meeting）。而且为了保证会议的成功,Meeting Initiator要相 当程度上能够确信 Important Participant会出席会议（Assured（Attends Meeting））。会议应该 安排在一个所有 Meeting Participant都空闲的时间,也就是说不能安排在 Meeting Participant 抽不出身来的时间（Exclusion Dates）。
在了解所有 Meeting Participant的空闲时间之后,Meeting Initiator可以提出一些可能的
会议时间（Proposed Dates）。然后,Meeting Participant从中选择一个自己倾向的时间（Preferred Dates）。在对所有会议参与者的倾向时间进行协调之后,可以确定最终的会议安排情况 Agreement。
15、简述场景应用和处理生命周期的 5种情况。 答：
场景的生命周期关注场景的处理和应用,也就是关注场景在整个需求工程中是如何被 捕获、修改和演化的。
实践中发现的场景应用和处理可以概括为 5种情况：
①从当前系统中捕获和建立关于现在的场景,它们描述问题域的状态和问题。 ②在当前的系统中分析问题和期望,捕获、分析和建立关于未来的场景。
③在当前的系统中分析问题和期望,捕获、分析和建立关于未来的场景,并依据场景 对解决方案的描述,建立需求模型。
④依据已经建立的需求规格说明解释和建立关于未来的场景,然后为场景中描述的解 决方案建立需求模型。
⑤依据需求规格说明所描述的解决方案,建立需求模型,同时建立能够验证解决方案 的场景。最后,使用场景来验证需求模型的正确性。
16、简要说明结构化分析方法的局限性。 答：
结构化分析方法也有自身的局限性。
首先,虽然有了功能实体矩阵、实体生命历史和事件实体矩阵等分析技术,但是数据 需求和处理需求的联接仍然不是一个容易的工作。
其次,结构化分析向结构化设计的过度(数据流图到结构图)中间有着难以处理的鸿沟。 再次,结构化分析过于重视对已有系统的建模,而这常常是难以实现的。 17、请说明为何要确定需求的优先级。 答：（划线部分为必答要点）
在理想的情况下,开发者应该让最终的软件系统完美地满足用户提出来的所有需求。 但是这种理想的情况并不总是会在现实中发生,甚至是很少在现实中发生。作为一项工程, 软件开发总是在一定的环境限制下进行的,成本效益比是它成功的一个基本衡量标准。因此, 在工程环境下,需求与需求之间并不是同等重要的,一些需求应该优于另一些需求得到更多 的实现保证,这就是要确定需求优先级的原因。
21
在实践中,确定优先级的活动尤为重要的情况有：
①一个项目的资源（时间、人力、成本等）有限,无法满足用户的所有需求。此时项目 管理者就需要确定一种最佳方案,在既定的成本下取得最大的效益。需求优先级就是项目管 理者进行此项工作的重要基础。
②项目采用了分阶段的开发方式。为了最大化地体现项目的成本效益,项目应该在第一 阶段就交付用户最重要和最紧急的需求,并将用户最不重要和最不紧急的需求放在开发的最 后一个阶段。这就需要通过确定需求优先级的方式来划分需求的重要性和紧急性等级。
③在项目的开始阶段,并不能明确所有的用户需求,或者无法保证会最终满足所有的用 户需求。这个情况是实践中最为常见的情况,迭代式的开发基本都属于这种情况。对这种情 况,要区分用户需求的优先级,优先迭代级别高的需求,保证项目最终最大程度地满足了用 户的需求。
18、请说明需求分析人员在需求协商当中应该予以确保的三个原则。 答：（划线部分为必答要点）
需求分析人员在需求协商当中应该予以确保的三个原则是：
①明确冲突的因素,避免情绪上的冲突。需求分析人员应该从技术上发现和描述冲突背 后的本质原因,并帮助避免和解决涉众在协商中间可能产生的情绪冲突（Emotional conflict）。
②明确冲突的解决空间。需求分析人员应该引导涉众之间的协商,在涉众协作中发现和 明确各种可能的解决方式（Alternatiyes）、论据（Argumentations）和理由（Rationales）。
③确定最佳解决方案。需求分析人员应该提供足够的技术信息支持,帮助涉众在既有 的解决空间内达成最佳的解决方案。
19、简述使用 DFD描述系统过程模型是必须遵守哪些规则。 答：
使用 DFD描述系统过程模型是必须遵守一些规则,这些规则可以保证过程模型的正确 性。这些规则有：
①过程是对数据的处理,必须有输入,也必须有输出,而且输入数据集和输出数据集 应该存在差异。
如果过程在没有输入的情况下产生了输出,称之为“奇迹”,即输出数据在没有任何可 见来源的情况下就奇迹般产生了。
如果过程接收了数据输入却没有产生输出,称之为“黑洞”。它浪费了输入的数据资源, 却没有做出应有的贡献。
过程是对数据的处理,这种处理是要产生附加价值的,即进行了数据的加工和变换, 而不是简单的数据转移。
②数据流是必须和过程产生关联的,它要么是过程的数据输入,要么是过程的数据输 出。
③DFD当中所有的对象都应该有一个可以唯一标识自己的名称。过程使用动词,外部 实体、数据流和数据存储使用名词。
20、请说明 DFD层次结构的建立的主要步骤。 答：
DFD层次结构的建立的主要步骤是： ①创建上下文图。 ②发现并建立 DFD片断。
22
③根据 DFD片断组合产生 0层图。
④对 0层图的过程进行功能分解,产生 N层图。 21、请说明 DFD图质量评判的准则是什么？ 答：
对 DFD图（尤其是 0层图）质量的判定有下面几个准则： ①遵守相应的规则,没有语法错误。
②具有良好的语义,过程的功能设置要高内聚、低耦合。
③保持数据一致性,过程的输人流要足以产生数据输出。同时过程的输出流是在充分 利用输入数据的基础上产生的,不存在输入数据的浪费。
④控制复杂度,不要一次在图中显示太多的信息。一般情况下,一个图中的过程数量 最好控制在 5～9（人脑的最佳信息处理量）个。而且图中的数据流数量越少越好,越简洁 越好（接口最小化）。
22、请说明如何快速有效地判定一个 DFD图是否为原始 DFD图？ 答：
功能分解的过程需要持续进行,直至最终分解产生的子图都是原始 DFD图,关键问题 是如何快速有效地判定一个 DFD图是否是原始 DFD图。在分解产生的子图为下述情景之一 时,可以判定其为原始 DFD图,此时应该停止持续的功能分解活动：
①所有过程都已经被简化为一个选择、计算或者数据库操作。 ②所有数据存储都仅仅表示了一个单独的数据实体。 ③用户已经不关心比子图更为细节的内容,或者子图的描述已经详细的足以支持后续 的开发活动。
④每一个数据流都已经不需要进行更详细的切分,以展示对不同数据的不同处理方式。 ⑤每一个业务表单、事务、计算机的屏幕显示（Computer On-line Display）和业务报表 都已经被表示为一个单独的数据流。
⑥系统的每一个最低层菜单选项都能在子图中找到独立的过程。 23、请说明如何进行 DFD的验证？ 答：（划线部分为必答要点）
在结束 DFD的建立工作之前,还应该执行 DFD的验证,以确保所创建 DFD的正确性 和有效性。
对 DFD的验证主要包括以下几个方面： （1）验证DFD的语法
要确保DFD中不会发生语法错误。有一些常见的语法错误,例如有些数据流没有终点、 有些过程没有输出流等,往往意味着在进行DFD描述时存在着信息的遗漏。 （2）验证DFD的结构
首先要验证DFD层次结构之间的一致性,包括分解的平衡性,也包括不同 DFD之间元 素实例使用的一致性（例如命名是否一致、格式要求是否一致等）。
其次要验证DFD层次结构说明的完备性,例如,是否所有的过程都有更详细的说明（子 图或者逻辑说明）,是否所有的数据流和数据存储都有数据说明等。 （3）验证DFD的语义
验证DFD的语义是为确保DFD所说明内容的正确性和准确性。这个工作通常要由用户 在需求工程师的帮助下来执行,用户需要浏览DFD图,从中发现和需求不符或者理解上存在
23
偏差的地方。
24、简述 ERD的创建步骤。 答：
在获得充分描述信息的情况下,ERD的创建工作可以按照下列步骤进行：
①从描述信息中辨识实体。从描述信息中寻找系统需要收集和存储的信息,然后将其 建模为实体。寻找时,可以重点关注描述信息中的名词,并以系统是否需要收集其相关的特 征为依据来判定是否将其建立为独立的实体元素。
②确定实体的标识符。为每个实体选择能够唯一标识实例且比较稳定的属性为标识符。 ③建立实体之间的关系。从描述信息中辨识实体之间存在的业务联系,描述为独立的 关系元素。并判断各个关系的建立是否会产生新的关联实体或者影响已有的实体特性。
④添加详细的描述信息。在得到一个初步的框架之后,进一步从描述中挖掘信息,为 数据模型添加详细的描述信息,包括实体的详细属性和关系的基数。
25、请说明为什么要编写需求规格说明文档？ 答：（划线部分为必答要点）
（1）编写需求规格说明文档的必要性：
在一个复杂软件系统的开发中,编写需求规格说明文档是非常必要的。
一方面,清晰、明确、结构化的文档可以将软件系统的需求信息和解决方案更好的传 递给所有的开发者。
另一方面,文档可以拓展人们的知识记忆能力。
（2）编写需求规格说明文档的他好处：
①需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。开发者和客户 可以使用它作为合同协议的重要部分,涉众也可以利用它在相互间达成一致。
②需求规格说明文档可以成为项目开发活动的一个重要依据。它可以作为软件估算和 项目进度安排的基础,也可以作为开发人员判断设计、测试等工作的进行是否正确的依据。
③在需求规格说明文档的编写过程中,可以尽早的发现和减少可能的需求错误,从而减 少项目的返工,降低项目的工作量。
④需求规格说明文档可以成为有效的智力资产。这个智力资产可以帮助新加入的团队 成员更快的融入项目,可以帮助更好地将软件产品移交给新客户,也可以帮助开发者更好地 进行其他类似项目或者后续增强项目的开发。
26、试比较编写需求规格说明文档所使用的三种语言。 答：（划线部分为必答要点）
需求工程师在描述需求规格说明文档时使用的语言分为三类： ①非形式化语言,即自然语言。
②半形式化语言,比自然语言具有更丰富的语义和更严格的语法同时又没有严格到完 全基于数学方法的语言,例如ERD、DFD、UML等图形语言。
③形式化语言,基于数学的语言,例如VDM、Z语言等。 自然语言具有复杂的规则和多样化的表达方式,所以它的表达能力最为强大。而且自 然语言属于普通人的语言,每个人都熟知其规则、表达方式和特点,所以非常利于用户的理 解。但同时自然语言也具有松散、模糊、歧义、凌乱等不好的特性。这使得它无法被机器所 理解,它所描述的信息内容也无法准确地映射为机器行为。
形式化语言是基于数学方法的语言,具有数学的表示法特性。使用形式化语言描述的
24
信息内容是可以进行逻辑一致性推导和证明的,所以它能够保证信息的正确性。而且形式化 的信息描述能够被机器所理解,它所描述的信息内容可以准确地映射为机器行为。但是形式 化描述的信息要求读者具备谓词演算方面的知识,这对普通的用户而言显然要求过高,以至 于大多数用户无法读懂以形式化方法描述的信息。形式化方法所能描述的内容也是有限的, 具体的有限性因形式化方法的不同而各异。
半形式化语言是介于自然语言和形式化语言之间的描述语言。一方面,半形式化语言 具有严格的语法,定义方式比自然语言更加严格,这使得它可以避免自然语言模糊、松散、 歧义、凌乱等不好的特性。另一方面,半形式化语言具有丰富的语义,使用规则比形式化语 言更复杂和多样,这使得它具有比形式化方法更强的表达能力。但是,丰富的语义使得半形 式化语言的语法无法严格到可以等价于数学方法的程度,所以它描述的信息还需要进行额外 的处理才能够被机器所理解或者准确地映射为机器行为。同时,严格的语法限制也使得半形 式语言的表达能力无法达到自然语言的程度。而且因为具有独特的语法和语义,所以半形式 语言对普通用户而言无异于一门全新的语言,它所描述的信息很难被用户所理解。
自然语言采用了以文本为主的描述方式；形式化语言也是使用以文本为主的描述方式； 半形式化语言采用了以图形为主的描述方式,因为：
①半形式化语言的语法限制使得它用于信息描述的基本元素是有限的,这个有限性使 得它以限定文本或者限定图形符号为描述方式成为可能。
②半形式化语言追求表达语义的丰富性,而在这一点上图形符号是胜过限定文本的, 所以人们倾向于选择使用图形符号的描述方式。
在进行需求规格说明文档的编写时,用户倾向于使用自然语言,因为其他两种类别的 语言难以理解。开发人员倾向于使用半形式语言和形式化语言,因为自然语言的表达不够严 格和准确。形式化语言在实践中的应用很少,因为需求规格说明对语言的语义和表达能力有 着较高的要求,而这恰恰是形式化语言有所欠缺的。
为了让需求规格说明文档的内容能够同时满足用户和开发人员的需要,需求工程师在 实践中更多时候会综合使用自然语言、半形式化语言和形式化语言。
27、简述评审的过程并说明何时可以结束评审？ 答：（划线部分为必答要点）
常见的评审过程可以分为 6个阶段：
（1）规划阶段（Planning）,作者和仲裁者共同制定审查计划,决定审查会议的次数,安 排每次审查会议的时间、地点、参与人员、审查内容。
（2）总体部署阶段（Overview）,作者和仲裁者向所有参与审查会议的人员描述待审查材 料的内容、审查的目标以及一些假设,并分发文档。
（3）准备阶段（Preparation）,审查人员各自独立执行检查任务。在检查的过程中,他们 可能会被要求使用检查清单、场景等检查方法,记录下来检查中发现的问题,以准备开会讨 论或者提交给收集人员。
（4）审查会议阶段（Inspection Meeting）,通过会议讨论,识别、确认和分类发现的错误。 在审查会议结束时,还可以根据审查发现的问题严重程度来确定软件需求规格说明文档是可 以在修正后接受,还是需要在修正后再次进行评审。
（5）返工阶段（Rework）,作者修改发现的缺陷。
（6）跟踪阶段（Follow-up）,仲裁者要确认所有发现的问题都得到了解决,所有的错误都 得到了修正。仲裁者还要判断修正后的文档是否已满足审查的结束标准,如果不满足就需要 再次进行评审。
若满足下列情况,审查工作可以结束。
25
①审查期间审查人员提出的所有问题都已解决。
②文档中和相关的工作产品中的所有更改都已正确完成。 ③修订过的文档已经进行了拼写检查。
④所有标识为TBD(待确定)的问题都已经解决,或者已经对每个待确定问题的解决过 程、计划解决的目标日期和由谁来解决等编制了文档。
⑤文档已经在项目的配置管理系统中作了登记。 28、简述需求管理的主要作用。 答：（划线部分为必答要点）
在实践中发现的需求管理的作用有：
①增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解。需求管理将需求 基线纳入了项目的知识管理,能够帮助项目涉众更好地获得并理解这些知识,从而增强了项 目涉众对需求(尤其是复杂需求)的掌握。
②增进了项目涉众之间的交流。需求管理为项目涉众提供了一个共同的需求理解,从 而有助于项目涉众之间的交流,减少了可能的误解和交流偏差。
③减少了工作量的浪费,提高了生产力。需求管理能够更加有效地处理需求的变更, 减少因此产生的返工工作,从而提高了项目的生产率。
④准确反映项目的状态,有助于项目决策。需求管理收集的需求跟踪信息能够更加准 确地反映项目的进展情况,从而帮助项目管理者更好地掌握项目状态,做出更加符合实际情 况的合理决策。
⑤改变项目文化,使得需求的作用得到重视和有效发挥。需求管理可以为项目涉众带 来很多的好处,使得项目涉众认识到需求在项目工作中的重要性,并依照需求开展工作。
29、简述需求管理的重要任务 答：
需求管理的重要任务有： ①交流涉众的需要。
②将需求应用、实施到解决方案。 ③驱动设计和实现工作。 ④控制变更。
⑤将需求分配到子系统。 ⑥测试和验证最终产品。 ⑦控制迭代式开发中的变化。 ⑧辅助项目管理。
30、简述如何进行需求变更控制？ 答：（划线部分为必答要点）
需求开发是一个获取、明确并定义需求的过程,但需求并不是在需求开发结束之后就 会恒定不变的。
为了解决需求变化给项目带来的影响,需要正确地处理需求变化,首先要认识到在很 多情况下,需求的变化是正当和不可避免的：
①问题发生了改变。软件被创建的目的在于解决用户的问题,可是随着时间的发展, 形势可能会发生变化,导致用户的问题也发生了变化。原来的问题可能因为各种原因不解白 破,或者用户将原来的主要问题降为次要问题,而将原来的次要问题升级为主要问题等。所
26
有这些都意味着软件的需求应该发生变化,否则创建的软件将会减小甚至失去服务用户的作 用。
②环境发生了改变。软件是通过与其周围环境进行交互的方式来解决用户的问题的。如 果软件的环境发生了改变（例如法律变化、业务变化等）,那么即使用户的问题依旧,软件 的需求也应该发生改变。否则,最终的软件将不能像设想的那样有效地解决用户的问题,因 为旧有的模式已经无法和新的环境形成有效互动。
③需求基线存在缺陷。需求开发的理想结果当然是建立一个完全无缺陷的需求基线, 但这是不可能达到的目标。因为需求工程的复杂性,需求开发得到的需求基线总是或多或少 的会遗留下一些缺陷。当这些缺陷在开发或者使用中暴露出来时,必须予以及时解决。
④用户变动。在开发和使用中,软件产品的用户可能发生的人员更替,这时新的用户 就可能会提出和原有用户不同的要求。在维护期间和比较长的开发周期中往往会发生这类变 更。
⑤用户对软件的认识变化。随着对软件开发和使用的直接参与,用户会对软件领域有 越来越多的了解,这时他们也往往会提出越来越多、越来越具体的需求,其中就夹杂着对原 有需求的修改要求。在一个全新的领域或者为一个没有软件经验的企业开发软件时,这种情 况非常常见。
⑥相关产品的出现。在产品开发的过程中,可能会有竞争产品、类似产品或者需要交 互的其他产品等相关产品出现,这时往往需要开发者根据相关产品的新鲜知识,变更原有的 软件需求和开发计划。
31、在功能分解过程中,最重要的是要保证分解过程的平衡性（Balance）。平衡性是保 证功能分解不会导致需求内容出现偏差的方法,它要求 DFD子图的输入流、输出流必须和 父过程的输入流、输出流保持一致。请对下图的平衡性做出分析。
答：
在上图所描述的功能分解中,父过程 P的输入流是 a,输出流是 b。在 P分解后产生的 子图当中,a是唯一从子图范围之外进入子图的数据流,所以 a是子图唯一的输入流。同样 b是唯一从子图流向范围之外的数据流,所以 b是子图唯一的输出流。这样,P的输入流、 输出流就和子图的输入流、输出流保持了一致,对 P的功能分解就满足了平衡性。
27
32、在功能分解过程中,最重要的是要保证分解过程的平衡性（Balance）。平衡性是保 证功能分解不会导致需求内容出现偏差的方法,它要求 DFD子图的输入流、输出流必须和 父过程的输入流、输出流保持一致。请对下图的平衡性做出分析。
答：
上图所表示的功能分解中,父过程的输入流为 a,父过程输出流为 b,子图的输入流为 a和 c,子图的输出流为 b。这样,虽然父过程和子图的输出流保持一致,但它们的输入流 却存在差异,于是图所描述的功能分解破坏了平衡性,是一个错误的功能分解。 六、案例分析题
1、请按下列描述,用 DeMarco-Yourdon和 Gane-Sarson表示法分别画出“食物订货系 统”的过程模型图（DFD）。
食物订货系统主要和 3种外部的实体：顾客、管理者和厨房存在交互行为。首先,食物 订货系统需要接收顾客的食物订单,并在接收后向顾客呈送一个收条,然后将订单转交系统 内部的功能处理。其次,食物订货系统要能够将已经接收的食物订单及时的转交给厨房,这 样厨房才能够根据订货的情况进行生产。最后,食物订货系统要能够基于一段时间的事务积 累,为管理者提供管理报表,反映组织的生产状况。
食物订货系统的内部功能主要有 4个。第一个功能是接收顾客的食物订单,向顾客呈送 收条,并将订单及时转交厨房,同时启动对订单的后续处理（第二个功能和第三个功能）。 第二个功能是处理顾客食物订单,根据订单生成并记录食物的销售事务。第三个功能也是处 理顾客食物订单,但其目的是根据订单更新库存信息,以保证生成的原材料供应。第四个功 能是根据一段时间内的食物销售情况和库存管理情况,生成管理报表,向管理者反映组织的 生产状况。
在食物订货系统中,食物销售记录和库存记录是为了完成系统的功能（产生管理报表）, 组织希望储存的数据。
28
解答：
图 1用 DeMarco-Yourdon表示法表示的 DFD
图 2用 Gane-Sarson表示法表示的 DFD
2、在下面的描述中,辨识参与者（ACTOR）和用例（USE CASE）,并画出一个用例 图。
在医生的办公室里,接待员、护士和医生使用病人记录和计划安排系统。当病人第一次 来这里看病时,接待员使用该系统来输入病人信息,并且他们安排所有的预约。护士使用系 统来跟踪病人每次看病的结果并输入护理病人的信息,如医疗和诊断。护士也可访问这些信 息以打印病人诊断结果或病人看病历史。医生主要用这个系统来查看病人的病史,偶尔也输 入病人医疗信息,但通常他让护士输入这些信息。
29
解答：
输入病人信息
接待员
安排预约
登录
医生
输入医疗信息
护士
输入护理病人（诊断）的信
息
打印病历
查询病人诊断结果
查询病史
打印病人诊断结果
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
11、在重新浏览面谈日程的时候,你发现有几个问题看上去不合适。下面是准备问
Sampson纸产品公司销售经理的原问题。这家公司想把它的一些销售信息放到 Web上去, 以便经理们可以交互地评论它,从而优化他们的销售方案。用更合适的方式,重新写下面的 问题。
（1）你的下属告诉我,你非常渴望有一台计算机。这是真的么? （2）我是这个领域的新手,我有没有忽略什么呢?
（3）你在销售计算中最常用的信息资源是什么,使用频度如何?
（4）其他销售经理认为,把一些月度销售商品放到 Web上,然后做趋势分析,将会是 一种主要改进,你同意他们的做法吗?
（5）没有比你现在使用的陈旧的方法更好的销售方案吗? 解答：
（1）你认为作为一个销售经理,是不是应该拥有一台计算机?（诱导性问题） （2）我是不是还忽略了什么?（上下文无关问题）
（3）①你在销售计算中最常用的信息资源是什么（双筒问题）
②使用频度如何
（4）你认为把一些月度销售商品放到 web上,然后做趋势分析会是一种改进吗（诱
导性问题）
（5）还有比目前方法更好的销售方案吗（上下文无关问题）
12、作为系统分析项目的一部分,需要为生产数字钟的 chronos公司更新自动化会计功 能。你将要同首席会计 Harry straiter面谈。写出 4到 6个涉及他所使用的信息资源、信息格 式、决策频度、需求的信息性质和决策样式的面谈目标。
（1）说明你将如何联系 Harry以安排一次面谈。
（2）说明在这场面谈中你会使用哪种面谈结构?为什么?
（3）Harry有 3个下属也使用这个系统。你和他们面谈吗?为什么?
（4）写出 3个开放式问题,在面谈前通过电子邮件寄给 Harry。用一句话解释为什么 应当由人而不是由电子邮件来指导面谈?
解答： （1）参考面谈过程的准备阶段：
打电话或者 E-mail给 Harry,因为要进行深入面谈,可以先将一些问题通过 E-mail发给 他。
（2）采用菱形面谈结构,因为目的是要更新自动化会计功能．也可以考虑使用漏斗结 构。
（3）应当面谈,因为下属和领导应该具有不唰的目标,而这些目标是领导不能提供的。
考察点：涉众的分类
采用漏斗型。以一般的开放式的问题开始．有助于分析人员取得总体认识。然后再逐 步就某些问题展开深入面谈。
（4）参考规则：
①面谈获取信息的类型 ②面谈的优点
面谈是复杂的过程。可以实现很多的目标,只有依靠人的灵活和主观能动性才能使面 谈达到最优效果。
35
13、下面是系统分析团队的一名成员提出的第一份面谈报告：在我看来,面谈进行的很 好。我和他就这个问题聊了一个半小时。他告诉我有关公司的所有历史,很有意思。他也提 到,自他来到该公司的16年间,公司没有任何变化。我们不久将再次举行会面,以及结束这 次面谈,因为我们还没有深入研究我准备的问题。”
（1）试评论这个面谈报告。假设你要团队成员使用下图提供的报表,那么他漏了什么主 要信息？
（2）什么信息对面谈报告来说是无关紧要的？
（3）如果真的发生了报告中提及的情况,则必须向队友提出哪3个建议,以帮助他更好 地举行下一次面谈。
面谈对象：SalDomask 会见者：S.Cabbot
日期：3月 3日 主题：计算机使用
面谈的目标：找出关于计算机使用的态度；
获得用户的使用估计；
看最新建议的系统的观点是否满足目标吗？
下次面谈的目标：
找出 Sal怎样看待系统支持部门。 找出下一个面谈对象的观点。 面谈的要点：
Sal说道：“计算机是我的朋友。” “一直”都在用计算机。 迫不及待地要熟悉新系统。
会见者的观点：
对了解更对有关系统如何促进工作感兴趣。 如果不使用计算机进行工作,会感到枯燥。 将成为新系统的热情支持者/促进者。
解答：
（1）面谈时间稍长,而且控制不佳。遗漏了关于“最新建议的系统的观点” （2）有关公司的所有历史
（3）参考面谈过程一一面谈主体阶段：
①控制面谈的过程。面谈开始的时候可以通过例如谈公司历史来酝酿一下交流的气氛, 但是不能偏离主题。如果长时间的谈论不相关的信息的时候。需求分析人员就可以委婉的提 醒面谈对象。并重新切回正题。
②注意保持面谈的主题。针对每个面谈的目标,要在面谈的过程中安排合适的提示。 逐一引导面谈对象对各个主题的叙述。
③总结面谈的要点,注意此次面谈过程的成功和失误,明确下次的目标。以便为下次 面谈做充分的准备
14、“每当我认为已经获取用户的信息需求时,他们却已经发生了变化。这就像试图射 中一个运动目标。在半数时间里,我认为甚至用户自己也不知道需要什么。”Flo Chart说。 他是 2Good 2 Be True公司的需求工程师,该公司负责为几家制造公司的营销部门调查产品 的用途。
（1）用一段话向 Flo chart解释,原型化方法怎样才能帮他更好地定义用户的信息需求。 （2）用一段话评论 Flo Chart的观察：“在半数时间里,我认为甚至用户自己也不知道需 要什么。”一定要解释原型化方法怎样才能真正地帮助用户更好地理解和阐明他们自己的信 息需求。
（3）用一段话向 Flo Chart建议：一个具备原型特征的交互式 web站点缘何能解决 Flo
36
关于捕获用户信息需求的问题。
解答：
（1）答案主题
①根据需要确定原型类型②进行原型开发③获得用户反馈④定义所得需求 （2）答案要以“隐含知识”和“用户表述时的主观加工”为主题
（3）原型化方法利用直观化的界面来最快程发的得到用户的反馈,通过用户的反馈来 获知其实际的需求。
15、“我有一个绝妙的主意!”Bea Kwicke宣布,他是系统团队的一位新来的需求工程 师,“让我们跳过所有的 SDLC垃圾,直接为一切设计原型。我们的项目会进展的更快,还 可以节省时间和金钱,并且所有的用户会感到我们似乎很在意他们,而不是连续几个月不与 他们交谈。”
（1）列出你(作为与 Bea同一个团队的成员)用来劝阻她不要试图放弃 SDLC,而直接为 所有项目设计原型的原因。
（2）Bea对你所说的话很失望。为了鼓励她,用一段话向她说明,你认为适用于原型化 方法的情形。
解答： （1）主要原因：原型仪仅是开发当中使用的一种手段,它利用得当可以加速开发的进程, 但不能代替软件开发中的所有工作。 （2）情形见下表,尤其是其中红字部分。
废弃型
阐明并细化用例和功能性需求
水平型
识别遗漏功能 研究用户界面方法
垂直型
演示系统可行性
演化型
实现核心用例
根据优先级实现其他用例 使得系统适应快速变化的需要 实现并扩充核心功能 实现并扩充核心算法 测试并调整性能
37
因篇幅问题不能全部显示，请点此查看更多更全内容