自学内容网 自学内容网

软件工程三 需求获取与结构化分析方法(需求分析、功能建模、数据建模、行为建模、数据字典等)

包括内容如下:

1. 需求获取与需求分析阶段的任务

2. 结构化分析方法

3. 系统需求规格说明

4. 需求评审

5. 需求管理

3.1 需求获取与需求分析阶段的任务

3.1包括:

需求获取的任务和原则

需求获取的过程

软件需求分析阶段的任务

3.1.1需求获取的任务和原则

获取并理解用户的需求是软件工程师所面对的最困难的任务之一。 

导出需求变得如此困难的原因归为以下几个方面的问题:

系统的目标或范围问题; 需求不准确性问题 ; 需求的易变问题 ;    

需求获取除了需要有专业的系统分析师,还需要通过有效的客户/开发者的合作才能成功。 

3.1.1.1 需求获取的任务

(1) 发现和分析问题,并分析问题的原因/结果关系。

(2) 与用户进行各种方式的交流,并使用调查研究方法收集信息。

(3) 按照三个成分观察问题的不同侧面:即数据、过程和接口

(4) 将获取的需求文档化,形式有用例、决策表、需求表等。

3.1.1.2. 需求获取应遵循的原则

(1) 深入浅出的原则。

就是说,需求获取要尽可能全面、细致。获取的需求是个全集,目标系统真正实现的是个子集。 (2) 以流程为主线的原则。

在与用户交流的过程中,应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。流程的描述既有宏观描述,也有微观描述。

3.1.2 需求获取的过程

1. 开发高层的业务模型

2. 定义项目范围和高层需求

3. 识别用户类和用户代表     

  系统的不同用户之间在很多方面存在差异,例如:     

    (1) 使用产品的频率;     

    (2) 用户在应用领域的经验和使用计算机系统的技能;   

    (3) 所用到的产品功能;     

    (4) 为支持业务过程所进行的工作;   

     (5) 访问权限和安全级别

4. 获取具体的需求    

具体需求的来源可以来自以下几种典型的途径。  

(1) 与用户进行交流。   (2) 现有产品或竞争产品的描述文档。       (3) 系统需求规格说明。   (4) 当前系统的问题报告和改进要求。   (5) 市场调查和用户问卷调查。   (6) 观察用户如何工作。  

5. 确定目标系统的业务工作流    

6. 需求整理与总结

必须对上面步骤取得的需求资料进行整理和总结,确定对软件系统的综合要求,即软件的需求。 并提出这些需求实现条件,以及需求应达到的标准。

这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。

3.1.3 软件需求分析阶段的任务

可以把软件需求分析阶段的工作分为4个步骤,即获取需求、分析需求、定义需求和验证需求,如图所示。 

软件需求分析阶段的工作步骤 

1. 需求获取    

通过启发、引导从客户(或用户)那里得到的原始需求是他们的业务要求(needs),简称为N。  

这是分析之前获取的需求,其中可能存在一些实际问题,这些问题只有通过分析才能得到解决,直接把获取的需求作为软件设计阶段的依据将会导致严重的后果。 

2. 需求分析    

认真研究获取的需求,必须考虑以下几方面:  

 (1) 完整性:每项获取的需求都应给出清楚的描述,使得软件开发工作能够取得设计和实现该功能所需要的全部必要信息。  

 (2) 正确性:获取的每项需求必须是准确无误的,并且需求描述无歧义性。  

 (3) 合理性:各项需求之间、软件需求与系统需求之间应是协调一致的,不应存在矛盾和冲突。

(4) 可行性:包括技术可行性 、经济可行性 、社会可行性 。  

 (5) 充分性:获取的需求是否全面、周到。

由于分析的过程会对获取的需求做部分调整,也即从获取的需求N中去掉了一些a,又补充了一些c,从而得到的是分析的需求R1(b+c)。

3. 需求定义    

将已经过分析的需求清晰、全面、系统、准确地描述成为正式的文档,这一步定义需求的工作就是编写需求规格说明

4. 需求验证    

为了确保已定义的需求(需求规格说明)准确无误,并能为客户(或用户)理解和接受,需要对其进行严格的评审。

3.2 结构化分析方法

传统的分析建模方法称为结构化分析(structured analysis,SA)方法。

结构化分析方法是一种建模技术,它建立的分析模型如图所示。

3.2.1 功能建模

功能建模的思想就是用抽象模型的概念,按照软件内部数据传递、变换的关系,自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止。功能模型用数据流图来描述。

数据流图可能会考,需要会画简单的数据流图。

数据流图的基本图形符号

多个数据流之间的关系

与(*),或(+),异或

环境图(也是功能建模里面的,context diagram)

也称为顶层数据流图(或0层数据流图),它仅包括一个数据处理过程,也就是要开发的目标系统。

环境图的作用是确定系统在其环境中的位置,通过确定系统的输入和输出与外部实体的关系确定其边界)

典型的环境图:

例图(画图):

招生系统需求描述

学校首先公布招生条件,考生根据自己的条件报名,之后系统进行资格审查,并给出资格审查信息;

对于资格审查合格的考生可以参加答卷,系统根据学校提供的试题及答案进行自动判卷,并给出分数及答题信息,供考生查询;

最后系统根据学校的录取分数线进行录取,并将录取信息发送给考生。

招生系统的环境图

数据流图的分层

对于稍微复杂一些的实际问题,在数据流图上常常出现十几个甚至几十个加工,这样的数据流图看起来不直观,不易理解,分层的数据流图能很好地解决这一问题。 按照系统的层次结构进行逐步分解,并以分层的数据流图反映这种结构关系,能清楚地表达和容易理解整个系统。

招生系统的分层数据流图

例题:

银行储蓄系统的业务流程:

储户填写的存款单或取款单业务员键入系统

如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率、密码(可选)等信息,并印出存单给储户;

如果是取款而且开户时留有密码,则系统首先核对储户密码,若密码正确或存款时未留密码,则系统计算利息并印出利息清单给储户。

要求画出分层的数据流图,并细化到2层数据流图。

(1) 识别外部实体及输入输出数据流

外部实体:储户、业务员。

输入数据:如果需要储户输入密码,储户才直接与系统进行交互。储户填写的存款或取款信息通过业务员键入系统,可以将存款及取款信息抽象为事务。

输出数据:存款单,利息清单。 

(2) 画出环境图(顶层数据流图)

(3) 画出一层数据流图

(4) 画出二层数据流图    对一层图中的“处理存款”及“处理取款”进行进一步分解,得到二层数据流图,即处理存款的数据流图和处理取款的数据流图。

处理存款的数据流图

处理取款的数据流图

3.2.2 数据建模

在结构化分析方法中,使用实体—关系建模技术来建立数据模型。

这种技术是在较高的抽象层次(概念层)上对数据库结构进行建模的流行技术。

实体—关系模型表示为可视化的实体—关系图(entity-relationship diagram,ERD),也称为ER图。

ER图中仅包含3种相互关联的元素:数据对象(实体)、描述数据对象的属性数据对象彼此间相互连接的关系

数据对象:

数据对象是目标系统所需要的复合信息的表示,所谓复合信息是具有若干不同属性的信息。

在ER图中用矩形表示数据对象。

属性

属性定义数据对象的特征,如数据对象学生的学号、姓名、性别、专业等,课程的课程编号、课程名称、学分等。

在ER图中用椭圆或圆角矩形表示属性,并用无向边将属性与相关的数据对象连接在一起。

关系

不同数据对象的实例之间是有关联关系的,在ER图上用无向边表示。

在无向边的两端应标识出关联实例的数量,也称为关联的重数。

从关联重数的角度可以将关联分为3种。

(1) 一对一(1:1)关联 (2) 一对多(1:m)关联 (3) 多对多(m:n)关联

实例关联还有“必须”和“可选”之分。

关联数量的表示

关系的属性

关系本身也可能有属性,这在多对多的关系中尤其常见,如学生和课程之间的关系可起名为“选课”,其属性应该有学期、成绩等。

关系属性的表示:在表示关系的无向边上再加一个菱形框,并在菱形框中标明关系的名字,关系的属性同样用椭圆形或圆角矩形表示,并用无向边将关系与其属性连接起来。  

3.2.3 行为建模

状态转换图(简称状态图)通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。状态图中使用的主要符号如图所示。

状态

状态是任何可以被观察到的系统行为模式,一个状态代表系统的一种行为模式,状态规定了系统对事件的响应方式。

状态可能有:初态(初始状态)、终态(最终状态)和中间态。

在一张状态图中只能有一个初态,而终态则可以有多个,也可以没有。

状态的表示:初态用实心圆表示,终态用牛眼图形表示,中间态用圆角矩形表示。

 

 

状态转换

状态图中两个状态之间带箭头的连线称为状态转换。

状态的变迁通常是由事件触发的,在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式。

如果在箭头线上未标明事件,则表示在源状态的内部活动执行完之后自动触发转换。

状态转换

下图为计算机应用软件的启动过程,在这个过程中没有外部事件触发,每个状态下的活动完成时,状态发生转换。

事件

事件是在某个特定时刻发生的事情,它是对引起系统做动作或从一个状态转换到另一个状态的外部事件的抽象。

事件表达式的语法如下:  事件说明 [守卫条件]/动作表达式

(1) 事件说明的语法如下:        

事件名(参数表)

(2) 守卫条件是一个布尔表达式。如果同时使用守卫条件和事件说明,则当且仅当事件发生且布尔表达式成立时,状态转换才发生。如果只有守卫条件没有事件说明,则只要守卫条件为真,状态转换就发生。

(3) 动作表达式是一个过程表达式,当状态转换开始时执行该表达式。

存款过程的状态图(考虑新开户 )

3.2.4  数据字典

数据字典以词条方式定义在数据模型、功能模型和行为模型中出现的数据对象及控制信息的特性,给出它们的准确定义,包括数据流、加工、数据文件、数据元素,以及数据源点、数据汇点等。 数据字典成为把3种分析模型黏合在一起的“黏合剂”,是分析模型的“核心”。

词条描述

对于在数据流图中每一个被命名的图形元素均加以定义;

其内容包括图形元素的名字,图形元素的别名或编号,图形元素类别(如加工、数据流、数据文件、数据元素、数据源点或数据汇点等)、描述、定义、位置等。 

数据流词条

数据流是数据结构在系统内传播的路径,数据流词条应包括以下几项内容。

①数据流名:要求与数据流图中该图形元素的名字一致。

②简述:简要介绍它产生的原因和结果。

③组成:数据流的数据结构。

④来源:数据流来自哪个加工或作为哪个数据源的外部实体。

⑤去向:数据流流向哪个加工或作为哪个数据汇点的外部实体。

⑥流通量:单位时间数据的流通量。

⑦峰值:流通量的极限值。

数据元素词条

数据流图中的每个数据结构都是由数据元素构成的,数据元素是数据处理中最小的、不可再分的单位,它直接反映事物的某一特征。

① 类型:数据元素分为数字型与文字型。数字型又分为离散值和连续值,文字的类型用编码类型和长度区分。

② 取值范围:离散值的取值或是枚举的(如3,17,21),或是介于上下界的一组数(如2..100);连续值一般是有取值范围的实数集(如0.0..100.0)。对于文字型,文字的取值需加以定义。

③ 相关的数据元素及数据结构。

数据存储文件词条

数据存储文件是数据保存的地方。一个数据存储文件词条应有以下几项内容。

① 文件名:要求与数据流图中该图形元素的名字一致。

② 简述:简要介绍存放的是什么数据。

③ 组成:文件的数据结构。

④ 输入:从哪些加工获取数据。

⑤ 输出:由哪些加工使用数据。

⑥ 存取方式:分为顺序、直接、关键码等不同存取方式。

⑦ 存取频率:单位时间的存取次数。

加工词条

加工可以使用诸如判定表、判定树、结构化语言等形式表达,主要描述如下。

① 加工名:要求与数据流图中该图形元素的名字一致。

② 编号:用以反映该加工的层次和父子关系。

③ 简述:加工逻辑及功能简述。

④ 输入:加工的输入数据流。

⑤ 输出:加工的输出数据流。

⑥ 加工逻辑:简述加工程序和加工顺序。

数据源点及数据汇点词条

对于一个数据处理系统来说,数据源点和数据汇点应比较少。

① 名称:要求与数据流图中该外部实体的名字一致。

② 简述:简要描述是什么外部实体。

③ 有关数据流:该实体与系统交互时涉及哪些数据流。

④ 数目:该实体与系统交互的次数。

数据结构描述

在数据字典的编制中,分析员最常用的描述数据结构的方式有定义式、Warnier图等。

定义式:  在数据流图中,数据流和数据文件都具有一定的数据结构,因此,必须以一种清晰、准确、无二义性的方式来描述数据结构。

Warnier图: Warnier图是表示数据结构的另一种图形工具,它用树形结构来描绘数据结构。

定义式中的符号

3.2.5  加工规格说明

在对数据流图的分解中,位于层次树最低层的加工也称为基本加工或原子加工,对于每一个基本加工都需要进一步说明,这称为加工规格说明。

在编写基本加工的规格说明时,主要目的是要表达“做什么”,而不是“怎样做”。

加工规格说明应满足如下的要求:

(1) 对数据流图的每一个基本加工,必须有一个加工规格说明。

(2) 加工规格说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。

(3) 加工规格说明必须描述实现加工的策略而不是实现加工的细节。

(4) 加工规格说明中包含的信息应是充足的,完备的,有用的,没有重复的多余信息。

决策表

决策表由4个部分组成:

左上部分是条件茬,在此区域列出了各种可能的单个条件;

左下部分是动作茬,在此区域列出了可能采取的单个动作;

右上部分是条件项,在此区域列出了针对各种条件的每一组条件取值的组合;

右下部分是动作项,这些动作项与条件项紧密相关,它指出了在条件项的各组取值的组合情况下应采取的动作。

决策表举例: 商店业务处理系统中“检查订货单” 的决策表。

决策表的改进:  

如果表中有两条或更多的处理规则具有相同的动作,并且其条件项之间存在着某种关系,就可设法将它们合并。

建立决策表的步骤:

(1) 列出与一个具体过程(或模块)有关的所有处理。

(2) 列出过程执行期间的所有条件(或所有判断)。

(3) 将特定条件取值组合与特定的处理相匹配,消去不可能发生的条件取值组合。

(4) 将右部每一纵列规定为一个处理规则,即对于某一条件取值组合将有什么动作。

决策树

决策树(decision tree)也是用来表达加工逻辑的一种工具,有时侯它比决策表更直观。

检查订货单的决策树:

3.3  系统需求规格说明

需求分析阶段的重要任务之一是根据分析的结果编写需求规格说明,经过严格评审并得到用户确认之后,作为这个阶段的最终成果。

按照国家标准GB/T 8567—2006《计算机软件文档编制规范》,涉及需求规格说明的文档有“软件需求规格说明(SRS)”、“数据需求说明(DRD)”等。


原文地址:https://blog.csdn.net/m0_74027860/article/details/144727257

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!