第3章需求分析ppt课件.ppt

《第3章需求分析ppt课件.ppt》由会员分享，可在线阅读，更多相关《第3章需求分析ppt课件.ppt（67页珍藏版）》请在三一文库上搜索。

1、第3章 需求分析,2,为什么需要需求分析,开发人员往往急于求成 希望对开发进行指导 希望开发人员对用户的要求理解 希望用户理解开发人员 测试部门有理可依,3,需求分析的任务,准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 规范的形式准确地表达用户的需求。,4,什么是用户需求,思考、涉及的几个问题 如何识别、获取需求? 你能够采取何种手段与用户进行交流沟通? 何为需求建模? 你如何理解模型与建模?,5,需求获取的内容,1.用户需求分类 (1)功能性需求: 定义了系统做什么（描述系统必须支持 的功能和过程） (2)非功能性需求（技术需求）: 定义了系统工作时的特性 （描述操作环

2、境和性能目标）,6,两类需求包括的内容,(1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档,(7) 数据 (8) 资源 (9) 安全保密 (10)软件成本消耗与开发进度 (11)质量保证,7,(1) 功能需求,系统做什么？ 系统何时做什么？ 系统何时及如何修改 或升级？,8,(2) 性能需求,软件开发的技术性指标 例如： 存储容量限制 执行速度、相应时间 吞吐量,9,(3) 环境需求,硬件设备：机型、外设、接口、 地点、分布、温度、 湿度、磁场干扰等 软件： 操作系统 网络 数据库,10,(4) 界面需求,有来自其它系统的输入吗？ 到自其它系统的输出吗

3、？ 对数据格式有规定吗？ 对数据存储介质有规定吗？,11,(5) 用户或人的因素,用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？,12,(6) 文档需求,需哪些文档？ 文档针对哪些读者？,13,(7) 数据需求,输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？,14,(8) 资源需求,软件运行时所需的数据、软件。 内存空间等资源。 软件开发、维护所需的人力、 支撑软件、开发设备等。,15,(9) 安全保密要求,需对访问系统或系统信息加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其

4、它程序和操作系统隔离？ 系统备份要求？,16,(10) 软件成本消耗 与开发进度需求,开发有规定的时间表吗？ 软硬件投资有无限制？,17,(11) 质量保证,系统的可靠性要求？ 系统必须监测和隔离错误吗？ 规定系统平均出错时间？ 出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？,18,3.2 需求获取的常用方法（Note 7）,建立分析小组 领域专家： 主角 系统分析员：导演 客户访谈 问题分析与确认,某出版社系统调查表,某出版社系统调查表,21,谁是客户,客户是指直接或间接从产品中获得利益的个人或组织 软件客户包括提出要求、支付款项、选择

5、、具体说明或使用软件产品的项目风险承担者( s t a k e h o l d e r )或是获得产品所产生的结果的人。,22,客户与开发人员之间的合作关系（Note 10）,高质量的需求来源于客户与开发人员之间有效的交流与合作 通常，开发人员与客户或客户代理人成为一种对立关系,23,软件客户需求权利书（1）（Note 11）,客户有如下权利： 1. 要求分析人员使用符合客户语言习惯的表达。 2. 要求分析人员了解客户系统的业务及目标。 3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。 5. 要求开发人员在整

6、个交流过程中保持和维护一种合作的职业态度。,24,软件客户需求权利书（2）(Note 12),6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 7. 描述产品使其具有易用、好用的特性。 8. 可以调整需求，允许重用已有的软件组件。 9. 当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。 10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。,25,软件客户需求义务书 （1）(Note 13),客户有下列义务： 1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3.

7、 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。 5. 要尊重开发人员的成本估算和对需求的可行性分析。,26,软件客户需求义务书（2）（Note 14）,6. 对单项需求、系统特性或使用实例划分优先级。 7. 评审需求文档和原型。 8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 10. 尊重需求工程中开发人员采用的流程（过程）。,27,“签约”意味着什么 (Note 15),客户与开发人员关系中的重要部分 客户代表经常把“签约”看作是毫无意义的 更为重要的是签名是建立在一个需求协议的基线上 与你的重

8、要客户一起讨论权利书和义务书，以达成协议，并付诸实践,28,高质量的需求过程带来的好处(Note 16),开发后期和整个维护阶段的重做的工作大大减少 强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间 将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成,29,优秀需求具有的特性(Note 17),1. 完整性 2. 正确性 3. 可行性 4. 必要性 5. 划分优先级 6. 无二义性 7. 可验证性,3.3 分析建模与规格说明,1). 分析建模 模型 -就是为了理解事物而对事物做出的一种抽象，是对事物的一

9、种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。 建模方法 在过去的数年中，人们提出了许多种分析建模的方法，其中两种在分析建模领域占有主导地位： 第一种是结构化分析 (Structured Analysis，SA)，70年代末由DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过30年的一个混合物。,具体的建模方法/表达方式有： 面向流的建模：数据流图（DFD/CFD） 数据建模：实体关系图（ERD） 基于行为的建模： Petri网、状态图,3.3.2 软件需求规格说明(SRS),Softwar

10、e Requirement Specification 通常用自然语言+模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。 软件需求规格说明书，是需求分析阶段得出的最主要的文档。,软件需求说明书的编写提示（GB856T88）,1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料,2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束,软件需求说明书的编写提示（GB856T88）,3 需求规定 3.1 对功能的规定 3.2 对性能的规定 3.2.1 精度 3.2.2 时

11、间特性要求 3.2.3 灵活性 3.3 输人输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求,4 运行环境规定 4.1 设备 4.2 支持软件 4.3 接口 4.4 控制,3.4 实体-联系图(ER) Entity Relationship Diagram,ER图 - 是用来建立数据模型的工具。 数据模型 - 是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而且与在软件系统中的实现方法无关。 数据模型中包含3种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象彼此间相互连接的关系。,(1).

12、数据对象,数据对象: 是对软件必须理解的复合信息的抽象。 复合信息: 是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。 可以由一组属性来定义的实体都可以被认为是数据对象。 如：外部实体、事物、行为、事件、角色、单位、地点或结构等。 数据对象彼此间是有关联的。,(2). 属 性,属性定义了数据对象的性质。 必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。 应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。 如：学生具有学号、姓名、性别、年龄、专业（其它略）等属性；

13、 课程具有课程号、课程名、学分、学时数等属性； 教师具有职工号、姓名、年龄、职称等属性。,(3). 联 系,数据对象彼此之间相互连接的方式称为联系，也称为关系。 联系可分为以下3种类型： a. 一对一联系(11) 如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。 b. 一对多联系(1N) 如：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。 c. 多对多联系(MN) 如：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。 联系也可能有属性。 如：学生“学”某门课程

14、所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性。,(4). 实体-联系图的符号,ER图中包含了实体(即数据对象)、关系和属性等3种基本成分。 通常用矩形框代表实体； 用连接相关实体的菱形框表示关系； 用椭圆形或圆角矩形表示实体(或关系)的属性； 并用直线把实体(或关系)与其属性连接起来。,举 例,图3.2 某校教学管理ER图,对象,教师属性,学生属性,课程属性,联系属性,关系,3.5 数据规范化,为什么数据要规范化？,规范化的目的是： 消除数据冗余，即消除表格中数据的重复； 消除多义性，使关系中

15、的属性含义清楚、单一； 使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组； 方便操作。使数据的插入、删除与修改操作可行并方便； 使关系模式更灵活，易于实现接近自然语言的查询方式。,如何规范化？,规范化 - 将数据的逻辑结构归结为满足一定条件的二维表 （关系）。即： 1. 表格中每个信息项必须是一个不可分割的数据项，不可 是组项。 2. 表格中每一列 (列表示属性)中所有信息项必须是同一 类型，各列的名字 (属性名) 互异，列的次序任意。 3. 表格中各行 (行表示元组) 互不相同，行的次序任意。,用教学管理例说明如何规范化,有三个实体型，即课程、学生和教师，

16、用三个关系保存它们的信息： 学生(学号，姓名，性别，年龄，年级，专业，籍贯) 教师(职工号，姓名，年龄，职称，职务，工资级别，工资) 课程(课程号，课程名，学分，学时，课程类型) 为表示实体型之间的联系，又建立两个关系： 选课 (学号，课程号，听课出勤率，作业完成率，分数) 教课 (职工号，课程号，授课效果) 这五个关系，组成了数据库的模型。 在每个关系中，属性名下加（下划线）指明关键字。并规定关键字能唯一地标识一个元组。,1、范式级别越高，存储同样数据就需要分解成更多张表，因此， “存储自身”的过程也就越复杂。,2、随着范式级别的提高，数据的存储结构与基于问题域的结构 间的匹配程度也随之下降

17、，因此，在需求变化时数据的稳定 性较差。,3、范式级别提高则需要访问的表增多，因此性能(速度)将下降。 从实用角度看来，在大多数场合选用第三范式都比较恰当。,所以，从实用角度看来，在大多数场合选用第三范式都比较恰当。,通常用“范式(Normal Forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。但是：,第 一 范 式,每个属性值都必须是原子值，即仅仅是一个简单值 而不含内部结构。 如：,学生(学号，姓名，性别，年龄，年级，专业，籍贯) 教师(职工号，姓名，年龄，职称，职务，工资级别，工资) 课程(课程号，课程名，学分，学时，课程类

18、型),第 二 范 式,满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。 如：,选课 ( 学号，课程号，听课出勤率，作业完成率，分数 ) 教课 ( 职工号，课程号，授课效果 ),第 三 范 式,符合第二范式的条件。 满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。 例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部

19、门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。,3.6 状态转换图,状态转换图(简称为状态图) 通过描绘系统的状态及引起系统状态转换的事件，来表 示系统的行为。此外，状态图还指明了作为特定事件的 结果系统将做哪些动作(例如，处理数据)。,1). 状 态,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。 初态 (即初始状态) 状态 终态 (即最终状态) 中间状

20、态,一张状态图中只能有一个初态，而终态则可以有0至多个。,2). 事 件,事件是在某个特定时刻发生的事情，它是对引起 系统做动作或(和)从一个状态转换到另一个状态 的外界事件的抽象。 例如，内部时钟表明某个规定的时间段已经过去， 用户移动或点击鼠标等都是事件。 简而言之，事件就是引起系统做动作或(和)转换 状态的控制信息。,初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。 中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。,3). 符 号,活动表

21、的语法格式：事件名(参数表)/动作表达式 其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。,3). 符 号,状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。 状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。 事件表达式的语法： 事件说明守

22、卫条件动作表达式 事件说明的语法为：事件名(参数表)。 守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。 动作表达式是一个过程表达式，当状态转换开始时执行该表达式。,3). 符 号,4). 举 例,电话系统的状态图,3.7 其他图形工具,层次方框图 Warnier图 IPO图,3.7.1 层次方框图,层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。 树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框

23、代表组成这个数据的实际数据元素(不能再分割的元素)。 随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。,举 例,3.7.2 Warnier图,法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。 Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。 用Warnier图可以表明信息的逻辑组织。 它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。 重复和条

24、件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。,举 例,图中表示一种软件产品要么是系统软件要么是应用软件。系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。,3.7.3 IPO图,左边的框中列出有关的输入数据。 中间的框内列出主要的处理，处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。 在右边的框内列出产生的输出数据。 在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。,一种

25、改进的IPO图(也称为IPO表),在需求分析阶段可以使用IPO表简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。 需求分析阶段，IPO表中的许多附加信息暂时还不具备，但在设计阶段可以进一步补充修正这些图，作为设计阶段的文档。 这正是在需求分析阶段用IPO表作为描述算法的工具的重要优点。,3.8 验证软件需求,验证软件需求的正确性，一般应从4个方面进行： (1) 一致性 所有需求必须是一致的，任何一条需求不能和其 他需求互相矛盾。 (2) 完整性 需求必须是完整的，规格说明书应该包括用户需 要的每一个功能或性能。 (3) 现实性 指定的需求应该是用现有的硬件技术和软件技术 基本上可以

26、实现的。 (4) 有效性 必须证明需求是正确有效的，确实能解决用户面 对的问题。,为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求： (1) 必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容； (2) 使用这个软件工具能够导出详细的文档； (3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果； (4) 使用这个软件工具之后，应该能够改进通信状况。,3.8.3 用于需求分析的软件工具,PSL/PSA系统的功能主要有下述4种： (1)

27、描述任何应用领域的信息系统； (2) 创建一个数据库保存对该信息系统的描述符； (3) 对描述符施加增加、删除和更改等操作； (4) 产生格式化的文档和关于规格说明书的各种分析报告。 PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理等8个方面描述信息系统。,3.9 小结,需求分析的任务: what functions + other requirements 获取需求的方法: visit, prototyping, refinement 分析建模与规格说明: 数据、功能和行为模型 实体-联系图 & 数据规范化 状态转换图+有穷状态机 数据字典&其他图形工具 验证软件需求:一致性、完整性、现实性和有效性,