《软件需求分析》习题集

1、软件需求分析习题集软件需求分析课程组编20122012年 4 4月目 录一、单项选择题 .2二、填空题 .5二、判断题.9四、名词解释题 .11五、问答题 . 14六、案例分析题 .28）理解不透彻或应用不软件需求分析习题集一、单项选择题1、软件生产中产生需求问题的最大原因在于对应用软件的（ 坚决。（A）复杂性（B）目的性（C）模拟性（D）正确性2、 需求分析的目的是保证需求的（）。（A）目的性和一致性（B）完整性和一致性（C）正确性和目的性（D）完整性和目的性3、系统需求开发的结果最终会写入（）。（A）可行性研究报告（B）前景和范围文档（C）用户需求说明4、（现实属性和中的（B）（D）系统需

2、求规格说明）构成了问题解决的基本范围，称为该问题的问题域。 实体和状态 （C）实体和操作（D）状态和操作5、功能需求通常分为三个层次，即业务需求、用户需求和（A）硬件需求（B）软件需求（C）质量属性6、比较容易发现的涉众称为初始涉众，又称为（ 的投资者。（A）关键涉众（B）涉众基线（C）普通涉众）。（D）系统需求，通常包括客户、管理者和相关（D） 般涉众7、如果在最终的物件（Fi nal Artifact）产生之前，一个中间物件（Mediate Artifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的（）。（A）模拟（B）构造（C）原

3、型（D）模型8、按照使用方式进行分类，原型可分为：演示原型、（）、试验原型和引示系统原型。（A）非操作原型（B）系列首发原型（C）选定特征原型（D）严格意义上的原型9、按照功能特征进行分类，原型可分为：（）、非操作原型、系列首发原型和选定特征原型。（A）拼凑原型（B）样板原型（C）纸上向导原型（D）严格意义上的原型10（按照开发方法进行分类，原型可分为：演化式原型和抛弃式原型，其中抛弃式原 型又被细分为（）。（A）演示原型和试验原型（B）系列首发原型和选定特征原型（C）探索式原型和实验式原型（D）样板原型和纸上向导原型11、原型的需求内容可以从三个纬度上分析：即（）。（A）外观、角色和实现（B

4、）开发、实现和作用（C）成本、技术和实现（D）需求、作用和角色12、当用户无法完成主动的信息告知，或与需求工程师之间的语言交流无法产生有效的结果时，有必要采用（）。（A）民族志13、 以下（A）突现14、 以下（B）观察法（C）话语分析（D）任务分析）不是情景性的重要性质（B）涉身（C）完善）是情景性的重要性质（D）模糊（D）即时（B）开放（C）交互（A）全局（A）面向目标的方法（B）基于场景的方法。（C）基于用例的方法（D16、下列（ ）属于定量硬数据（A）工作手册（B）规章手册仃、下列（ ）属于定性硬数据（A）数据收集表 （B）月报表18、功能目标可以分为（基于采样的方法（C统计报表（C）

5、年报表（D备忘录（D）规章手册（A）安全目标和可用性目标(B)满足型目标和信息型目标（D）解和细化时使用的维护目标和实现目标AND Co ntributi on 链接和 OR Co ntribution接，Contribution的作用是（）。（A）积极的（B）消极的（C）积极的或消极的（D）不能确定化的子目标，D链接将将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细（A）无法确定（B）阻碍（C）不能满足（D）足以满足21、OF链接是将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细 化子目标中的（），那么将足以满足父目标。（A）每一个（B）任何一个（C）特定的（D）

6、某一个22、下列选项中，（）不是在目标模型中使用的其他模型元素。（D）概念）。24、场景的分类框架将场景方法从场景的（）4个方面进行了分类和描述。（A）形式、目的、内容和生命周期（B）外观、目的、内容和生命周期（C）描述、目的、内容和形式（D）描述、外观、目的和内容25、场景的形式是指场景的表达模式，从形式上分为两个方面：（）（A）内容和目的（B）内容和生命周期（C）描述和外观（D）描述和目的26、描述场景所使用的表示法要符合正规性要求，一般可使用非形式化语言、半形式 化语言和形式化语言。在实践中，（）是主要的描述方式。（A）形式化的程序语言（B）非形式化的自然语言（C）形式化的图形工具/、亠

7、27、外观是指场景被表达出来时的效果，主形式化的设计语言）三种类型。（A）静态、动态和结构化（B）线性、非线性和交互（C）静态、动态和动静结合（D）静态、动态和交互不是场景的场景的内容是指场景所表达的知识类型。它被分为6个不同的方面。下列（A）主要关注点（B）环境范围 （C）目的 （D）抽象层次29、需求工程利用场景的目的可能有三种：即：（A）描述、探索和解释（B）描述、表示和探索（C）描述、探索和发现（D）表示、解释和证明30、使用解释性场景在需求分析时能够（），或者被用于进行需求的验证。（A）提高模型的复杂性（B）降低模型的复杂性15、下列（）不是需求获取常见的模型驱动方法（A）行为者（B

8、）场景（C）操作（C）建立目标模型（D）发现问题和缺陷（C）提高预见性（D）降低编程量31、(A)卜列（）不是场景方法在需求工程中的应用。帮助进行详细的需求分析（D）演绎关系）的描述方式。（D）动态结构化文本（）三合取、 析取和扩展（B）编写系统需求规格说明（C）结合面向目标的方法，指导需求获取活动的开展（D）组织需求获取得到的信息32、 下列（）是组织场景时可用的场景关系。（A）合取关系（B）定性关系（C）定量关系33、 与其他的场景方法相比，用例最大的特点是采用了（A）静态非结构化文本（B）动态非结构化文本（C）静态结构化文本34、用例之间的关系主要有（A）包含、扩展和简化（D）包含、扩展

9、和泛化、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息，这种分析活动被称为（）。（A）需求信息获取（B）建立软件系统解决方案（C）需求信息转化（D）建立需求分析模型36、 （）是建模最为常用的两种手段。（A）具体和抽象（B）抽象和分解（C）分解和细化（D）抽象和细化37、 抽象通过强调本质的特征，（）了问题的复杂性。（A）调整（B）避免（C）增加 （D）减少38、 需求分析仅仅需要描述解决方案，不需要探索实现细节的情况下，分析模型又是（）的，尤为适用。（A）形式化（B）半形式化（C）结构化（D）非结构化39、上下文图描述系统与环境中外部实体之间的界限和联系。它从现实世界的角度说明

10、了系统的（ ），并确定了所有的输入和输出。（A）环境与外观（B）边界和联系 （C）边界和环境 （D）输入和输出40、 （）是结构化分析方法的核心技术，它表明系统的输入、处理、存储和输出，以 及它们如何在一起协调工作。（A）数据流图DFD（ B）实体联系图 ERD （ C）状态转换图（D）上下文图41、 结构化、信息工程和面向对象三种方法学下的需求分析技术都是（）的。（A）面向问题域 （B）面向解系统 （C）面向设计 （D）面向需求一）需求阶段的分析。42、 使用面向冋题的技术对冋题世界的建模就被称为（A）前期（B）中期（C）后期 （D）全过程）需求阶段的分析。43、 使用面向解系统的技术对软件

11、系统解决方案的描述称为（44、 需求分析活动中期个重要任务是进行（D）全过程），明确用户需求的隐含信息，展开为 明确的对软件系统的行为期望，即系统需求。（A）需求整理（B）需求细化 （C）需求获取（D）需求分析45、 在分层结构中，DFD定义了三个层次类别的 DFD图：（）、0层图和N层图。（A） 1层图（B）底层图（C）上下文图（D）顶视图图中不会出现为数据存储是系统内部的功能实现，所以在将系统视为黑盒的情况下，上下文。（C）虚线框（D）矩形框。（B）顺序图、通信图和时间图（D）交互概述图、通信图和时间图（C）交互图、状态图和活动图），重点都是用户的现（A）实体（B）数据存储实例（C）需求信

12、息（D）过程处理47、 数据建模技术能够弥补过程建模在（）方面的缺陷，它描述数据的定义、结构和关系等特性。（A）需求分析（B）数据转换 （C）数据说明（D）数据分析48、 。概念实体是一种抽象概念，不考虑概念背后的物理存在，所以通常不包含与之相关联的其他（）。（A）模型（B）特征（即属性）（C）关系 （D）处理49、 在ERD建模中，实体通常所指的就是（）。（A）逻辑实体 （B）概念实体 （C）物理实体（D）进程实体数据5被称为属属性是实体的特征，不是数据。属性会以一定的形式存在，这种存在才是（A）域（B）实例（C）说明（D）值51、 ERD关系的度数（Degree）是指参与关系的实体数量，是

13、度量关系（）的一个指标。（A）模型（B）复杂度（C）精确度（D）属性值52、 ERD关系的基数分为最大基数和最小基数。最大基数又被称为（）。（A）键约束（B）参与约束（C）自然约束 （D） 般约束 的形式是在实体之间建立关系时，可能会产生一些附带的实体，被称为关联实体，最常见（A）逻辑实体（B）进程实体（C）概念实体（D）自然实体54、在实现ERD与过程模型同步的技术中，（）是一种较为常见的技术。（A）用例图（B）数据流图（C）功能/实体矩阵（D）微规格说明55、 下列（）不是用例模型中的关系（B）关联（C）泛化（D）包含56、系统性边界是指一个系统所包含的系统成分与系统外事物的分界线。用例模

14、型使用一个（）来表示系统边界，以显示系统的上下文环境。（A）圆形框 （B）菱形框57、UM使用的行为模型有三种，即:（A）交互图、状态图和顺序图58、项目的前景和范围文档、用户需求文档都被视为属于（ 实世界。（A）开发文档（B）需求文档（C）前景文档（D）用户文档59、 系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口 需求规格说明文档和人机交互文档一起被用于系统开发的目的，都被认为是开发文档。（A）开发文档（B）需求文档（C）过程文档（D）用户文档60、 下列（）不是需求规格说明文档的读者（A）项目管理者（B）编程人员（C）销售商（D）律师、填空题1、传统的需求分析方法

15、都是从设计领域转入分析领域的。2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进行巧 妙的功能安排。3、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡，寻找一套切实产生软件需求规格说明系统影响，却会给解系统带来极大影响的问题域特性有效的功能配置。4、应用型软件分析阶段的主要目的是发现人们利用软件的原因（目的），找出需要软件 解决的问题，理解应用环境中的领域知识，保证功能的模拟性-5、需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需 求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。6、软件需求开发用来确定系统需求中应该由

16、软件满足的部分，将其映射为软件行为,8、优秀的需求应该具备 7个特性，即完整性、正确性、精确性、可行性、必要性、无11、演示原型主是被用在项目启户想段中的系统视图，所以它要能够表现用户界面的重 要特征。13、 ，如果一个问题的技术解决方案是不清晰的，演示原型也可以被用来展现相应的细 节功能以使用户确信该问题解决的可能性。14、 通常来说，如果用户需求出现了模糊、不清晰、不完整等具有一定不确定性的特征, 就可以考虑使用原型方法。15、角色是指原型物件在用户工作中的价值，也就是说它为什么对用户是有用的。16、外观是指用户对原型物件的具体感觉体验，即用户在使用原型物件时会看到什么、 听到什么和感觉是

17、指原型物件完成功能的细节技术和方法。18、 使用演化式原型方法，在开发时就需要注意原型的健壮性和代码的质量。19、 使用实验式开发方法，需要实现多种技术方案，考察重要的系统的质量属T20、 选择使用探索式开发方法，需要尽可能地考虑各种不同的设计选项，比较不同选项 下的用户反型方法的最大优点是能够及早地解决系统开发中的不确定性十而降低软件项目 失败的风险。22、航空调度、证券交易、医疗手术控制等复杂的协同问题都具有突现的情景性。23、 民族志的一个主要应用目的就是研究和解决复杂的协同问题。24、 复杂的工作总会同时存在着正常流程和异常流程，异常流程大多是一些特殊情况下 的处理，限定了异常处理的上

18、下文环境，即异常处理具有局部的情景性。25、 有很多重要工作的进行需要用户具备一定的认知，认知要求已经成了用户工作必备 的部分3、即工作观察是最简的情的观察方法，应用目的是发现异常流程，验证用户所述知识和实 际的一致性，以及发现默认知识。27、时间采样允许需求工程师建立指定的时间间隔来观察用户的活动情况。28、文档审查主要获取对象包括相关产品的需求规格说明、硬数据和客户的需求文档。29、文档分析通常是数据建模方法的一个基础部分，它是通过检查采集的硬数据来确定 潜在的需求。果当前存在一份客户的需求文档，就可以使用需求剥离技术，从需求文档中抽取 单个的需求并加入到新的需求文档之中。31、需求工程师

19、可以使用模型驱动方法来进行信息的整理和归类，其中模型驱动方法所建立的模型是进行信息整理和归类的很好的框架32、 模型驱动方法的模型是在前期需求阶段的分析中建立的。33、 目标模型的一个核心要素是元素之间的关系，称为链接。10、按照媒介载体进行分类，原型可分为：样板原型和纸上向导原型。34、 目标模型的链接有两类：一类是目标之间的链接；另一类是目标与其他模型元素之 间的链接。面向目标方法的处理过程可以分为三个阶段：目标获取、目标分析（即目标模型的 建立）和目标实现。36、 目标实现阶段的主要任务是收集与目标相关的需求信息，讨论可能的候选解决方案, 确定最终的系统详细需求和解决方案。37、 场景具

20、有重点描述真实世界的特征，它利用情景、行为者之间的交互、事件随时间 的演化等方式来叙述性地描述系统的使用。38、 静态外观的场景被展现为一个或者数个描述性的文本或者图片。39、 动态外观的场景会被以动态的方式展现出来，人们可能会要求按时序向前或者向后浏览场景，也可能会要求跳转到场景的某一个时刻进行观察。_40、 交互外观的场景提供交互性，它允许用户在一定程度上控制和改变场景的变化时序 或者效果。具体场景，又称为实例场景，是对个别行为者、事件、情节的细节描述。42、 抽象场景，又称为类型场景，是以经验中的类别和抽象概念来描述事实。43、 探索性场景可以用来进行需求获取和需求建模与分析。44、 每

21、个用例是对相关场景集合的叙述性的文本描述，这些场景是用户和系统之间的交 互行为序列用例是场景方法中的的目一种，是静态的结构化文本描述。46、 在高层的功能需求获取完备之前，用例的产生方式中不允许使用功能分解47、 单个用例描述了系统的功能片段，系统的所有用例基于一定的关系组织起来，建立 用例模型，原就有用例和新个系统的功用例的咲系即为包含关系。49、在需求工程中，主要产生三类重要的文档：项目前景和范围文档、用户需求文档以 及需求规格说明。用例文档通常被用来代替用户需求文档，起到记录、交流领域信息和用户 期望的0作用需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差 距。需求

22、分析就是用来解决这个差距的需求工程活动。51、 需求分析的根本任务是：建立分析模型并创建解决方案。52、 分解将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子 冋题之间白基于软件构建单位及其之间的关系建立的模型，用来说明软件逻辑上的构建方式 和实现方式，由于它使用的组元及其关系都是软件的元素，因此它是来自于软件的模型，称 为计算模型。型语言的三要素：语法、语义、语用。其中语用给出”个模型元素描述的更 宽广的上下文，以及影响该模型元素意义的约束和假定。55、 互相之间建立了语义联系的多个模型，集成在一起通常被称为视图。56、 需求分析方法主要有：结构化方法、信息工程方法和面向对

23、象方法。其中面向对 象方法是目前工程和结构化方法的本质差别在于解决问题的策略不同。58、前期需求阶段分析的重点是理解问题世界，因此它关注的是整个问题世界，注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等等，软件系统只是整个背景下 的一个要素。59、后期需求阶段分析关注的是解系统解决方案的建立，因此它以软件系统为中心, 注重于分析系统的内部功能以及它与环境的互动，是对系统功能的详细信息的分析。60、 以软件复用为核心，建立产品族的方法被称为产品线。61、 需求协商活动既包括对目标冲突的处理，也包括对需求细节冲突的处理。62、 微规格说明被用来描述 DF过程分解结构中最底层过程的处理逻辑

24、。63、DFD中所有的外部实体联合起来构成了软件系统的外部上下文环境，它们与软件65、DFD勺0层图中的每个过程都可以进行分解，被分解的过程称为父过程，分解后 产生的揭示更多细节的 DFD图称为子图。66、 DFD勺0层图通常被用来作为整个系统的功能67、 为了保证DFE图的可理解性，0层图应该被描述的简洁、清晰，所以在描述复杂的 系统时，0 层图中不应出现太过具体的过程和数据存储。68、 DF冲对0层图的过程分解产生的子图称为1层图。69、 数据建模建立的模型称为数据模型，是问题域和解系统共享的知识集合，通常能 够反映企业业务的核心知识。70、数据模型的内容是问题域和解系统所共享的知识模型，

25、可以用问题域的语言来解 释，也可以用解系统的语言来解释，还可以用介于问题域和解系统之间的中立语言来解释。_ 、在需求工程中，数据建模建立的是概念数据模型和逻辑数据模型，不涉及物理数据模型2、ERD勺逻辑实体是对概念实体的细化，拥有完整的特征扌 -73、数据建模中对行为和事件的建模需要是为了了解它们在某些时刻的快照或者运行 环境信息，而不是它们所体现出来的功能和达成的效果，所以称这类实体为进程实体。74、ER冲属性就是可以对实体进行描述的特征，一系列属性的存在集成起来就可以 描述一个实体D中属性取值的受限制范围称为域（Domain）。76、ERD实体指定一个属性或多个属性的组合，可以用来唯一地确

26、定和标识每个实 例，这些属性或属性的组合称为实体的标识符，又称为键。78、 一个人们可多有候选键中这些键使被称定的选一。键来进行实例的标识，这个被 选中的候选键被称为主键，没有被选做主键的候选键被称为替代键。79、 实体实例大多数属性的值都是需要从现实中获取的，称为存储属性。80、 有些实体实例的属性的值是可以由其他属性的值计算得出的，称为导出属性。82、只有是个实体参与的关系存在于实体的不同实例之间，称为一元关系，又称为递 归关系。83、 ER冲关系的基数分为最大基数和最小基数。最小基数又被称为参与约 -84、 ER冲一个实体在关系中的最大基数是指，对关系中任意的其他实体实例，该实 体可能参

27、与关系的最大数量关系中的最小基数是指，对关系中任意的其他实体实例，该实体可能参与关系的最小数量。86、 ER冲被关系影响的实体主要是弱实体和关联实体。87、 用例模型的基本兀素有四种：用例、参与者、关系和系统边88、 UML亍为模型是用例模型的实现，以更加详细的方式说明用例所描述的系统行为。89、 UML亍为模型的活动图是依据处理流程进行的用例实现 -90、 UML亍为模型的交互图通常描述的是单个用例的典型场景。91、接口需求规格说明文档是对整个系统中需要软、硬件协同实现部分的详细描述。利性跟踪关性和级动化验析。可修改、可跟踪等特性。94、 评审又被称为同级评审，是指由作者之外的其他人来检查产

28、品问题的方法。95、在系统验证中，评审是主要的静态分析手段，所以评审也是需求评审的一种主要 方法。96、需求基线的维护主要包括配置管理和状态97、需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需 求以及跟踪需求变化的能力。98、 从需求向后回溯（前向跟踪的两种联系之一）说明软件需求来源于哪些涉众的需 要和目标。99、 后向跟踪是指需求被定义到软件需求规格说明文档之后的演化过程。100、 后向跟踪包括两种联系：从需求向前跟踪和回溯至 三、判断题1、需求工程包括需求获取和需求开发两个方面。（X）2、需求验证是需求工程中最后一个活动。（X）3、软件系统能够与问题域进行交互和相互

29、影响的原因在于，软件系统中的某些部分对问 题域中的某格说明是问题域为满足用户需求而提供的解决方案，规定了解系统的行为特征。（X）5、业务需求具有明显的目的性和较高的抽象性，经过明确和细化的处理，可以直接转化 为系统需求。（X）6、需求开发的一些特性决定了需求开发过程只能是一个简单的线性增量过程。（X）7、对于需求不确定性比较小的项目，用户参与可以取得比较好的效果，但对于需求不确 定性比较大的项!技术进行分反而原型可分阻碍作用原型和垂直原型。（9、严格意义上的原型主要被用在需求分析阶段。（V）10、 要完成相同的功能，构建抛弃式原型比构建演化式原型所花费的代价要大得多。（X）11、水平原型方法仅

30、仅实现选定功能实现的所有层次，能够处理较大范围的功能。（X）12、垂直原型方法会触及选定功能所有层次中的某些特定层次，处理的功能范围通常较 小。（X）13、建立外观原型时重在原型的用户界面和交互方式，原型的功能和技术实现细节就会 被简化处理。（V）14、如果选择的开发方法是实验式或者探索式开发方法，应该尽量花费最小的代价，争 取最快的速度，忽略或简化不重要的功能处理。（V）15、 原型修正主要依据评估人员的反馈，可以忽略事先的原型调整计划。（X）16、 文档审查是一种传统的需求获取方法，是专门针对文档进行的需求获取活动。（V）17、 由于文档是来自于当前计算机或手工系统的产物，因此它是正确的，

31、也正是客户所 需要的。（X）18、 成功的需求获取任务不仅要求成功地执行每一次具体的需求获取行为，还要求成功地处理多次获取行为之间的关系。（V）19、 软目标是一类无法清晰判断是否满足的目标，所以可以用AND和OR链接直接应 用于软目标。（X）20、 子目标的实现只能促进父目标的实现。（X）21、 AN和OR链接用于描述目标的分解和细化关系。（V）22、 目标的发现并是一个自上而下分解的过程，也就是一个不断发现和细化的过程。（X）23、 对系统的现状和背景进行分析往往能够发现重要的目标，得到一些明确的问题和缺陷，它们的反面就是系统需要实现的目标。（V）24、 场景被人们广泛接受的原因是因为人们

32、更倾向于会对真实事件和真实事物的描述产 生反应。（V）25、 描述场景时所使用的常见媒介形式主要有：叙述性的自由文本、结构化文本。强限 制文本、表格、图表、图像等。（V）26、 在实践中，以动态的场景外观为主。（X）27、 场景内包含的知识只能是关于未来的。（X）28、 描述性场景的目的是为了记录已经得到的需求，即整理每次需求获取行为中得到的 彳信息。（）口心29、UM就是以用例来捕获系统所有的系统需求的。（X）30、 用例的内容只能包含有正常流程，而不能包含有异常流程。（X）31、 用例可以用于各种目的的应用，包括描述、探索和解释。（V）32、 用例是在对现实世界的探索中或者是在对需求规格说

33、明的解释中产生的，是通过功 能分解的方式创例是不能被实例化的，它必须被包含在其他用例中才能得以执行。（V）34、 用例间的泛化关系是指子用例继承了父用例的特征。（X）并增加了新的特征35、 抽象一方面要求人们关注重要的信息，同时又不能忽略次要的内容。另一方面也要 求人们将认知保留在适当的层次，屏蔽更深层次的细节。（X）36、 由于计算模型的形式化特征不适合于需求工程阶段，因此计算模型不适合用于需求 分析中的建有形式化特征的计算模型是用户和开发者共同理解的模型。（X）38、由于模型需要描述的内容太过复杂的，因此分析模型对模型语言语用的要求不可能 太咼39（緞件需求分析的关键是为真实世界的问题建立

34、模型，即问题域建模。（V）40、 在“结构化方法一信息工程方法一面向对象方法”的发展历程中，每一种后来的方 法在吸收了前面方法的重要思想的同时也替代前面的方法。（X）41、 结构化、信息工程和面向对象三种方法学下的需求分析技术都适合于需求阶段全过 程的分析任务下文图是后期D的一个特定层次，被用来说明系统的上下文环境，确定系统的边 界。（V）43、 外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，但它们要 受系统的控制，开发者可以以任何方式操纵它们。（X）44、 上下文图以黑盒看待和描述系统的方式使它非常适合描述系统的应用环境、定义系统的边界，这正是 DFD在层次结构中将其置于最

35、高层的原因。（V）45、数据模型说明了问题域和解系统共享的事物、对共享事物的描述和共享事物之间 的关系6、僅）关系表达的不是逻辑上的链接（例如整体部分关系），而是实体物理上的联系。（X）47、 ER中存在于两个实体之间的关系是最常见的关系，称为二兀关系。（V）48、 ER呼子类型关系是实体间自然的业务联系，而不是人为施加的结构关系，是一 种特殊的实体间功能系。实体矩阵的过程可以帮助验证过程模型和数据模块的正确性，发现其中 的错误、遗漏、冗余和不一致。（V）50、 发起或触发用例的外部用户以及其他软件系统等角色被称为参与者。（V）51、 交互图是对单个用例的典型场景的实现，适合于事务性业务工作的

36、表示。（V）52、 UML亍为模型的状态图是以状态机模型的方式进行的用例实现。状态图只能用来 实现单个用例无法被用来描述程序的控制逻辑和工作流程。（V）54、OC的表达式定义可以在程序中得到直接的执行。（X）55、软件需求规格说明文档是对部分系统功能分配给软件部分的详细描述。（X）56、硬件需求规格说明文档是对整个系统功能当中分配给硬件部分的详细描述。（V）57、人机交互文档是对整个系统功能中需要进行人机交互部分的详细描述。（V）60、前向跟踪是指需求在被获取到软件需求规格说明文档之前的演化过程。（X）定义 四、名词解释题1、需求工程：需求工程是软件工程的一个分支，它关注于软件系统所应予实现的

37、现实 世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软 件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之 间的联系。2、需求：IEEE对需求的定义为： 用户为了解决问题或达到某些目标所需要的条件或能力。 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备 的条件或能或中的一个条件或一种能力的一种文档化表述。3、需求分析：需求分析是利用建模与分析技术对获取笔录的内容进行明确、整理、汇 总，建立一个综合考虑问题域特性和需求的系统模型，然后根据系统模型将用户需求转化为 系统需求的需求工程活动。4、前景（Visio

38、n ）:前景描述了产品的作用以及最终的功能，它将所有涉众都统一到一 个方向上。5、范围（scope）:范围指出当前项目是要解决产品长远规划中的哪一部分，范围声明 它为项目划定了需求的界线。6、 用户参与(User Involvement ):是以用户为中心的设计方法的核心思想，它要求开 发者建立和用户的直接联系，尽早地关注于用户和用户的任务执行过程，通过及时获得用户的反馈来调整软件设计，以完成高质量的设计。另一方面，用户参与就是反对通过和市场人 员、管理者等中间媒介来了解用户，因为这些间接的联系会减少或歪曲用户的信息。59、反复地执行验证。7、 硬数据：表格和文档资料是用户对实际业务进行加工和

39、抽象之后的结果，是一种精 化过的知识。这些文档资料被称为硬数据。硬数据分为定量硬数据和定性硬数据两种类型。8、 结构化面谈：结构化面谈指在面谈的过程中，会见者会完全按照事先的问题和结构 来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息，一些 统计性倾向信息的获取也可以使用结构化面谈。9、 半结构化面谈：半结构化面谈指在面谈的过程中，事先需要根据面谈内容准备面谈 的问题和面谈结构。但在面谈过程中，会见者可以根据实际情况采取一些灵活的策略。半结 构化面谈是在需求获取中应用最多的一种面谈类型，能够处理大部分的需求获取任务。10、非结构化面谈：在非结构化面谈的过程中，没有事先

40、预定的议程安排。在比较极 端的情况下，会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地，就 某个主题开展会谈。11、 头脑风暴(Brainstorming ):是一种特殊的群体面谈方式，它的目的不是发现需求， 而是“发明”需求，或者说是发现“潜在”需求。它鼓励参与者在无约束的环境下进行某些 问题的自由思考和自由讨论，以产生新的想法。它是需求获取中用于“发明”需求的方法，但它会增加需求的数量。12、原型：原型是一个系统，它内化了( Capture ) 一个更迟系统(Later System )的本 质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。”13、

41、严格意义上的原型：严格意义上的原型主要被用在需求分析阶段，是开发者在建 立系统信息模型的同时建立的原型，通常被用来阐明用户界面或者系统功能的某些特定方 面，帮助人们及时地澄清问题。14、 场景：场景是对系统和环境行为的局部描述，或者说场景是对行为或者事件序列 的描述，序列中的行为和事件是系统需要完成的一个任务的特殊示例。(也可以说，场景是用户为了达到某个目标而和软件系统发生的行为交互序列，是开 发者描述软件功能和需求的一种重要形式。)15、情境性：情景性是指某些事件只有和它们发生时的具体环境联系起来，才能得到 理解，它也是用户无法完成主动信息告知的主要原因。16、民族志：民族志是由人类学家最早

42、提出来的，用来理解原始社会(Primitive Societies )的社会机制。它要求人类学家花费长期的时间(通常是数年)在被研究的社会中生活并且仔细观察该社会中的实际活动，得到第一手的观察数据。对这些观察数据的分析可以揭示被研 究社会的社会结构、组织方法和具体活动。17、 模型驱动法：模型驱动法是一类以定义明确的模型为理论基础，依据模型指导和 组织活动开展的需求工程方法。18、 用例驱动法：用例是一种场景的文本化表现方式，使用叙述性的文本来描述场景。 以用例为核心，围绕用例开展活动的软件开发方法被称为用例驱动的软件开发方法。19、 企业建模：企业建模是以使用产品的组织团体为系统的环境，进行

43、分析。它主要 用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等。企业建模 利用企业的目标、任务、策略、资源等来刻画组织的行为，并依此来发现组织开发系统的目 的，建立系统的业务需求。20、 过程建模：过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程 的集合，其中一些由人来执行，另一些由软件系统来执行。过程建模使用的主要技术有上下 文图、数据流图、微规格说明和数据字典等。21、 上下文图：上下文图是 DFD最高层次的图，是系统功能的最高抽象，它将整个系统看做是一个过程，这个过程实现系统的所有功能。上下文图中存在且仅存在一个过程，表 示整个系统。这个单一的过程通常编

44、号为0。22、 概念数据模型：概念数据模型是以问题域的语言解释数据模型，反映了用户对共 享事物的描述和看法，由一系列应用领域的概念组成。23、 物理数据模型：物理数据模型是对数据模型的解系统语言的解释，它描述的是共 享事物在解系统中的实现形式，是形式化的定义。24、 逻辑数据模型：逻辑数据模型是为了缓解开发人员将概念数据模型转换成物理数 据模型的困难，而使用一种介于问题域和解系统之间的中立语言来进行的数据模型的描述。 这种中立的语言使用更加倾向于用户的概念和词汇，同时使用更加倾向于解系统语言的表达 方式。25、 关系的基数：关系的基数是衡量关系复杂性的指标之一，又被称为关系的约束。 一个实体在

45、关系中的基数定义了在关系中其他实体实例确定的情况下，该实体实例可能参与 关系的数量。26、 交互图（UM行为模型）：交互图用于描述在特定上下文环境中一组对象的交互行 为，该上下文环境就是被实现用例的某个场景。所以，交互图通常描述的是单个用例的典型 场景。交互图中的每一个交互都描述了环境中的对象为了实现某个目标而执行的一系列消息 交换。27、 OCL（语言）：OCL（Object Constraint Language）称为对象约束语言。OC不是编程语言而是一种建模语言，它在保证一定表达能力的前提下，注重于语言的简洁性和抽象性。但它无法被用来描述程序的控制逻辑和工作流程，而且它的表达式定义也无法

46、在程序中得到 直接的执行。28、基线：基线是已经通过正式评审和批准的规格说明或产品，可以作为进一步开发的 基础，并且只有通过正式的变更控制过程才能修改它。29、 需求基线：需求基线(Requirements Baseline)就是被明确和固定的需求集合，是 项目团队需要在某一特定产品版本中实现的特征和需求集合。30、需求跟踪：需求跟踪是一种有效的控制手段，能够在涉众的需求变化中协调系统的 演化，保持各项开发工作对需求的一致性。需求跟踪是以软件需求规格说明文档为基线，在 向前和向后两个方向上，描述需求以及跟踪需求变化的能力，分为前向跟踪(PreTraceabmty )和后向跟踪(Post Tra

47、ceability )两种。五、问答题1、简述需求工程的主要任务。答：需求工程有以下三个主要任务： 需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软 件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施 加的限制和约束，也即要同时说明软件需要“做什么”和“为什么”需要做。 需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并 对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、 设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、

48、功能和约束随着 时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、 功能和约简述常件产品族定义错化和分布情况进行综合考虑与处理。答：(划线部分为必答要点)在实践和研究过程中，人们发现关于需求定义的具体的错误主要有以下几种：需求并没有反映用户的真实需要。实践表明，获取用户的真实需求是非常困难的。原因之一是用户在表达自己的需要时，可能会在潜意识下进行一定的加工。为了发现 用户的真实需求，需求工程师一定要进行问题分析，尽力发现问题背后的问题。原因之二是在人际交流中，信息会发生自然的衰减，甚至扭曲，导致需求丁程师理解 的并非是用户所表达的。解决方法是在需求传递给开发人员

49、之前，请提出需求的用户进行仔 细模检和歧义认需求。在实践中，人们总是会有意和无意地写出模糊和歧义的需求定义。无意中写出模糊和歧义的需求定义往往是因为选词造句不当，导致不同的人对同一项 需求产生了不同的理解。解决方法是为项目中重要的词汇建立一个公共的可共同理解的词汇 表，然后意产生的模的基础之上的需求定义往往是为了应付对需求持有不同立场的用户，这些 用户关于需求的目标互相冲突，需求工程师于是采用了模糊化的处理方法。正确解决方法是 在项目前景的指导下，促进用户之间的协商解决。信息遗漏。信息遗漏也是-类常见的问题，包括明显的信息遗漏和不明显的信息遗漏。-明显的信息遗漏，其主要原因在于项目的范围定义不

50、当，可以通过加强对业务需求的 处理得以解决。不明显的信息遗漏，是因为相关信息难以发现，只能靠需求工程师的经验来加以避免。不必要的需求。产生不必要需求的原因主要是：其一是用户将一些不必要的需求作为和开发人员谈判的筹码，然后通过自己对不必要 需求的要求而在和开发人员的谈判当中取得真正想要的利益，例如金钱。对此问题，唯一需 要的就是是用户员代表中炎总是害怕信息有所遗漏，并因此产生不利后果，因此用户总是倾 向于表达各种各样的需要。要解决这个问题，就需要开发人员在进行用户需求的获取之前， 先定义明确的业务需求，然后根据业务需求进行用户需求的过滤和选择。其三是需求开发人员“画蛇添足”，添加“用户肯定会喜欢

51、”的功能，该类功能既会造 成项目额外的耗费，又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用户为 中心不切实际的期望。心。不切实际的期望也是实践中常见的需求定义问题，而且它在很大程度上影响着项目的 成败。面对不切实际的期望，要求软件开发者提供可行性、成本等足够的技术参考信息，帮 助用户对其进行取舍和调整。3、简要说明需求获取活动的过程。答：（1）收集和应用背景资料，建立初始的知识框架。分析涉众的高层次问题，总结出系 统的业务需求。（2）设计一个高层次的解决方案，并确定解决方案需要具备的系统特性。高层次的解 决方案和系统特性定义了项目的前景和范围。（3）在项目的业务范围内，需求工程要寻

52、找相关的涉众，并分析和涉众选择。（4）对组织里存在大量的表格、单据等与业务相关的硬数据进行采样，它们是需求获 取活动中5）个重要的信息来源需求获取活动，要依据项目范围确定主题和内容，涉众特征和 硬数据，从而确定信息来源。获取方法通常只有综合内容、来源和系统环境三者才能做出正 确的决定内容、来源和方法都确定之后，需求工程师就可以开展具体的获取活动，获取用户 需求和问题域特性。获取得到的具体信息要记录下来，以获取笔录的形式进行保存。4、简述涉众识别的基本过程。答：涉众识别的基本过程如下： 将初始涉众集中起来，进行一次头脑风暴，尽可能地列出一个涉众类别列表。对上一步产生的涉众类别列表进行分析，判断它

53、们和软件系统的相关性，找出其中的 键涉众类为上一步的各个关键涉众类别选择代表，集中起来进行进一步的头脑风暴，列出新的 涉众类别列表。如果新列出的涉众类别列表趋于稳定，就可以结束涉众识别过程。如果新列 出的涉众类别列表有了新的发现，就提交新的涉众类别列表，转向第步。5、试比较面谈问题组织的三种结构。答：（1）金字塔结构面谈问题的归纳式组织被看做是金字塔形状。使用这种形式时，会见者以很具体的问题 （通常是封闭式的问题）开始，然后逐渐提高问题的开放度，同时允许被会见者用越来越笼 统的答主回情况题。如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构, 通过逐步的引导使被会见者进入讨论。在被动

54、的情况下，如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看 上去不情愿讨论某个话题，也可以采用金字塔结构。在某个话题讨论结束的时候，使用金字塔结构的提问顺序也是有用的。在这种结斗结构会见者使用演绎的方法，以一般的、开放式的问题开始，然后用封闭式 的问题缩小可能的答复。这种面谈结构可看做是漏斗型。在主动的情况下，漏斗结构为开始一场面谈提供了一种容易而轻松的途径。答复者即使 答错在被动的情况下也不会感到压对话题有情绪，并且需要自由表达这些情绪的时候，需要 采用漏斗型提问顺序。或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组 织方式用漏斗结构的一个好处是：用这种方式组织面谈能

55、得出很多的详细信息，以至于没有 必要使用长序列的封闭式问题。（3）菱形结构人们在面谈中常常会将上述两种结构结合起来使用，其中菱形结构就是一种最好的结合 结果。这种结构以一种非常明确的方式开始，然后考察一般问题，最后得出一个非常明确的 结士彳论结论。会见者首先提出一些简单的、封闭式的问题，为面谈过程做好铺垫。在面谈的中间阶段, 向被会见者提出明显没有“正确答案”的一般话题的看法。然后，会见者再次限制问题以获 得明确的答复，这样就为会见者和被会见者提供了面谈的结束时机。菱形结构结合了其他两种结构的长处，但是也有缺点，即所花的时间比其他任何一个都 长。6、简述软件开发中为何使用原型工具以及使用的好处

56、。答：因为原型是在最终系统产生之前的一个局部真实表现，所以原型方法可以让人们在系统 的开发过程中，就能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软 件开发过程中存在的各种不确定性。不确定性是指人们已经拥有的知识是不充分的，不足以 预测将来的事件发展，或者不足以清晰、准确地描述某个事物。 践证明，力用响型有如下好处变化。 减少返工。 帮助控制不完整需求所带来的风险。 可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤。 减少开发成本，提高经济效益。 增加开发者之间的交流，帮助确定技术解决方案的可行性。 有效地识别风险和解决风险，帮助进行风险管理。 提高用户在软件开发

57、中的参与程度。7、试说明在哪些情景下原型法可以帮助需求工程师及早解决需求的不确定性。答： 产品以前从未存在过，而且难以可视化。这些产品属于创新性产品，它们的基本需求 是潜在的，有着很大的不确定性。 产品的用户对相关类别的产品没有经验，而且对将要采用的技术也没有经验。此时用 户无法明确工作的具体细节，产品的细节需求存在着不确定性。 用户进行自己的工作已经有一段时间了，但在完成工作的方式上仍然存在障碍。此时 用户无法判断问题的解决方案是否现实可行，所以产品在整体方案的可行性上存在着不确定 性。用户在清晰说明他们的需求方面存在困难，例如默认需求或者潜在需求。这些相关的 需求是有着不确定性的需求。 需

58、求工程师在理解用户的需求上存在困难。在澄清和理解之前，这些需求存在着不确 定性。 需求的可行性值得怀疑，即具体需求的可满足性存在着不确定性。8、试比较原型开发方法的三种类型。答：（划线部分为必答要点）（1）探索式探索式原型法是以缺陷需求开始继而不断调整和修正需求的原型开发方式。探索式的 原型方法通常要尽可能地调整各种设计选项（例如需求内容、软件化内容以及软件支持方式 等），并比较多种设计方案下的用户反馈以得到理想的用户需求。探索式的原型方法能够帮 助开发者更深入地了解用户的业务、问题和期望。实验式的原型方法初始时拥有清晰的用户需求，但是开发者对，这些需求的实现方法、 实现效果和可行性没有太大的

59、把握。实验式的原型方法需要首先定义一个对原型的评估方 法，确定评估的属性（例如可行性、适用性、效率、吞吐量等），据此评估各种技术方案下 的原型，演需求的可行性和有效的技术实现方案。在演化式的原型方法中，原型的开发并不是 个独立的活动，而是整个项目的持续开 发过程中的一个部分。原型开发的初始点既有要求原型化的需求，也有项目积累下来的原型 资产。积累下的原型资产所没有实现的需求，往往是清晰的需求。在开发原型时，还要能够 以一个整体的方式传递给下一个原型开发过程。这个被不断传递和不断增强的原型资产将成 为最终的软件系统。通过在持续开发过程中使用原型方法，可以使软件开发过程更好地处理 用户了很多次错误

60、的尝试之后才产生的。这些错误的尝试过程会在最终的原型产品中留下痕迹， 原型中的一些代码是在错误的前提（错误的需求、错误的技术方案）下完成的，它们会使原 型产品具有很差的质量，所以人们在得到正确的尝试之后往往会抛弃这些原型产品，另起炉灶。为此，- Throwaway Prototype )。抛弃式原型的贡献不在于它的代码，而是它所包含的内容，它说明了正确的需求和正确的-的代价，争取最快的速度。为此，原型的开发者会使用一些简易的开发工具和不成熟的构造 技术，忽略或简化一些和原型目标不相关的功能特征。9、试述在需求获取中使用原型方法的主要步骤。答：在需求获取中使用原型方法的主要步骤包括： 确定原型需