湖科需求工程还有半天怎么办？上个厕所就够了

选择题10个20分
判断题10个10分
简答题题：4个每个5分
画图：50 预测范围：实验搞明白，书上就是目标模型，加十四章的一堆鸟图
只要厕所不扎堆，99不是梦

第一章

1.1.2软件的模拟特性

软件的模拟特性来源于其知识载体的特性：软件在运行中表现出来的特性、行为应该和应用的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件”模拟”了现实.

1.2.1需求工程简介

什么是需求工程？
定义1：简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记
录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。
定义2：从细节来说，需求工程是软件工程的一个分支，它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系

1.2.1.2.需求工程基本活动

需求工程基本活动：

• 需求获取的目的是从项目的成略规划开始建立的最初原始需求。为此,它需要研究系统将来的应用环境,确足系统的涉众，了解现有的问题,建立.新系统的目标,获取为支持新系统目标而需要的业务过程细节和具体的用户需求。
• 需求分析的目的是保证需求的元整性和一致性。它从需求获取阶段输出的原始需求和业务过程细节出发,将目标、功能和约束映射为软件行为,建立系统模型,然后在抽象后的系统模型中进行分析,标识并修复其中的不一致缺陷,发现并弥补遗漏的需求。
• 需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来。在文档中,可以使用非形式化的文本(如自然语言)描述,也可以使用半形式化的图形语言,如统一建模语言(Unified Modeling Language ,UML)描述,还可以使用形式化的语言(如Z语言)描述。描述的结果文档是接下来将被提交进行需求验证的软件需求规格说明。
• 需求验证是需求开发中的最后一个活动。它的首要目的是保证需求及其文档的正确性,即需求正确地反映了用户的真实意图;它的另一个目标是通过检查和修正,保证需求及其文档的完整性和一致性。需求验证之后的需求及其文档应该是得到所有涉众一致同意的软件需求规格说明,它将作为项目规划、设计、测试、用户手册编写等多个其他软件开发阶段的工作基础,对帮助项目开发人员建立共同的前景具有重要作用。

1.3.4.需求工程师要不要创新

在表面上看,需求工程师的工作只是捕获涉众的想法并忠实的转述给开发者,这使得需求工程师似乎不需要创新能力,其至于应该抵制创新以与涉众促持一致。但事实上,是否具备创新能力往往是判断一个需求工程师是否出色的必要条件。

需求工程师的创新表现在两个方面:

• 软件系统并不仅仅是模拟现实,还要让现实变得更好。这需要需求工程师以现实为基础构思现实中不存在的软件解决方案,这是一种最基本的创新能力,虽然幅度不是那么明显。[ Maiden 2007]还发现,涉众在描述现实时,往往会受到现实过度细节的约束或者对抽象的概念解释不清,这时就需要需求工程师运用创新能力,剥离细节约束或者丰富抽象概念细节,建立更好的软件解决方案。
• 出色的需求工程师往往还会给出具有飞跃意义上的创新[Robertson 2002],如最早的搜索引擎产品、电子产品等概念创新。需要认识到的是,这些创新开个是脱离现实随意构思的与涉众不同的想法,而是需要需求工程师敏锐地洞察现实才能实现的创新。它的基础是潜在需求——涉众自己都没有认识到但事实上非常需要的东西。所以,需求工程师的创新并没有脱离涉众,而是更积极地与涉众保持了一致。

第二章

2.2.5需求规格说明

因为解系统解决问题的方法是改变共享知识.影响问题域的运行.进而满足用户的需求。所以需求规格说明主要包括两部分(如图2-5所示):对共享现象(模型)的描述和对系统对共享现象所施加的操作的描述。这也是软件系统中最为核心的两个部分:数据与功能。

2.2.2问题域的理解

软件系统在应用于现实之后，就成为现实世界的一个部分。当然，软件系统不会也不需要与整个现实世界互动，它只需要与现实世界中的一部分互动即可。这部分就是问题的发生地，也是问题解决的基本范围——解决问题必须涉及的事件和事物，将他们称为问题域。

软件系统通过影响问题域帮助人们解决问题，所以称之为解系统。

2.3需求和问题都有层次性

1.业务需求：针对整个业务的期望

 业务需求是抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标

 它描述了组织为什么要开发系统 。

2.用户需求：针对具体业务的期望

 执行实际工作的用户对系统所能完成的具体任务的期望，

 描述了系统能够帮助用户做些什么。

 其基本表达方式为“XX用户可以使用系统完成XX任务”

3.系统级需求：针对用户与系统一次交互的期望

 业务需求描述了系统的目标与效益，适合决策者。用户需求描述了具体任务，适合用户；它们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供响应。

 系统级需求的典型形式是“系统可以XXX”或者“在XX用户提出XX请求时，系统应该XXX”。

2.4.1.2严格意义上的软件需求分类

• 需求功能：和系统主要的工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
• 性能需求：系统整体或其组成部分应该拥有的性能特征，如CPU使用率和内存使用率等。
• 质量属性：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，如可靠性程度和可维护性程度。
• 对外接口：系统和环境中其它系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等
• 约束：进行系统构建时需要遵守的约束，如编程语言和硬件设施等。

4.优秀需求的特性（完备，正确等）

完备性、正确性、可行性、必要性、无歧义、可验证

第三章

3.1需求工程过程概述

过程是一组相关活动的集成,通过这些活动的执行,可以完成一项任务或者达到一个目标。需求工程过程是系统开发中需求开发活动的集成,它以用户所面临的业务问题为出发点进行分析和各种转换,最终产生一个能够在用户环境下解决用户业务问题的系统方案,并将其文档化为明确的规格说明。

3.3需求开发的过程是并发和迭代的

需求开发过程：需求获取>需求分析>需求规格说明>需求验证
迭代：由于需求开发与软件开发过程中存在大量的不确定性，甚至是软件开发中不确定性最多的一个阶段，所以需求开发与软件开发应该是迭代的。
并发：需求开发不仅是迭代的，而且他的两个重要活动——需求获取与需求分析还是交织的，所以实践中很难准确区分两者的工作量。更进一步地说，他的各个活动是并发的。

3.6需求方法与软件开发方法是否适配更能影响成败

答案是会。需求开发过程之所以对后续软件开发过程有重要的影响，并不仅仅是因为它的结果制品——需求——是后续开发过程的工作基础，更要认识到需求开发过程中还会产生很多正性信息（如前景与范围定义、涉众描述、分析模型、需求特征描述等）。如果单纯从产生软件需求规格这个任务来看，这些正性信息都是不必要的，但他们对后续软件开发过程的影响则是很明显的。

第四章

4.5获取信息的来源

在需求获取中,信息的主要来源包括以下几方面。
①涉众:包括用户、客户、领域专家以及市场人员、销售人员等其他用户替代源。
②硬数据:包括登记表格、单据、报表等定量文档,以及备忘录、日志等定性文档。
③相关产品:包括原有系统、竞争产品及协作产品(和解系统存在接口的其他软件系统)。
④重要文档:包括原有系统的规格说明、竞争产品的规格说明、协作产品的规格说明及客户的需求文档(委托开发的规格说明、招标书)。
⑤相关技术标准和法规:包括相关法律、法规及规章制度,行业规范、行业标准及领域参考模型。

第五章

5.3目标分析

作为一种实践方法,问题分析将每一个问题都独立对待,这使得它易于操作但却只能适用于简单情况,因为复杂情况下的不同问题之间会存在相互依赖关系。
相比之下,目标分析使用目标建模技术作为基础,能够处理问题、目标、特性、角色和任务等各种因素的相互依赖关系。

5.3.2.1目标的分类（功能非功能，软硬目标）

• 功能目标是期望系统提供的服务
• 非功能目标是期望系统满足的质量
• 软目标是指无法清晰判断是否满足的目标，如关于可维护的目标
• 硬目标是指那些可以通过一些技术确认其是否满足的目标，如关于性能指标的目标

5.3.3目标分析过程

5.6系统边界定义

系统边界是系统与环境互动的界限,定义系统边界可以明确系统需要满足的与外界的交互行为,从而从宏观上界定了系统的功能概要。
系统边界是需求工程后期阶段需求分析活动的起始模型.后期的需求分析可以看成是逐一细化系统边界中的对外交互行为的活动。
结构化方法中使用上下文图作为系统边界定义模型.面向对象方法中使用系统用例图作为系统边界定义模型。二者的区别是:上下文图更注重系统与环境的输入/输出数据流交互;系统用例图更注重系统与环境的功能性(目的性、任务性)交互。

1.问题分析与系统边界定义
如果前景与范围定义活动主要使用问题分析方法,那么就可以得到每个问题的解决方案边界,将它们合并(叠加、汇总、补充)起来就是整个系统的边界定义。
2.目标分析与系统边界定义
如果前景与范围定义活动主要使用目标分析方法,那么可以从目标模型中抽取系统的边界定义:

• 分配主体包括“将要构建的系统”和系统环境(涉众、硬件、其他系统等)的底层目标,这往往意味着存在系统与环境的互动,它们就是系统边界定义要考虑的目标,可以称为边界目标。
• 分析边界目标所覆盖的场景和操纵的操作(任务),可以得到系统用例,并据此建立面向对象的系统边界定义——系统用例图。
  公
• 分析边界目标所关注的数据对象,可以得到系统与环境的输人/输出流,并据此建立结构化的系统边界定义——上下文图。

3.业务过程分析与系统边界定义
如果前景与范围定义活动使用了业务过程分析方法,那么分析的业务过程可以帮助完善系统边界的定义:

• 活动图的每一个动作都可能(未必一定)是一个用例,可以据此完善面向对象方法的系统用例图。
• 活动图的每一个对象流都可能(未必一定)是一个系统与环境的输入/输出数据流,可以据此完善结构化方法的上下文图。

第六章

6.1什么是涉众

定义：所有对软件系统开发和应用有发言权和决定权的人统称为涉众

6.2涉众分析

关于涉众分析工作的差异性，可以借用对信息系统的复杂度的分类加以说明。按照复杂度，将信息分成4种类型。

• 小型系统
• 组织级系统
• 战略信息系统
• 组织间系统

涉众分析过程
①涉众识别:寻找软件系统的涉众类别。
②涉众描述:

• 描述不同涉众类别的简单特征,包括个人特征和工作特征。
• 描述不同涉众类别的复杂特征,包括关注点和兴趣取向,重要性和影响力,输赢条件和受影响程度。

③涉众评估:

• 为涉众类别划分优先级。
• 评估不同涉众类别的风险,化解风险。
• 分析涉众冲突,实现共赢。

④涉众代表选择:从每种涉众类别中选择代表。
⑤制定涉众代表参与需求开发乃至软件系统的参与策略。

6.3.2.2检查列表方法

在实践中人们总结出了常见的涉众类别列表，并据此指导涉众识别工作，称为检查列表方法

常见的涉众类别
用户、客户、开发者、管理者、领域专家、政府力量、市场力量、维护人员

6.5涉众评估

在涉众描述之后可以得到大量关于涉众的信息,这些信息分别描述了涉众某些方面的特征。涉众评估是将这些孤立的描述信息联合起来进行分析,以得到更深层次信息的过程。常见的涉众评估包括优先级评估、风险评估和共赢分析。

6.5.1优先级评估

在进行优先级评估时,要优先考虑涉众的基本特征,尤其是任务特征,因此出钱购买系统的客户(可能不是用户)和政治影响较大的涉众并不定就会有比较高的优先级。例如,在区分用户群体优先级时,使用系统更多或更重要功能、使用系统更加频繁、规模更大的用户群体可能拥有更高的优先级。对任务的分析和比较要联系项目的业务需求来进行。

根据人数和任务

根据力量和兴趣

6.8使用目标模型进行涉众分析

基于拥有者的目标模型,可以更好地执行涉众评估:
1.根据目标的优先级安排主体的优先级。
2.根据目标的风险确定主体的风险。
3.根据目标分析深入分析主体间的互动

• 根据目标冲突可以发现深层次的主体冲突。
• 根据目标的冲突情况协商解决主体间的冲突。

第七章

7.2.3用例/场景的层次性

7.3用例/场景模型

7.3.1.3用例/场景的目的

第八章

8.2.2问题类型

开放：
开放式问题的开放式一词意指被会见者对答复的选择可以是开放的和不受限制的，他们可能答复两个词，也可能答复两段话。

• 优点：会让会见者感到自在；会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；提供丰富的细节。
• 缺点：提此类问题可能会产生太多不相干的细节；面谈可能失控；开放式的回答会花费大量的时间才能获得有用的信息。

封闭：
封闭式问题对答案有基本形式，被会见者的回答是受到限制的。

• 优点：节省时间；切中要点；保持对面谈的控制；快速探讨大范围的问题；得到贴切的数据
• 缺点：使被会见者厌烦；得不到丰富的细节；不能和面谈者建立友好关系。

如何选择：当会见者对事实和问题掌握比较有限则选择开放式问题，否则封闭式

8.5面谈的类别

面谈类别主要分三类：结构化面谈、半结构化面谈和非结构化面谈。
结构化面谈：会见者按照事先的问题和结构来控制面谈。通常是一些比较确定的或空间选择有限的信息。
半结构化面谈：会见者按照事先的问题和结构来控制面谈，但在面谈过程种，会见者可以采取一些灵活的策略进行调整问题结构
非结构化面谈：没有事先准备直接进行面谈

8.6面谈的优缺点

面谈的优点：
1.面谈的开展条件较为简单，经济成本较低；
2.能获得包括事实、问题、被会见者观点、被会见者态度和被会见者信仰等各种信息类型在内的广泛内容；
3.通过面谈，需求工程师可以和涉众（尤其是用户）建立相互之间的友好关系；
4.通过参与面谈，被会见者会产生一种主动为项目做出贡献的感觉，提高涉众的项目参与热情。

面谈的缺点和局限性：
1.面谈比较耗时，时间成本较高；
2.在被会见者地理分散的情况下往往难以实现面谈；
3.面谈参与者的记忆和交流能力对结果影响较大，尤其是面谈的成功较高的依赖于需求工程师的人际交流能力；
4.交谈当中常见的概念结构不同、模糊化表述、默认知识、潜在知识和态度偏见等各种问题在面谈中都不可避免，进而影响面谈的效果，导致产生不充分的、不相关的或者错误的数据；
5.在会见者不了解被会见者认知结构的情况下，面谈不可能取得令人满意的效果。

第九章

9.1.1不确定性

面对不确定的知识，涉众是自己是无法解释清楚的，自然也不可能通过面谈告知需求工程师，这就要求需求工程师想办法解决不确定性，主要手段就是原型

9.2.1原型基本过程

①确定原型需求。搞清楚为什么要开发原型,拥有的起始点是什么,期望的结束标准是什么?
②原型开发。依据原型的需求特点和开发目的,以最低的成本建立初始原型。
③原型评估。对上一阶段产生的原型进行评估,根据评估者的反馈判断原型是否满足结束标准。评估者一般是用户和开发者。
④原型修正。如果已经建立的原型达到了目的,就结束原型方法过程;否则根据评估者反馈的不足进行原型调整,调整完成后准备再次进行原型评估。

第十章

10.1.1概述

常见的观察方法：
1.采样观察（Sampling Observation）：传统、简单的观察方法。
2.民族志（Ethnography）：深入到用户中，长期、浸入式的观察方法。
3.话语分析（Discourse Analysis）：对用户之间的交谈行为的观察。
4.协议分析（Protocol Analysis）： 对用户任务的观察。
5. 任务分析（Task Analysis）：专门针对人机交互行为进行的观察。

观察方法的适用情况：
1.当用户无法完成主动的信息告知，或者用户与需求工程师之间的语言交流无法产生有效的结果时，采用观察方法。
2.用户无法完成主动告知的原因归结于事件的情景性（情景性是指某些事件只有在和他们发生时的具体情景环境联系起来才能得到理解）。

第十一章

11.1.1.2两个世界三个模型

1.计算世界与计算模型 （不适合需求建模）
需求分析阶段不适宜建立形式化的计算模型
2.问题世界与业务模型（不适合需求建模）
使用了业务描述的方式，具有非形式化特征
非形式化特征使得它不适合于进行需求建模
3.软件分析模型
介于计算模型和业务模型二者之间的模型形式 使用了计算模型的组元形式 在组元的表现上采用了业务模型的表现方式

第十二章

12.1过程建模概述

过程建模就是分析需求获取活动获得的信息,发现系统的功能及其与外界的交互,建立能够实现系统功能的过程分解结构,形成系统的过程模型,并用图形的方式将过程模型描述出来。同时,过程建模也需要定义系统中涉及的数据的结构

12.2.1数据流图基本元素

数据流图是过程模型所使用的主要建模技术。他在建模时所使用的基本模型元素有四种：外部实体、过程、数据流和数据存储。最终的数据流图会以图形的方式表现出来，他的表示法主要有两种：DeMarco-Yourdon表示法和Gane-Sarson表示法。

1.外部实体

外部实体是指处于待构建系统之外的人、组织、设备或其他的软件系统，他们不受系统的控制，开发者不能以任何的方式操纵他们。一般用矩形加以描述.

在实践中，常见的外部实体有:

• 从待构建系统中获取数据或称为为其提供数据的组织，如供货方式和销售放等
• 需要和待构建系统交互的个人。他们可能是待构建系统组织的成员，也可能是待构建系统组织之外的人员，如顾客或办事员等。
• 需要和待构建系统交换数据的其他软件系统

2.过程

过程是指施加于数据的动作或行为，他们使数据发生变化，包括被转换、被存储或被分布。

3.数据流

数据流是指数据的运动，它是系统与其环境之间或者系统内两个过程之间的通信形式。数据流程图的数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数据输出。

4.数据存储

数据存储是软件系统需要在内部收集、保存，供日后使用的数据集合。如果说数据流描述的是运动的数据，那么数据存储描述的就是禁止的数据。

5.实例

12.2.2使用规则

12.2.3分层结构

12.3逻辑说明-微规格说明（决策树决策表简单看）

12.4数据字典

第十三章

13.2.1.2概念实体与逻辑实体

第十五章

15.2.2需求规格说明文档的类型

第十六章

16.2.1.4评审的类型

16.2.1需求评审