CH3需求分析课件.pptVIP

第三章 需求分析;本章内容提要;3.1 需求分析的任务;3.1 需求分析的任务;需求分析的任务;需求分析的任务;本章内容提要;访谈和调研 和用户进行访谈和调研通常是适用于任何环境下的最重要最直接的方法之一 访谈的一个主要目标是确保访谈者的偏见或主观意识不会干扰自由的交流，避免理解偏差是做好需求的关键 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化； 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题； 提问和回答在汇总后应能够反映用户需求的全貌。; 专题讨论会 专题讨论会是一种可用于任何情况下的软件需求调研方法，是最有效的获取需求的方法 专题讨论会的目的是鼓励软件需求调研并且在很短的时间内 对讨论的问题达成一致。 专题讨论会一般由开发团队的成员主持，主要讨论系统应具备的特征或者评审系统特性。;脑力风暴(brainstorming) 脑力风暴是一种对于获取新观点或创造性的解决方案而言非常有用的方法 由纽约广告代理的老板Alex F Osborn在1930年发明，其前提是在一般的讨论中，人们害怕别人批评而约束自己，因此而不能产生有创意的点子 脑力风暴是一种技法，可以激发小组成员产生大量的有创意的点子 脑力风暴包括创造一种氛围，让人们感到无拘无束，此时人们可能提出在平时认为不太可能提出的解决方案，但往往收到意想不到的效果 通常，专题讨论会的一部分时间是用于进行脑力风暴，找出关于软件系统的新想法和新特征;3.2.2 面向数据流自顶向下求精 ;FAST，Facilitated Application Specification Techniques , 一种面向团队的需求收集法 访谈或面向数据流求精定义需求时，用户处于被动地位，不能像同一个团队的人齐心协力识别和精化需求 应用规格说明技术提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求 Software is indeed a sport teamwork;3.2.3 简易的应用规格说明技术;3.2.4 快速建立软件原型（Protype）;本章内容提要;3.3 分析建模;需求分析中的三种模型;本章内容提要;3.4 数据建模-实体关系图;3.4 数据建模-实体关系图;3.4 数据建模-实体关系图;3.4 数据建模-实体关系图;某校教学管理ER图;本章内容提要;规范化 --- 将数据的逻辑结构归结为满足一定条件的二维表（关系） 1. 表格中每个信息项必须是一个不可分割的数据项，不可是组项 2. 表格中每一列 (列表示属性)中所有信息项必须是同一类型，各列的名字 (属性名) 互异，列的次序任意 3. 表格中各行 (行表示元组) 互不相同，行的次序任意;3.5 数据规范化;课程、学生和教师三个实体，用三个关系保存它们的信息： 学生(学号，姓名，性别，年龄，年级，专业，籍贯) 教师(职工号，姓名，年龄，职称，职务，工资级别，工资) 课程(课程号，课程名，学分，学时，课程类型) 为表示实体型之间的联系，又建立两个关系： 选课 (学号，课程号，听课出勤率，作业完成率，分数) 教课 (职工号，课程号，授课效果) 这五个关系，组成了该系统的数据库的模型 在每个关系中，属性名下加下划线指明关键字，并规定关键字能唯一地标识一个元组。;通常用“范式(Normal Forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。 范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂 范式级别提高则需要访问的表增多，因此性能(速度)将下降 从实用角度看来，在大多数场合选用第三范式比较恰当;第一范式;满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。 如：;符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。 如：;本章内容提要;3.6 行为建模（ Behavior model）;状态;事件;状态转换图中的符号表示;活动表语法格式;事件表达式语法格式;电话系统的状态图;思考：订货系统的状态转换图;本章内容提要;3.7 其他图形工具;层次方框图的一个例子;3.7 其他图形工具;3.7 其他图形工具--IPO图;IPO图表示主文件更新的例子;IPO图表示订货系统的例子;一种改进的IPO图(也称为IPO表);本章内容提要;3.8 验证软件需求;软件需求正确性的验证的内容;验证软件需求的方法;验证需求的完整性和有效性 理想做法：先根据需求分析