软件的需求的工程期末复习资料
软件工程期末考试参考题及答案
软件工程期末考试参考题及答案1. 考试题目：软件需求工程考试要求：根据给定的需求文档，完成以下题目。
题目一：根据给定的需求文档，设计一个在线购物系统。
请根据以下要求完成系统设计：（1）使用UML类图绘制系统的类结构；（2）使用UML时序图描述用户登录和浏览商品的流程；（3）使用UML活动图描述用户下订单的流程。
答案：（1）类图如下所示：[在这里插入UML类图图片]（2）时序图如下所示：[在这里插入UML时序图图片]（3）活动图如下所示：[在这里插入UML活动图图片]题目二：根据给定的需求文档，设计一个在线学习系统。
请根据以下要求完成系统设计：（1）使用UML用例图描述系统的功能需求；（2）使用UML活动图描述学生完成在线学习的流程；（3）使用UML状态图描述学生的学习状态变化。
答案：（1）用例图如下所示：[在这里插入UML用例图图片]（2）活动图如下所示：[在这里插入UML活动图图片]（3）状态图如下所示：[在这里插入UML状态图图片]2. 考试题目：软件设计模式考试要求：根据给定的题目，选择并解答以下问题。
题目一：分析以下代码，判断其使用了哪种设计模式，并阐述该设计模式的作用和优势。
```javapublic interface Car {void drive();}public class Sedan implements Car {@Overridepublic void drive() {System.out.println("Driving a sedan car."); }}public class SUV implements Car {@Overridepublic void drive() {System.out.println("Driving an SUV car."); }}public class CarFactory {public Car createCar(String type) {if (type.equals("sedan")) {return new Sedan();} else if (type.equals("suv")) {return new SUV();} else {throw new IllegalArgumentException("Invalid car type: " + type);}}}```答案：该代码使用了工厂模式。
软件需求期末考试题及答案
软件需求期末考试题及答案# 软件需求期末考试题及答案一、选择题（每题2分，共20分）1. 软件需求分析的主要目的是：A. 确定软件的功能B. 确定软件的性能C. 确定软件的界面D. 确定软件的成本答案： A2. 以下哪项不是需求分析阶段的输出？A. 需求规格说明书B. 系统设计文档C. 用户手册D. 数据字典答案： B3. 需求变更控制的目的是什么？A. 降低成本B. 减少开发时间C. 确保需求的一致性和完整性D. 提高软件质量答案： C4. 以下哪个不是功能性需求的例子？A. 系统必须能够处理在线支付B. 系统必须支持多语言界面C. 系统必须在1秒内响应用户请求D. 系统必须能够存储用户数据答案： C5. 非功能性需求通常包括以下哪些方面？A. 可用性B. 性能C. 安全性D. 所有以上选项答案： D...（其他选择题省略）二、简答题（每题10分，共30分）1. 简述什么是软件需求，并区分功能性需求与非功能性需求。
答案：软件需求是指用户对软件系统的功能、性能、行为和约束的详细描述。
功能性需求描述了软件系统必须执行的任务，例如处理数据、执行计算或与用户交互。
非功能性需求则描述了软件的属性，如性能、安全性、可用性、可靠性等，这些属性通常不涉及软件的具体功能，但对软件的整体表现至关重要。
2. 解释什么是需求变更，以及如何处理需求变更。
答案：需求变更是指在软件开发过程中，由于各种原因（如市场变化、用户需求变化、技术进步等）导致的对原始需求文档的修改。
处理需求变更通常包括以下几个步骤：识别变更、评估影响、与利益相关者沟通、更新需求文档、重新评估项目计划、重新测试以及重新部署。
3. 描述需求获取的方法，并给出一个具体的例子。
答案：需求获取是指从用户或其他利益相关者那里收集需求的过程。
常见的方法包括访谈、问卷调查、观察、原型开发、焦点小组讨论等。
例如，通过访谈，开发团队可以直接与用户交谈，了解他们的工作流程、痛点和期望的功能，从而获取需求。
软件需求过程期末考试必备
软件需求分析习题汇总目录一、单项选择题二、填空题三、判断题四、名词解释题五、问答题六、案例分析题一、单项选择题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演示原型和试验原型 B系列首发原型和选定特征原型C探索式原型和实验式原型 D样板原型和纸上向导原型11、原型的需求内容可以从三个纬度上分析：即 ;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工作手册 B规章手册 C统计报表 D备忘录17、下列属于定性硬数据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、描述场景所使用的表示法要符合正规性要求,一般可使用非形式化语言、半形式化语言和形式化语言;在实践中, 是主要的描述方式;A形式化的程序语言 B非形式化的自然语言C形式化的图形工具 D非形式化的设计语言27、外观是指场景被表达出来时的效果,主要有三种类型;A静态、动态和结构化 B线性、非线性和交互C静态、动态和动静结合D静态、动态和交互28、场景的内容是指场景所表达的知识类型;它被分为6个不同的方面;下列不是场景的内容;A主要关注点 B环境范围 C目的 D抽象层次29、需求工程利用场景的目的可能有三种：即： ;A描述、探索和解释 B描述、表示和探索C描述、探索和发现 D表示、解释和证明30、使用解释性场景在需求分析时能够 ,或者被用于进行需求的验证;A提高模型的复杂性 B降低模型的复杂性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建立软件系统解决方案C需求信息转化 D建立需求分析模型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层图;A1层图 B底层图 C上下文图D顶视图46、因为数据存储是系统内部的功能实现,所以在将系统视为黑盒的情况下,上下文图中不会出现 ;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过程文档 D用户文档60、下列不是需求规格说明文档的读者A项目管理者 B编程人员 C销售商 D律师二、填空题1、传统的需求分析方法都是从设计领域转入分析领域的;2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进行巧妙的功能安排;3、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡,寻找一套切实有效的功能配置;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、需求工程师可以使用模型驱动方法来进行信息的整理和归类,其中模型驱动方法所建立的模型是进行信息整理和归类的很好的框架依据;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、前期需求阶段分析的重点是理解问题世界,因此它关注的是整个问题世界,注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等等,软件系统只是整个背景下的一个要素;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中一个实体在关系中的最小基数是指,对关系中任意的其他实体实例,该实体可能参与关系的最小数量;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、原型修正主要依据评估人员的反馈,可以忽略事先的原型调整计划;×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、由于计算模型的形式化特征不适合于需求工程阶段,因此计算模型不适合用于需求分析中的建模;√。
需求工程期末复习总结
填空：1.在导致需求问题的原因中，一个最为重要的原因是：未能很好的掌握应用型软件的模拟特性以及由此产生的一系列的影响和要求。
2.面向专业用户的纯工具型软件的首要成功标准是：要具有功能的复杂性和使用的高效性。
3.需求开发过程中产生的主要文档有三种：项目前景和范围文档，用户需求文档，需求规格说明文档。
4.系统用例图和上下文图通常被用来定义系统的边界。
5.在需求建模时，常用的技术包括：数据流图，实体联系图，状态转换图，类图等半形式化建模技术。
6.业务需求，高层解决方案及系统特性都应该被记录下来，定义为项目前景与范围文档。
7.每一个明确，一致的问题都意味着涉众存在一些相应的期望目标，即业务需求。
8.业务需求中需要特别注意的特征是可行性和可验证性。
9.在会谈中使用的问题基本上可以分为两种：开放式和封闭式问题10.面谈的类别：结构化，半结构化和非结构化面谈11.原型的需求内容可以从三个纬度上分析：外观，角色，实现12.民族志一个主要的应用目的就是研究和解决复杂的协同问题13.分类框架将场景方法从场景的形式（又分为描述和外观两个方面），目的，内容和生命周期四个方面进行了分类和描述14.工程利用场景的目的有三种：描述，探索，解释15.抽象和分解是建模最为常用的两种手段16.抽象通过强调本质的特征，减少了问题的复杂性；分解的手段体现了分而治之的思想17.分析模型是半形式化的18.建模语言有三个要素：语法，语义，语用19.按照Zachman的矩阵框架，分析技术就是用来对第二行（企业模型）的各列进行建模和描述的技术20.面向对象分析方法以对象为基础，结构化分析方法以功能和数据为基础21.结构化，信息工程和面向对象三中方法学下的需求分析技术都是面向解系统的22.使用面向问题的技术称为前期需求阶段的分析，使用面向解系统的技术称为后期需求阶段的分析23.数据流图建模时使用的基本模型元素有四种：外部实体，过程，数据流和数据存储24.DFD定义了三个层次的DFD图：上下文图，0层图和N层图25.实体联系图用实体，属性和关系三个基本构建单位来描述数据模型26.除了静态的事物和抽象的概念之外，行为和事件也是常见的实体类型27.在关系的命名上通常使用动词28.用例模型的基本元素：用例，参与者，关系，系统边界29.UML的行为模型有三种：交互图，状态图，活动图30.在目标模型中使用的其他模型元素有行为者，场景，操作，任务，资源，UML元素等//31.需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力名词解释：1.需求工程：是软件工程的一个分支，它关注与软件系统所应予实现的现实世界目标，软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素的准确的软件行为规范说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
软件需求工程考试复习资料：复习提纲.doc
第二章:描述1、需求的定义a用户为了解决问题和解释或达到某些目标所需要的条件能力b系统或系统部件为了满足合同，标准，规范或其他正式文档所规定的要求而需要具备的条件或能力c对a或b中的一个条件或一种能力的一种文档表述。
2、需求的内涵：问题域、解系统与共享现象a要解决问题，就需要改变现实中某些实体的状态，或者改变实体状态变化的演进顺序，使其达到期望的状态和理想的演进顺序。
这些实体与状态构成了问题解决的基本范围，称为该问题的问题域。
b软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。
c共享现象:通过映射建立的共同知识，就是问题域中与解系统中的共享现象。
3、分类：类别有：功能需求，性能需求，质量需求，对外接口，约束4、功能需求的三个层次:5、需求工程的路线图问题分析：明确问题定义业务需求制定解决方案及系统特性-＞需求获取：用户需求，性能需求质量属性对外接口约束问题域特性-＞需求分析：系统需求系统模型-＞文档化与验证第四章：描述6、需求获取的困难用户和开发人员的背景不同，立场不同首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够和用户进行有效沟通的粗略的知识框架默认(Tacit)知识现象利用有效的获取方法与技巧(角色扮演、观察等)来发现并获取默认知识普通用户缺乏概括性、综合性的表述能力普通用户的知识结构就相对局限于一些具体的业务细节善于表达具体业务的细节问题专家用户的知识结构因其渊博性而具有概括性和广泛性能够回答概括性和综合性的问题开发人员在与用户接触之前就先行确定获取的内容主题,然后设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望。
7、需求获取的流程第五章8、定义项目前景和范围的流程:描述9、问题分析：应用第六章：描述+应用10、涉众分析的流程11、涉众识别的方法12、涉众评估的内容13、涉众选择的策略第7——9章：描述+应用14、面谈的问题类型15、面谈的结构16、面谈的优缺点17、原型的各种特征分类18、原型的优缺点利用原型的好处有:及时、有力的响应用户需求的变化；减少返工；帮助控制不完整需求所带来的风险；可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤;减少开发成本，提高经济效益;增加开发者之间的交流，帮助确定技术解决方案的可行性；有效的识别风险和解决风险，帮助进行风险管理;提高用户在软件开发中的参与程度。
软件需求工程期末考试试题
软件需求工程期末考试试题### 软件需求工程期末考试试题一、选择题（每题2分，共20分）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. 个人偏好二、简答题（每题10分，共30分）1. 描述需求工程的一般过程，并解释每个阶段的主要活动。
2. 解释为什么需求变更控制对于软件项目的成功至关重要。
3. 简述如何使用用例来捕捉和组织软件需求。
三、案例分析题（每题25分，共50分）1. 假设你是一名软件需求工程师，负责一个在线书店系统的开发。
请根据以下场景，列出至少5个功能性需求和3个非功能性需求，并解释每个需求的重要性。
场景：用户需要能够浏览书籍，搜索特定书籍，购买书籍，并能够查看订单历史。
系统需要能够处理高并发访问，并保证数据的一致性和安全性。
2. 描述一个需求变更的情况，并解释在这种情况下，需求变更控制流程如何帮助确保项目顺利进行。
附加题（10分）1. 假设你正在参与一个跨文化团队的软件项目，团队成员来自不同的国家和文化背景。
请讨论在这种环境下进行需求收集和沟通时可能遇到的挑战，并提出你的解决方案。
注意：请考生仔细阅读题目，认真作答，确保答案清晰、准确。
考试结束后，将答题纸交回。
祝各位考生考试顺利！。
需求工程简答题--复习资料
需求工程简答题--复习资料四、名词解释题1、需求工程：需求工程是软件工程的一个分支，它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
2.需求：需求是用户对问题域中的实体状态或事件的期望描述。
2、需求：IEEE对需求的定义为：①用户为了解决问题或达到某些目标所需要的条件或能力。
②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。
③对①或②中的一个条件或一种能力的一种文档化表述。
3、需求分析：需求分析是利用建模与分析技术对获取笔录的内容进行明确、整理、汇总，建立一个综合考虑问题域特性和需求的系统模型，然后根据系统模型将用户需求转化为系统需求的需求工程活动。
4、前景（Vision）：前景描述了产品的作用以及最终的功能，它将所有涉众都统一到一个方向上。
5、范围（scope）：范围指出当前项目是要解决产品长远规划中的哪一部分，范围声明它为项目划定了需求的界线。
7、硬数据：表格和文档资料是用户对实际业务进行加工和抽象之后的结果，是一种精化过的知识。
这些文档资料被称为硬数据。
硬数据分为定量硬数据和定性硬数据两种类型。
8、结构化面谈：结构化面谈指在面谈的过程中，会见者会完全按照事先的问题和结构来控制面谈。
结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息，一些统计性倾向信息的获取也可以使用结构化面谈。
9、半结构化面谈：半结构化面谈指在面谈的过程中，事先需要根据面谈内容准备面谈的问题和面谈结构。
但在面谈过程中，会见者可以根据实际情况采取一些灵活的策略。
半结构化面谈是在需求获取中应用最多的一种面谈类型，能够处理大部分的需求获取任务。
10、非结构化面谈：在非结构化面谈的过程中，没有事先预定的议程安排。
在比较极端的情况下，会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地，就某个主题开展会谈。
《软件需求工程》期末考试试题2套含答案(大学期末复习资料).doc
考试科目名称 软件需求工程1、(本题满分10分) (1) 解释下列三个概念：业务需求、用户需求、系统需求；(2)说明为什么在需求开发当中要重视软件的质呈属性。
2、(本题满分10分)试分析按下列顺序安排的问题是什么面谈结构:(1) 你在这个职位多久了？(2) 你的主要责任是什么？(3) 你接受什么报告？⑷你是如何看待部门目标的?(5) 你是如何描述决策过程的?(6) 怎样才能最好地支持这个过程?(7) 做这些决策的频度如何？(8) 当你做决策时会咨询谁？(9) 你做过的对于部门机能有重要意义的决策是什么？(1)这里采用了什么结构？你是如何确定的?得分 得分（2）通过改变问题的顺序，重新安排面谈的结构（如果有些必要，可以省略一些问题）。
标明所用的结构。
3、（本题满分15分）在各种关于软件的调研当中，无一例外的发现“缺乏用户参与”是导致软件失败的最大原因，请列举至少3条会使得用户参与不足的原因？并说明相应的解决方法。
4、（本题满分15分）根据下列叙述性描述，为描述的内容绘制一个上下文DFD：校园书店“课本库存系统”的目的是向学生提供本地大学课程的课本。
大学的教学部门通过一个“课本主清单”向书店提交初始数据，包括课程、教师、课本和预计注册人数。
书店生成一个“购买订单”，“购买订单”被送到供应课本的出版公司。
图书订单随着一个“包装清单”到达书店，它被接收的部门检查和验证。
学生填写包含课程信息的“购书要求”，当他们付了书款Z后就得到一个“销售单据”。
5、（本题满分15分）一个CD销售商店需要开展网上销售业务，下而是它的一个典型销售场景：Normal Flow of Events:1.Customer submits a search request to the system, the request contains the category information ofCDs.2.The system provides the customer a list of recommended CDs.3.The customer chooses one of the CDs to find additional information according to its identifie匚4.The system provides the customer with basic information & CD Reviews5.The customer maintains the order, records the item chosen・6.The customer iterates over 3 through 5 until finished shoppin g・7.The customer checks out and leaves the website・请以上述场景的描述为基础，执行名词抽取、建立关联和识别属性三个过程，并最终为上述描述建立领域模型，要求详细记录你在执行三个过程时的具体步骤。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
行自动切换或者可否由用户采取某些措施来激发这样转变？还有，在文档中显示转变的范围
是什么？是所选的文本、整个文档或其它内容？这个需求也存在一个不确定性问题。“非打
精彩文档
实用标准文案
印”字符是否指隐藏文本、属性标记或者其它的控制字符？由于存在这些问题，该需求是不 可验证的。用如下的语句描述这个需求可能会更好一些：
成的百分比。
c.当完成后台任务时，后台任务管理器(BTM)必须显示一个“已完成”的消息。
d.如果后台任务中止执行，那么后台任务管理器(BTM)必须显示一个出错信息。
（2）“产品必须在显示和隐藏非打印字符之间进行瞬间切换”。
在瞬间这一时间概念上，计算机不能完成任何工作，因此，这个需求是不可行的。该需
求也是不完整的，因为它没有说清状态切换的原因。在特定的条件下，软件产品是否可以进
需求定义阶段：根据用户需求编写出需求规格说明。
需求的形式化描述阶段：用严格的数学知识和符号来构造系统的需求模型。
需求验证阶段：检验软件需求规格说明。
需求管理阶段：开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影
响及可能的成本及费用，然后实施更改，一级有效的管理需求规格说明文档和跟踪更改需求
☆ 请指出下列陈述属于哪种类型的软件需求或不属于软件需求。
p26
（1）只有电梯停在某一楼层时，电梯才能改变方向。 非功能
（2）系统必须用三个主要模块来实现，即检测、记录和统计分析模块，每个模块各自实现
精彩文档
实用标准文案
一个主要功能。
功能性需求
（3）当用户输入他们的口令后，系统便自动从口令文件中检索他们的加密口令，并进行核
护性和可扩展性等。
约束与限制：指软件开发人员在设计和实现软件系统时的限制，如：开发语言，使用的数据
库等。
精彩文档
实用标准文案
☆ 试述快速原型开发模型和面向对象开发模型的基本思想，然后说明快速原型开发模型中
抛弃型模型和进化型模型的作用。
p9
快速原型模型基本思想：快速建立一个实现了若干功能的（不要求完全）可运行模型来启发、
求信息录入
旅客基本信息及 订票要求信息
1.13 航班安
排
订票信息
旅客基本信息
航班信息
1.14 旅客管
理
1.12 航班管
理
D2通知和账单记录
D3旅客基本信息表
D4航班信息票
订票细化流程图
精彩文档
2.3 打印机
票
实用标准文案
2.2 收费
旅客去票通知和 账单信息
2.1 正确 核对机
票信息
订票信息
D1订票记录
对。
功能性需求
（4）通过对用户进行不到一个小时的培训后，用户能输入和打印某些数据，且输入/出的出
错率低于 1/20。
非功能
（5）所有报销单据必须经过财务部门某负责人审核后才能交由系统处理。
非功能
（6）系统必须用面向对象的方法和糊，如果含糊的话，请在说明理由后给予修改：
另附数据字典：
旅客信息:
姓名：xxx 性别：男 描述：旅客订票时所填的资料(省份证号、所需机票的基本信息、乘机时间） 定义：订票申请表单(旅客姓名、旅客性别、起飞日期、飞行目的地、座位类型 ） 位置：位置：在客户端由旅客填写
航班信息：
航班名称： 航班类型： 描述：所有从本地起飞的航班信息（航班号、起飞时间、到达的目的地、空出的 座位数、票价） 定义：航班信息（航班号、起飞日期、飞行目的地、空出的座位数、票价） 位置：从服务器端查询后，发送到客户端
围和项目应达到的目标。
业务需求：主要描述软件系统必须完成的任务、实际业务或工作流程等。软件开发人员通常
可从业务需求进一步细化出具体的功能需求和非功能需求。
功能需求：指开发人员必须实现的软件功能或软件系统应具有的外部行为。
性能需求：指实现的软件系统功能应达到的技术指标，如：计算效率和精度，可靠性，可维
揭示和不断完善用户需求，直到满足用户的全部需求为止。其基本过程如下：
收集需求 快速设计 建立原型 评价并细化需求 设计与实现 测试 维护
面向对象开发模型基本思想：
应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析
和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作
为运行机制的一种问题求解方法。其基本过程如下：
面向对象分析
面向对象设计
面向对象实现和测试
系统维护
抛弃型模型：指在原型达到预期目的后将其抛弃，而且在构建该原型时，可以忽略具体的软 件构造技术，亦即应以最小的代价构造抛弃型原型。 进化型模型：在需求被清楚定义的情况下，以渐增式方式构建原型，并使原型最终能成为软 件产品的一部分。
“系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表中查不到 该货物的编号，系统必须显示一个出错消息并且拒绝订货。”第二种相关需求可能记录了一 种异常情况：当进行货物编号确认时，主货物编号列表不可访问。 （7）“产品不应该提供将带来灾难性后果的查询和替换选择。”
“灾难性后果”的含义是解释的中心词。在编辑文档时，毫无目的地作出全局性变化而 用户又不能检测出错误或没有任何办法来纠正它，此时就可能带来灾难性后果。你也要合理 地使用反面需求，因为这些需求描述了系统所不能做的事情。潜在的关注焦点在于当发生意 外损坏时，能保护文件的内容。也许，真正的需求是针对多级撤销 ( u n d o )能力、全局 变化或其它可导致数据丢失行为确定的。
实用标准文案
☆ 什么是软件需求工程？请说明软件需求工程中各阶段的主要任务。
p5
1 定义
一般定义：指应用工程化的方法、技术和规格来开发和管理软件的需求。
需求工程的目标： 获取高质量的软件需求。
与软件工程中传统的需求分析概念相比，需求工程突出了工程化的原则，强调以系统化、条
理化、可重复化的方法和技术进行与软件需求相关的活动，从而有利于提高所有与软件需求
p42
系统数据流图
旅客
订票信息 机票
机票预订 系统
取票通知和账单
取通知和账单 付费信息
旅客
顶层数据流程图
顶层数据流图只是粗略的给出整个系统的数据流情况。为了更好的把“航空机票预定系 统”中各个模块的具体数据流处理细节表示出来，可以在顶层图的基础上自顶向下继续分解， 得到 1 层和 2 层数据流图。
旅客信息
p84
（1）系统必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于 60 秒。
含糊。需求不完整，导致需求不可验证。改进如下：
后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。
a.在后台任务进程启动之后，消息必须每隔 60(10)秒更新一次，并且保持连续的可见性。
b.如果正在正常处理后台任务进程，那么后台任务管理器(BTM)必须显示后台任务进程已完
我在想：“如果可能的话”这句话意味着什么？该需求是否在技术上可行？是否可以在 线访问主货物编号列表？如果你不能确信是否可以递交一个请求，那么就使用“待确定” ( T B D )来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败， 将会发生什么情况。应该尽量避免使用不精确的词汇，例如“应当”。 客户可能需要这个功 能或者不需要这个功能。一些需求规格说明利用关键字之间微妙的差别如“应当”，“必须” 和“可能”来指明重要性。我更喜欢使用“必须”或“将要”来明确说明需求的目的并且明 确指定其优先级。改进后的该需求描述如下：
“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有 H T M L 标 记之间进行切换”。现在，指代关系就清楚了，非打印字符指的是 H T M L 标记。修改过的 需求指明了是用户触发了显示状态的转换，但是它并没有对设计造成限制，因为它并没有精 确定义所使用的机制。当设计人员选择好一种触发机制（例如热键、菜单命令或语音输入） 时，你就可以编写详细的测试用例来验证这种转换操作是否正确。 （3）编译系统应该能生出出错报告，这样就可使初学者能迅速的排错。 应说明编译系统在什么情况下出什么出错报告，改为： 编译系统应该能标识出错误，并在错误所在的位置显示出出错报告，这样就可使初学者迅速 的排错。 （4）软件系统应具有良好的反应时间和数据精度，且能由菜单方式驱动。 “良好的”应使用量化的语言叙述，改为： 软件系统的反应时间应小于 1 秒，数据精度为 10^-6。 （5）“分析程序应该能生成 H T M L 标记出错的报告，这样就可以使 H T M L 的初学者使 用它来迅速排错。” “迅速”这个词具有模糊性。缺乏对出错报告内容的定义表明该需求是不完整的。我不知道 你是如何验证这个需求的。找一些 H T M L 的初学者，看他们利用这个报告是否可以迅速 排错？还有一点不清楚的是： H T M L 初学者使用的是分析程序还是出错报告。并且何时 生成这样的报告？让我们使用另一种方式表述这个需求： a. 在 H T M L 分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个 报告中包含了在分析文件过程中所发现错误的 H T M L 所在的行号以及文本内容，还包含
相关的活动及其过程的可管理性，降低需求开发和管理的难度和成本。
其它定义：
Alan.Davis： 直到（但不包括）把软件分解为实际架构组建之前的所有活动，即软件设计
之前的一切活动。该定义虽然没有详细说明需求工程是什么，但其给出了需求工程的范围。
Lan K. Bray：对问题域及需求做调查研究和描述，设计满足那些需求的解系统的特性，并
精彩文档
实用标准文案
☆ 为方便顾客，某航空公司拟开发一个机票预订系统。机票售票点把预订机票的顾客信息
（姓名，性别，身份证号，出发时间和目的地，航班号等）输入该系统，系统为顾客查询航