SE05瀑布模型-需求分析幻灯片

《SE05瀑布模型-需求分析幻灯片》由会员分享，可在线阅读，更多相关《SE05瀑布模型-需求分析幻灯片（114页珍藏版）》请在金锄头文库上搜索。

1、瀑布模型,需求分析,提纲,需求过程 需求诱导 需求的特性 需求建模 需求和规格说明书 原型化需求 需求文档 确认和验证 举例,从客户引发需求 对需求进行建模 评审需求以确保其质量 文档化需求,如何做需求,需求诱导 需求分析和谈判 需求规约 系统建模 需求确认 需求管理,需求分析,需求(Requirement),对期望行为的表达，处理 对象或实体 他们的状态 用于改变状态或对象特性的功能 需求仅理解客户的问题和需要，不考虑如何解决或实现,需求分析,基本任务是准确回答“系统必须做什么” 需求分析不是确定系统怎样完成它的工作，而仅仅是对目标系统提出完整、准确、清晰、具体的要求 需求有自己的过程 结果

2、关系到工程的成败和软件的质量 构建软件系统最艰难的是准确决定要做什么。没有其他的概念性工作像建立详细的技术需求这样困难，包括所有对人的界面、对机器的接口、对其他系统的接口。如果它做错了，系统基本失败,需求分析很重要,31%的项目在完成前取消，9%项目按时在预算内交付（而小公司为16%） 失败原因 不完整的需求 13.1% 缺少用户的参与 12.4% 缺乏资源 10.6% 不切实际的期望 9.9% 缺乏行政支持 9.3% 改变需求和规格说明 8.7% 缺乏计划 8.1% 不再需要该系统 7.5%,修复错误的代价 需求过程 1 设计 5 编码 10 单元测试 20 交付后 200,获取需求的过程,

3、系统分析员 需求分析员,如何做需求,需求诱导 需求分析和谈判 需求规约 系统建模 需求确认 需求管理,需求诱导,询问客户、用户和其他人：什么是系统或产品的目标？需要完成什么？系统或产品如何满足业务的需要？最终系统或产品如何使用？ 困难： 范围问题，边界未定义好或刻画了可能混淆的、不必要的技术细节，非简明、整体的系统目标 理解问题，用户不能完全理解问题领域，与系统工程师沟通不好，省略一些他们认为是“明显”信息，提出与其他客户的需要冲突或有歧义的需求 易变问题，需求随时间变化,影响需求的人,观点会冲突；需求分析员可理解每种观点并以反映每个参与者关注的方式获取需求,需求诱导,针对提议的系统评估业务和

4、技术可行性 确定能帮助刻画需求和了解他们的组织偏爱的人员 定义系统或产品将放置的技术环境 确定“领域约束”(特定应用领域的业务环境约束) 定义一种或多种需求诱导方法 多人参加，从不同视角对需求进行定义，并确定每个要记录的需求的理由 确定有歧义的需求作为原型实现的候选 创建使用场景,需求类型,功能需求 功能 系统什么时候做什么 有多种操作模式么 必须执行什么计算或数据转换 对可能刺激的合适反应是什么 数据 输入、输出的格式应该是什么 在任何时间都必须保留任何数据么 设计约束 过程约束,需求类型,设计约束 物理环境 设备安置，一个地点还是多个 对环境有何限制，温湿度、电磁干扰 对系统规模可有限制

5、电源、供热、制冷上限制 对现有软件的结构导致编程语言有限制 接口 输入来自一个或多个系统 输出是否传送到一个或多个其他系统 输入/输出数据的格式是否预先制定 数据使用必须使用规定的介质 用户 谁使用 有几种类型用户 每类用户技术怎样,需求类型,过程约束 资源 构造系统需要哪些材料、人员或其他资源 开发人员应具有怎样的技能 文档 需要多少文档 文档是联机的、印刷的还是都要 每种文档针对哪些读者 标准 需要遵循什么标准,需求类型,质量需求 性能 有无执行效率、响应时间或吞吐量的约束 用什么方法测量上述约束 有多少数据需经系统处理 数据收发的时间间隔等 可用性和人的因素 每类用户需要什么样的培训 用

6、户理解并使用系统的难易程度 系统需要在多大程度上防止用户误用系统 安全性 必须控制对系统或信息的访问么 每个用户的数据应与其他用户的隔离开么 每个用户的程序和其他程序或系统隔离开么 需采取预防措施防盗窃或蓄意破坏么,需求类型,可靠性和可用性 系统检测并隔离故障么 规定的平均无故障时间是多少，重启时间是多少 多长时间备份一次系统，副本要放在不同地方么 可维护性 维护是仅纠错还是包括改进系统 系统可能在将来什么时候被什么方式破坏 给系统增加功能的难易程度如何 移植系统容易否 精度和准确性 数据计算的准确度有何要求，竟算精度到什么程度 交付时间/代价 有预先规定的开发时间表么 花在软硬件扩开发上的资

7、金有限么,需求冲突,从所有相关人员获取的需求，会遇到“需求应该是什么”的不一致 请用户划分优先级 绝对需要满足的 非常值得要但非必须的 可要可不要的 按优先级排序 重新评估和商谈 技能、耐心和经验,需求文档,需求的用途 系统分析员和客户用需求解释对系统行为的理解 设计人员将需求作为可接收解决方案的约束 测试人员依需求得一套验收标准，表明确为所求 维护人员用需求来增强系统 需求文档 需求定义 客户想要的每一件事情的完整列表 需求规格说明书 将需求重新陈述成关于要构架系统如何运转的说明,需求特性,正确么 一致么 无冲突 无二义性么 完备么 指定了所有约束下、所有状态下、所有可能输入和输出以及必须的

8、行为 外部完备，内部完备（没有未定义项） 可行么 每一个需求都相关么 可测试么 可跟踪么,需求诱导的产品,需要和可行性的陈述 系统或产品的范围的限制性描述 参与需求诱导活动的客户、用户和其他风险承担者列表 系统的技术环境描述 （可按功能组织的）需求的列表和应用于每个需求的领域限制 一组使用场景，提供对不同运行条件下系统或产品的使用的见识 为更好地定义需求而开发的任意原型,需求分析和谈判,需求诱导的产品是需求分析的基础。 需求分析活动对需求进行分类并将他们组织为相关的子集，根据和其他需求的关系来考察每个需求，检查需求的一致性、疏忽和二义性 前者解决一致性、抽象与否、是否必要、需求的来源清楚与否、

9、可测试？ 后者解决多个用户的冲突的需求或在给定资源下，要求多于可实现的情况,需求分析 任务,确定对系统的综合要求 系统功能要求 系统性能要求 运行要求 将来可能提出的要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划 确认需求 开发原型系统,可能的任务还有开发原型系统,分析过程,软件系统可以认为是将输入数据变换成输出数据的信息处理系统 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析方法,结构化方法 沿数据流图回溯 回溯初步得算法IPO 用户审查 DFD, IPO, 数据字典 细化DFD 修正开发计划 书写文档 审查和复查,循环进行,需求分析的基本过程,采用DFD时 此为基

10、本样式，采用其他技术也需要类似处理,分析追踪 DFD,用户复查,细化DFD,不需分解,无补充 修正,有补充修正,需分解,文档和分析过程,系统规格说明 DFD+IPO 数据要求 数据字典+层次方框图+Warnier图 DB 用户系统描述 简单的用户手册 修正的开发计划,建模表示法,实体关系图 UML类图 事件踪迹 UML时序图 状态机 UML状态图 Petri网 数据流图 用例图 函数和关系,判定表和判定树 逻辑表达 对象约束语言 Z语言 层次图 Warnier图 IPO图 IPO表,不同问题，可采用多种表示 好用就好,概念模型 ER模型,采用实体-联系方法描述现实世界的实体，而不涉及实现方法

11、实体 联系 （基数） 1:1 1:N M:N 属性 实体或联系的性质,ER图实例,关于结构,职称,性别,姓名,ID,教师,职务,系,性别,姓名,ID,学生,年级,成绩,学分,学时,课名,ID,课程,教,学,1,N,N,M,ERD的补充,形态 关系的出现是可选的，关系的形态是0 关系必须出现1次，则形态是1,基数 生产一种汽车,形态 强制的 必须生产一种汽车,基数 可生产多种汽车,形态 强制的,十字旋转门例子,规范化,有些数据是要长期保存的，用规范化方法减少冗余范式NF NF1NF5 冗余度 存储自身 性能 稳定性 NF1：属性值为原子的，无内部结构 NF2：非关键字属性均由整个关键字决定 NF

12、3：非关键字属性均仅由整个关键字决定，非关键字属性值不依赖于另一个非关键字属性值,UML类图,事件踪迹,关于实体行为 关于现实世界实体间交换的事件序列的图形描述 对文档化系统行为无效,UML时序图,状态机,单个模型中一组时间踪迹；表示动态行为和响应已发生事件时的行为变化有效,UML状态图,UML状态图,UML状态图,Petri网,做状态-迁移的表示法 UML协作图类似 Petri 圆：位置，表示活动或条件，存放令牌 条：变迁 箭头：将变迁与其输入位置和输出位置连接 Petri网可描述同步和并发,举例：简单Petri网,举例，高级Petri网,数据流图,DFD,DFD 示例,用DFD方式说明需求

13、获取与分析过程,DFD0,DFD1,DFD 2-1: 对DFD1中的”1”进行展开,DFD 3-1: 对DFD2-1中的”1.1”进行展开,DFD3-2: 对DFD2-1的”1.2”进行展开,用例,函数和关系,判定表,函数规格说明的表格式表示 可能的输入事件、条件和动作,动作序列,输入事件,条件,判定表,OCL对象约束语言UML中的一个扩展,精确+易读等 指示出不变量约束等,形式化语言 Z,形式化的需求规格说明，将集合论的变量定义组织到一个问题的完整的抽象数据类型模型中，并用逻辑来表示每个操作的前置和后置条件 可作自动化证明 类似的有代数规格说明等 修改 ？输入 ！输出 查询,SDL数据,规格

14、说明和描述语言（SDL）中的数据 难度在于构造完备的、一致的和反映期望的公理,图形工具,层次方框图 树形结构的一系列举行框描绘数据的层次结构,完整的数据结构,子集1,子集2,子集n,实际数 据元素,Warnier图,可表明信息的逻辑组织,IPO图,次序描述了执行的顺序,数据通信情况,IPO表,IPO表描述算法,需求和规格说明语言,UML 用例图 -DFD 类图 -ERD 时序图 -事件踪迹 协作图 -事件踪迹 状态图 -状态机 OCL特性 -逻辑 结构化方法 SD系统图 -DFD SD方框图 -DFD SD进程图 -状态机,需求文档,需求定义 需求规格说明书,需求规约,规约specificat

15、ion对不同的人意味着不同的事。规约可以是文档、图形化模型、形式化数学模型、使用场景、原型或上述的任意组合 系统规约是系统和需求工程师的最终工作产品，将作为硬件、软件、数据库及人力分配的基础。描述了基于计算机的系统的功能和性能以及将控制其开发的约束。 规约界定了每一个分配的系统元素，也描述了系统输入、输出的信息（数据和控制）,需求规格说明书 (IEEE推荐),1 文档的引言 1.1产品的目的 1.2 产品的范围 1.3 首字母缩写词、缩略词、定义 1.4 参考文献 1.5 SRS剩余部分的概要介绍 2 产品的总体描述 2.1 产品的背景 2.2 产品功能 2.3 用户的特性 2.4 约束 2.

16、5 假设和依赖关系,3 说明需求 3.1 外部接口需求 3.1.1 用户界面 3.1.2 硬件接口 3.1.3 软件接口 3.1.4 通信接口 3.2 功能需求 3.2.1 类1 (功能1) 3.2.2 类2 (功能2) 3.3 性能需求 3.4 设计约束 3.5 质量需求 3.6 其他需求 4 附录,分析模型的结构,数据字典,ERD,DFD,STD,PSPEC,CSPEC,DS,DS 数据对象描述 STD 状态变迁图 PSPEC 加工规约 CSPEC 控制规约,功能建模 DFD+加工规约 数据建模 ERD 行为建模 CFD+控制规约,家居安全系统,需求诱导 需求分析和谈判 需求规约 系统建模 需求确认 需求管理,产品描述,我们的研究表明，家庭安全系统的市场正以每年40的比率增长，我们希望进入该市场，试图建造基于微处理器的家庭安全系统，该系统将保护和/或识别一系列不希望的“情况”，如