搜索
1需求工程概述需求获取需求分析与建模需求归档需求评审需求管理2学习目标•了解需求工程的几个阶段；•了解需求分析的任务；•掌握需求的种类；•掌握获取需求的方法；•掌握需求确认和验证。3•需求的概念•需求分析的任务•需求工程阶段需求工程概述4•什么是需求？产品必须提供的服务产品必须具备的质量特征•需求关注于顾客的需要，指定系统要“做什么”，而不关心问题的解决方案或实现•参与者：系统分析人员需求的概念5项目失败的原因13%12%10%10%9%9%8%7%22%需求不完备缺乏用户参与缺乏资源期望不现实缺乏行政支持需求及规格变动缺乏规划不再需要系统其他StudybytheStandishGroupinvolving350companiesfrom1994/95,see[Pfleeger98].6需求分析的任务•深入描述软件的功能和性能•确定软件设计的约束和软件同其它系统元素的接口细节•定义软件的其它有效性需求7•需求分析研究的对象：项目的用户要求•准确地表达被接受的用户要求•确定被开发软件系统的系统元素•将功能和信息结构分配到这些系统元素中8•需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。9•AlanDavis把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”•HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理•MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证•……需求工程阶段10•我们将软件需求工程细分为：需求获取需求分析与系统建模需求归档需求评审需求工程阶段11•注意：实际的需求开发是一个迭代过程获取分析与建模编写规约验证重新评估更正并减小误差证实重写12需求获取•软件需求种类•需求获取方法与策略13•通过用户交流对现有系统的观察对任务进行分析•确定功能性需求非功能性需求14软件需求的种类•功能需求•非功能性需求性能需求用户或人的因素环境需求界面需求文档需求数据需求资源使用需求安全保密要求可靠性需求软件成本消耗与开发进度需求其他非功能性要求15需求获取方法与策略•建立顺畅的通信途径•访谈与调查•观察用户操作流程•组成联合小组•用况（UseCase）16建立顺畅的通信途径•建立分析所需要的通信途径，以保证能顺利地对问题进行分析。17访谈与调查•访谈方法：折衷法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：提问问题应循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；提问和回答在汇总后应能够反映用户需求的全貌。•调查：市场调查、多种调查方式18•例子：“赛艇比赛成绩计算系统”的第一次面谈的准备计划初次与Dartchurch航行俱乐部的航行秘书（DR）接触，面谈有关事宜。(在电话交谈时，了解到他们希望得到的是一个“价廉”的，基于PC的系统，以用于计算赛艇比赛成绩)时间：2005-6-5地点：对方场地主要问题确定基本问题。确定DR的角色――还涉及其它人员吗？调查财物方面事宜。系统（大致上）是如何运作的？当前存在的问题是什么？他们都希望做些什么？19观察用户操作流程•到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。20组成联合小组•被称为便利的应用规约技术(FacilitatedApplicationSpecificationTechniques,FAST)：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进了解和协调21FAST基本原则①在中立的地点举行由开发者和用户出席的会议；②建立准备和参与会议的规则；③建议一个足够正式的议程以便可以进行自由的交流；④一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；⑤使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；⑥目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。22FAST会议步骤•1)举行开发者和用户的初步访谈后，确定FAST会议的时间地点，并在会议日之前将产品请求发布给所有的与会者。•2)要求每个FAST出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表(如，成本、规模大小、权重)和性能标准列表(如，速度、精度)。•3)进行FAST会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品。23•4)一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的FAST出席者讨论，进行添加、删除或进一步的精化等工作。•5)在小规约完成后，每个FAST的出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。24用况（UseCase）•主要用于描述系统的高层次功能性需求•用况：系统的使用场景。•创建用况模型的主要步骤如下：1)确定谁会直接使用该系统，即参与者（Actor）2)选取其中一个参与者3)定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况4)对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程5)描述该用况的基本过程25需求分析与建模•需求分析原则•需求协商•需求建模26需求分析原则•1．必须能够表示和理解问题的信息域信息域：包括信息内容、信息流、以及信息结构。•2．必须能够定义软件将完成的功能•3．必须能够表示软件的行为(作为外部事件的结果)•4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节•5．分析过程应该从要素信息移向细节信息27信息域•信息域：包括信息内容、信息流、以及信息结构。信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等28信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出信息结构表示了各种数据和控制项的内部组织•数据或控制项将被组织为n维表还是树形结构？•在结构的语境内，什么信息是和其他信息相关的？•信息包含在单个结构中，还是使用不同的结构？•在某信息结构中的信息如何和在另一个结构中的信息相关？29抽象、分解与多视点分析•需求分析技术•抽象：由一般到特殊，首先关注一般问题的解决途径，进而指导特殊问题的解决方法。30•分解：层次化分解，不断细化。大或复杂问题被分解为若干子问题逐级进行，直至子问题被分解为一个容易分析理解的部分例如横向分解纵向分解31需求协商•讨论需求冲突，找出折衷方案•不是简单的逻辑或技术上的争论•要注意组织和行政方面的因素①不一致的目标②责任的丧失或转移③组织文化④组织管理态度和士气⑤部门差异32•通常会议是解决冲突最快的方式参加者：应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题通常会议分为三个阶段：•叙述阶段•讨论阶段•决策阶段33需求建模•在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做•目标软件的模型不应涉及软件实现细节34•常用的分析方法：面向数据流的结构化分析方法(SA)面向数据结构的分析方法面向对象的分析方法(OOA)35需求归档•编写需求规约•需求分析阶段的所有文档软件需求说明书（即规约）数据要求说明书初步的用户手册修改、完善与确定软件开发实施计划36需求规约的原则•1．从现实中分离功能，即描述要“做什么”而不是“怎样实现”。•2．要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。•3．如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。•4．规约必须包括系统运行环境。37•5．规约必须是一个认识模型，而不是设计或实现的模型。•6．规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。•7．规约必须允许不完备性并允许扩充。•8．规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。38需求规约IEEE/ANSI830-1993标准Ⅰ.引言A.系统参考文献B.整体描述C.软件项目约束Ⅱ.信息描述A.信息内容表示B.信息流表示：ⅰ数据流ⅱ控制流Ⅲ.功能描述A.功能划分B.功能描述：ⅰ处理说明ⅱ限制∕局限ⅲ性能需求ⅳ设计约束ⅴ支撑图C.控制描述ⅰ控制规约ⅱ设计约束Ⅳ.行为描述A.系统状态B.事件和响应Ⅴ.检验标准A.性能范围B.测试种类C.期望的软件响应D.特殊的考虑Ⅵ.参考书目Ⅶ.附录39•引言：陈述软件目标，在基于计算机的系统语境内进行描述。•信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。•功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。•行为描述：描述作为外部事件和内部产生的控制特征的软件操作。•检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。•参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。•附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。40需求评审•需求确认和验证的手段。•应指定专门人员负责。•按规程严格进行。41需求评审的内容•评审人员评审时往往需要检查以下内容：1.系统定义的目标是否与用户的要求一致；2.系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；3.被开发项目的数据流与数据结构是否确定且充足；4.主要功能是否已包括在规定的软件范围之内，是否都已充分说明；5.设计的约束条件或限制条件是否符合实际；6.开发的技术风险是什么；7.是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。42需求管理•需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动•需求跟踪有两种方式，正向跟踪与逆向跟踪正向跟踪：以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在《需求规约》中找到出处43本章小结•需求工程的几个阶段。•软件需求的概念及种类•需求获取方法•需求分析的原则•需求规约的原则及内容•需求评审的主要内容。44本章作业•1.需求工程的步骤？每个步骤的任务？•2.获取需求的方法?•3.软件需求的种类？•4.需求分析的原则？•5.如何进行需求评审？