软件需求工程备课34.docx

软件需求工程备课34.docx

《软件需求工程备课34.docx》由会员分享，可在线阅读，更多相关《软件需求工程备课34.docx（16页珍藏版）》请在冰豆网上搜索。

软件需求工程备课34

软件需求工程备课资料

教材：

毋国庆梁正平

第三章需求获取

需求获取过程：

3.1确定项目的目标和范围

根据项目目标把项目相关人员定位到一个共同的和明确的方向上，并决定软件系统的范围。

目标需求：

——从开发商角度

》为客户提供便利的自动售货功能；

》通过管理系统向顾客提供品种较齐全的消费品；

》吸引顾客对商品的兴趣；

》高可靠性

——从零售商的角度

》能吸引和方便更多的顾客；

》代替人工操作，节省开支；

——从开发人员角度

》使用较为先进的开发技术和工具；

》建立高科技系统。

3.2确定调查对象

3.3实地收集信息

1.步骤

——向掌握全局的负责人调查；

——向部门负责人调查；

——向业务人员调查；

2.方式

——座谈会

——书面咨询

——利用用例表示

3.需求信息分类

——目标需求

——用例说明

——业务规则

——功能需求

——性能需求

——外部接口需求

——限制

——数据定义

4.确定非功能需求

——可靠性

——可扩充性

——安全性

——互操作性

——易使用性

——可维护性

——可移植性

——可重用性

3.4使用场景技术的需求获取

场景是指用户与软件系统实现某个目标二进行交互活动过程的描述。

是对使用系统经历的描述

1.场景的构成

——执行者；

——进入场景前系统状态；

——执行者的目的；

——动作和事件序列（包括正常或非正常事件流）。

2.场景的表示

非形式化表示

形式化表示

自然语言

转台图

结构化语言

流程图

图形

时序图

动漫画等

代数描述图等

3.5使用用例的需求获取

用例描述可发生的所有事件序列，描述软件系统与外部执行者的交互顺序，而场景描述起哄的一部分，因此，用例也可以说是场景的集合，一个场景是用例的实例。

——例如;ATM机的用例模型和取现金的用例。

——场景技术特点：

》把软件系统的需求信息文本化；

》有助于实现软件系统前，明确用户与软件系统的相互作用；

》可以把当前系统存在的问题作为实例记录下来；

》可以成为项目相关人员间的共同语言；

》具体、易理解；

第四章需求分析

——基本任务：

提炼、分析和审查已收集到的需求信息，找出真正的和具体的需求；

——具体工作：

》建立系统关联图；

》构建用户接口模型；

》分析需求可行性；

》确定需求的优先级；

》需求过程；

》建立数据词典。

4.1建立系统关联图

根据需求获取阶段确定的系统范围，用图形表示系统与外部实体间的关联。

——关联图含义：

用于描述系统与外部实体间的界限和接口，而且明确通过接口的信息流和物质流。

类似于结构化需求建模中的0层图。

——关联图图例：

》系统表示为椭圆，内有名字；

》带标识的有向边表示系统系统与外部实体间的关系和信息（物质）流向；

》方框表示系统外部实体。

——实例：

4.2分析需求的可行性

——目的：

在允许的成本和性能要求以及系统范围内，分析每项需求得以实施的可能性。

目的是明确风险。

——风险类型：

》性能风险；

》安全风险；

》过程风险；

》实现技术风险；

》数据库风险；

》日程风险；

》外部接口风险；

》稳定风险。

4.3构建用户接口原型

——含义：

一个可能的局部实现。

——目的：

对于软件开发人员或用户不能明确化的需求，通过建立相应的用户接口原型然后评估该原型，使得项目相关人员能更好理解所要解决的问题。

——分类：

抛弃型原型、进化型原型。

——构建方法：

》纸上原型化

》人工模拟原型化

》自动原型化

4.4确定需求的优先级别

4.5需求建模

4.6建立数据词典

1.含义

是定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、格式和度量单位、精度及允许取值范围的共享数据仓库。

2.作用

确保软件开发人员使用统一的数据定义，提高需求分析、设计、实现和维护过程的可跟踪性。

3.注意

每个项目建立一个独立的数据字典，而不是每个需求出现的地方定义每个数据项。

第五章需求建模方法与技术

5.1软件工程中的模型

1.模型分类

——描述性模型：

能真实和较完整地反映客观世界（如：

照片）；

——规约性模型：

能用于创造新事务的规约（如需求模型）；

——探测性模型：

过渡性的、经常被修改而非最终决定的模型。

2.软件工程中的模型概念与数学和逻辑学中的模型概念不一样

软件工程中的模型

数学和逻辑中的模型

对客观世界的问题领域进行抽象，并用某描述方法表示的结果

满足理论的客观世界中的对象集合

例：

开发过程模型、数据流模型、实体关联模型、状态转移模型等

5.2结构化的需求建模方法

1.作用

主要用于分析系统的功能，是一种直接根据数据流划分功能层次的分析方法。

3.SA方法的特点

——表达问题时尽可能使用图形符号方式，使非计算机专业人员也易于理解；

——设计数据流图时只考虑系统必须完成的基本功能，不需要考虑如何具体地实现这些功能。

4.SA基本思想

化整为零，各个击破

5.SA方法的描述手段

——一套分层的数据流图

——一本词典

——其它补充材料

6.数据流图

——描述系统内部处理流程、用于表达软件系统需求模型的一种图形工具。

——数据流（X,Y,Z）

》一组数据项组成的数据；

》从源点流向加工，从加工流向加工，从加工流向终点，从加工流向文件，从文件流向加工；

》流向或流出文件的数据流可以不指定名称，而给出文件名。

——加工（P1,P2）

》对数据进行的操作或变换称为加工；

——文件

》存放数据的逻辑单位；

——源点和终点

》表示数据的来源和最终去向，主要代表软件系统外的实体。

——例：

7.分层的DFD

8.画分层DFD的步骤

——确定软件系统的输入/输出数据流、源点和终点；

——将基本系统模型加上源点和终点，构成顶层DFD；

——画出各层的DFD

——数据词典

用于描述数据的具体含义和加工的说明，由数据词典和加工就可构成软件系统的逻辑模型（或需求模型）。

》数据流条目：

定义数据流，说明由哪些数据项组成数据流，数据流的定义也采用简单的形式符号方式，如=+|{}等

订票单可定义为：

订票单=顾客信息+订票日期+出发日期+航班号+目的地+……

顾客信息=姓名+性别+身份证号+联系电话

选修课程数据流可定义为：

选修课程=课程表+教师+教材

课程表={课程名+星期几+上课时间+教室}

教师={主讲教师名+辅导教室名}

DFD中所有数据定义完毕后，汇总。

》文件条目：

定义文件，说明组成文件的所有数据项，同时说明文件的组成方式。

航班表文件={航班号+出发地+目的地+时间}

组成方式=按航班号大小排列

》加工条目：

说明加工内容

5.3SA方法的分析步骤

1.理解和分析当前的现实环境，以获得当前系统的具体模型

2.建立当前系统的逻辑模型：

强调做什么

3.建立目标系统的逻辑模型

4.进一步完善

5.4面向对象的需求建模方法

1.需求分析内容

——问题分析

主要任务是收集并确认用户的需求信息，描述静态关系，建立关于对象的分析模型。

——应用分析

主要任务是动态描述系统中对象的合法状态序列，并用动态模型表达对象的动态行为、对象之间的消息传递和协同工作的动态信息。

对象的动态行为与静态结构密切相关并受其约束，静态结构限制了对象状态的取值范围，而动态结构又反映了对象状态的变化序列。

——面向对象设计

2.分析过程

面向对象建模技术（OMT）的基本思想是将面向对象的分析过程视为一个模型的构建过程：

——构件描述系统静态数据结构的对象模型——类图

——构件描述系统控制结构的动态模型——状态转换图和序列图

——构件描述系统功能结构的功能模型——数据流图

4.基于OMT的需求建模步骤

5.有关图形工具

——扩充的状态转换图

—序列图

——实例：

见教材

第六章需求定义——需求规格说明

1.需求规格说明的作用

——是软件设计和实现的基础

——是测试和用户验收软件系统的重要依据

——能为软件维护提供重要的信息

2.需求规格说明的结构和内容

3.需求规格说明文档的编写要求

4.需求规格说明的描述语言

第七章需求验证

1.需求验证的目的和意义

——发现和修复需求规格说明书存在的问题，并避免在软件系统设计和实现时出现返工。

——要求各方面人员从不同的技术角度对需求规格说明文档作出综合性评价。

——存在的问题：

没有很好的方法证明一个需求规格说明是正确的。

——从4个方面进行验证：

》一致性

》完整性

》现实性（可行性）

》有效性

——审查过程：

——审查的内容：

》需求是否完整？

》需求是否一致？

》需求是否可理解？

》需求是否明确？

》需求是否可实现？

》需求是否可跟踪？

》需求是否易于修改？

》需求规格说明文档是否完整？

》……

2.需求验证的内容和方法

3.需求评审

——审查人员的确定和分工

——正式的审查过程

——审查的内容

——需求评审面临的困难

4.需求测试

基于人工，对每个需求通过设计一个或多个可能的测试用例，使这些用例能用于检查系统是否满足需求。

通过跟踪每个测试用例的执行路径，系统分析员可以发现一些布正确和遗漏的需求等。

5.编写用户使用手册草案

6.解释需求模型