需求工程简答题--复习资料_docx

当前位置: Docx88>IT/计算机>计算机软件及应用>需求工程简答题--复习资料_docx


四、名词解释题

1、需求工程:需求工程是软件工程的一个分支,它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束,同时它也关注以上因素和准确的软件行为规格说明之间的联系,关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。

2.需求:需求是用户对问题域中的实体状态或事件的期望描述。

2、需求:IEEE对需求的定义为:

①用户为了解决问题或达到某些目标所需要的条件或能力。

②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。

③对①或②中的一个条件或一种能力的一种文档化表述。

3、需求分析:需求分析是利用建模与分析技术对获取笔录的内容进行明确、整理、汇总,建立一个综合考虑问题域特性和需求的系统模型,然后根据系统模型将用户需求转化为系统需求的需求工程活动。

4、前景(Vision):前景描述了产品的作用以及最终的功能,它将所有涉众都统一到一个方向上。

5、范围(scope):范围指出当前项目是要解决产品长远规划中的哪一部分,范围声明它为项目划定了需求的界线。

7、硬数据:表格和文档资料是用户对实际业务进行加工和抽象之后的结果,是一种精化过的知识。这些文档资料被称为硬数据。硬数据分为定量硬数据和定性硬数据两种类型。

8、结构化面谈:结构化面谈指在面谈的过程中,会见者会完全按照事先的问题和结构来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息,一些统计性倾向信息的获取也可以使用结构化面谈。

9、半结构化面谈:半结构化面谈指在面谈的过程中,事先需要根据面谈内容准备面谈的问题和面谈结构。但在面谈过程中,会见者可以根据实际情况采取一些灵活的策略。半结构化面谈是在需求获取中应用最多的一种面谈类型,能够处理大部分的需求获取任务。

10、非结构化面谈:在非结构化面谈的过程中,没有事先预定的议程安排。在比较极端的情况下,会见者甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地,就某个主题开展会谈。

11、头脑风暴(Brainstorming):是一种特殊的群体面谈方式,它的目的不是发现需求,而是“发明”需求,或者说是发现“潜在”需求。它鼓励参与者在无约束的环境下进行某些问题的自由思考和自由讨论,以产生新的想法。它是需求获取中用于“发明”需求的方法,但它会增加需求的数量。

12、原型:原型是一个系统,它内化了(Capture)一个更迟系统(Later System)的本质特征。原型系统通常被构造为不完整的系统,以在将来进行改进、补充或者替代。”

13、严格意义上的原型:严格意义上的原型主要被用在需求分析阶段,是开发者在建立系统信息模型的同时建立的原型,通常被用来阐明用户界面或者系统功能的某些特定方面,帮助人们及时地澄清问题。

14、场景:场景是对系统和环境行为的局部描述,或者说场景是对行为或者事件序列的描述,序列中的行为和事件是系统需要完成的一个任务的特殊示例。

(也可以说,场景是用户为了达到某个目标而和软件系统发生的行为交互序列,是开发者描述软件功能和需求的一种重要形式。)

15、情境性:情景性是指某些事件只有和它们发生时的具体环境联系起来,才能得到理解,它也是用户无法完成主动信息告知的主要原因。

16、民族志:民族志是由人类学家最早提出来的,用来理解原始社会(Primitive Societies)的社会机制。它要求人类学家花费长期的时间(通常是数年)在被研究的社会中生活并且仔细观察该社会中的实际活动,得到第一手的观察数据。对这些观察数据的分析可以揭示被研究社会的社会结构、组织方法和具体活动。

17、模型驱动法:模型驱动法是一类以定义明确的模型为理论基础,依据模型指导和组织活动开展的需求工程方法。

18、用例驱动法:用例是一种场景的文本化表现方式,使用叙述性的文本来描述场景。以用例为核心,围绕用例开展活动的软件开发方法被称为用例驱动的软件开发方法。

19、企业建模:企业建模是以使用产品的组织团体为系统的环境,进行分析。它主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等。企业建模利用企业的目标、任务、策略、资源等来刻画组织的行为,并依此来发现组织开发系统的目的,建立系统的业务需求。

20、过程建模:过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程的集合,其中一些由人来执行,另一些由软件系统来执行。过程建模使用的主要技术有上下文图、数据流图、微规格说明和数据字典等。

21、上下文图:上下文图是DFD最高层次的图,是系统功能的最高抽象,它将整个系统看做是一个过程,这个过程实现系统的所有功能。上下文图中存在且仅存在一个过程,表示整个系统。这个单一的过程通常编号为0。

26、交互图(UML行为模型):交互图用于描述在特定上下文环境中一组对象的交互行为,该上下文环境就是被实现用例的某个场景。所以,交互图通常描述的是单个用例的典型场景。交互图中的每一个交互都描述了环境中的对象为了实现某个目标而执行的一系列消息交换。

28、基线:基线是已经通过正式评审和批准的规格说明或产品,可以作为进一步开发的基础,并且只有通过正式的变更控制过程才能修改它。

29、需求基线:需求基线(Requirements Baseline)就是被明确和固定的需求集合,是项目团队需要在某一特定产品版本中实现的特征和需求集合。已经通过正式评审和批准的规格说明或产品,它可以作为进一步开发的基础,并且只有通过正式的变更控制才能修改它

30、需求跟踪:需求跟踪是一种有效的控制手段,能够在涉众的需求变化中协调系统的演化,保持各项开发工作对需求的一致性。需求跟踪是以软件需求规格说明文档为基线,在向前和向后两个方向上,描述需求以及跟踪需求变化的能力,分为前向跟踪(Pre—Traceabmty)和后向跟踪(Post—Traceability)两种。

3.规格说明:规格说明是解系统为满足用户需求而提供的解决方案,规定了解系统的行为特征。

4.用户需求:就是执行实际工作的用户,对系统所能完成的具体任务的期望,描述了系统能够帮助用户做什么。

5.涉众:软件系统的涉众可以定义为:所有能够影响软件系统的实现,或者会被实现后的软件所影响的个人和团体。

7.文档审查:是一种传统的需求获取方法,是针对文档进行的需求获取活动

8.用例:在系统和外部对象的交互当中所执行的行为序列的描述,包括各种不同的序列和错误的序列,它们能够联合提供一种有价值的服务

10.微规格说明:是一种被用来描述过程处理逻辑的技术,主要有三种:a.结构化英语b.行为图c.决策表/树

11.交互图:交互图是用于描述在特定上下文环境中的一组对象的交互行为,该上下文环境就是被实现用例的某个场景