需求工程

一1.软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题2.软件开发带来的需求问题：1）对软件的开发成本和进度的估计常常不准确；2）用户对已完成的系统常常不满意；3）软件的质量不可靠；4）软件的可维护程度较低；5）软件常常没有适当的文档资料；6）软件的成本不断提高；7）软件开发生产的效率较低；3.需求工程活动包括：需求开发和需求管理；需求开发包括：需求获取、需求分析、需求规格说明和需求验证4个部分；需求获取：目的从项目的张罗规划开始建立最初的原始需求。需求分析：目的保证需求的完整性和一致性；需求规格说明：目的将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来；需求验证：目的保证需求及其文档的正确性，即需求真实地反映了用户的真实意图；以及通过检查和修正保证需求及其文档的完整性和一致性；4.软件的模拟特性：软件在运行中表现出来的特性、行为应该和应用的实际情况保持一致。5.需求工程与系统工程的关系传统的需求处理是软件工程的需求阶段；但系统化的需求工程将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到了重要的作用。需求工程处于系统的起始阶段，包括系统需求开发和软件需求开发两个部分。6.需求工程的重要性软件开发是利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的，定义问题就是需求工程的任务。开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求。容易忽略需求工程重要性的地方问题广为人知问题小而简单第二章1.需求的定义：（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。2.需求的分类功能需求：和系统主要工作相关的需求。功能需求主要表现为系统和环境之间的行为交互。业务需求：是系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统。用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。系统需求：系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，需求工程需求开发需求管理需求获取需求分析需求规格说明需求验证描述了开发人员需要实现什么性能需求：系统整体或系统组成部分应该拥有的性能特征。质量属性：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求。对外接口：系统和环境中其他系统之间需要建立的接口。约束：进行系统构造时需要遵守的约束3.优秀需求的特性完整性，正确性，精确性，可行性，必要性，无歧义，可验证4．常见的需求定义错误1需求并没有反映用户的真实需要2模糊和歧义的需求3明显的信息遗漏4不必要的需求5不切实际的期望第三章1.需求工程过程的活动3.2.1需求获取需求获取是从人、文档或者环境当中获取需求的过程；需求获取阶段任务：收集背景资料：要开发系统的背景资料；定义项目前景和范围：早期产生项目的前景和范围可以提高客户的信心；选择信息的来源：用户、硬数据（表单、报表备忘录）、相关的文档和领域专家；选择获取方法，执行获取：面谈、调查表、观察等方法；记录获取结果：获取的信息要及时记录下来；3.2.2需求分析需求分析：利用建模和分析技术对获取笔录的内容进行明确整理汇总，建立一个综合考虑了问题域特性和需求的系统模型；然后根据系统模型将用户需求转化为系统需求。需求分析：还为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案；需求分析：还需要检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正；需求分析阶段任务：背景分析：对于规模较大的系统，系统环境往往难以梳理，需要一些专门的分析方法：企业建模确定系统边界：项目的范围；系统边界之内定义是系统需要对外提高哪些功能；系统边界之外标识的是对系统有功能要求的外部实体；需求建模：数据流图、E-R图、状态转换图、类图来把需求描述出来；需求细化：用户需求往往具有模糊、歧义等不利特征；确定优先级：用户对系统需求需要，并不是处于同样重要地位；需求协商：不同用户间的需求冲突，要求协商；3.2.3需求规格说明获取的需求需要被编写成文档，主要目的是为了在系统涉众之间交流需求信息；文档要求：简洁、精确、一致、易于理解；业务需求被写入项目前景和范围文档；用户需求被写入用户需求文档（或者用例文档）；系统需求被写入需求规格说明；需求规格说明阶段任务：1）定制文档模版：IEEE1998推荐模板；2）编写文档：准确的表达需求、良好的结构和易读性；3.2.4需求验证需求验证：确保需求规格说明文档能正确、准确的反映用户的意图；需求规格文档至少满足以下几个标准:文档内每条需求都正确、准确的反映了用户的意图；文档记录的需求集在整体上具有完整性和一致性；文档的组织方式和需求的书写方式具有可读性和可修改性;需求验证阶段任务：1）执行验证：执行验证方法：同级评审；2）问题修正：发现问题及时修正；3.2.5需求管理需求管理是在需求开发结束之后，保证整个软件的产品生命周期中的持续、稳定和有效发挥；需求管理阶段主要任务：1）建立和维护需求基线集：需求基线就是把这些需求都划一根“线”，说明这些需求已经确定下来，添加新的需求和修改原有的需求都必须通过需求变更流程来操作，记录变更情况，变更日期、变更原因等。目的就是为了防止需求的滥变给程序架构造成重大影响。2）建立需求跟踪信息：需求要具有可跟踪性；后向跟踪：跟踪需求去向，寻找特定需求的导出需求；前向跟踪：跟踪需求的来源，寻找提出特定需求的用户；3）进行变更控制：需求可能不断变化，为了保证项目顺利进行，这些变化的需求必须得到妥善控制。第四章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、环境与约束：软件的应用环境，以及获取需求的约束条件4.获取信息的来源1、涉众2、硬数据3、相关产品4、重要文档5、相关技术标准和法规5.获取信息的方法1、传统方法问卷调查、面谈、硬数据分析、文档检查、需求剥离等2、集体获取方法3、原型4、模型驱动方法5、认知方法6、基于上下文的方法6.获取信息的成果产生获取笔录（ElicitationNotes）可能会产生两份定义明确的正式文档：第六章1.涉众：所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个人和团体。涉众类别：1、用户:最终使用和操作产品的人2、客户:为软件系统的开发付费的人3、开发者:负责实现软件系统的人4、管理者：参与软件系统开发事务管理的人5、领域专家:在问题域中具有丰富知识的专家6、政府力量:法律法规、长远规划、政策意向等7、市场力量：组织中的市场部门人员2.涉众分析就是为软件系统寻找并理解关键涉众的过程。3.涉众分析过程涉众识别：寻找和发现各种涉众类别；涉众描述：首先描述对涉众的基本特征描述、也会包括地理和社会特征；涉众评估：是将这些孤立的描述信息联合起来进行分析，以便得到更深层次信息的过程；涉众选择：为每个涉众类别选择合适的代表4.硬数据：人们在实际工作中产生的各种各样的表格和文档资料；常见硬数据分为定量硬数据和定性硬数据两种类型：1、定量硬数据定量硬数据：指经过仔细设计、具有严格规范要求的格式化文档。2、定性硬数据定性硬数据：使用自然语言进行描述的文本资料。5.涉众分析主要任务：1.寻找软件系统的涉众类别，辨别关键的涉众类别；2.描述不同涉众类别的特征，包括个人特征、工作特征；3.分析不同涉众类别的输赢条件和受影响程度；4.描述不同涉众类别的关注点和兴趣取向；5.分析不同涉众类别的重要性和影响力；6.为每种涉众类别选择合适的代表参与项目开发。6.采样方式：1.1、随机抽样1.随机地采样数据；2.2、分层抽样1.考虑系统的分层，从每一层中随机抽取一个样本；第七章1.面谈中的问题基本上可以分为两种类型：开放式问题和封闭式问题2.开放式问题的优缺点优点：让被会见者感到自在；会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；提供丰富的细节；对没采用的进一步的提问有启迪作用；让被会见者更感兴趣；容许更多的自发性；会见者可以在没有太多准备的情况下进行面谈。缺点：提此类问题可能会产生太多不相干的细节；面谈可能失控；开放式的回答会花费大量的时间才能获得有用的信息量；可能会使会见者看上去没有准备。封闭式问题的优缺点优点：节省时间；切中要点；保持对面谈的控制；快速探讨大范围问题；得到贴切的数据缺点：使得被会见者厌烦；得不到丰富的细节；出于上述原因，失去主要思想；不能建立和面谈者的友好关系。3.面谈的过程准备面谈主持面谈处理面谈结果4.面谈准备的主要工作：1.阅读背景资料2.确定面谈主题和目标3.选择被会见者4.准备被会见者：提前打电话通知，时间地点5.确定问题和类型第八章1.原型的定义如果在最终的物件产生之前，一个中间物件被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。2..原型方法的过程在需求获取中原型方法的过程，主要步骤包括：1)确定原型的需求：搞清楚为什么要开发原型，拥有的起始点是什么，期望结束的标准是什么？2)原型开发：选择原型的开发方法和构建技术，建立初始原型。3)原型评估：对上一阶段原型进行评估，根据评估者反馈判断原型是否满足结束标准。4)原型修正：如果反馈不满足结束标准，对原型进行调整。3.8.2.原型的类别（几种重要的分类方法）8.2.1按照使用方式分类1.演示原型（presentationprototype）主要被用在启动项目阶段，用来展示用户想象中的系统试图；目的是让用户相信应用系统的开发是可行的；2.严格意义上的原型（prototypeproper）主要被用在分析需求阶段；目的用来阐明用户界面或者系统功能的某些特定方面，帮助人们及时澄清问题；3.试验原型（breadboardprototype）主要被用在构建系统阶段；目的帮助开发者澄清他们所面对的一些和系统构建相关技术问题，或者被用来确定系统某些功能实现的技术可行性；4.引示系统原型（pilotsystemprototype）会被开发在系统开发的各个阶段；目的用作最终系统的构建核心；8.2.2按照开发方法分类1.探索式（exploratory）以缺陷需求开始继而不断调整和修正需求的原型开发方式称为探索式；要尽可能的调整各种设计选项，并比较多种设计方案下的用户反馈得到理想的用户需求。2.实验式（experimental）该方法具有清晰的用户需求，但开发者对需求的实现方法、实现效果、可行性没有把握；实验式：首先定义一个对原型的评估方法，确定评估的属性，据此明确需求的可行性和有效的技术实现方案。3.演化式（evolutionary）演化式的原型方法的开发并不是一个独立的活动，而是整个项目的持续开发过程中的一部分，以清晰的原型化需求和项目积累下来的原型资产为开始；可以被不断传递和不断增强的原型资产将成为最终的软件系统。8.2.3按构建技术1.水平原型方法（horizontalprototyping）它仅仅实现选定功能所有层次中的某些特定层次，建立的原型产品称为水平原型（