软件需求工程考试复习资料：需求MyReview.docxVIP

第二章复习题：IEEE需求定义：（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。你的认知：问题域：当现实的状况与人们期望的状况产生差距时，就产生了问题。要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain）软件系统通过影响问题域，能够帮助人们解决问题，称为解系统共享现象：系统交互：需求是用户对问题域当中的实体状态或事件的期望描述问题域自治的规律性称为问题域特性明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征描述明确的问题域特性E; 定义良好的系统行为S ; 预期的需求R需求工程的目的就是根据E，构建S，使得需求工程的困难之处：（1）不存在描述明确的E；（2）不存在确定的针对S的评估标准R；（3）是一个创造性的过程。需求工程的主要工作需求开发,确定R 研究问题背景，描述问题域特性E 构建解系统，描述解系统行为S，使得4.功能需求（Functional Requirement）：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。性能需求（Performance Requirement）：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。质量属性（Quality Attribute）：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。对外接口（External Interface）：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。约束进行系统构造时需要遵守的约束，例如编程语言、硬件设施等系统需求分类：硬件，软件，其他5.业务需求：系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision）特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么直接用户间接用户对所有的用户需求，都应该有充分的问题域知识作为背景支持特性模糊、不清晰多特性混杂多逻辑混杂系统需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么直接用户间接用户对所有的用户需求，都应该有充分的问题域知识作为背景支持特性模糊、不清晰多特性混杂多逻辑混杂6.完整性R2.5-1：系统应该允许被扩展。（更好）R2.5-2：系统的调度算法应该允许被扩展正确性真实的反映用户的意图必须请需求的提出者予以确认精确性描述仅包含必要的信息简洁、清晰（不好）R2.5-3：在实现之后，系统的调度算法应该允许被扩展可行性由开发人员进行检查需要进行一定的分析和研究，而不是单纯的凭借经验和直觉必要的时候要通过开发原型来加以验证必要性满足用户的业务需求所必需的无歧义每一项需求都应该有而且只能有一种解释定义一个可以共同理解的词汇表（Glossary）可验证通过分析、检查、模拟或者测试等方法能够判断需求是否被满足不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要让需求具体化小心形容词和副词的使用避免程度词的使用7.常见问题：需求并没有反映用户的真实需要用户在表达自己的需要时，可能会在潜意识下进行一定的加工发现问题背后的问题在人际交流当中，信息会发生自然的衰减，甚至扭曲检查和确认模糊和歧义的需求无意中写出模糊和歧义的需求定义往往是因为选词造句不当为项目中重要的词汇建立一个公共的可共同理解的词汇表有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户在项目前景的指导下，促进用户之间的协商解决明显的信息遗漏明显的信息遗漏，其主要原因在于项目的范围定义不当加强对业务需求的处理不明显的信息遗漏，往往是因为相关信息难以发现该类问题是最难以解决的问题，只能靠需求工程师的经验来加以避免不必要的需求其一是用户将之作为和开发人员谈判的筹码谈判技巧其二是用户在交流当中，用户总是倾向于表达各种各样的需要根据业务需求进行用户需求的过滤和选择其三是需求开发人员“画蛇添足”保持以用户为中心案例题：第三章思考题：第四章思考题：需求获取内容：在项目