1、需求工程一1.软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题2.软件开发带来的需求问题：1）对软件的开发成本和进度的估计常常不准确；2）用户对已完成的系统常常不满意；3）软件的质量不可靠；4）软件的可维护程度较低；5）软件常常没有适当的文档资料；6）软件的成本不断提高；7）软件开发生产的效率较低；3.需求工程活动包括：需求开发和需求管理； 需求开发包括：需求获取、需求分析、需求规格说明和需求验证4个部分；需求获取：目的从项目的张罗规划开始建立最初的原始需求。需求分析：目的保证需求的完整性和一致性；需求规格说明：目的将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地
2、固定下来；需求验证：目的保证需求及其文档的正确性，即需求真实地反映了用户的真实意图；以及通过检查和修正保证需求及其文档的完整性和一致性；4.软件的模拟特性：软件在运行中表现出来的特性、行为应该和应用的实际情况保持一致。5.需求工程与系统工程的关系传统的需求处理是软件工程的需求阶段；但系统化的需求工程将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到了重要的作用。需求工程处于系统的起始阶段，包括系统需求开发和软件需求开发两个部分。6.需求工程的重要性软件开发是利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的 ，定义问题就是需求工程的任务。开发软件系统最为困难的部分就
3、是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求。容易忽略需求工程重要性的地方问题广为人知 问题小而简单 第二章 1. 需求的定义：（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。2. 需求的分类功能需求：和系统主要工作相关的需求。功能需求主要表现为系统和环境之间的行为交互。业务需求：是系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统 。用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描
4、述了系统能够帮助用户做些什么。系统需求：系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么 性能需求：系统整体或系统组成部分应该拥有的性能特征。质量属性：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求。对外接口：系统和环境中其他系统之间需要建立的接口。约束 ：进行系统构造时需要遵守的约束3. 优秀需求的特性完整性 ，正确性 ，精确性，可行性 ， 必要性 ，无歧义 ， 可验证 4常见的需求定义错误1 需求并没有反映用户的真实需要 2 模糊和歧义的需求3 明显的信息遗漏 4 不必要的需求 5 不切实际的期望第三章1. 需求工程过程的活动3.2.1
5、需求获取需求获取是从人、文档或者环境当中获取需求的过程；需求获取阶段任务： 收集背景资料：要开发系统的背景资料； 定义项目前景和范围 ：早期产生项目的前景和范围可以提高客户的信心；选择信息的来源 ：用户、硬数据（表单、报表备忘录）、相关的文档和领域专家；选择获取方法，执行获取：面谈、 调查表、观察等方法；记录获取结果 ：获取的信息要及时记录下来；3.2.2 需求分析需求分析：利用建模和分析技术对获取笔录的内容进行明确整理汇总，建立一个综合考虑了问题域特性和需求的系统模型；然后根据系统模型将用户需求转化为系统需求 。 需求分析：还为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案
6、；需求分析：还需要检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正 ；需求分析阶段任务：背景分析 ：对于规模较大的系统，系统环境往往难以梳理，需要一些专门的分析方法：企业建模确定系统边界： 项目的范围；系统边界之内定义是系统需要对外提高哪些功能；系统边界之外标识的是对系统有功能要求的外部实体；需求建模：数据流图 、E-R图、状态转换图、类图来把需求描述出来；需求细化 ：用户需求往往具有模糊、歧义等不利特征；确定优先级 ：用户对系统需求需要，并不是处于同样重要地位；需求协商 ：不同用户间的需求冲突，要求协商；3.2.3 需求规格说明获取的需求需要被编写成文档，主要目的是为了在系统涉众之
7、间交流需求信息；文档要求：简洁、精确、一致、易于理解；业务需求被写入项目前景和范围文档；用户需求被写入用户需求文档（或者用例文档）；系统需求被写入需求规格说明 ；需求规格说明阶段任务：1）定制文档模版：IEEE1998推荐模板； 2）编写文档：准确的表达需求、良好的结构和易读性；3.2.4 需求验证需求验证：确保需求规格说明文档能正确、准确的反映用户的意图；需求规格文档至少满足以下几个标准:文档内每条需求都正确、准确的反映了用户的意图；文档记录的需求集在整体上具有完整性和一致性；文档的组织方式和需求的书写方式具有可读性和可修改性; 需求验证阶段任务：1）执行验证 ：执行验证方法：同级评审；2）
8、问题修正 ：发现问题及时修正；3.2.5 需求管理需求管理是在需求开发结束之后，保证整个软件的产品生命周期中的持续、稳定和有效发挥；需求管理阶段主要任务：1）建立和维护需求基线集：需求基线就是把这些需求都划一根“线”，说明这些需求已经确定下来，添加新的需求和修改原有的需求都必须通过需求变更流程来操作，记录变更情况，变更日期、变更原因等。目的就是为了防止需求的滥变给程序架构造成重大影响。 2）建立需求跟踪信息 ：需求要具有可跟踪性； 后向跟踪：跟踪需求去向，寻找特定需求的导出需求； 前向跟踪：跟踪需求的来源，寻找提出特定需求的用户；3）进行变更控制：需求可能不断变化，为了保证项目顺利进行，这些变
9、化的需求必须得到妥善控制。第四章1.4.2.需求获取中的常见困难4.2.1用户和开发人员的背景不同，立场不同 4.2.2 普通用户缺乏概括性、综合性的表述能力4.2.3 用户存在认知困境 4.2.4用户越俎代庖 4.2.5 缺乏用户参与 2. 需求获取活动需求获取活动的要点：1.确定获取信息的内容2.确定待获取信息的来源3.确定应采用的获取方法4.执行获取5.获取的结果3. 需求工程需要获取的内容主要有三种：1.需求：需求是获取的主要对象，是系统期望达到的目标，它主要来源于用户、客户、领域专家等；2.问题域描述：问题域：是指被开发系统的应用领域，即在客观世界中由该系统处理的业务范围；3、环境与
10、约束：软件的应用环境，以及获取需求的约束条件4. 获取信息的来源1、涉众2、硬数据3、相关产品4、重要文档5、相关技术标准和法规5. 获取信息的方法 1、传统方法 问卷调查、面谈、硬数据分析、文档检查、需求剥离等 2、集体获取方法 3、原型 4、模型驱动方法5、认知方法 6、基于上下文的方法 6. 获取信息的成果产生获取笔录（Elicitation Notes） 可能会产生两份定义明确的正式文档：第六章1.涉众：所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个人和团体。涉众类别：1、用户: 最终使用和操作产品的人2、客户: 为软件系统的开发付费的人 3、开发者: 负责实现软件系统
11、的人 4、管理者：参与软件系统开发事务管理的人 5、领域专家: 在问题域中具有丰富知识的专家 6、政府力量 :法律法规 、长远规划、政策意向等 7、市场力量：组织中的市场部门人员 2. 涉众分析就是为软件系统寻找并理解关键涉众的过程。3. 涉众分析过程 涉众识别：寻找和发现各种涉众类别；涉众描述：首先描述对涉众的基本特征描述、也会包括地理和社会特征；涉众评估：是将这些孤立的描述信息联合起来进行分析，以便得到更深层次信息的过程；涉众选择：为每个涉众类别选择合适的代表4. 硬数据：人们在实际工作中产生的各种各样的表格和文档资料；常见硬数据分为定量硬数据和定性硬数据两种类型：1、定量硬数据定量硬数据
12、：指经过仔细设计、具有严格规范要求的格式化文档。2、定性硬数据定性硬数据：使用自然语言进行描述的文本资料。5. 涉众分析主要任务：1.寻找软件系统的涉众类别，辨别关键的涉众类别；2.描述不同涉众类别的特征，包括个人特征、工作特征；3.分析不同涉众类别的输赢条件和受影响程度； 4.描述不同涉众类别的关注点和兴趣取向；5.分析不同涉众类别的重要性和影响力；6.为每种涉众类别选择合适的代表参与项目开发。6.采样方式：1.1、随机抽样1.随机地采样数据； 2.2、分层抽样 1.考虑系统的分层，从每一层中随机抽取一个样本； 第七章1. 面谈中的问题基本上可以分为两种类型：开放式问题和封闭式问题 2. 开
13、放式问题的优缺点优点：让被会见者感到自在；会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；提供丰富的细节；对没采用的进一步的提问有启迪作用；让被会见者更感兴趣；容许更多的自发性；会见者可以在没有太多准备的情况下进行面谈。缺点：提此类问题可能会产生太多不相干的细节；面谈可能失控；开放式的回答会花费大量的时间才能获得有用的信息量；可能会使会见者看上去没有准备。封闭式问题的优缺点优点：节省时间；切中要点；保持对面谈的控制；快速探讨大范围问题；得到贴切的数据缺点：使得被会见者厌烦；得不到丰富的细节；出于上述原因，失去主要思想；不能建立和面谈者的友好关系。 3.面谈的过程准备面
14、谈主持面谈处理面谈结果4. 面谈准备的主要工作：1.阅读背景资料 2.确定面谈主题和目标 3.选择被会见者 4.准备被会见者：提前打电话通知，时间地点 5.确定问题和类型 第八章1.原型的定义如果在最终的物件产生之前，一个中间物件被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。2.原型方法的过程在需求获取中原型方法的过程，主要步骤包括：1)确定原型的需求：搞清楚为什么要开发原型，拥有的起始点是什么，期望结束的标准是什么？2)原型开发：选择原型的开发方法和构建技术，建立初始原型。3)原型评估：对上一阶段原型进行评估，根据评估者反馈判断原型是
15、否满足结束标准。4)原型修正：如果反馈不满足结束标准，对原型进行调整。3. 8. 2. 原型的类别（几种重要的分类方法）8.2.1 按照使用方式分类1.演示原型（presentation prototype）主要被用在启动项目阶段，用来展示用户想象中的系统试图； 目的是让用户相信应用系统的开发是可行的； 2.严格意义上的原型（prototype proper） 主要被用在分析需求阶段； 目的用来阐明用户界面或者系统功能的某些特定方面，帮助人们及时澄清问题； 3.试验原型（breadboard prototype） 主要被用在构建系统阶段； 目的帮助开发者澄清他们所面对的一些和系统构建相关技术问
16、题，或者被用来确定系统某些功能实现的技术可行性； 4.引示系统原型（pilot system prototype） 会被开发在系统开发的各个阶段； 目的用作最终系统的构建核心； 8.2.2 按照开发方法分类1.探索式（exploratory） 以缺陷需求开始继而不断调整和修正需求的原型开发方式称为探索式；要尽可能的调整各种设计选项，并比较多种设计方案下的用户反馈得到理想的用户需求。2.实验式（experimental） 该方法具有清晰的用户需求，但开发者对需求的实现方法、实现效果、可行性没有把握； 实验式：首先定义一个对原型的评估方法，确定评估的属性，据此明确需求的可行性和有效的技术实现方案。
17、 3.演化式（evolutionary） 演化式的原型方法的开发并不是一个独立的活动，而是整个项目的持续开发过程中的一部分，以清晰的原型化需求和项目积累下来的原型资产为开始；可以被不断传递和不断增强的原型资产将成为最终的软件系统。8.2.3 按构建技术1.水平原型方法（horizontal prototyping）它仅仅实现选定功能所有层次中的某些特定层次 ，建立的原型产品称为水平原型（horizontal prototype。） 要把注意力集中在概括性需求和工作流问题上 ；2.垂直原型方法（vertical prototyping）它会触及到选定功能实现的所有层次，建立的原型产品称为垂直原型
18、（vertical prototype） 。要保证真实实现它的各种功能； 第九章1. 常见的观察方法：1）采样观察：选取特定的时间特定的事件进行观察；2）民族志：要求观察者深入到用户中花费较长时间来观察 用户的活动；3）话语分析：与用户交谈话语发现和获取相关信息；4）协议分析：要求观察对象一边执行任务，一边解释执行任务时产生的各种想法；5）任务分析：观察、记录、分析用户和软件系统的交互行为；2. 采样观察：选取特定的时间、特定的事件进行观察；1、概述民族志：要求观察者深入到用户中花费较长时间来观察 用户的活动；2、优点能够得到信息的深度理解； 能够让真实世界的社会性因素可见化； 打破人们已有的
19、一些错误假设和错误观念； 3、缺点需要耗费很多的时间； 调研结果很难传递到开发过程 ；3.什么是情境性事件情景性：是指某些事件只有和它们发生时的具体环境联系起来，才能理解。对于情景性的事件，需要将它们放在发生时的情景中进行解释，才能明确其意图；4.为什么需要观察方法，观察方法的适用情境很多时候用户无法完成主动的信息告知，这时就有必要采用观察的方法5. 文档审查三种方法9.2.1 需求重用在开发新产品时，常常可以发现相关产品（原有产品、竞争产品）的需求规格说明。需要将这些规格说明作为需求获取的一个部分进行分析，发现可以移植到新产品中的需求信息，进行需求重用。9.2.2 文档分析文档分析是通过检查
20、采集的硬数据来确定潜在的需求。9.2.3 需求剥离如果当前存在一份客户需求文档（委托开发的规格说明、招标书），就可以使用需求剥离技术，从需求文档中抽取出单个的需求并加入到新的需求文档中。第十一章1. 需求分析的根本任务如下：2. 需求分析方法1 传统分析 没有什么根本的方法论可言 (1950s)依赖个体才智,依据个人习惯；缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构等等；2结构化分析 结构化分析方法：把现实世界描绘为数据在信息系统中的流动，以及在数据流动过程中数据向信息的转化，它帮助开发人员定义系统需要做什么（处理要求），系统需要存储和使用哪些数据（数据要求），需要什么样的输入和输出
21、。传统结构化分析 (late 1960s),现代结构化分析 (late 1970s)以数据流动为中心，以DFD(数据流图)、E-R图（实体联系图）为核心技术，辅助STD3信息工程 信息工程方法：是对结构化的一种改进，其分析过程与结构化相似，但其从信息系统的角度来开发系统，主张从数据入手；而结构化方法：从功能的角度来考虑问题，主张从功能入手；以数据知识结构为基础，ERD为核心技术，辅助DFD，STD, FDD, PD 4面向对象分析 面向对象方法：认为系统是对象的集合，这些对象之间相互协作，共同完成系统任务；面向对象方法：以对象为中心，以UML（类图）为核心技术；与结构化方法不同，结构化方法以功
22、能为基础；以全面思想革新为理想，以继承结构化技术为现实；3.结构化分析与信息工程的区别是什么，他们有哪些公共的建模技术，使用哪些技术的差别是什么？ 见上题4. 需求分析需要执行哪些活动：1）问题分析2）确定系统边界3）需求建模4）需求细化5）确定需求优先级6）需求协商5. 需求分析人员在需求协商中应确保3个原则：（注意事项）1）明确冲突的因素，避免情绪上的冲突； 2）明确冲突的解决空间：发现和明确各种可能的解决方式、论据、理由；3）确定最佳解决方案：帮助涉众在已有的解决空间内达成最佳的解决方案； 第十二章1.过程建模的定义和技术：过程建模：就是分析需求获取活动获得的信息，发现系统的功能和其与外
23、界的交互，建立能够实现系统功能的过程分解结构，形成系统的过程模型，并用图像的方式将过程模型描述出来。过程建模，使用的主要技术：1）上下文图：用来说明系统的上下文环境，确定系统边界；2）数据流图：用来建立过程的分解结构；3）微规格说明：用来描述数据流图过程分解结构中最底层过程的处理逻辑；4）数据字典：用来说明系统中涉及的数据的结构；2. 数据流图（DFD）基本元素和规则基本元素：外部实体、过程、数据流和数据存储在使用DFD描述系统过程模型时，有一些规则必须遵守，这些规则可以保证过程模型的正确性：1）过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应该存在差异； 没有输入情
24、况下产生输出，称为“奇迹”； 如果过程接收了输入数据却没有输出，称为“黑洞”；3. DFD的层次结构建立步骤：1.创建上下文图 ；2.发现并建立DFD片断 ；3.根据DFD片断组合产生0层图；4.对0层图的过程进行功能分解，产生N层图 ；4. 微规格说明的定义微规格说明的是一些被用来描述过程处理逻辑的技术，主要有3中技术：1、结构化英语2、行为图3、决策表/树5. 模块结构图1.功能分解图功能分解图（FDD）：又被称为功能层次图，它在一个图内自上至下的集中显示系统的功能分解结构；最顶层的单独功能通常是对整个系统的使命描述，是对系统业务需求的概括； 系统使命说明的下一层被称为功能的最顶层，描述了
25、系统应该具备的一些重要功能，它们支撑着系统使命的实现； 功能最顶层下面的分支是对最顶层功能执行分解后形成的层次关系； 最底层的是基本的业务功能。这些基本的业务功能是人们所能找到的最基本的、不可再细分的功能或处理；功能分解图能够更加集中、更加直观的展示大量过程之间的层次关系 。2.过程依赖图与DFD相比，FDD虽然能够跟好地展示功能和过程的层次结构，但FDD丢失了功能和过程之间的关系，例如数据依赖、顺序关系等。所以在信息工程中引入了过程依赖图，来描述功能和过程之间的依赖关系；依赖包括： 数据依赖关系资源依赖关系约束依赖关系 第十三章1.数据建模与过程建模的区别？过程建模：以数据在系统中的产生和使
26、用为重点，以数据转换的过程为核心，建立层次结构来描述系统，它描述了系统的行为和数据。过程建模：更多是侧重数据产生和使用的时间、地点和方式，而没有描述数据的定义、结构和关系等特性。数据模型（弥补了过程建模的不足）a)描述数据的定义、结构和关系等特性的模型；b)说明了问题域和解系统共享的事物、对共享事物的描述和共享事物之间的关系 ；c)能够反映企业业务的核心知识 ； 建立数据模型的过程被称为数据建模；2. 三种常见的数据模型：1）概念数据模型（ERD） 它是按用户的观点来对数据和信息建模；以问题域的语言解释数据模型，反映了用户对事物的描述和看法；2）逻辑数据模型： 按计算机系统的观点对数据建模，描
27、述数据的逻辑结构 ；3）物理数据模型 描述事物在解系统中实现形式，描述数据在系统内部的表示方式和存取方法；注：在需求工程中，数据建模建立的是概念数据模型和逻辑数据模型；不涉及物理数据模型； 数据建模最常用的方法是实体联系图ERD；2.区分基数和度数基数：指在关系中其他实体实例确定的情况下，该实体实例可能参与关系的数量；关系的度数：指参与关系的实体数量； 第十四章1.面向对象建模的定义及常用技术？面向对象建模：一种用于辨识系统环境中的对象及这些对象之间关系的技术在需求分析中,利用UML建模，包含技术有：a)对象模型Object Model (Domain Model)b)用例模型Use Case
28、 Modelc)行为模型Behavior Modeld)状态机模型e)对象约束语言OCL2.用例模型的定义及基本元素？用例模型：就是以用例为基本单位建立的一个系统功能展示模型，它是系统所有用例的集合，以统一、图形化方式展示系统的功能和行为特性；基本元素：1）用例（Use Case）：是对业务工作的描述，或者说是对系统功能的陈述； 2）参与者（Actor）：发起或触发用例的外部用户以及其他软件等角色参与者； 用一个小人图标来表示参与者；3）关系（Relationship）：用例模型中有以下几种关系：A、关联：是用例与参与者直接按关系，描述用例和参与者之间的交互；B、包含、扩展与泛化描述用例与用例
29、之间关系；4）系统边界（System Boundary）：是指一个系统所包含的系统成分与系统外事物的分界线。 使用一个矩形框来表示系统边界； 3.行为建模概述，三种模型解决什么问题？开发人员无法直接从用户那里获得对象模型，首先使用用例来获得用户需求，建立用例模型。然后，需要以用例模型为基础，产生对象模型；行为模型就是实现用例模型到对象模型的桥梁；UML使用的行为模型有3种：a)交互图（Interaction Diagram）i.顺序图（Sequence Diagram）ii.通信图（Communication Diagram）iii.交互概述图（Interaction Overview Dia
30、gram）iv.时间图（Timing Diagram）b)活动图（Activity Diagram）c)状态图（State Diagram）交互图：以一组对象为中心的交互描述技术； d)描述在特定上下文环境中一组对象的交互行为； e)通常描述的是单个用例的典型场景；f)交互图中的每一个交互都描述了环境中的对象为了实现某个目标而执行的一系列消息交换；g)顺序图和通信图是最常用的 交互图；h)交互图中出现的对象应该在领域模型中有相应的对象存在； 状态图i)以状态机理论为基础建立的对系统行为的描述手段；i.状态机是以“状态”概念为基础解释系统行为的一种技术；ii.有限状态机FSM是用于建模的最简单的状态机；iii.在FSM技术基础之上，发展出了多种
