第二章
复习题：
1. IEEE是怎样定义需求的？从中你可以得到什么认识？ IEEE对需求的定义：
（1）用户为了解决问题或达到某些目标所需要的条件或能力；
（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力； （3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。
为了融合不同群体的看法，IEEE的定义当中同时包括了用户的观点（第一种条件和能力）和开发者的观点（第二种条件和能力），但是即便如此，不同群体的人们也很难就IEEE的定义进行一直和准确的解读，因为需求概念的内涵和外延都非常丰富。
2. 解释下列名词：问题域、解系统和共享现象，并结合它们的含义说明软件系统是如何与现实世界形成
互动的？ 问题域： ? ? ?
当现实的状况与人们期望的状况产生差距时，就产生了问题。
要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。
这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain） 软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。 共享现象： ?
软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性。 ?
换句话说，软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。 ? ?
问题域中的某些信息能够和模型中的信息建立映射关系
这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象 解系统：
共享现象就是问题域和解系统实现交互和互相影响的途径与接口，问题域和解系统都通过改变这些共同知识来影响对方，或者通过认同这些共同知识的改变来接受对方的影响。
3. 解释下列名词：需求、规格说明、问题与特性和约束，并结合它们的含义说明需求工程的主要任务是
什么？
需求是用户对问题域当中的实体状态或事件的期望描述。
1
直接需求是可以通过更改共享现象被满足的需求;
间接需求是需要修改共享现象，同时连锁影响问题域才能满足的需求。 规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。
解决方案只能通过改变共享知识，影响问题域的运行，进而满足用户的需求，所以规格说明主要包括两个部分：（1）对共享现象（模型）的描述；
（2）系统对共享现象所施加的操作的描述。
需求关注的是现实世界中的部分，软件关注的是解系统，而规格说明关注的是共享现象 问题域特性：问题域自治的规律性称为问题域特性。包括结构特性和行为特性等。 需要关注的问题域特性：
间接特性；
约束和假设：（问题域当中有些特性完全不受共享现象的影响，即完全不受解系统的影响，同时却可能很大程度上影响共享现象，影响解系统，甚至关乎解系统的成败。这些特性被认为是解系统对环境的依赖特性。当这些特性非常明确时，称之为约束；不明确时，需要限定特性的变化范围，称之为假设）
4. 需求有哪些常见的类别？功能需求和非功能需求有什么差异？ 需求的分类1：
? 功能需求（Functional Requirement）：
? 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行
的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
? 性能需求（Performance Requirement）：
? 系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
非功能需求? 质量属性（Quality Attribute）：
? 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程
度、可维护性程度等。
? 对外接口（External Interface）：
? 系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等
等。
? 约束
? 进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
需求的分类2：
2
系统需求（System）：硬件需求（Hardware）、软件需求（Software）、其他需求 功能需求和非功能需求的差异：
除功能需求之外的其他四种类别需求又被统称为非功能需求。在非功能需求当中，质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。
5. 描述业务需求、用户需求和系统（级）需求的区别与联系。 ?
业务需求：
系统建立的战略出发点，表现为高层次的目标，它描述了组织为什么要开发系统
为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）
参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope） ?
用户需求：
执行实际工作的用户对系统所能完成的具体任务的期望 描述了系统能够助用户做些什么。 直接用户、间接用户
对所有的用户需求，都应该有充分的问题域知识作为背景支持 特性：模糊不清晰、多特性混杂、多逻辑混杂 ?
系统需求：
用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求；系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。 用户需求---->系统需求的过程：
首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
6. 优秀的需求哪些特性？试为每一个特性都举出一个不符合的示例。 优秀的需求特性： 1)
完整性：不需要做更多的扩展就可以充分的说明用户所需要的系统功能。
每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息
R6（不完整）：系统应该允许被扩展
R7（完整、较R8精确）:系统的调度算法应该允许被扩展 2) 3) 4)
正确性：真实的反映用户的意图；必须请需求的提出者予以确认 精确性：描述仅包含必要的信息；简洁、清晰
R8（不精确）：在实现之后，系统的调度算法应该允许被扩展。
可行性：由开发人员进行检查
需要进行一定的分析和研究，而不是单纯的凭借经验和直觉 必要的时候要通过开发原型来加以验证
示例：保证系统核心功能可以7×24小时连续运行 5) 6)
必要性：满足用户的业务需求所必需的
无歧义：每一项需求都应该有而且只能有一种解释
3
定义一个可以共同理解的词汇表（Glossary）
7)
可验证：通过分析、检查、模拟或者测试等方法能够判断需求是否被满足 示例：
实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化； 实现工作流程合理化、高效化，决策支持科学化、准确化；
统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。
不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要：让需求具体化、小心形容词和副词的使用、避免程度词的使用
7. 列出需求草稿中常见问题，需求工程师如何消除这些错误？ 1) 需求并没有反映用户的真实需要
原因1：用户在表达自己的需要时，可能会在潜意识下进行一定的加工
进行问题分析，发现问题背后的问题
原因2：在人际交流当中，信息会发生自然的衰减，甚至扭曲
在需求传递给开发人员之前，请需求提出者进行仔细的检查和确认
2) 模糊和歧义的需求
原因1：无意中写出模糊和歧义的需求定义往往是因为选词造句不当
为项目中重要的词汇建立一个公共的可共同理解的词汇表
原因2：有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户
在项目前景的指导下，促进用户之间的协商解决
3) 明显的信息遗漏
原因1：明显的信息遗漏，其主要原因在于项目的范围定义不当
加强对业务需求的处理
原因2：不明显的信息遗漏，往往是因为相关信息难以发现，如系统的环境依赖信息
该类问题是最难以解决的问题，只能靠需求工程师的经验来加以避免
4) 不必要的需求
其一是用户将之作为和开发人员谈判的筹码；开发人员代表的谈判技巧 其二是用户在交流当中，用户总是倾向于表达各种各样的需要
开发人员先定义明确的业务需求，根据业务需求进行用户需求的过滤和选择 其三是需求开发人员“画蛇添足”，添加“用户肯定会喜欢”的功能
需求开发人员要保持以用户为中心
案例题：
1. 解答一：（1）她没有仔细认真地分析问题；
（2）她没有及时跟相关人员交流信息，没能把握住有价值信息； （3）她没能及时跟公司员工交流，引用过时的文件结构； （4）她没有仔细研究分析新引进的系统的性能需求是否满足； （5）她没有仔细研究新引进的系统的功能需求是否满足； （6）她没有仔细研究引进的系统的质量属性，对外接口是否满足。
解答二：业务需求中没有和高层管理人员沟通好；她提出的用户需求没有和用户（自己的职员）沟通好，也没有向开发人员提出可行性、质量属性（可扩展性）等。
解答三：没有获得高层支持；财政部支持；下属抵制使用；信息不流通，文件使用不一致；要求的图形报告没有；不知道是否能修改
4
2. 业务需求：保持财务业绩与它的发展同步；有效地追踪客户账单和收据；降低成本；实行特价时能够
知道是否有利可图，是否带动去他的销售；增加回头客。 解答：业务需求如BR。
BR1：实现客户账单和收据的有效追踪；
BR2：实现产品特价时的利润和相关销售情况检查； BR3：实现一个客户数据库。
3. 先定义明确的业务需求，获得开发系统的必要性，根据业务需求，协调涉众的立场，限定问题的范围，
指导用户需求的获取过程：和涉众沟通（即向业务人员了解相关的业务知识，业务流程；再和销售人员沟通，由于他们的顾客是流动的，不确定的，只能通过销售人员间接获取来自于顾客的用户需求，了解他们的背景和习惯），最后根据业务需求对用户需求进行过滤和选择，得到充分必要用户需求。 4. UR1：使用户可以根据系统的明确操作提示做出正确的反应；
UR2：用户插入银行卡后需要输入密码，得到验证后才可进行有效的具体操作； UR3：在用户进入系统后，可以选择使用查询金额、存取现金、转账的功能； UR4：用户能够正确、安全地退出系统。
5. SR1：（1） 系统显示用户插入磁卡的动态图像，正确标明插卡位置；
（2）用户根据提示，正确插入磁卡；
（3）系统读取磁卡卡号，界面显示输入密码的提示；
SR2：（1）对用户输入的密码，系统自动进行字符匹配； （2）匹配正确的话，进入具体操作界面；
（3）匹配不正确的话，警告密码不正确，并提示再次输入；
SR3：（1）若用户选择查询金额图标和查询金额币种，系统读取银行数据库中用户对应的信息，反馈在
用户界面上；
（2）若用户选择取款图标和金额币种及输入金额数目，系统读取用户请求，接受金额，修改数据
库中该用户对应的信息，并提示成功与否；
（3）若用户选择存款图标和金额币种，系统弹出存款框，用户放入现金，系统接收现金并辨认真
伪，并反馈存入金额数目，得到用户确认后，修改数据库中该用户对应的信息，并提示成功与否；
（4）若用户选择转账图标和金额币种并输入对方账号和转账金额数目，系统读取用户请求，修改
数据库中所涉及到的用户的信息，并提示成功与否；
SR4：（1）用户选择退出图标； （2）系统提示拔卡信息。
6. 性能需求：在用户点击图标后，系统在3s内作出反应。
质量属性：易用、可靠、安全、容错、可恢复、可维护。
约束：当用户输入密码次数等于3次后就不再提示输入密码，并自动锁定银行卡。
第三章
思考题：
1. 除了需求开发的四个活动和需求管理活动之外，需求工程中还有没有需要执行的活动？如果有的话，
它们是哪些活动？给出你的理由。 有。项目管理（人力、资金的管理）、过程管理
（还有其他一些活动，例如：过程管理活动和项目管理活动。过程管理活动是跟踪项目开发过程，记录项
5
大学计算机软件需求工程复习2
