软件需求分析笔试题库

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

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

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

4、析：即（）。（A）外观、角色和实现（B）开发、实现和作用（C）成本、技术和实现（D）需求、作用和角色12、 当用户无法完成主动的信息告知, 或与需求工程师之间的语言交流无法产生有效的结果时 , 有必要采用（）。（ A ）民族志（B）观察法（C）话语分析（ D ）任务分析13、以下（）不是情景性的重要性质？( A )突现（B）涉身（C）完善( D)模糊14、以下（）是情景性的重要性质？( A )全局（B）开放（C）交互( D)即时15、下列（ ）不是需求获取常见的模型驱动方法？（A）面向目标的方法（B）基于场景的方法。（C）基于用例的方法（D）基于采样的方法16、下列（ ）属于定量硬数据？（A

5、）工作手册（B ）规章手册17、下列（ ）属于定性硬数据？（A）数据收集表（B）月报表18、功能目标可以分为 （） 。（A ）安全目标和可用性目标（C）软目标和硬目标（C）统计报表（D）备忘录（C）年报表（D ）规章手册（B）满足型目标和信息型目标（D）维护目标和实现目标19、在表达软目标的分解和细化时使用的AND Contribution 链接和 OR Contribution 链接, Contribution 的作用是（）。（A）积极的 （B）消极的（C）积极的或消极的（D ）不能确定20、AND链接将一个父目标连接到一系列细化的子目标 化的子目标 ,那么将（ ）父目标。（A ）无法确定

6、（B）阻碍（C）不能满足21、OR链接是将一个父目标连接到一系列细化的子目标 化子目标中的（ ） ,那么将足以满足父目标。, 意思是如果能够满足所有细（D）足以满足,意思是如果能够满足所有细（A）每一个（B ）任何一个（C）特定的（D）某一个22、下列选项中 ,（ ）不是在目标模型中使用的其他模型元素。（A）行为者（B）场景（C）操作 （D）概念23、 面向目标方法的目标分析阶段的主要任务是（）。（A）获取目标（B）确定解决方案（C）建立目标模型（D）发现问题和缺陷24、场景的分类框架将场景方法从场景的（A）形式、目的、内容和生命周期（C）描述、目的、内容和形式） 4个方面进行了分类和描述。B

7、 ）外观、目的、内容和生命周期（D）描述、外观、目的和内容25、 场景的形式是指场景的表达模式, 从形式上分为两个方面：（）（A）内容和目的（B）内容和生命周期 （C）描述和外观 （D）描述和目的26、 描述场景所使用的表示法要符合正规性要求, 一般可使用非形式化语言、半形式 化语言和形式化语言。在实践中 , （ ）是主要的描述方式。（A）形式化的程序语言（B）非形式化的自然语言（C）形式化的图形工具（D）非形式化的设计语言27、 外观是指场景被表达出来时的效果, 主要有（ ）三种类型。（A）静态、动态和结构化 （B）线性、非线性和交互（C）静态、动态和动静结合（D）静态、动态和交互28、 场

8、景的内容是指场景所表达的知识类型。它被分为6个不同的方面。下列（）不是场景的内容。（A）主要关注点（B ）环境范围（C）目的 （D ）抽象层次29、 需求工程利用场景的目的可能有三种：即：（）。（A）描述、探索和解释（B）描述、表示和探索（C）描述、探索和发现（D）表示、解释和证明30、 使用解释性场景在需求分析时能够（） , 或者被用于进行需求的验证。（A）提高模型的复杂性（B）降低模型的复杂性（C）提高预见性（D）降低编程量31、下列（）不是场景方法在需求工程中的应用。（ A ）帮助进行详细的需求分析（B）编写系统需求规格说明（C）结合面向目标的方法，指导需求获取活动的开展（D）组织需求获

9、取得到的信息32、下列（ A ）合取关系33、与其他的场景方法相比（ A ）静态非结构化文本（C）静态结构化文本34、用例之间的关系主要有（ （ A ）包含、扩展和简化 （C）包含、多态和继承35、分析的活动主要包括识别、 事物的信息 , 这种分析活动被称为（ A ）需求信息获取（C）需求信息转化）是组织场景时可用的场景关系。（B ）定性关系 （C）定量关系（D）演绎关系, 用例最大的特点是采用了（）的描述方式。（ B ）动态非结构化文本（D）动态结构化文本 ）三种。（ B ）合取、（D）包含、 定义和结构化）。析取和扩展扩展和泛化, 它的目的是获取某个可以转换为知识的B ）建立软件系统解决方

10、案D ）建立需求分析模型36、 （）是建模最为常用的两种手段。（A）具体和抽象（B）抽象和分解（C）分解和细化（D）抽象和细化37、抽象通过强调本质的特征 , （ ）了问题的复杂性。（A）调整 （B）避免 （C）增加（D）减少38、 需求分析仅仅需要描述解决方案, 不需要探索实现细节的情况下 , 分析模型又是 ）的 , 尤为适用。（A）形式化（B）半形式化（C）结构化（D ）非结构化39、上下文图描述系统与环境中外部实体之间的界限和联系。它从现实世界的角度说明了系统的（ ） ,并确定了所有的输入和输出。（A）环境与外观（B）边界和联系40、（ ）是结构化分析方法的核心技术 及它们如何在一起协调

11、工作。（A ）数据流图 DFD（ B）实体联系图（C）边界和环境 （D）输入和输出, 它表明系统的输入、处理、存储和输出 , 以ERD（ C）状态转换图（D）上下文图41、结构化、信息工程和面向对象三种方法学下的需求分析技术都是（）的。）需求阶段的分析。）需求阶段的分析。（A）面向问题域（B）面向解系统（C）面向设计（D ）面向需求42、使用面向问题的技术对问题世界的建模就被称为（A）前期 （B）中期（C）后期（D）全过程43、使用面向解系统的技术对软件系统解决方案的描述称为（A）前期 （B）中期（C）后期（D）全过程44、 需求分析活动的一个重要任务是进行（） ,明确用户需求的隐含信息 ,展

12、开为 明确的对软件系统的行为期望 ,即系统需求。（A）需求整理（B）需求细化 （C）需求获取（D）需求分析45、 在分层结构中，DFD定义了三个层次类别的DFD图：（）、0层图和 N层图。（A） 1层图 （B）底层图 （C）上下文图 （D）顶视图46、因为数据存储是系统内部的功能实现， 所以在将系统视为黑盒的情况下 ， 上下文图中不会出现（ ）。（A）实体（B）数据存储实例（C）需求信息（D ）过程处理47、 数据建模技术能够弥补过程建模在（）方面的缺陷 , 它描述数据的定义、结 构和关系等特性。（A）需求分析（B）数据转换 （C）数据说明（D）数据分析48、。概念实体是一种抽象概念 ,不考虑

13、概念背后的物理存在 , 所以通常不包含与之相 关联的其他（ ）。（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）键约束 （

14、B）参与约束（C）自然约束（D ）一般约束53、在实体之间建立关系时 , 可能会产生一些附带的实体 , 被称为关联实体 , 最常见 的形式是（ ）。（A）逻辑实体（B）进程实体 （C）概念实体（D）自然实体54、在实现 ERD与过程模型同步的技术中，（）是一种较为常见的技术。（A）用例图（B）数据流图（C）功能/实体矩阵（D）微规格说明55、 下列（）不是用例模型中的关系？（A）属性（B）关联（C）泛化 （D）包含56、系统边界是指一个系统所包含的系统成分与系统外事物的分界线。用例模型使用一个（ ）来表示系统边界 , 以显示系统的上下文环境。（A）圆形框（B）菱形框（C）虚线框 （D）矩形框5

15、7、UML 使用的行为模型有三种（A）交互图、状态图和顺序图（C）交互图、状态图和活动图, 即：（）。（B）顺序图、通信图和时间图（D）交互概述图、通信图和时间图） , 重点都是用户的现（D ）用户文档58、项目的前景和范围文档、用户需求文档都被视为属于（ 实世界。（A ）开发文档（B ）需求文档 （C）前景文档59、系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口, 都被认为是开发文档。需求规格说明文档和人机交互文档一起被用于系统开发的目的（A）开发文档（B）需求文档（C）过程文档（D）用户文档60、下列（）不是需求规格说明文档的读者？（A）项目管理者（B ）编程人员（

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

17、由软件满足的部分, 将其映射为软件行为 ,产生软件需求规格说明。7、约束是不受解系统影响 , 却会给解系统带来极大影响的问题域特性。8、优秀的需求应该具备 7个特性 , 即完整性、正确性、精确性、可行性、必要性、无 歧义和可验证。9、所有对软件系统的开发和应用具有发言权和决定权的人统称为涉众。10、按照媒介载体进行分类 , 原型可分为：样板原型和纸上向导原型。11、演示原型主要被用在项目启动阶段。12、演示原型都是被用来展示用户想象中的系统视图 , 所以它要能够表现用户界面的重 要特征。13、,如果一个问题的技术解决方案是不清晰的 , 演示原型也可以被用来展现相应的细 节功能以使用户确信该问题

18、解决的可能性。14、通常来说 , 如果用户需求出现了模糊、不清晰、不完整等具有一定不确定性的特征 就可以考虑使用原型方法。15、角色是指原型物件在用户工作中的价值 , 也就是说它为什么对用户是有用的。16、外观是指用户对原型物件的具体感觉体验 , 即用户在使用原型物件时会看到什么、 听到什么和感觉到什么。17、实现是指原型物件完成功能的细节技术和方法。18、使用演化式原型方法 , 在开发时就需要注意原型的健壮性和代码的质量。19、使用实验式开发方法 , 需要实现多种技术方案 , 考察重要的系统的质量属性。20、选择使用探索式开发方法 , 需要尽可能地考虑各种不同的设计选项 ,比较不同选项 下的

19、用户反馈。21、原型方法的最大优点是能够及早地解决系统开发中的不确定性 , 从而降低软件项目 失败的风险。22、航空调度、证券交易、医疗手术控制等复杂的协同问题都具有突现的情景性。23、民族志的一个主要应用目的就是研究和解决复杂的协同问题。24、复杂的工作总会同时存在着正常流程和异常流程 , 异常流程大多是一些特殊情况下 的处理 ,限定了异常处理的上下文环境 , 即异常处理具有局部的情景性。25、有很多重要工作的进行需要用户具备一定的认知 , 认知要求已经成了用户工作必备 的部分 , 即工作具有涉身的情景性。26、采样观察是最简单的观察方法 ,应用目的是发现异常流程 , 验证用户所述知识和实

20、际的一致性 , 以及发现默认知识。27、时间采样允许需求工程师建立指定的时间间隔来观察用户的活动情况。28、文档审查主要获取对象包括相关产品的需求规格说明、硬数据和客户的需求文档。29、文档分析通常是数据建模方法的一个基础部分 , 它是通过检查采集的硬数据来确定 潜在的需求。30、如果当前存在一份客户的需求文档 , 就可以使用需求剥离技术 , 从需求文档中抽取 单个的需求并加入到新的需求文档之中。31、需求工程师可以使用模型驱动方法来进行信息的整理和归类 , 其中模型驱动方法所 建立的模型是进行信息整理和归类的很好的框架依据。32、模型驱动方法的模型是在前期需求阶段的分析中建立的。33、目标模

21、型的一个核心要素是元素之间的关系 , 称为链接。34、目标模型的链接有两类：一类是目标之间的链接；另一类是目标与其他模型元素之 间的链接。35、面向目标方法的处理过程可以分为三个阶段：目标获取、目标分析（即目标模型的 建立）和目标实现。36、目标实现阶段的主要任务是收集与目标相关的需求信息 , 讨论可能的候选解决方案 确定最终的系统详细需求和解决方案。37、场景具有重点描述真实世界的特征 , 它利用情景、行为者之间的交互、事件随时间 的演化等方式来叙述性地描述系统的使用。38、静态外观的场景被展现为一个或者数个描述性的文本或者图片。39、动态外观的场景会被以动态的方式展现出来 , 人们可能会要

22、求按时序向前或者向后 浏览场景 , 也可能会要求跳转到场景的某一个时刻进行观察。40、交互外观的场景提供交互性 , 它允许用户在一定程度上控制和改变场景的变化时序 或者效果。41、具体场景 ,又称为实例场景 , 是对个别行为者、事件、情节的细节描述。42、抽象场景 ,又称为类型场景 , 是以经验中的类别和抽象概念来描述事实。43、探索性场景可以用来进行需求获取和需求建模与分析。44、每个用例是对相关场景集合的叙述性的文本描述 , 这些场景是用户和系统之间的交 互行为序列 , 帮助实现用户的目的。45、用例是场景方法中的一种 , 是静态的结构化文本描述。46、在高层的功能需求获取完备之前 , 用

23、例的产生方式中不允许使用功能分解方式。47、单个用例描述了系统的功能片段 , 系统的所有用例基于一定的关系组织起来, 建立用例模型 , 就可以描述整个系统的功能。48、原有用例和新建立的抽象用例的关系即为包含关系。49、在需求工程中 , 主要产生三类重要的文档：项目前景和范围文档、用户需求文档以 及需求规格说明。用例文档通常被用来代替用户需求文档 , 起到记录、交流领域信息和用户 期望的作用。50、需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差 距。需求分析就是用来解决这个差距的需求工程活动。51、需求分析的根本任务是：建立分析模型并创建解决方案。52、分解将单个复杂和

24、难以理解的问题分解成多个相对更容易的子问题, 并掌握各子问题之间的联系。53、基于软件构建单位及其之间的关系建立的模型, 用来说明软件逻辑上的构建方式和实现方式 , 由于它使用的组元及其关系都是软件的元素, 因此它是来自于软件的模型 , 称为计算模型。54、模型语言的三要素：语法、语义、语用。其中语用给出了一个模型元素描述的更 宽广的上下文 , 以及影响该模型元素意义的约束和假定。55、互相之间建立了语义联系的多个模型, 集成在一起通常被称为视图。56、需求分析方法主要有：结构化方法、信息工程方法和面向对象方法。其中面向对 象方法是目前工业界使用的主流方法。57、信息工程和结构化方法的本质差别

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

26、部上下文环境，它们与软件系统的交互流就是软件系统与其外部环境的接口，这些接口联合起来定义了软件系统的系统边界。64、数据流是指数据的运动，它是系统与其环境之间或者系统内两个过程之间的通信 形式。65、 DFD的 0层图中的每个过程都可以进行分解，被分解的过程称为父过程，分解后 产生的揭示更多细节的 DFD图称为子图。66、DFD的0层图通常被用来作为整个系统的功能概图。67、为了保证DFD图的可理解性，0层图应该被描述的简洁、清晰 ，所以在描述复杂的 系统时，0层图中不应出现太过具体的过程和数据存储。68、 DFD中对0层图的过程分解产生的子图称为1层图。69、 数据建模建立的模型称为数据模型

27、，是问题域和解系统共享的知识集合，通常能够反映企业业务的核心知识。70、 数据模型的内容是问题域和解系统所共享的知识模型，可以用问题域的语言来解 释，也可以用解系统的语言来解释 ，还可以用介于问题域和解系统之间的中立语言来解释。71、 在需求工程中，数据建模建立的是概念数据模型和逻辑数据模型，不涉及物理数 据模型。72、 ERD的逻辑实体是对概念实体的细化，拥有完整的特征描述。73、数据建模中对行为和事件的建模需要是为了了解它们在某些时刻的快照或者运行环境信息，而不是它们所体现出来的功能和达成的效果，所以称这类实体为进程实体。74、 ERD中属性就是可以对实体进行描述的特征，一系列属性的存在集

28、成起来就可以 描述一个实体的实例。75、 ERD中属性取值的受限制范围称为域（Domain）。76、 ERD为实体指定一个属性或多个属性的组合，可以用来唯一地确定和标识每个实例，这些属性或属性的组合称为实体的标识符，又称为键。77、一个实体可能有多个键，这些键都被称为候选键。78、 通常人们从多个候选键中选择和使用固定的某一个键来进行实例的标识，这个被 选中的候选键被称为主键，没有被选做主键的候选键被称为替代键。79、 实体实例大多数属性的值都是需要从现实中获取的，称为存储属性。80、 有些实体实例的属性的值是可以由其他属性的值计算得出的，称为导出属性。81、关系是存在于一个或多个实体之间的自

29、然业务联系。82、 只有一个实体参与的关系存在于实体的不同实例之间，称为一元关系，又称为递 归关系。83、ERD中关系的基数分为最大基数和最小基数。最小基数又被称为参与约束。84、 ERD中一个实体在关系中的最大基数是指，对关系中任意的其他实体实例，该实体可能参与关系的最大数量。85、 ERD中一个实体在关系中的最小基数是指，对关系中任意的其他实体实例，该实 体可能参与关系的最小数量。86、ERD中被关系影响的实体主要是弱实体和关联实体。87、用例模型的基本元素有四种：用例、参与者、关系和系统边界。88、UML 行为模型是用例模型的实现 , 以更加详细的方式说明用例所描述的系统行为。89、UM

30、L 行为模型的活动图是依据处理流程进行的用例实现。90、UML 行为模型的交互图通常描述的是单个用例的典型场景。91、接口需求规格说明文档是对整个系统中需要软、硬件协同实现部分的详细描述。92、优秀的需求规格说明文档应该具备：正确性、无歧义、完备性、一致性、根据重 要性和稳定性分级、可验证、可修改、可跟踪等特性。93、需求验证常见方法有：需求评审、原型与模拟、测试用例开发、用户手册编制、 利用跟踪关系和自动化分析。94、评审又被称为同级评审 , 是指由作者之外的其他人来检查产品问题的方法。95、在系统验证中 ,评审是主要的静态分析手段 , 所以评审也是需求评审的一种主要 方法。96、需求基线的

31、维护主要包括配置管理和状态维护。97、 需求跟踪是以软件需求规格说明文档为基线, 在向前和向后两个方向上 , 描述需 求以及跟踪需求变化的能力。98、从需求向后回溯（前向跟踪的两种联系之一）说明软件需求来源于哪些涉众的需 要和目标。99、后向跟踪是指需求被定义到软件需求规格说明文档之后的演化过程。100、后向跟踪包括两种联系：从需求向前跟踪和回溯到需求的跟踪。三、判断题1、需求工程包括需求获取和需求开发两个方面。（X）2、需求验证是需求工程中最后一个活动。（X）3、 软件系统能够与问题域进行交互和相互影响的原因在于, 软件系统中的某些部分对问 题域中的某些部分具有模拟特性。（V）4、 规格说明

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

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

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

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

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

37、分析模型对模型语言语用的要求不可能 太高。（X）39、 软件需求分析的关键是为真实世界的问题建立模型，即问题域建模。（V）40、 在“结构化方法一信息工程方法一面向对象方法”的发展历程中， 每一种后来的方 法在吸收了前面方法的重要思想的同时也替代前面的方法。（X）41 、结构化、信息工程和面向对象三种方法学下的需求分析技术都适合于需求阶段全过 程的分析任务。（X）后期42、上下文图是 DFD 的一个特定层次 ， 被用来说明系统的上下文环境 ， 确定系统的边 界。（V）43、 外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统， 但它们要 受系统的控制，开发者可以以任何方式操纵它们。

38、（X）44、上下文图以黑盒看待和描述系统的方式使它非常适合描述系统的应用环境、定义系统的边界，这正是 DFD在层次结构中将其置于最高层的原因。（V）45、数据模型说明了问题域和解系统共享的事物、对共享事物的描述和共享事物之间 的关系。（V）46、 ERD关系表达的不是逻辑上的链接（例如整体部分关系）,而是实体物理上的联系。 （X）47、 ERD中存在于两个实体之间的关系是最常见的关系,称为二兀关系。（V）48、 ERD中子类型关系是实体间自然的业务联系，而不是人为施加的结构关系，是一 种特殊的实体间关系。（X）49、 建立功能实体矩阵的过程可以帮助验证过程模型和数据模块的正确性, 发现其中 的

39、错误、遗漏、冗余和不一致。（V）50、发起或触发用例的外部用户以及其他软件系统等角色被称为参与者。（V）51、 交互图是对单个用例的典型场景的实现，适合于事务性业务工作的表示。（V）52、UML 行为模型的状态图是以状态机模型的方式进行的用例实现。状态图只能用来 实现单个用例。 （X）53、OCL无法被用来描述程序的控制逻辑和工作流程。（V）54、OCL的表达式定义可以在程序中得到直接的执行。（X）55、软件需求规格说明文档是对部分系统功能分配给软件部分的详细描述。 （X）56、硬件需求规格说明文档是对整个系统功能当中分配给硬件部分的详细描述。（V）57、人机交互文档是对整个系统功能中需要进行

40、人机交互部分的详细描述。 （V）58、验证活动同样普遍存在于需求分析过程中。（X）59、 需求验证并不是一个可以一次结束的活动，它可能需要多次、反复地执行验证。（V）60、前向跟踪是指需求在被获取到软件需求规格说明文档之前的演化过程。（X）定义四、名词解释题1、需求工程：需求工程是软件工程的一个分支， 它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束 ，同时它也关注以上因素和准确的软 件行为规格说明之间的联系 ， 关注以上因素与其随时间或跨产品族而演化之后的相关因素之 间的联系。2、需求：IEEE对需求的定义为： 用户为了解决问题或达到某些目标所需要的条件或能力

41、。 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备 的条件或能力。 对或中的一个条件或一种能力的一种文档化表述。3、需求分析：需求分析是利用建模与分析技术对获取笔录的内容进行明确、整理、汇总， 建立一个综合考虑问题域特性和需求的系统模型 ， 然后根据系统模型将用户需求转化为 系统需求的需求工程活动。4、 前景（Vision ）:前景描述了产品的作用以及最终的功能，它将所有涉众都统一到一 个方向上。5、 范围（scope）:范围指出当前项目是要解决产品长远规划中的哪一部分，范围声明 它为项目划定了需求的界线。6、用户参与( User Involvement )：是以用

42、户为中心的设计方法的核心思想 , 它要求开 发者建立和用户的直接联系 , 尽早地关注于用户和用户的任务执行过程 , 通过及时获得用户 的反馈来调整软件设计 , 以完成高质量的设计。另一方面 , 用户参与就是反对通过和市场人 员、管理者等中间媒介来了解用户 , 因为这些间接的联系会减少或歪曲用户的信息。7、硬数据：表格和文档资料是用户对实际业务进行加工和抽象之后的结果, 是一种精化过的知识。这些文档资料被称为硬数据。硬数据分为定量硬数据和定性硬数据两种类型。8、结构化面谈：结构化面谈指在面谈的过程中, 会见者会完全按照事先的问题和结构来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比

43、较有限的信息 , 一些 统计性倾向信息的获取也可以使用结构化面谈。9、半结构化面谈：半结构化面谈指在面谈的过程中, 事先需要根据面谈内容准备面谈的问题和面谈结构。但在面谈过程中 , 会见者可以根据实际情况采取一些灵活的策略。半结 构化面谈是在需求获取中应用最多的一种面谈类型, 能够处理大部分的需求获取任务。10、非结构化面谈：在非结构化面谈的过程中, 没有事先预定的议程安排。在比较极端的情况下 , 会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地 , 就 某个主题开展会谈。11、头脑风暴( Brainstorming )：是一种特殊的群体面谈方式 , 它的目的不是发现需求 而是

44、“发明”需求 , 或者说是发现“潜在”需求。它鼓励参与者在无约束的环境下进行某些 问题的自由思考和自由讨论 , 以产生新的想法。它是需求获取中用于“发明”需求的方法 , 但它会增加需求的数量。12、原型：原型是一个系统,它内化了( Capture) 一个更迟系统(Later System)的本 质特征。原型系统通常被构造为不完整的系统 , 以在将来进行改进、补充或者替代。”13、严格意义上的原型：严格意义上的原型主要被用在需求分析阶段, 是开发者在建立系统信息模型的同时建立的原型 , 通常被用来阐明用户界面或者系统功能的某些特定方 面, 帮助人们及时地澄清问题。1 4 、场景：场景是对系统和环

45、境行为的局部描述, 或者说场景是对行为或者事件序列的描述 , 序列中的行为和事件是系统需要完成的一个任务的特殊示例。(也可以说 , 场景是用户为了达到某个目标而和软件系统发生的行为交互序列, 是开发者描述软件功能和需求的一种重要形式。)15、情境性：情景性是指某些事件只有和它们发生时的具体环境联系起来, 才能得到理解,它也是用户无法完成主动信息告知的主要原因。1 6 、民族志：民族志是由人类学家最早提出来的, 用来理解原始社会( Primitive Societies )的社会机制。它要求人类学家花费长期的时间(通常是数年)在被研究的社会中生活并且仔 细观察该社会中的实际活动 , 得到第一手的

46、观察数据。对这些观察数据的分析可以揭示被研 究社会的社会结构、组织方法和具体活动。17、模型驱动法：模型驱动法是一类以定义明确的模型为理论基础, 依据模型指导和组织活动开展的需求工程方法。18、用例驱动法：用例是一种场景的文本化表现方式, 使用叙述性的文本来描述场景。以用例为核心 , 围绕用例开展活动的软件开发方法被称为用例驱动的软件开发方法。19、企业建模：企业建模是以使用产品的组织团体为系统的环境, 进行分析。它主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等。企业建模 利用企业的目标、任务、策略、资源等来刻画组织的行为 , 并依此来发现组织开发系统的目 的, 建

47、立系统的业务需求。20、过程建模：过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程 的集合 , 其中一些由人来执行 , 另一些由软件系统来执行。过程建模使用的主要技术有上下 文图、数据流图、微规格说明和数据字典等。21、 上下文图：上下文图是DFD最高层次的图，是系统功能的最高抽象，它将整个系统看做是一个过程 , 这个过程实现系统的所有功能。上下文图中存在且仅存在一个过程, 表示整个系统。这个单一的过程通常编号为0。22、 概念数据模型：概念数据模型是以问题域的语言解释数据模型， 反映了用户对共 享事物的描述和看法 ， 由一系列应用领域的概念组成。23、 物理数据模型：物理数据模型

48、是对数据模型的解系统语言的解释， 它描述的是共 享事物在解系统中的实现形式 ， 是形式化的定义。24、逻辑数据模型：逻辑数据模型是为了缓解开发人员将概念数据模型转换成物理数 据模型的困难 ， 而使用一种介于问题域和解系统之间的中立语言来进行的数据模型的描述。 这种中立的语言使用更加倾向于用户的概念和词汇 ， 同时使用更加倾向于解系统语言的表达 方式。25 、关系的基数：关系的基数是衡量关系复杂性的指标之一， 又被称为关系的约束。一个实体在关系中的基数定义了在关系中其他实体实例确定的情况下， 该实体实例可能参与关系的数量。26、交互图（ UML 行为模型）：交互图用于描述在特定上下文环境中一组对

49、象的交互行 为， 该上下文环境就是被实现用例的某个场景。所以 ， 交互图通常描述的是单个用例的典型 场景。交互图中的每一个交互都描述了环境中的对象为了实现某个目标而执行的一系列消息 交换。27、 OCL （语言）：OCL （ Object Constraint Language ）称为对象约束语言。OCL不是编 程语言而是一种建模语言 ， 它在保证一定表达能力的前提下 ， 注重于语言的简洁性和抽象性。 但它无法被用来描述程序的控制逻辑和工作流程 ， 而且它的表达式定义也无法在程序中得到 直接的执行。28、基线：基线是已经通过正式评审和批准的规格说明或产品, 可以作为进一步开发的基础 , 并且只

50、有通过正式的变更控制过程才能修改它。29、需求基线：需求基线( Requirements Baseline )就是被明确和固定的需求集合 , 是 项目团队需要在某一特定产品版本中实现的特征和需求集合。30、需求跟踪：需求跟踪是一种有效的控制手段 , 能够在涉众的需求变化中协调系统的 演化 , 保持各项开发工作对需求的一致性。需求跟踪是以软件需求规格说明文档为基线, 在向前和向后两个方向上 , 描述需求以及跟踪需求变化的能力 , 分为前向跟踪(PreTraceabmty )和后向跟踪( Post Traceability )两种。五、问答题1、简述需求工程的主要任务。答：需求工程有以下三个主要任

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

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

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

54、遗漏和不明显的信息遗漏。明显的信息遗漏 , 其主要原因在于项目的范围定义不当 , 可以通过加强对业务需求的 处理得以解决。不明显的信息遗漏 ,是因为相关信息难以发现 , 只能靠需求工程师的经验来加以避免。 不必要的需求。产生不必要需求的原因主要是： 其一是用户将一些不必要的需求作为和开发人员谈判的筹码, 然后通过自己对不必要需求的要求而在和开发人员的谈判当中取得真正想要的利益 , 例如金钱。对此问题 , 唯一需 要的就是开发人员代表的谈判技巧。其二是用户在交流中 , 总是害怕信息有所遗漏 , 并因此产生不利后果 , 因此用户总是倾 向于表达各种各样的需要。要解决这个问题 , 就需要开发人员在进

55、行用户需求的获取之前 , 先定义明确的业务需求 , 然后根据业务需求进行用户需求的过滤和选择。其三是需求开发人员“画蛇添足” , 添加“用户肯定会喜欢”的功能 , 该类功能既会造 成项目额外的耗费 , 又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用户为 中心。 不切实际的期望。不切实际的期望也是实践中常见的需求定义问题 , 而且它在很大程度上影响着项目的 成败。面对不切实际的期望 ,要求软件开发者提供可行性、成本等足够的技术参考信息 , 帮 助用户对其进行取舍和调整。3、简要说明需求获取活动的过程。答：（1）收集和应用背景资料 ,建立初始的知识框架。分析涉众的高层次问题 , 总结出系 统的业务需求。（2）设计一个高层次的解决方案 , 并确定解决方案需要具备的系统特性。高层次的解 决方案和系统特性定义了项目的前景和范围。（3）在项目的业务范围内 ,需求工程要寻找相关的涉众 , 并分析和涉众选择。（4）对组织里存在大量的表格、单据等与业务相关的硬数据进行采样, 它们是需求获取活动中一个重要的信息来源。（ 5）针对某一次具体的需求