需求分析.docx
《需求分析.docx》由会员分享，可在线阅读，更多相关《需求分析.docx（18页珍藏版）》请在冰豆网上搜索。
需求分析
第4章需求分析
4.1需求分析的特点
在计算机系统发展的早期，所求解的问题一般比较小，而且问题也容易理解，所以需求分析的重要性没有显现出来。
随着计算机应用领域的扩大和所要处理的问题对象越来越复杂，需求分析的重要性愈加突出，而且需求分析也愈加困难，主要体现在以下几个方面：
1、问题的复杂性
2、交流障碍
3、需求易变性
4、不一致性和不完整性
4.2需求收集
4.2.1需求收集的内容
需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束、软件同其它系统元素的接口细节，定义软件的其它有效性需求。
针对这一目标，需求收集工作主要集中在以下五个方面的内容：
①信息需求（数据需求）
②功能需求
③性能需求
④运行需求
⑤未来需求
4.2.2需求收集的方式
1、访谈
访谈是需求收集的一种重要方式。
访谈从开发人员与用户会面开始，就待开发系统进行面对面的交谈，直至开发人员确信已从用户获取了有关信息。
访谈的类型基本有两种：
程式化的访谈和非程式化的访谈。
访谈结束后，开发人员应该尽快将访谈的内容整理出来，并将整理的结果送一份拷贝给受访用户，以便受访用户再有一次机会澄清某些陈述或增加一些被忽略的信息。
2、问卷调查
问卷调查通过向有关用户发放事先准备好的问卷调查表的方式来获取用户的需求。
问卷调查方式在需要考虑数量特多的用户个体的需求意见时特别有用。
同时，由于受访用户在这种方式下可以有充分的时间对被调查的问题进行思考。
因此，问卷调查的结果可能比访谈取得的信息更准确。
当然，由于问卷调查表是预先设计好的，不能像访谈那样可以及时地获得用户的回答并据此修改后面的谈话内容，因而有可能不如访谈那样能够揭示更多的信息。
3、场景使用
使用场景描述来获取用户需求具有以下几个方面的好处：
①使用场景描述系统的行为，便于用户理解，也会促使额外需求的发现。
②场景可以使得用户在整个需求获取过程中显得积极主动，便于获取用户的真正需求。
4、用户资料收集
认真研读用户资料能够导致准确地把握用户的要求。
现行系统中用户使用的有关表格和报表是最为重要的用户资料。
利用这些用户资料，可以准确地找出现行系统已“做了什么”和“是如何做的”等重要信息，便于理解用户的业务过程，这对决定用户需求特别有用。
4.3数据流建模
教学内容：
主要阐述数据流建模的过程、方法和表示。
教学重点：
数据流图、数据词典和加工说明。
教学难点：
分层数据流图的建模过程。
教学方法：
课堂讲授+案例。
教学要求：
掌握数据流建模的过程和方法，熟悉数据流图、数据词典和加工说明的表示，理解结构化方法在数据流建模中的运用。
思考题：
1）为何任何应用均可用数据流进行建模？
2）为何采用分层数据流图描述系统功能需求，而不是一张图？
3）数据流建模应该从哪个方面着手？
4.3.1数据流图
在可行性研究阶段，数据流图（DataFlowDiagram,DFD）常用来描述系统的逻辑模型，其主要成份有四种：
数据流、数据存储、加工处理、数据的源点和终点。
1、数据流
数据流用箭头表示，箭头方向表示数据流向，在箭头线上标明数据流的名称。
数据流是数据在系统内传播的路径，由一组固定成份的数据组成。
数据流不代表控制流。
数据流反映的是加工处理的对象，而控制流是一种选择或用来影响加工的性质。
2.加工
加工是对数据进行处理的单元，又称数据处理。
在数据流图中，加工一般用一个圆圈或圆角方框来表示，并在圆圈内或圆角方框内标明加工的名称以及加工的编号。
3．数据存储
数据存储用来保存数据流，可以是暂时的，也可以是永久的，同数据流一样，数据存储也由若干数据项组成。
数据存储并不等同于一个文件，它可以表示文件、文件的一部分、数据库的元素或记录的一部分等。
数据可以存储在磁盘、磁带存储器或其它任何介质上。
4．数据的源点和终点
数据的源点和终点代表系统外部的人、物或组织，表示系统中数据的来源和去处。
在数据流图中一般用正方形或立方体来表示。
4.3.2数据词典
数据词典（DataDictionary，DD），又称数据字典，是关于数据信息的集合，是对数据流图中的每个数据，包括数据流和数据存储，进行严格定义的场所，以保持数据在系统中的一致性。
在数据词典中定义的数据条目可能有三种类型：
只含一个数据的数据项（或数据元素）；由多个相关数据组成的数据流；和数据存储。
4.3.3加工说明
在分层数据流图中，子图可以看作是父图中被分解的加工的一种说明，如同数据词典对数据的说明一样。
但数据流图中的“基本加工”由于没有进一步分解得到子图，因而需要加工说明来对其进行描述。
一般说来，IPO图、结构化语言、判定表、判定树等均可作为加工说明的工具。
在描述“基本加工”时，应满足：
描述基本加工如何把输入数据流变换成输出数据流的加工规则；描述实现加工的策略而不是实现加工的细节。
每个加工说明均可同数据词（字）典一样将其记在卡片上。
1．IPO图
IPO（Input/Process/Output，IPO）图是输入/处理/输出图的简称，是由美国IBM公司发展完善起来的一种图形工具，能够方便地描述输入数据、对数据的处理和输出数据之间的关系。
2．结构化语言
结构化语言，又称PDL（ProgramDesignLanguage,PDL）或伪代码（PseudoCode），是一种介于自然语言和形式语言之间的一种半形式语言。
结构化语言通常分为外层和最内层。
3．判定表/判定树
判定表为说明复杂的决策逻辑提供了一种机制，是一种形式化的以表格为基础的表示方法。
判定树是判定表的图形表示，有时比判定表更直观，开发人员可根据用户的需要在二者中选择。
判定表/树的最大优点在于能把在什么条件下完成什么操作表达成得十分清楚、准确、易于理解。
但它的不足之处在于无法表达重复执行的动作。
4.3.4数据流建模步骤
对系统的数据流建模，原则上是由外向里、自顶向下去模拟问题的处理过程，通过一系列的分解，逐步求精地表达出整个系统的信息流动和处理情况。
常用数据流建模步骤如下：
1、画顶层数据流图；
2、画分层数据流图
3．用数据词（字）典定义数据流图中的所有数据；
4．用加工说明详细描述数据流图中的基本加工。
4.4?
?
IDEF0功能建模
教学内容：
IDEF0方法及IDEF方法系列、IDEF0建模过程、IDEF0图。
教学重点：
IDEF0图。
教学难点：
IDEF0建模过程。
教学方法：
课堂讲授+案例。
教学要求：
了解IDEF方法系列，理解IDEF0功能建模过程，掌握IDEF0图。
思考题：
IDEF0图和DFD图中的箭头有何不同？
4.4.1IDEF0图
IDEF0方法用严格的自顶向下、逐层分解的方式来构造系统的功能模型，用IDEF0图来描述。
IDEF0图的主要元素是简单的盒子及箭头。
1、盒子
在IDEF0图中，盒子用方框表示，在方框内部用主动的动词短语来对功能（活动）进行描述，并在盒子的右下角写上盒子的编号。
2．箭头
IDEF0图中，箭头代表数据约束，而不是数据流或执行顺序。
在同一图上，若几个盒子所需的数据约束都满足，则这个几个活动可同时时执行。
3．分层IDEF0图
对于大型系统，一张IDEF0图难以描述，IDEF0方法采用严格的自顶向下、逐层分解的方式建立IDEF0图描述系统的功能模型。
同数据流图相似，顶层图也用来确定系统的范围，但IDEF0图的顶层图有若干个活动，而不是一个活动。
然后，采用结构化分析方法对IDEF0图中的活动逐步分解，展开其有关细节。
为了明确分解过程中数据和图形间的关系，采用ICOM码和结点号来进行标识。
4.4.2IDEF0建模步骤
立IDEF0模型的基本目标是描述系统的功能。
IDEFO方法在详细的功能需求调研基础上，用严格的自顶向下、逐层分解的方式来进行，其基本步骤如下。
1．确定建模的范围、观点及目的
2．建立系统的内外关系图，即A-0图
3．画出顶层图，即A0图
4．建立A0图的一系列子图
5．书写文字说明
4.4.3有关注意事项
在绘制活动图形时，应该注意以下几个方面：
1、盒子
⑴盒子在活动图形中，盒子应按约束关系从左至右，从上到下呈对角线排列；
⑵每一个盒子应有一个在活动图形中的顺序号；
⑶A-0图之下的所有图形中的盒子不能少于3个，不能超过6个；
⑷盒子中的活动名称要使用动词短语，而较少使用专门术语或缩略词。
2、箭头
⑴箭头表示约束条件而不是执行顺序；
⑵输出箭头表示活动可能出现的结果，并不表明在那种条件下一定出现哪种结果；
⑶箭头的详细程度必须与盒子的详细程度相一致；
⑷箭头若可同时用作（或怀疑是）控制及输入时，则将其作为控制；
⑸一个箭头在父图是控制箭头时，在子图中可能是控制，也可能是输入；
⑹一个盒子至少要有一个控制箭头；
⑺箭头线只能是水平线或垂直线；
⑻如果箭头线较长，则应标记它两次；
⑼除特殊原因外，一般将有相同源和目的的箭头用一个箭头代替；
⑽盒子的一边一般不要超过4个箭头，多于4个则可采用一个箭头加分支来处理；
⑾通常不要把一个箭头分裂成对同一盒子的输入及控制箭头；否则，要分别写出所分出2个箭头的标签，以示区别原因；
3、评审和复查
在自顶向下绘制各层图时，应注意每一阶段的模型和图形都要进行评审和阶段复查。
评审人员与图形设计人员不应是相关人员，以保证评审的公正性。
同时，对于一个子系统的所有图纸都要由相关业务部门或其它子系统负责人会签，以确保全局范围内的协调和集成。
整个图纸最后应交上级部门批准和保存。
4.5IDEF1X数据建模
教学内容：
IDEF1X建模步骤和IDEF1X图。
教学重点：
IDEF1X图。
教学难点：
数据建模过程。
教学方法：
课堂讲授+案例。
教学要求：
掌握IDEF1X图，理解IDEF1X数据建模过程。
思考题：
独立实体和从属实体有何区别？
4.5.1IDEF1X图
IDEF1X图的主要成份有三种：
实体、联系和属性。
实体表示包含数据的有关事物；联系反映事物之间的关系；属性则表明事物的特征。
1．实体
实体是具有相同属性或特征的现实或抽象事物的集合，这个集合中的一个元素便称为实体的一个实例。
一个现实世界的事物可以是多个实体的一个实例。
2．联系
在IDEF1X图中，实体间的联系有两种：
确定联系和非确定联系。
确定联系反映的是实体间“一对一”或“一对多”的关系；“非确定联系”反映的是实体间的“多对多”的关系。
3．属性
属性表示现实或抽象的事物一种特性或性质。
如果属性（一个或多个组合）能唯一确定实体的每个实例，则称之为“侯选关键字”。
如果实体存在多个“侯选关键字”，则必须指定其中一个为“主关键字”，其余则为“次关键字”。
4.5.2IDEF1X建模步骤
IDEF1X建模方法用来建立系统的数据模型，其基本步骤如下：
1．0阶段——确定建模目标和计划
2．1阶段——定义实体
3．2阶段——定义联系
4．3阶段——定义键
5．4阶段——定义属性
4.6UML建模语言
教学内容：
UML的构成及4+1视图、静态模型图、动态模型图、UML特点及应用。
教学重点：
UML类图、UML用例图。
教学难点：
4+1视图。
教学方法：
课堂讲授+案例。
教学要求：
了解UML的形成历史，理解4+1视图，掌握UML类图和用例图，明白系统静态结构和动态行为的各种UML描述，了解UML的特点及运用。
思考题：
UML为何采用多个不同的视图来描述系统？
4.6.1UML结构
UML本身有它的结构，这个结构包括：
构造块、公共机制和构架三个部份。
UML构造块有三种：
物件、关系和图。
UML公共机制描述了达到对象建模目的的方法，它们一致地应用在UML语言中，使得UML变得简单。
UML一共提供了四种公共机机制：
规格说明、修饰、公共划分和扩展机制。
UML定义了系统的四个不同视图：
逻辑视图、进程视图、实现视图和部署视图，以捕获系统构架，即系统的组织结构，包括系统分解的组成部分、它们的关联性、交互、机制和指导原则，且这四个不同视图由用例视图集成到一起。
4.6.2UML静态模型图
UML提供的静态模型图有五种：
1．类图
类图描述了系统中存在的类以及类之间的关系，是面向对象软件最常用的一种图。
2.包图
包图由包或类组成，表示包与包、包与类之间的关系，用于描述系统的分层结构。
3．组件图
组件图，又称构件图，用来描述软件的各个组件（包括源代码文件、二进制文件、脚本、可执行文件等）之间的依赖关系。
4．部署图
部署图，又称配置图，显示的是对运行时处理节点以及其中的组件的配置，反映了系统硬件的物理拓扑结构。
5.对象图
对象图描述的一组对象以及它们之间的关系。
4.6.3UML动态模型图
UML提供5种视图捕获UML物件如何交互以产生软件系统所需的行为，即用例图、顺序图、协作图、状态图和活动图。
1．用例图
用例图从系统外部执行者的角度来描述系统需要提供哪些功能，指明这些功能的参与者，即用例图描述了参与者和用例及它们之间的关系。
2．顺序图
顺序图用来建模以时间顺序安排的对象的交互。
顺序图中的主要成份有两类：
对象和消息。
3．协作图
协作图，又称合作图，用来建模对象或角色之间的交互，描述这些对象或角色之间是如何彼此通信的。
4、状态图
状态图描述一个类对象所经历的各种状态以及事件发生时状态的转移条件。
状态图通常是对类图的一个补充。
5．活动图
活动图是由状态图变化而来的，描述需要执行的活动以及执行这些活动的顺序。
活动图既可用于描述操作的行为，也可用来描述用例和对象内部的工作过程。
4.6.4UML特点
UML作为一种对软件密集型系统的制品进行可视化、详述构造和文档化的可视化建模语言，具有如下特点：
1．统一了面向对象方法的基本概念
2．具有更强的建模能力
3．独立于特定的开发语言和开发过程
4.6.5UML应用
UML是一种通用的标准建模语言，可对任何具有静态结构和动态行为的系统进行建模，常用于建立软件系统的模型，适用于系统开发的不同阶段。
1．需求分析
通过用例图来描述系统用户的需求，即对系统感兴趣的外部角色和它们对系统功能的需求。
然后，通过分析建立问题域的静态结构，用类图来描述。
为了实现用例，用动态模型，如状态图、顺序图和协作图等来描述类之间所需的协作。
2．设计
在需求分析的基础上，定义软件系统中的技术细节用到的类，如引入处理用户交互的类、处理数据的类、处理通信和并行性的类等。
3．实现
主要任务是使用面向对象程序设计语言，将来自设计的类转换成源程序代码，用组件图来描述代码组件的物理结构以及组件之间的关系。
用部署图来描述系统中硬件的拓扑结构和组件的分布。
4．测试
UML模型是测试的依据。
例如，单元测试使用类图；集成测试使用组件图、协作图；确认测试使用例图；等等。
4.7用例建模
教学内容：
用例图的表示、用例及参与者的描述、用例建模过程。
教学重点：
用例图的表示，包括参与则、用例及它们之间的关系。
教学难点：
用例间关系的使用。
教学方法：
课堂讲授+案例。
教学要求：
掌握用例的表示，理解用例模型中各种关系的作用和使用，掌握用例建模的方法。
思考题：
1）何时使用用例模型中的关系描述用例？
2）在建立用例模型时，是从参与者着手还是从用例着手？
为何？
3）用例和功能有何区别和联系？
4）用例建模与数据流建模相比有何优势？
4.7.1用例图
用例图非常简单直观，主要有四种基本成份：
系统、参与者、用例和关系。
1、系统
系统是指特开发的任何事物，包括软件、硬件或者过程。
2、参与者
参与者用于表示使用系统的对象，是系统外部的一个实体，以某种方式参与用例的执行过程。
3、用例
用例是参与者为达到某个目的而与系统进行的一系列交互，执行结果将为参与者提供可观察的价值。
4、关系
在用例图中，关系用来描述参与者、用例间的联系，主要有四类关系：
通信关系、泛化关系、包含关系和扩展关系。
（1）通信关系
通信关系用来描述参与者与用例之间的关系。
（2）泛化关系
在用例图中，参与者与参与者之间以及用例与用例之间存在泛化关系。
参与者之间的泛化关系意味着一个参与者可以完成另一个参与者同样的任务，它也可补充额外的任务。
（3）包含关系
包含关系描述了用例间的共同行为。
（4）扩展关系
当对一个已存在的用例增加新的功能时，可使用扩展关系。
扩展关系一般用于有条件地扩展已有用例的行为，是一种不改变原始用例的情况下增加用例行为的一种方法。
4.7.2参与者及用例的描述
在用例图中，参与者和用例均是简单的名字，在用例建模过程中须要进一步描述。
1、参与者描述
参与者描述的内容主要包括参与者的名称、是否为抽象参与及对参与者的简要描述。
2、用例描述
用例描述有许多种方法，如简单文字、模板、表格、形式化语言和图形等，开发人员可根据项目进展及用户特点灵活选择。
下面介绍几种常用方式。
（1）简单文字
简单文字一般用于用例建模的早期，其内容主要是对用例提供功能的简单说明。
（2）模板
模板也是一种文字形式的描述，规定了开发人员须要阐述的有关项目。
（3）表格
表格描述用例时采用二维表格表示参与者的动作和系统的响应，主要描述用例的动作序列。
4.7.3用例建模步骤
用例建模主要用来建立系统的功能模型，其基本步骤如下：
1、找出系统的参与者和用例
确定系统的参与者和用例，也即确定系统边界，是用例建的第一步。
2、区分用例的优先次序
区分用例的优选次序，也即确定哪一项任务是最关键的，哪些用例涉及全局认识，哪些地用例可以为其它用例所重用，等等。
3、详细描述每个用例
详细描述每个用例的主要目的是为了详细描述用例的事件流，包括用例如何开始，如何与参与者进行交互以及如何结束。
4、构造用户界面原型
构造用户界面原型的目的是便于用户能有效地执行用例，为最关键的参与者确定用户界面的外观和感觉。
5、构造用例图
构造用例图的目的是借助用例图中各元素的关系，如包含、泛化、扩展等，给出系统的合理结构，以便用户更易理解和处理。
4.8对象建模
教学内容：
Coad/Yourdon建模方法，包括对象层、结构层、主题层、属性层和服务层等对象模型个层次的建模方法。
教学重点：
面向对象迭代、增量式建模方法。
教学难点：
面向对象迭代、增量式建模方法。
教学方法：
课堂讲授+讨论。
教学要求：
理解Coad/Yourdon建模方法，理解迭代、增量式建模方法，掌握对象标识方法，理解聚合和组合的差别，掌握如何建立属性层和服务层的方法。
思考题：
1）CRC方法如何识别对象？
在分析时，对象和类是同一个概念吗？
2）聚合和组合有何差别？
3）泛化关系和实现关系在软件复用中有何作用？
4）什么是迭代增量式软件开发方法？
4.8.1确定对象&类
对象和类是面向对象方法的两个基本概念。
面向对象方法以对象为中心，以类和继承为构造机制来抽象现实世界，并构建相应的软件系统。
1、对象的表示
对象是现实世界某些事物的一个抽象，它反映该事物在系统中需要保存的信息和发挥作用。
对象是属性值和相应操作的一种封装，对象的属性值反映了对象的状态，对象的操作表明对象具有的能力，用来改变对象的状态。
2、类的表示
类是具有相同属性和操作的一组对象的集合。
分类是人类认识客观世界的基本方法，即忽略事物的非本质特征，只注意那些与当前目标有关的本质特征，多而找出事物的共性，把具有共性的事物归为一类，得出一抽象的概念，即类。
3、确定对象&类的方法
正确确定对象&类是采用面向对象技术提高软件开发质量和生产率的基础。
在实际应用中，应最大限度地降低对象&类标识的主观性。
4、电梯控制系统的对象&类标识示例
电梯控制系统用以调度和控制一幢50层高的建筑物中的5部电梯。
电梯控制系统必须高效而合理地调度电梯。
在没有召唤和未完成的目的地请求时，电梯就应停在最后所到达的楼层，直到再次投入使用。
同时，在将乘客送往目的地之前不能反方向运行。
而且，一个已经满载的电梯（每部电梯均有超载传感器可供系统程序查询了解是否超载）不再受理新的召唤请求。
4.8.2标识结构
标识结构是用来处理对象建模复杂性的机制之一。
整体/部分关系，又称组装结构，反映了事物之间的组成关系。
整体/部件关系有两种情况，一种是部分对象只能隶属于唯一的整体对象；一种是部分对象可以被多个整体对象共享。
1．结构的表示
在UML中，对象&类的结构均在类图中描述，
2．标识结构的方法
对于分类继承关系，可以采用如下的方式来标识：
自顶向下和自底向上方式。
使用自顶向下方式时将一个对象&类考虑成通用的，考察它在问题域中各种可能的专用特性，针对这些专用特性检查：
它属于该问题域吗？
它是该系统的任务吗？
存在继承性吗？
专用特性之间存在差异吗？
等等。
对于整体/部分的聚合和组合关系，也可以从两个方面来考虑。
一方面，把每一个对象的类看成是一个整体，另一方面，把每一个对象的类看成一个部件。
3．电梯控制系统的对象&类结构标识示例。
在考察电梯控制系统的对象&类集合时，我们发现“越载传感器”、“到达面板”和“目的地面板”均是“电梯”的一部分。
同时“电梯”的另一个部分“电梯马达”在系统中需要进行控制。
这样。
通过标识组装结构，发现了一个新的对象&类“电梯马达”。
进一步考察，我们还发现，每个“楼层”均有一个“召唤面板”，因而“楼层”和“召唤面板”之间也构成整体/部分的组装结构。
4.8.3标识主题
在结构化方法中，大多采用层次分解的技术来处理模型的复杂性。
在对象建模的过程中，大多数模型都是非层次式的。
Coad/Yourdon方法使用主题来处理规模比较大的复杂模型。
同时，使用主题可以控制一个用户必须同时考虑的模型数目；使用主题有助于了解模型的总体概貌。
在Coad/Yourdon方法中，主题采用方框来描述，并对每个主题进行编号。
在UML中包可用来把语义上相关的建模元素分组为内聚的单元。
因而也可用来表示主题。
在选择主题时，可采用如下的策略：
对每一个结构增加一个相应的主题；对每个对象增加一个相应的主题；将紧密耦合的主题组合起来得到更好的主题；如果主题的数目较多不符合“7±2规则”，则应进一步精炼主题。
4.8.4定义属性及实例关联
属性是对象&类的数据单元，对象&类只有在其封装的那些数据上才能工作，定义属性使得问题域更加明确，也使对对象&类和结构的认识更深入具体。
在分析阶段，一般不使用属性来表示对象&类之间的关系，而使用对象&类的实例关联来描述。
实例关联可以看成是一种事务规则或应用论域限制。
当实现这些对象的时侯，这些事务规则指明操作如何运行，以确保与系统的策略相一致。
1．符号表示
在UML中，实例的关联表示包括：
关联名称、角色名称、多重性和导航性，
2．定义属性
属性的种类有三种：
描述性属性、命名性属性和参考属性。
描述性属性用来提供对象&类中每个实例的内在特性，是实例表现出来的固有性质或特征。
定义
升级会员 