需求工程复习题【填空题部分】

34、目标模型的链接有两类：一类是目标之间的链接；另一类是目标与【其他模型元素之间的链接】。
35、面向目标方法的处理过程可以分为三个阶段：目标获取、【目标分析】和目标实现。
36、目标实现阶段的主要任务是收集与目标相关的需求信息，讨论可能的候选解决方案，确定最终的系统详细需求和解决方案。
37、场景具有重点描述真实世界的特征，它利用情景、【行为者之间的交互】、事件随时间的演化等方式来叙述性地描述系统的使用。
50、需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差距。需求分析就是用来解决这个差距的需求工程活动。
51、需求分析的根本任务是：【建立分析模型】并创建解决方案。
52、分解将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系。
53、基于软件构建单位及其之间的关系建立的模型，用来说明软件逻辑上的构建方式和实现方式，由于它使用的组元及其关系都是软件的元素，因此它是来自于软件的模型，称为计算模型。
60、以软件复用为核心，建立产品族的方法被称为产品线。
61、需求协商活动既包括对目标冲突的处理，也包括对需求细节冲突的处理。
62、微规格说明被用来描述DFD过程分解结构中最底层过程的【处理逻辑】。
63、DFD中所有的外部实体】=联合起来构成了软件系统的外部上下文环境，它们与软件系统的交互流就是软件系统与其外部环境的接口，这些接口联合起来定义了软件系统的系统边界。
64、数据流是指数据的运动，它是系统与其环境之间或者系统内【两个过程】之间的通信形式。
65、DFD的0层图中的每个过程都可以进行分解，被分解的过程称为父过程，分解后产生的揭示更多细节的DFD图称为子图。
66、DFD的0层图通常被用来作为整个系统的【功能概图】。
67、为了保证DFD图的可理解性，0层图应该被描述的简洁、清晰，所以在描述复杂的系统时，0层图中不应出现太过具体的过程和数据存储。
1、传统的需求分析方法都是从【设计领域】转入分析领域的。
2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进行巧妙的【功能安排】。
3、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡，寻找一套切实有效的【功能配置】。
4、应用型软件分析阶段的主要目的是发现人们利用软件的原因（目的），找出需要软件解决的问题，理解应用环境中的领域知识，保证功能的【模拟性】。
17、实现是指原型物件完成功能的细节技术和方法。
18、使用演化式原型方法，在开发时就需要注意原型的健壮性和代码的质量。
19、使用实验式开发方法，需要实现多种技术方案，考察重要的系统的质量属性。
20、选择使用探索式开发方法，需要尽可能地考虑各种不同的设计选项，比较不同选项下的用户反馈。
21、原型方法的最大优点是能够及早地解决系统开发中的不确定性，从而降低软件项目失败的风险。
98、从需求向后回溯说明软件需求来源于哪些涉众的需要和【目标】。
99、后向跟踪是指需求【被定义】到软件需求规格说明文档之后的演化过程。
100、后向跟踪包括两种联系：从需求向前跟踪和【回溯到需求的跟踪】。
74、ERD中属性就是可以对实体进行描述的特征，一系列属性的存在集成起来就可以描述一个实体的【实例】。
75、ERD中属性取值的受限制范围称为【域】。
76、ERD为实体指定一个属性或多个属性的组合，可以用来唯一地确定和标识每个实例，这些属性或属性的组合称为实体的标识符，又称为键。
77、一个实体可能有多个键，这些键都被称为候选键。
71、在需求工程中，数据建模建立的是概念数据模型和逻辑数据模型，不涉及物理数据模型。
72、ERD的逻辑实体是对概念实体的细化，拥有完整的【特征描述】。
73、数据建模中对行为和事件的建模需要是为了了解它们在某些时刻的快照或者运行环境信息，而不是它们所体现出来的功能和达成的效果，所以称这类实体为进程实体。
13、，如果一个问题的技术解决方案是不清晰的，演示原型也可以被用来展现相应的细节功能以使用户确信该问题解决的可能性。
14、通常来说，如果用户需求出现了模糊、不清晰、不完整等具有一定不确定性的特征，就可以考虑使用原型方法。
15、角色是指原型物件在用户工作中的价值，也就是说它为什么对用户是有用的。
16、外观是指用户对原型物件的具体感觉体验，即用户在使用原型物件时会看到什么、听到什么和感觉到什么。
26、采样观察是最简单的观察方法，应用目的是【发现异常流程】，验证用户所述知识和实际的一致性，以及发现默认知识。
27、时间采样允许需求工程师建立指定的【时间间隔】来观察用户的活动情况。
28、文档审查主要获取对象包括相关产品的【需求规格说明】、硬数据和客户的需求文档。
29、文档分析通常是数据建模方法的一个基础部分，它是通过检查采集的硬数据来确定潜在的需求。
47、单个用例描述了系统的功能片段，系统的所有用例基于一定的关系组织起来，建立【用例模型】，就可以描述整个系统的功能。
48、原有用例和新建立的【抽象用例】的关系即为包含关系。
49、在需求工程中，主要产生三类重要的文档：项目前景和范围文档、用户需求文档以及需求规格说明。用例文档通常被用来代替用户需求文档，起到记录、交流领域信息和用户期望的作用。
38、静态外观的场景被展现为一个或者数个描述性的文本或者图片。
39、动态外观的场景会被以动态的方式展现出来，人们可能会要求【按时序】向前或者向后浏览场景，也可能会要求跳转到场景的某一个时刻进行观察。
40、交互外观的场景提供交互性，它允许用户在一定程度上控制和改变场景的【变化时序】或者效果。
41、具体场景，又称为【实例场景】，是对个别行为者、事件、情节的细节描述。
30、如果当前存在一份客户的需求文档，就可以使用需求剥离技术，从需求文档中抽取单个的需求并加入到新的需求文档之中。
31、需求工程师可以使用模型驱动方法来进行信息的整理和归类，其中模型驱动方法所建立的模型是进行信息整理和归类的很好的框架依据。
32、模型驱动方法的模型是在前期需求阶段的分析中建立的。
33、目标模型的一个核心要素是元素之间的关系wk.baidu.com称为链接。
94、评审又被称为【同级评审】，是指由作者之外的其他人来检查产品问题的方法。
95、在系统验证中，评审是主要的【静态分析】手段，所以评审也是需求评审的一种主要方法。
96、需求基线的维护主要包括配置管理和【状态维护】。
97、需求跟踪是以【软件需求规格说明文档】为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。
68、DFD中对0层图的过程分解产生的子图称为【1层图】。
69、数据建模建立的模型称为数据模型，是问题域和解系统共享的知识集合，通常能够反映【企业业务】的核心知识。
70、数据模型的内容是问题域和解系统所共享的知识模型，可以用问题域的语言来解释，也可以用解系统的语言来解释，还可以用介于问题域和解系统之间的【中立语言】来解释。
22、航空调度、证券交易、医疗手术控制等复杂的协同问题都具有突现的情景性。
23、民族志的一个主要应用目的就是研究和解决复杂的协同问题。
24、复杂的工作总会同时存在着正常流程和异常流程，异常流程大多是一些特殊情况下的处理，限定了异常处理的上下文环境，即异常处理具有局部的情景性。
25、有很多重要工作的进行需要用户具备一定的认知，认知要求已经成了用户工作必备的部分，即工作具有【涉身】的情景性。
8、优秀的需求应具备的特性：完整性、正确性、精确性、可行性、必要性、无歧义和【可验证】。
9、所有对软件系统的开发和应用具有发言权和决定权的人统称为涉众。
10、按照媒介载体进行分类，原型可分为：[样板原型]和纸上向导原型。
11、演示原型主要被用在[项目启动]阶段。
12、演示原型都是被用来展示用户想象中的系统视图，所以它要能够表现用户界面的重要特征。
54、模型语言的三要素：语法、语义、语用。其中语用给出了一个模型元素描述的更宽广的上下文，以及影响该模型元素意义的约束和假定。
55、互相之间建立了语义联系的多个模型，集成在一起通常被称为视图。
56、需求分析方法主要有：结构化方法、信息工程方法和【面向对象方法】。其中面向对象方法是目前工业界使用的主流方法。
42、抽象场景，又称为【类型场景】，是以经验中的类别和抽象概念来描述事实。
43、探索性场景可以用来进行需求获取和【需求建模与分析】。
44、每个用例是对相关场景集合的叙述性的文本描述，这些场景是用户和系统之间的交互行为序列，帮助实现用户的目的。
45、用例是场景方法中的一种，是静态的结构化文本描述。
46、在高层的功能需求获取完备之前，用例的产生方式中不允许使用【功能分解】方式。
57、信息工程和结构化方法的本质差别在于解决问题的【策略】不同。
58、前期需求阶段分析的重点是理解问题世界，因此它关注的是整个问题世界，注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等等，软件系统只是整个背景下的一个要素。
59、后期需求阶段分析关注的是解系统解决方案的建立，因此它以软件系统为中心，注重于分析系统的内部功能以及它与环境的互动，是对【系统功能】的详细信息的分析。
82、只有一个实体参与的关系存在于实体的不同实例之间，称为一元关系，又称为【递归关系】。
83、ERD中关系的基数分为最大基数和最小基数。最小基数又被称为【参与约束】。
84、ERD中一个实体在关系中的【最大基数】是指，对关系中任意的其他实体实例，该实体可能参与关系的最大数量。
85、ERD中一个实体在关系中的【最小基数】是指，对关系中任意的其他实体实例，该实体可能参与关系的最小数量。
86、ERD中被关系影响的实体主要是弱实体和【关联实体】。
87、用例模型的基本元素有四种：用例、参与者、关系和【系统边界】。
88、UML行为模型是用例模型的实现，以更加详细的方式说明用例所描述的系统行为。
89、UML行为模型的活动图是依据【处理流程】进行的用例实现。
90、UML行为模型的交互图通常描述的是单个用例的【典型场景】。
78、通常人们从多个候选键中选择和使用固定的某一个键来进行实例的标识，这个被选中的候选键被称为主键，没有被选做主键的候选键被称为替代键。
79、实体实例大多数属性的值都是需要从现实中获取的，称为【存储属性】。
80、有些实体实例的属性的值是可以由其他属性的值计算得出的，称为【导出属性】。
81、关系是存在于一个或多个实体之间的自然业务联系。
91、接口需求规格说明文档是对整个系统中需要软、硬件【协同实现】部分的详细描述。
92、优秀的需求规格说明文档应该具备：正确性、无歧义、完备性、一致性、根据重要性和稳定性分级、【可验证】、可修改、可跟踪等特性。
93、需求验证常见方法有：需求评审、【原型与模拟】、测试用例开发、用户手册编制、利用跟踪关系和自动化分析。
5、需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的【期望效应】。
6、软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。
7、约束是不受解系统影响，却会给解系统带来极大影响的【问题域】特性。