发现求精建模规约需求工程是系统地使用已被证明的原理技术Read课件

第11章

分析概念和原则

软件工程

第11章

分析概念和原则

软件工程1第11章

分析概念和原则11.1需求分析11.2软件的需求诱导11.2.1过程的启动11.2.2便利的应用规约技术11.2.3质量功能部署11.2.4use-case第11章

分析概念和原则11.1需求分析2第11章

分析概念和原则11.3分析原则11.3.1信息域11.3.2建模11.3.3划分11.3.4要素视图和实现视图

11.4软件原型实现

11.4.1选择原型实现方法11.4.2原型方法和工具

第11章

分析概念和原则11.3分析原则3第11章

分析概念和原则11.5规约11.5.1规约原则11.5.2表示11.5.3软件需求规约11.6规约评审11.7小结第11章

分析概念和原则11.5规约4需求分析任务:发现求精建模规约需求工程是系统地使用已被证明的原理、技术、语言和工具去处理价格有效的分析、文档以及用户需要的系统的外部行为规约的不断演化。需求分析任务:发现511.1需求分析需求分析是种软件工程活动在系统级软件分配和软件设计间起桥梁作用系统工程软件需求分析软件设计11.1需求分析需求分析是种软件工程活动系统工程软件需求分6问题识别评估和方案综合建模规约评审软件需求分析5个工作阶段：问题识别软件需求分析5个工作阶段：7软件需求分析中的相互通信总是要在两方或多方间进行

11.2软件的需求诱导

软件需求分析中的相互通信总是要在两方或多方间进行11.28客户和开发者之间最常用的交流方式以及开始相互通信过程的技术是进行预备会议或访谈。必须启动通信活动，分析员可从询问一组语境无关的问题开始，语境无关的问题就是，一组将导致对问题、需要解决方案的人员、希望的解决方案的性质以及第一次遭遇的效率等的基本理解的问题。第一组语境无关的问题关注于客户、整体目标和收益。11.2.1过程的启动

客户和开发者之间最常用的交流方式以及开始相互通信过程的技术是9在中立的地点举行会议建立准备和参与会议的规则建议一个足够正式的议程而又是足够非正式一个“协调者”控制会议使用一种“定义机制”(工作表、图表等)目标是标识问题、方案的要素、商议的方法、解决方案需求典型FAST—11.2.2便利的应用规约技术方法：在中立的地点举行会议典型FAST—11.2.2便利的应用规约10质量功能部署(QFD)是一种质量管理技术，它将客户的需要翻译为软件的技术需求。QFD“集中于最大限度地让客户满意”。QFD强调理解什么是对客户有价值的，然后在整个工程活动中部署这些价值。11.2.3质量功能部署质量功能部署(QFD)是一种质量管理技术，它将客户的需要翻译11质量功能部署(QFD)标识三类需求：

正常的需求期望的需求兴奋的需求11.2.3质量功能部署质量功能部署(QFD)标识三类需求：

11.2.3质量功能部1211.2.4use-case当需求作为非正式会议、FAST或QFD的一部分而收集之后，软件工程师可创建一组标识一串待构造系统的使用场景。这些场景被称为：use-case，它提供了系统将被如何使用的描述。控制软件的4种交互模式（角色）：编程模式(编程员)、测试模式(测试员)、监控模式(监控员)、纠错模式(纠错员)通常，一个use-case只简单地是一段撰写的叙述，描述某参与者在和系统交互时的角色。11.2.4use-case当需求作为非正式会议、FAST1311.3分析原则

必须表示和理解问题的信息域必须定义软件将完成的功能必须表示软件的行为(作为外部事件的结果)必须划分描述信息、功能和行为的模型分析过程应该从要素信息移向细节实现11.3分析原则必须表示和理解问题的信息域14针对“需求工程”的指导性原则：建立模型前先理解问题。开发使用户了解人机交互的原型记录每个需求的起源及原因使用多个需求视图给需求赋予优先级努力删除歧义性针对“需求工程”的指导性原则：15信息域包含三个数据和控制视图：11.3.1信息域信息内容和关系（数据模型）：表示个体数据和控制对象，它们构成了某个更大的被该软件变换的信息集合。信息流：表示数据和控制在系统中流动时变化的方式。信息结构：表示各种数据和控制项的内部组织。信息域包含三个数据和控制视图：11.3.1信息域信息内容1611.3.2建模创建系统的模型:功能模型行为模型

｛输入处理输出11.3.2建模创建系统的模型:｛输入1711.3.3划分本质上:划分将问题分解为其构成成分概念上:我们建立信息或功能的层次表示，然后划分最上层的元素，通过在层次上垂直向下移动而暴露更多的细节或在层次上水平移动而分解问题。11.3.3划分本质上:划分将问题分解为其构成成分1811.3.3划分在层次上垂直向下移动而显露更多的细节在层次上水平移动而分解问题

11.3.3划分在层次上垂直向下移动而显露更多的细节1911.3.4要素视图和实现视图软件需求的基本视图给出了将要完成的功能和将要处理的信息，而不管实现细节。软件需求的实现视图给出了处理功能和信息结构的现实世界表示。

软件需求分析应该着重于软件将完成什么，而不是处理将如何实现11.3.4要素视图和实现视图软件需求的基本视图给出了将要2011.4软件原型实现

11.4.1选择原型实现方法

原型范型：封闭结束――丢弃型原型实现开放结束――演化型原型实现11.4软件原型实现

11.4.1选择原型实现方法

原型21原型实现的候选因素可被定义：软件应用领域软件应用复杂性客户特征项目特征

原型实现的候选因素可被定义：软件应用领域22客户和原型交互信息的两个基本点：客户资源被用于原型评估和精化客户能够以即时的方式作出需求决策发现求精建模规约需求工程是系统地使用已被证明的原理技术Read课件23建议原型的实现方法建议原型的实现方法24三个类属的方法和工具类：

11.4.2原型实现方法和工具第四代技术可复用软件构件形式化规约和原型实现环境三个类属的方法和工具类：11.4.2原型实现方法和工具第四2511.5.1规约原则分离功能性和实现开发一个系统的行为模型--包含了系统对各种数据和功能的反应通过刻画其他系统构件和软件交互的方式，建立软件操作的语境11.5规约11.5.1规约原则分离功能性和实现11.5规约264.定义系统运作的环境并指明“一组高度缠绕在一起的代理如何对环境中由其他代理产生的刺激（对象的变化）作出反应”5.创建认知模型而不是设计或实现模型6.认识“规约必定是不完整的和可增加的”7.建立规约的内容和结构，并使得它能适应未来的变化11.5.1规约原则4.定义系统运作的环境并指明“一组高度缠绕在一起的代理如何对2711.5.2表示指导原则：表示格式和内容应该和问题相关包含在规约中的信息应该是嵌套的图和其他符号应该在数量上有所限制，并在使用上一致表示应该是可修订的11.5.2表示指导原则：2811.5.3软件需求规约软件需求规约的候选格式引言信息描述--功能描述，行为描述确认标准--确认标准的规约是对其他需求的隐式评审参考书目和附录

11.5.3软件需求规约软件需求规约的候选格式引言29发现求精建模规约需求工程是系统地使用已被证明的原理技术Read课件3011.6规约评审软件需求规约(和/或原型)的复审是由软件开发者和客户一起进行的，因为规约构成了设计和以后的软件工程活动的基础，在进行复审时必须给予特别的重视。11.6规约评审软件需求规约(和/或原型)的复审是由软件开3111.7小结

需求分析必须关注问题的：信息功能行为域11.7小结

需求分析必须关注问题的：信息3211.7小结

分析后的实现方法：创建模型划分问题描述需求要素表示以后的实现细节11.7小结

分析后的实现方法：创建模型33需求分析是软件工程过程的第一步骤，它被精化为具体的规约，它是后面所有软件设计活动的基础。

软件需求规约作为分析的结果而被开发11.7小结

需求分析是软件工程过程的第一步骤，它被精化为具体的规约，它是34

第11章

分析概念和原则

软件工程

第11章

分析概念和原则

软件工程35第11章

分析概念和原则11.1需求分析11.2软件的需求诱导11.2.1过程的启动11.2.2便利的应用规约技术11.2.3质量功能部署11.2.4use-case第11章

分析概念和原则11.1需求分析36第11章

分析概念和原则11.3分析原则11.3.1信息域11.3.2建模11.3.3划分11.3.4要素视图和实现视图

11.4软件原型实现

11.4.1选择原型实现方法11.4.2原型方法和工具

第11章

分析概念和原则11.3分析原则37第11章

分析概念和原则11.5规约11.5.1规约原则11.5.2表示11.5.3软件需求规约11.6规约评审11.7小结第11章

分析概念和原则11.5规约38需求分析任务:发现求精建模规约需求工程是系统地使用已被证明的原理、技术、语言和工具去处理价格有效的分析、文档以及用户需要的系统的外部行为规约的不断演化。需求分析任务:发现3911.1需求分析需求分析是种软件工程活动在系统级软件分配和软件设计间起桥梁作用系统工程软件需求分析软件设计11.1需求分析需求分析是种软件工程活动系统工程软件需求分40问题识别评估和方案综合建模规约评审软件需求分析5个工作阶段：问题识别软件需求分析5个工作阶段：41软件需求分析中的相互通信总是要在两方或多方间进行

11.2软件的需求诱导

软件需求分析中的相互通信总是要在两方或多方间进行11.242客户和开发者之间最常用的交流方式以及开始相互通信过程的技术是进行预备会议或访谈。必须启动通信活动，分析员可从询问一组语境无关的问题开始，语境无关的问题就是，一组将导致对问题、需要解决方案的人员、希望的解决方案的性质以及第一次遭遇的效率等的基本理解的问题。第一组语境无关的问题关注于客户、整体目标和收益。11.2.1过程的启动

客户和开发者之间最常用的交流方式以及开始相互通信过程的技术是43在中立的地点举行会议建立准备和参与会议的规则建议一个足够正式的议程而又是足够非正式一个“协调者”控制会议使用一种“定义机制”(工作表、图表等)目标是标识问题、方案的要素、商议的方法、解决方案需求典型FAST—11.2.2便利的应用规约技术方法：在中立的地点举行会议典型FAST—11.2.2便利的应用规约44质量功能部署(QFD)是一种质量管理技术，它将客户的需要翻译为软件的技术需求。QFD“集中于最大限度地让客户满意”。QFD强调理解什么是对客户有价值的，然后在整个工程活动中部署这些价值。11.2.3质量功能部署质量功能部署(QFD)是一种质量管理技术，它将客户的需要翻译45质量功能部署(QFD)标识三类需求：

正常的需求期望的需求兴奋的需求11.2.3质量功能部署质量功能部署(QFD)标识三类需求：

11.2.3质量功能部4611.2.4use-case当需求作为非正式会议、FAST或QFD的一部分而收集之后，软件工程师可创建一组标识一串待构造系统的使用场景。这些场景被称为：use-case，它提供了系统将被如何使用的描述。控制软件的4种交互模式（角色）：编程模式(编程员)、测试模式(测试员)、监控模式(监控员)、纠错模式(纠错员)通常，一个use-case只简单地是一段撰写的叙述，描述某参与者在和系统交互时的角色。11.2.4use-case当需求作为非正式会议、FAST4711.3分析原则

必须表示和理解问题的信息域必须定义软件将完成的功能必须表示软件的行为(作为外部事件的结果)必须划分描述信息、功能和行为的模型分析过程应该从要素信息移向细节实现11.3分析原则必须表示和理解问题的信息域48针对“需求工程”的指导性原则：建立模型前先理解问题。开发使用户了解人机交互的原型记录每个需求的起源及原因使用多个需求视图给需求赋予优先级努力删除歧义性针对“需求工程”的指导性原则：49信息域包含三个数据和控制视图：11.3.1信息域信息内容和关系（数据模型）：表示个体数据和控制对象，它们构成了某个更大的被该软件变换的信息集合。信息流：表示数据和控制在系统中流动时变化的方式。信息结构：表示各种数据和控制项的内部组织。信息域包含三个数据和控制视图：11.3.1信息域信息内容5011.3.2建模创建系统的模型:功能模型行为模型

｛输入处理输出11.3.2建模创建系统的模型:｛输入5111.3.3划分本质上:划分将问题分解为其构成成分概念上:我们建立信息或功能的层次表示，然后划分最上层的元素，通过在层次上垂直向下移动而暴露更多的细节或在层次上水平移动而分解问题。11.3.3划分本质上:划分将问题分解为其构成成分5211.3.3划分在层次上垂直向下移动而显露更多的细节在层次上水平移动而分解问题

11.3.3划分在层次上垂直向下移动而显露更多的细节5311.3.4要素视图和实现视图软件需求的基本视图给出了将要完成的功能和将要处理的信息，而不管实现细节。软件需求的实现视图给出了处理功能和信息结构的现实世界表示。

软件需求分析应该着重于软件将完成什么，而不是处理将如何实现11.3.4要素视图和实现视图软件需求的基本视图给出了将要5411.4软件原型实现

11.4.1选择原型实现方法

原型范型：封闭结束――丢弃型原型实现开放结束――演化型原型实现11.4软件原型实现

11.4.1选择原型实现方法

原型55原型实现的候选因素可被定义：软件应用领域软件应用复杂性客户特征项目特征

原型实现的候选因素可被定义：软件应用领域56客户和原型交互信息的两个基本点：客户资源被用于原型评估和精化客户能够以即时的方式作出需求决策发现求精建模规约需求工程是系统地使用已被证明的原理技术Read课件57建议原型的实现方法建议原型的实现方法58三个类属的方法和工具类：

11.4.2原型实现方法和工具第四代技术可复用软件构件形式化规约和原型实现环境三个类属的方法和工具类：11.4.2原型实现方法和工具第四5911.5.1规约原则分离功能性和实现开发一个系统的行为模型--包含了系统对各种数据和功能的反应通过刻画其他系统构件和软件交互的方式，建立软件操作的语境11.5规约11.5.1规约原则分离功能性和实现11.5规约604.定义系统运作的环境并指明“一组高度缠绕在一起的代理如何对环境中由其他代理产生的刺激（对象的变化）作出反应”5.创建认知模型