目录
大三上需求工程老师划重点
第一章
（主要是选填）
1.
软件的模拟特性定义
软件的模拟特性来源于其知识载体的特性：软件在运行中表现出来的特性、行为应该和应用的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件”模拟”了现实.
2.
需求工程的定义
简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。
或
从细节来看，需求工程是软件工程的一个分支，它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
3.
需求工程的三个主要任务（三点的第一句话）
①需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，也即要同时说明软件需要“做什么”和“为什么”需要做。
②需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程 为重要的成果，是项目规划、设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。
③现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。
4.
基本活动 图1-6
5.p13
第二段需求获取目的，需求分析的目的，需求规格说明的目的，需求验证的目的
（然后呢这就是第一章的大概的一个考点你会考需求的定义或者是一些填空需求的定义）
第二章
1.
（简答）p23
需求定义三点
IEEE 对需求的定义为：
①用户为了解决问题或达到某些目标所需要的条件或能力。
②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备
的条件或能力。
③对①或②中的一个条件或一种能力的一种文档化表述。
2.
（选填）二十四页问题域和解系统的定义
软件系统在应用于现实之后，就成为现实世界的一个部分。当然，软件系统不会也不需要与整个现实世界互动，它只需要与现实世界中的一部分互动即可。这部分就是问题的发生地，也是问题解决的基本范围——解决问题必须涉及的事件和事物，将他们称为
问题域
。
软件系统通过影响问题域帮助人们解决问题，所以称之为
解系统
。
3.p28
需求的分层，图2-6
的三层（每层对应内容及含义、表达方式等）
1.业务需求：针对整个业务的期望
业务需求是抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标
它描述了组织为什么要开发系统 。
2.用户需求：针对具体业务的期望
执行实际工作的用户对系统所能完成的具体任务的期望，
描述了系统能够帮助用户做些什么。
其基本表达方式为“XX用户可以使用系统完成XX任务”
3.系统级需求：针对用户与系统一次交互的期望
业务需求描述了系统的目标与效益，适合决策者。用户需求描述了具体任务，适合用户；它们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供响应。
系统级需求的典型形式是“系统可以XXX”或者“在XX用户提出XX请求时，系统应该XXX”。
4.p35
严格意义上的需求分类
功能需求
性能需求
质量属性
对外接口
约束
除了功能需求外，其他4项是非功能需求。
5.p44
优秀需求的特性
小标题六个
完备性 正确性 可行性 必要性 无歧义 可验证
6.
（简答）p47
不必要需求的原因
产生不必要需求的原因主要是：
其一是用户将一些不必要的需求作为和开发人员谈判的筹码，然后通过自己对不必要
需求的要求而在和开发人员的谈判当中取得真正想要的利益，例如金钱。对此问题，唯一需
要的就是开发人员代表的谈判技巧。
其二是用户在交流中，总是害怕信息有所遗漏，并因此产生不利后果，因此用户总是倾
向于表达各种各样的需要。要解决这个问题，就需要开发人员在进行用户需求的获取之前，
先定义明确的业务需求，然后根据业务需求进行用户需求的过滤和选择。
其三是需求开发人员“画蛇添足”，添加“用户肯定会喜欢”的功能，该类功能既会
造成项目额外的耗费，又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用
户为中心。
第三章
1.p53
三个成果文档
项目前景和范围文档、用户需求文档、需求规格说明文档
2.p55
涉众分析概念
这些具有不同特性的用户对系统的需求往往也是不一样的，因此要想让选取的少数代表完整地表达用户的声音，就需要将用户分成不同的类型,然后在理解每种类型用户特征的情况下为其选择合适的用户代表。这个过程称为涉众分析。
第四章
1.p80
复杂获取活动五个步骤，获取的三种内容内容小标题
1） ①确定待获取信息的内容;
②确定待获取信息的来源;
③确定应采用的获取方法;
④ 执行获取;
⑤记录成果。
2）获取内容主要有三种：需求、问题域描述、环境与约束
2.p81
获取信息的来源五个，
获取信息的方法
（每个地方基本分类掌握，尤其是模型驱动方法）
获取信息的来源
：①涉众:包括用户、客户、领域专家以及市场人员、销售人员等其他用户替代源。②硬数据:包括登记表格、单据、报表等定量文档，以及备忘录、日志等定性文档。
③相关产品:包括原有系统、竞争产品及协作产品(和解系统存在接口的其他软件系统)。④重要文档:包括原有系统的规格说明、竞争产品的规格说明、协作产品的规格说明及客户的需求文档(委托开发的规格说明、招标书)。⑤相关技术标准和法规:包括相关法律、法规及规章制度,行业规范、行业标准及领域参考模型。
获取信息的方法：
1.传统方法
传统方法在需求获取中起着基础的作用。
分类：问卷调查、面谈、文档分析、文档检查、需求剥离等
2.集体获取方法
将很多涉众有机、有效组织在一起，通过讨论发现需求
方法1.头脑风暴（Brainstorming）发挥各自的聪明才智及想象力
2.专题讨论会（Workshop）主题要明确，有目的、计划组织领域专家及有关人员参加
3.JAD联合应用开发、
4.JRP联合需求计划等
3.原型
在需求模糊和不确定性的情况下，可利用原型方法使问题清晰、明确和有效。原型方法在此阶段起着重要的作用。
方法：如低保真、高保真等原型
4.模型驱动方法
首先定义一个明确的模型，模型定义了所要收集的信息类型。模型建立和完善的过程就是进行需求获取的过程。
方法：面向目标的方法（goal-oriented methods）
基于场景的方法(scenario-based methods)
基于用例的方法（use case-based methods)
5.认知方法
任务分析（Task Analysis）：
协议分析（Protocol Analysis）等
6.基于上下文的方法
重视用户在一定环境下表现出来的行为，通过分析用户行为得到信息。
常用的方法有：观察：利用需求工程师们所具备的知识，发挥其洞察力的能力
民族志（Ethnography），开会集中、主题讨论、举手表决等形式。
话语分析（Conversation Analysis），分析领域专家及专业涉众等有关提出的问题和
第五章
1.p96
前景范围定义
前景描述了产品用来做什么，以及最终产品是什么样子。
范围为项目划定了需求的界限。
2.p108
页目标的分类（掌握）
1）功能目标：功能目标是期望系统提供的服务。又包括满足型目标、信息型目标。
满足型目标 ：是对行为者请求的满足目标；
信息型目标 ：是为了保持对行为者的信息告知；
非功能目标：非功能目标是期望系统满足的质量，依据质量模型的属性细分为：
安全目标、
性能目标、
可用性目标等等
2）目标也可被分为软目标和硬目标
3.p121
问题分析目标分析特征，适应情况
问题分析方法将每一个问题、目标、特性等都看作是相互独立的，所以只能完成简单系统的前景与范围定义任务；
目标分析能够表达问题、目标、特性之间依赖关系，所以能够完成较为复杂系统的前景与范围定义任务。
4.p122
活动图定义
BPM业务流程的业务过程模型，用来建立活动图，活动图是描述业务过程和对象行为的模型，以“令牌（toke）”平衡为手段保证过程与行为中的复杂并发协同现象。
5.
一百二十四页结合图判断，规则，概念，令牌平衡
第六章
1.p145
涉众定义，信息系统四种类型小标题
1）所有对软件系统的开发和应用具有发言权、决定权的人统称为涉众。
2）按照复杂程度，信息系统分四种类型
小型系统、组织级系统、战略信息系统、组织间系统
2.p147
涉众分析过程五点（图）
3.
（简答）p150
涉众识别的方法及了解内容掌握
1）简单方法：先膨胀后收缩(Expand Shrink)
膨胀：在该阶段，需求工程师在收集到背景资料后，凭借自己的经验，尽可能多地列出涉众类别，越多越好。
收缩：在该阶段，需求工程师判断是否有两类或多类涉众的立场是一样的，将一样的多个类别进行同类合并。
优点：适用于涉众群体比较简单的系统开发。
缺点：复杂系统开发使用先膨胀，后收缩方法进行涉众识别，容易出现遗漏
2）经验方法：检查列表
优点：清晰、明确，容易操作，如果经验丰富会比较有效。
缺点：有些类别太粗，尤其是用户作为一个类别是远远不够的，没有细化方法
3）涉众网络方法
涉众网络适用于非常复杂情况下的涉众识别，保证正确性、完备性。缺点的复杂。
4.
（选）一百五十二页涉众基线定义
比较容易发现的涉众称为初始涉众，又称为涉众基线，通常包括客户、管理者和相关的投资者。
5.p154
涉众描述，个人特征和复杂特征
6.p156
涉众评估，三个方法下面的方法
1）优先级评估：User/Task矩阵、Power/Interest分布图，
2）风险评估：Power/Attitude分布图、Power/Interest分布图
3）共赢分析：建立Stakeholder/Issue关系图
7.p160
涉众采样规则四个小标题
涉众采样基本原则：完整采样:、态度积极、数量适中、比例恰当
8.p166
定量硬数据定性硬数据分类
定量硬数据：数据收集表格、统计报表
定性硬数据：整个组织的描述文档、业务指导文档、业务备忘
9.p167
硬数据采样公式，确定性因子
第七章
（做做题库选择题）
案例题有一个场景的描述
如果要复习的话一百七十三页用例，场景的定义重点就是7.3，7.3节关于用例场景一个定位什么场景呢会使用什么样的一种描述方式的一个外观啊然后呢他的一个目的根据目的的一个分类
1.p187
关系
用例图中的关系：关联、包含、扩展
第九章
1.p219
原型定义，用途分类
如果在最终的物件（final artifact）产生之前，一个中间物件（mediate artifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。
根据用途分为：1.演示原型2.严格意义上的原型3.试验原型4.引示系统原型
2.p224
原型开发方法分类（每个类别目的），224
最后一段
1）（1）探索式
探索式原型法是以缺陷需求开始继而不断调整和修正需求的原型开发方式
。探索式的原型方法通常要尽可能地调整各种设计选项（例如需求内容、软件化内容以及软件支持方式等），并比较多种设计方案下的用户反馈以得到理想的用户需求。探索式的原型方法能够帮助开发者更深入地了解用户的业务、问题和期望。
（2）实验式
实验式的原型方法初始时拥有清晰的用户需求，但是开发者对这些需求的实现方法、实现效果和可行性没有太大的把握。
实验式的原型方法需要首先定义一个对原型的评估方法，确定评估的属性（例如可行性、适用性、效率、吞吐量等），据此评估各种技术方案下的原型，明确需求的可行性和有效的技术实现方案。
（3）演化式
在演化式的原型方法中，原型的开发并不是一个独立的活动，而是整个项目的持续开发过程中的一个部分。
原型开发的初始点既有要求原型化的需求，也有项目积累下来的原型资产。积累下的原型资产所没有实现的需求，往往是清晰的需求。在开发原型时，还要能够以一个整体的方式传递给下一个原型开发过程。这个被不断传递和不断增强的原型资产将成为 终的软件系统。通过在持续开发过程中使用原型方法，可以使软件开发过程更好地处理用户需求的不断变动。
在探索式、实验式和演化式这三种原型方法中，前两种方法产生的原型往往是在经历了很多次错误的尝试之后才产生的。这些错误的尝试过程会在 终的原型产品中留下痕迹，原型中的一些代码是在错误的前提（错误的需求、错误的技术方案）下完成的，它们会使原型产品具有很差的质量，所以人们在得到正确的尝试之后往往会抛弃这些原型产品，另起炉灶。为此，
探索式和实验式方法产生的原型产品又被称为抛弃式原型
抛弃式原型的贡献不在于它的代码，而是它所包含的内容，它说明了正确的需求和正确的技术方案。因为抛弃式原型的代码是要被抛弃的，所以在建立抛弃式原型时，应该尽量花费 小的代价，争取 快的速度。为此，原型的开发者会使用一些简易的开发工具和不成熟的构造技术，忽略或简化一些和原型目标不相关的功能特征。
3.p231
原型方法的风险
1、原型方法最大的风险是成本失控
2、原型方法的第二个风险是给涉众造成错误印象
3、原型方法的第三个风险是用户可能会被原型所表现出来的非功能特性遮蔽了眼睛从而忽略了他们更应该重视的功能特性。
4. 原型方法的第四个风险是在澄清需求不确定性的同时也可能会掩盖一些用户假设，这些假设将会无从发现
第十一
章
1.p270
四个分析方法小标题特点
传统分析、结构化分析、信息工程方法、面向对象方法
传统分析
没有方法
依赖个体才智,依据个人习惯
缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构等等
结构化分析
以数据流动为中心，以DFD为核心技术，辅助ERD,STD…
信息工程
以数据知识结构为基础，ERD为核心技术，辅助DFD，STD, FDD, PD…
面向对象分析
以对象为中心，以UML（类图）为核心技术
以全面思想革新为理想，以承继结构化技术为现实
2.p280
需求细化的根本
需求细化的根本：将从问题域和业务的角度表述的用户需求等价的转化为从软件和技术的角度表述的系统级需求
3.p284
确定优先级常用方法小标题
累计投票
区域划分
Top-N
数据量化
4.
需求分析活动分为了三个阶段：需求细化、确定需求优先级、需求协商
5.
（简答）p286
需求协商应确保的三点原则
明确冲突的因素，避免情绪上的冲突
明确冲突的解决空间
确定最佳解决方案
第十四
章
1.p342
特征
可被抽象为对象两个条件：独立可确认
2.p343
对象关系
链接
对象之间相互协作的关系，描述对象之间的物理或业务联系。
导航和可见性
由a指向b的链接除了包含假设和期望因素之外，还意味着a能够在链接的指引下，正确的找到并将消息发送给b，即a可以导航到b
3.p345
类和类关系
关联
聚合与组合
继承
多态
4.p359
分类uml
交互图
UML交互图又包括：顺序图、通信图、交互概述图、时间图
第十五
章
1.
简答p392
原因，一方面另一方面和下面四点第一句话
编写需求规格说明文档的必要性：在一个复杂软件系统的开发中，编写需求规格说明文档是非常必要的。
一方面，清晰、明确、结构化的文档可以将软件系统的需求信息和解决方案更好的传递给所有的开发者。
另一方面，文档可以拓展人们的知识记忆能力。
编写需求规格说明文档的好处：
①需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。开发者和客户可以使用它作为合同协议的重要部分，涉众也可以利用它在相互间达成一致。
②需求规格说明文档可以成为项目开发活动的一个重要依据。它可以作为软件估算和项目进度安排的基础，也可以作为开发人员判断设计、测试等工作的进行是否正确的依据。
③在需求规格说明文档的编写过程中，可以尽早的发现和减少可能的需求错误，从而减少项目的返工，降低项目的工作量。
④需求规格说明文档可以成为有效的智力资产。这个智力资产可以帮助新加入的团队成员更快的融入项目，可以帮助更好地将软件产品移交给新客户，也可以帮助开发者更好地进行其他类似项目或者后续增强项目的开发。
2.p394
读者
项目管理者、设计人员和程序员、测试人员、文档编写人员、维护人员、培训人员、律师
3.p409
优秀需求规格说明文档特性
正确性、无歧义、完备性、一致性、根据重要性和稳定性分级、可验证、可修改、可跟踪
第十六
章
1.
（简答）p419
需求评审过程六点
整个评审过程可以分为6个阶段：
（1）规划阶段（planning）:作者和仲裁者共同制定评审计划，决定评审会议的次数，安排每次评审会议的时间、地点、参与人员和评审内容等。
（2）总体部署阶段（oveview）,作者和仲裁者向所有参与评审会议的人员描述待评审材料的内容，评审的目标以及一些假设，并分发文档。
（3）准备阶段（preparation）,评审人员各自独立执行检查任务。检查中发现问题会被记录下来，以准备开会讨论或者提交给收集人员。
（4）评审会议阶段（inspection meeting）,通过会议讨论，识别、确认、分类发现的错误。
（5）返工阶段（rework）,作者修改发现的缺陷。
（6）跟踪阶段（follow-up）,仲裁者要确认所有发现的问题都得到了解决，所有的错误都得到了修正。仲裁者还要判断评审是否满足结束标准，是否还需再次进行评审。
2.
（填空）需求验证的方法分类：需求评审，原型与模拟，开发测试用例，用户手册编制，利用跟踪关系，自动化分析
第十七章
1.p432
需求基线四段话好好看看考选填
2.
（简答）p440
需求的变化第一句话
需求的变化是正当和不可避免的：
问题发生了改变
环境发生了改变
需求基线存在缺陷
在实践中，下列因素也常常会导致需求变化：
用户变动
用户对软件的认识变化
相关产品的出现