第3章需求工程.ppt

1、第3章需求工程、需求工程概要获得需求分析、协商与建模需求规约与验证需求管理、需求工程概要Alan Davis将需求工程概述为“将软件分解为实际的体系结构组件之前的所有活动(但不包括Herb Krasner定义了需求工程的五个生命周期。 需求的定义和分析、需求的决定、需求规格的形成、需求的实现和验证、需求发展管理Matthias Jarke和Klaus Pohl提出了三阶段循环的学说：获取、表示和验证、软件需求工程分为需求获取、需求分析和协议、系统建模、需求规约、需求验证和需求管理六个阶段系统分析师通过与用户的交流，对系统或产品的范围进行有限的说明，对系统或产品相关人员和特征的列表，对系统的技术

2、环境的说明，对系统功能的列表和适用于各种需求的领域的限制，对不同运行条件下的系统或产品的使用情况进行说明的一系列应用程序需求获得的工作产品提供进行需求分析的基础，与需求分析进行协商，需求获得结束后，分析活动对需求进行分类组织，分析各需求的其他需求的关系，检查需求的一致性、重复和遗漏的情况，根据用户的需求进行排序。 在需求获得阶段，用户的要求超出软件系统能够实现的范围，或者实现能力的问题经常发生。不同的用户使用相互冲突的需求、系统建模、建模工具是用户和系统分析师之间的统一语言常见的分析和建模方法包括面向数据流的方法、面向数据结构的方法和面向对象的方法。 需求规约、软件需求规约是分析任务的最终产物

3、，通过完整的信息描述、详细的功能和行为描述、性能需求和设置修订约束的说明、确立适当的检验标准，给予目标软件各种各样的需求。 需求规约作为用户和开发者之间的协议，在以后的软件工程的各个阶段发挥着重要的作用。 作为需求验证、需求开发阶段工作的重新审视手段，需求验证评价功能的正确性、完整性和明确性，以及其他需求。 为了保证软件需求定义的质量，审查应由专门指定的人员负责，按规程严格执行。 在实际的开发过程中，用于获取、分析、建模、协议创建和验证这些需求的开发活动不是线性的，也不是顺序的。 实际上，这些活动是交叉、增加和重复的。 需求管理、需求工程包括软件需求的获取、分析、规定、验证、管理，软件需求管理

4、是所有相关活动的修订版和控制。 也就是说，需求管理是一个系统化方案，用于捕获、组织和记录系统需求，以及用户和项目团队针对不断变化的系统需求达成一致的过程。 需求获取、软件需求包括功能需求性能需求用户或人的要素环境需求接口需求文档需求、数据需求资源使用需求安全保密请求可靠性请求软件成本消耗和开发进度需求其他非功能需求、需求获取方法和策略、顺利的通信路径采访和调查建立用户操作过程， 建立和确立平稳的通信渠道，采访和调查在具体实践中通常采用权衡的方法。 也就是说，我们正在对采访进行适当的修订，但不太详细，能够具有一定的灵活性。一般按照以下原则准备：被提问题应该逐步从整体方面开始提问，下一个问题应该有

5、助于更好地理解和细分上一个问题。 不要限制用户对问题的回答。 这可能会导致本来没有注意到的问题。问题和回答总结后，应该能够反映用户需求的整体情况。 例如：“赛艇比赛成绩核算系统”初次面谈的准备修订计划可以观察用户的操作流程，在用户的实际工作环境中观察用户的工作流程，理解用户的实际操作环境、操作过程和操作要求，并与用户提出的问题陈述相对照，使用户的需求更加全面、组成联合组，方便应用规约技术(FAST ) :提出足够的正式议程，打破用户(用户)和开发者(供应商)的界限，制定组成联合组的会议准备和参与规则，提出用户、开发者、 或者可能是其他外部人员的协调员控制会议使用工作表、图表、贴墙纸、贴墙板等定

6、义机制的目标是确定问题、提出解决方案的要素、协商不同的方法，在有助于实现目标的气氛中描绘初步需求FAST会议步骤，1 )在开发人员和用户之间进行初步访问后，确定FAST会议的时间位置，并在会议日期之前向所有参与者发布产品请求。 2 )每个FAST出席者需要列出环绕系统环境的一系列对象以及对这些对象的操作或对象之间的交互，并开发约束列表(成本、规模、权重等)和性能标准列表(速度、精度等) 这些列表可以不是穷举的，但是希望每个列表能够反映每个人对该系统的感觉。 在举行FAST会议时，如果小组的每个成员提出一个名单，整个小组就会制作一个小组名单，这个小组名单删除冗长的项目，加上表达过程中出现的新思想

7、。 创建所有主题组合列表后，开始讨论活动。 缩短、延长或重新组合列表，以便正确反映要开发的产品。FAST会议步骤(续)、4 )如果创建意见一致的列表，则将小组分成更小的组，各组尝试为各列表中的一个或多个项目开发小规章(即，列表中所包含的单词、短语的细分)。 各组随后将把他们开发的各项小规约提交所有FAST与会者讨论，进行追加、删除或进一步精化等工作。 (在所有讨论过程中，小组可能会提出会议中无法解决的问题。 在这种情况下，请保留问题列表，以便这些想法对今后的活动有帮助。 5 )小规约完成后，各FAST出席者提交产品的准确标准清单，并将该清单提交小组，制作意见一致确定的标准清单。 获得需求后，该

8、列表为需求分析和建模提供基础信息。 另外，在将需求收集为非正式会议、Fast的一部分之后，分析师可以创建使用场景来标识要构建的系统序列。创建用例模型的主要步骤是确定直接使用该系统的用户，即参与者定义该参与者希望使用系统，针对该参与者希望使用系统的每一天使用该系统， 通常是指确定发生什么。需求分析原则1能够表示理解问题信息域2软件完成的功能3软件的行为(外部事件的结果)必须表现出4数据、描述功能和行为的模型，详细5分析过程从要素信息中包含详细信息、信息域、信息域信息内容代表单个数据和控制对象，目标软件全部处理的信息集合由它们构成。 例如，数据对象的“薪水”是重要的数据体的组合，如接收者的姓名、网

9、络支付数、支付总额、扣除额等，信息流指示数据和系统流动的改变方式，输入对象指向中间信息(数据和/或控制) 还是使用了别的构造？ 一个信息结构中的信息是如何与另一个结构中的信息相关联的，抽象、分解和多视点分析，问题抽象方法要求分析者在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系，首先关注一般问题的解决途径，指导特殊问题的解决方法。问题分解的目的是能够将问题分层分解、细分化。 可以将大型或复杂问题分解为若干子问题并进行理解和分析的分解是，直到子问题分解为易于分析理解的部分，例如需求协商为止，协商的过程是讨论需求冲突，找到人人都满意的权衡的协商不是单纯的逻辑或技术上的争论， 组织和行政要素不

10、一致的目标责任的丧失或者组织文化组织的管理态度和士气部门的不同需要注意的是可以解决发现的问题的项目有关人员会议应该讨论非正式讨论不能解决的问题。 一般会议分为三个阶段：叙述阶段讨论阶段决定阶段、需求建模、软件需求分析阶段，建立的模型重点描述系统应该做什么的一般分析方法：面向数据流的结构化分析方法(SA )面向数据结构的分析方法面向对象的分析方法(OOA ) 需求规约和验证、需求规约的原则1从现实中分离出功能，即记述的不是“如何实现”而是“做什么”。 期望使用面向二处理的协议语言(或系统定义的语言)来研究来自环境的各种刺激可能对系统产生什么样的功能反应，定义行为模型以获得“做什么”的协议。 3如

11、果开发的软件只是基于计算机的系统的一个要素，则整个大型系统也包括在规格说明中。 4规约必须包含系统的运行环境。 需求规约的原则(续)，5规约不得为设定修订或实现的模式，而应为认识模式。 6对于任何测试用例，协议必须能够操作，以确定提议的解决方案是否能够满足协议。 七规约必须容许不完整和扩张。 8规约需要局部化和松散结合。 其中包含的信息需要本地化，在修改信息时修改各个段落即可(理想)。此外，条款必须是松散的(即松散联接)的，以便于添加和删除某些段落。需求规约、引言：阐述软件目标，并在基于修订机的系统语境内描述。 信息说明：提供软件必须解决的问题的详细说明，记录信息的内容和关系，流和结构。 功能

12、说明：说明解决问题所需的各项功能。 它以一个或多个图形的形式表示软件的整体结构和软件功能与其他系统元素之间的相互影响，这些软件描述了每个功能的一个处理过程，描述了设置修订约束的性能特性。 动作说明：对外部事件和内部生成的控制特性即软件动作进行说明。 检验标准：表示检验系统成功的标志。 也就是说，对系统进行了怎样的测试，得到了什么样的结果，这表明系统是成功的。 这是“确认测试”的基础。 参考文献：包含对与此软件相关的所有文档的引用。 其中包括其他软件工程文档、技术参考文献、供应商文献、标准等。 附录：包含规章的补充信息、表数据、算法的详细说明、图表和其他资料。 需求验证、需求验证的目的是，在验证需求是否能够反映用户意愿审查员的审查时，检查系统定义的目标是否与用户的要求一致，即系统要求分析阶段提供的文档是否齐全，文档内的说明对用户的要求是否准确反映确定了所开发项目的数据流和数据结