搜索
第3章结构化需求分析本章学习内容：1．掌握需求、需求工程的基本概念2．明确需求分析应遵循的原则3．掌握如何使用需求获取技术来进行数据采集4．掌握结构化分析的思想与过程5．掌握数据流建模技术软件需求作为软件生存周期的第一个阶段，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域——需求工程。20世纪90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE）；1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。3.1需求分析概述软件需求的重要性软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。完成并实施完成未实施未完成分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。未完成完成未实施完成3.1需求分析概述3.1.1需求分析的任务将用户对软件的一系列要求、想法转变为软件开发人员所需要的有关软件的技术规格说明。需求:成功的软件开发的前提软件质量=系统所实现的需求/客户所期望的需求软件项目投标及签订合同的基础软件系统实现的基础系统确认移交的基础需求的定义IEEE软件工程中需求的定义(1977)1.用户解决问题或达到目标所需的条件和能力2.系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力3.以上条件和能力的文档说明Sommerville&Sawyer1997需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束1．用户需求：是用户关于软件的一系列想法的集中体现，涉及软件的功能、操作方式、界面风格、报表格式、用户机构的业务范围、工作流程，以及用户对软件应用的展望等。3.1需求分析概述3.1需求分析概述特点：（1）用户需求直接来源于用户。需求可以由用户主动提出，也可以通过与用户沟通、交流或者进行问卷调查等方式获得。由于用户对计算机系统认识上的不足，分析人员有义务帮助用户挖掘需求。（2）用户需求需要以文档的形式提供给用户审查。因此，需要使用流畅的自然语言和简洁清晰的直观图表来表述，以方便用户的理解与确认。（3）可以把用户需求理解为用户对软件的合理请求。这意味着，必须全面理解用户的各项要求，但又不能全盘接受所有的要求。（4）用户需求主要是为用户方管理层撰写的，但是用户方的技术代表、软件系统今后的操作者以及开发方的高层技术人员，也有必要认真阅读用户需求文档。3.1需求分析概述2．系统需求：系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。系统需求需要对系统的功能、性能、数据等方面进行规格定义。软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出3.1需求分析概述功能性需求和非功能性需求功能性需求系统需要提供的服务或功能：如图书检索系统对特定输入的处理方式：如对非法输入的提示系统在特定环境下的行为：如长时间无操作时的屏保非功能性需求对系统功能或服务附加的质量约束，例如响应时间、容错性、安全性等——客户所关心的(外部质量)从系统开发和维护角度出发的质量属性，例如可理解性、可扩展性、可配置性等——软件开发或维护者所关心的(内部质量、软件所特有)第3章结构化需求分析领域需求：它是由软件系统的应用领域所决定的特有的功能需求或是对功能的约束。例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：⑴图书编目要求按照《中国图书馆分类法》进行；⑵由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。第一条需求是遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。13举例14举例1516例1718功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。软件需求19是从各个角度对系统的约束和限制，反映了应用对信息系统质量和特性的额外要求。非功能需求包括过程需求、产品需求和外部需求等类型，其中过程需求包含交付、实现方法和标准等方面的需求，产品需求包含性能、可用性、实用性、可靠性、可移植性、安全性、容错性等方面的需求，外部需求有法规、成本、互操作性等需求。非功能需求非功能需求还包括哪些方面？20非功能需求要求分析人员使用符合客户语言习惯的表达要求分析人员了解客户系统的业务及目标要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明要求开发人员对需求过程中所产生的工作结果进行解释说明要求开发人员在整个交流过程中保持和维护一种合作的职业态度要求开发人员对产品的实现及需求都要提供建议，拿出主意描述产品使其具有易用、好用的特性可以调整需求，允许重用已有的软件组件当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评估获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的软件客户的权力给分析人员讲解业务及说明业务方面的术语等专业问题抽出时间清楚地说明需求并不断完善当说明系统需求时，力求准确详细需要时要及时对需求做出决策要尊重开发人员的成本估算和对需求的可行性分析对单项需求、系统特性或使用实例划分优先级评审需求文档和原型一旦知道要对项目需求进行变更，要马上与开发人员联系在要求需求变更时，应遵照开发组织确定的工作过程来处理尊重需求工程中开发人员采用的流程（过程）软件客户的义务项目案例案例角色和人物–小王：软件项目负责人–老王：公司技术老总–开发小组：小李，老赵，小田，小谢要对软件需求进行管理(1/2)按照初步的项目计划，老赵带领项目组的部分成员(需求分析小组)开始进驻用户场地，开展需求调查工作，但在需求分析和后续开发过程中陆续出现了许多与用户需求有关的一系列问题，影响软件项目的实施整个项目规模比较庞大，需求分析小组不知如何开展工作？从何处下手？对需求分析的复杂性和难度估计不足。需求分析小组不能有效工作：不知哪些属于用户需求，哪些不是？不知怎样才能获取用户需求？如何把它分析清楚？不知应该按照怎样的规范书写软件需求规格说明书?得到的软件需求质量不高：说不清，遗漏，矛度，罗嗦….需求评审不严格，导致遗漏了许多需求，获取的用户需求不一致、描述的不清晰和准确要对软件需求进行管理(2/2)更为糟糕的是，由于用户没有参加需求评审，使得许多软件需求没有得到用户的认可，最终所开发出的软件不能满足用户的要求，用户拒绝接收软件，并拒绝付款由于软件需求的不准确性、不一致性和二义性，在软件开发阶段，软件设计人员不得不通过用户再次确认需求在开发过程中，用户的需求仍然在改变，需求分析小组负责获取改变了的用户需求，然而这些改变了的需求没有得到有效的管理和控制，没能将变化的需求及时反馈给软件开发小组，导致这些需求未能在待开发的软件中得到体现由于需求未能得到有效管理，在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期案例提示我们需求分析是极为重要的需求分析是困难和复杂的用户需求经常性的变更是正常的为了保证软件需求的质量，必须对需求分析的人、过程和产品进行有效管理需求管理的不善将会导致严重后果第3章结构化需求分析3.1.2需求工程需求工程指应用工程化方法、技术和规格来开发和管理软件的需求。需求工程的目标是获取高质量的软件需求。需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理等。需求获取：资料收集需求分析与协商：理解分析整理系统建模：用模型描述(写下来)需求规约：完善需求文档并定稿需求验证：验证确认需求管理：整体规划及变更管理需求工程的六个阶段需求获取系统分析人员通过与用户的交流，了解业务现状以及对待开发系统的期望需求获取收集的“原始材料”为进行需求分析提供了基础确定系统或产品范围的限制性描述与系统或产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的领域限制一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型需求分析与协商对需求进行分类组织，分析需求之间的关系检查需求的一致性、重叠和遗漏的情况根据用户的需要对需求进行排序在需求获取阶段，经常出现以下问题：提出的要求超出软件系统可以实现的范围或实现能力不同的用户提出了相互冲突的需求系统建模建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁系统分析人员借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法需求规约、规格描述通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。软件需求规约是分析任务的最终产物。需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。需求验证需求开发阶段工作的复查手段。对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责(应该是需求分析人员之外的其他人员)，并按规程严格进行。需求确认与需求分析二者密切相关都需对系统需求中的遗漏和冲突进行识别和分析区别需求分析处理的是未整理的原始需求，此时发现的问题是客户的问题。需求确认的对象是经分析后形成的需求规格说明，此时发现的问题是需求分析人员的问题，此外还需要考虑需求文档是否满足相应的质量标准。在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。获取分析与建模编写规约验证重新评估更正并减小误差证实重写需求工程需求为什么需要管理？1、需求不总是显而易见的，而且它可来自各个方面。2、需求并不总是容易用文字明白无误地表达。3、存在不同种类的需求，其详细程度各不相同。4、如果不加以控制，需求的数量将难以管理。5、需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。6、需求既非同等重要，处理的难度也不同。7、需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。8、需求发生变更。9、需求可能对时间敏感。需求管理需求管理是一种获取、组织并记录系统需求的系统化方案：对所有需求工程相关活动的规划和总体控制。需求变更管理：一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程(变更的记录、分析、变更过程管理、追踪等)。内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求获取需求获取：通过客户调研等手段对需求进行收集、分析、细化、核实和组织两种项目(相对)的需求获取过程：产品项目：一般是根据公司战略和市场需求研发，旨在进行批量出售或推广的项目。工程项目：一般是根据与用户签定的合同研发，旨在满足特定用户需求的项目。需求获取需求获取困难的原因缺乏领域知识,应用领域的问题常常是模糊的、不精确的；存在默认的知识,如难以描述的常识问题；存在多个知识源,且多个知识源之间可能有冲突；客户可能的偏见，如不能提供或不想告知你所需要了解的事情。需求获取方法与策略建立顺畅的通信途径深入客户方进行访谈与调查观察用户操作流程组成各方联合小组建立顺畅的通信途径建立分析所需要的通信途径，以保证能顺利地对问题进行分析需求捕获的策略需求捕获的过程是人和人打交道的过程，是需求分析人员展示自己沟通能力的地方，因此就需要掌握一些人文、沟通技巧，学会一些和人打交道的策略。需