6需求分析选编.ppt

本堂课讲授重点 一、需求分析规格说明书的写法 二、需求工程 三、需求分析工具 四、需求分析的二十条法则 上堂课讲授内容 一、需求分析概述 二、分析建模 三、ERD图 数据规范化 软件系统需要长期保存的信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。 通常用“范式(normal forms)”表示数据的规范化程度。第一范式(1 NF)规范化程度最低，第五范式(5 NF)规范化程度最高。 范式的提高依靠对表的分解来实现，分解后的表越多，访问速度越低，所以需要找一个综合性能和速度的平衡点。在大多数场合选用第三范式都比较恰当。 范式的区分 通常按照属性间的依赖情况区分规范化的程度。 1NF：每个属性值都必须是原子值。 2NF：满足第一范式条件，而且每个非主属性都由整个码决定(而不是由码的一部分来决定)，即不存在非主属性对码的部分依赖。 3NF：符合第二范式的条件，并且不存在非主属性对码的传递依赖。 状态转换图 状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作。 状态图提供了行为建模机制，可以满足第3条分析准则的要求。 状态 状态是任何可以被观察到的系统行为，一个状态代表系统的一种行为。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。 在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。 事件 事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。例如：超时，或者某个动作 符号 在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。 中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。活动表的语法格式如下： 事件名(参数表)/动作表达式 在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。 状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向，箭头线上标出触发转换的事件表达式。 状态图中使用的主要符号 P63 复印机状态转换图 层次方框图 用树形结构的一系列多层次的矩形框描绘数据的层次结构。 树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。 层次方框图的一个例子 Warnier图 表示信息层次结构的另外一种图形工具。 比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。 Warnier图描绘软件产品的例子 IPO图 IPO图是输入、处理、输出图的简称，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。 IPO图使用的基本符号既少又简单，因此很容易学会使用这种图形工具。它的基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序，用箭头清楚地指出数据通信的情况。 IPO图的一个例子图 改进的IPO图的形式 验证软件需求 需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证： 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。 现实性：用现有的硬件技术和软件技术基本上可以实现的。 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。 验证软件需求的方法 验证需求的一致性：对于用自然语言书写的结果，靠人工技术审查，这种非形式化的规格说明书是难于验证的；对用形式化方法书写的结果，可以采用软件工具验证。 验证需求的现实性：参照以往开发类似系统的经验。 验证需求的完整