软件工程重点复习（2）
第三章 可行性研究
1.可行性研究的任务
1.1可行性研究的目的： 用最小的代价，在尽可能短的时间内确定问题是否能够解决。
可行性研究的实质： 就是一次压缩、简化了的系统分析和设计的过程。
1.2可行性研究的任务
可行性研究应着重考虑如下几个方面：
技术可行性：使用现有的技术能否实现这个系统。建立系统模型
经济可行性：进行成本∕效益分析。从经济角度判断系统开发是否“合算”。成本∕效益分析。
操作可行性：系统的操作方式在这个用户组织内是否行得通。
法律可行性：确定系统开发可能导致的任何侵权、妨碍和责任。
开发方案的选择性研究：提出并评价实现系统的各种开发方案，并推荐较优方案。
可行性研究最根本的任务：对以后的行动方针提出建议
2.可行性研究过程
3.1.系统流程图
是概括地描绘物理系统的传统工具；
它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件，包括 程序 文档 数据库 人工过程等；
它表达了数据在系统各部件之间的流动情况
4.1数据流图（DFD）
源点和终点: 源点和终点是系统之外的实体，可以是人、物或其他软件系统 ;源点和终点是为了帮助理解系统接口而引入的
处理/加工/变换 :对数据进行处理的单元 ;在分层数据流图中，要对加工进行编号，以便于管理; 加工也要选取适当的名字，以提高数据流图的易读性
数据流 :由一组数据项组成 例如，数据流“订票单”由姓名、联系地址、电话、航班号、日期、始点、终点等数据项组成 ;数据流可以从加工流向加工 如“航班”、“费用” ;可以从源点流向加工，或从加工流向终点; 可以从加工流向数据存储，或从数据存储流向加工
数据存储/文件 :用来暂时存储数据 ;如果加工要读文件，则数据流的方向是从文件到加工 ;如果加工要写文件，则数据流的方向是从加工到文件 ;如果加工既要读文件又要写文件，则数据流的方向是双向的
注意：
※画数据流图不是画流程图
父图和子图的平衡问题
局部文件的问题
分解的深度和层次问题 ：最好不超过7层，均匀
命名问题：对于数据流：应该代表整个数据流，※不要把控制流作为数据流（考生成绩vs取下一个考生成绩）
对于加工命名：通常先为数据流命名，然后再为与之相关联的处理命名，动宾短语
用途：
作为交流信息的工具
作为分析和设计的工具： 用数据流图辅助物理系统的设计时，以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界 每组自动化边界可能意味着一个不同的物理系统，因此可以根据系统的逻辑模型考虑系统的物理实现
可以从数据流图出发映射出软件结构
5.1数据字典
数据字典是对数据流图中包含的所有元素（数据流； 数据流分量（即数据元素）； 数据存储 ；处理（加工））的定义的集合
于写加工逻辑说明的工具：
结构化英语（Structured English）
判定表（Decision Table）
判定树（Decision Tree）
第四章 需求分析
1.1需求定义：就是系统的特征（Features），或对系统为达到某个目标所能做的事情的一个描述
1.2需求过程本质：在问题空间与求解空间中间架设桥梁
1.3区分功能需求、非功能需求
功能需求 ：系统与环境间的交互——描述系统必须支持的功能和过程的系统需求（比如指纹验证）
非功能需求： 客户给出的具体约束、指标——描述操作环境和性能目标的系统需求（比如验证要在2秒内完成）
二者的区别： 功能需求描述系统应该做什么 非功能需求则为如何实现这些需求设定约束
1.4※需求过程不仅是可能的而且也是值得的： 需求提取、需求分析、需求协商、需求确认
1.5需求分析的任务
1.必须理解并描述问题的信息域 根据这条准则应该建立数据模型
2.必须定义软件应完成的功能 这条准则要求建立功能模型
3.必须描述作为外部事件结果的软件行为 这条准则要求建立行为模型
4.必须对描述信息、功能和行为的模型进行分解 用层次的方式展示细节
5.确定对系统的综合要求 ：
功能需求；
性能需求；
可靠性和可用性需求
出错处理需求 ；
接口需求--用户接口需求；硬件接口需求；软件接口需求；通信接口需求 ；
约束--精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台
逆向需求
将来可能提出的要求
6.分析系统的数据要求 ：建立数据模型： E-R图
复杂数据结构的描述 ：数据字典 层次方框图 Warnier图
数据库 ：数据规范化
7.导出系统的逻辑模型 ：详细的逻辑模型通常使用以下方式描述 数据流图 数据字典 E-R图 状态转换图 主要的处理算法描述
8.修正系统的开发计划 ：每当获得对系统更深入的了解，就可以更准确地估计系统的成本和进度，修正以前制定的开发计划
2.1与用户沟通获取需求的方法
1.访谈：正式访谈 非正式访谈 分发调查表 情景分析技术
2.面向数据流自顶向下求精：分析追踪数据流图，用户复查，补充修正，细化
3. 简易的应用规格说明技术：一种面向团队的需求收集法，用户与开发者密切合作
4.快速建立软件原型：快速建立起来的旨在演示目标系统主要功能的可运行的程序；快速 容易修改，原型可能要求投入较高成本 并可能导致延迟交付；不提倡把原型做成最终系统 原型趋向于非结构化
2.2需求的特征：
正确性 ：要确保需求的表达中没有引入错误（faults）
一致性 ：确保没有互相冲突、矛盾的需求；确保没有不确定的需求
完整性： 如果需求描述了所有可能的状态，以及状态的变化、输入、过程和约束，那么这组需求就是完整的 外部完整：需求描述的所有关系都与客户想要的环境相关 内部完整：所收集的需求之间没有未定义的引用
可检验性： 必须能写出测试来说明需求已被满足 摒除需求中不确定、不完整、不正确的部分 例如：“要能立刻访问水质的信息”这样表述是不可测试的 应准确地描述：“要在请求后2秒内找到水质的记录”
现实性 ：确保客户要求系统做的事真的能做到
实用性： 确保需求和要解决的问题有直接关系
可回溯性： 保证每个系统功能都能追溯到一组要求它的需求 确保很容易找到处理系统特定方面的某一组需求
3.1分析建模（过程式分析方法）
过程式分析方法创建的高层逻辑模型，应包括：
数据模型：理解并描述问题的信息域
功能模型：定义软件应完成的功能
行为模型：描述作为外部事件结果的软件行为
如果问题较为复杂，可以用自顶向下求精的方式对模型进行逐层分解 用层次的方式展示细节
3.2两种需求文档：
需求定义
需求规约（SRS文档）
4.1E-R图
概念性数据模型是一种面向问题的数据模型，描述从用户角度看到的数据，反映用户的现实环境 与在软件，与在软件系统中的实现方法无关
数据模型中包含3种相互关联的信息：实体，实体的属性，实体间联系（也可能是联系集）
联系类型：一对一联系(1∶1) 一对多联系(1∶N) 多对多联系(M∶N)
5.1数据规范化
目的： 减少数据冗余 避免出现插入异常、删除异常 简化修改数据的过程
第一范式（1NF）：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
第二范式（2NF）:满足第一范式条件,而且每个非关键字属性都由整个关键字决定，而不是由关键字的一部分来决定。（所有属性值都由主键唯一标识）
不满足2NF可能导致:数据冗余 更新异常 插入异常 删除异常
特例：所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字
第三范式（3NF）：符合第二范式的条件，非主属性相互独立，即任何非主属性间不存在函数依赖。（即，除主键之外，其它属性之间都是独立无关联的）
BCNF:
6.1状态转换图：状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为
状态： 是任何可以被观察到的系统行为模式，规定了系统对事件的响应方式
事件： 在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象
7.1其它图形工具
层次方框图用树形结构的一系列多层次的矩形描述数据的层次结构
Warnier图也用树形结构描绘信息，但是它比层次方框图提供了更丰富的描绘手段
IPO图（输入 处理 输出）
改进的IPO图（ipo表）
8.1验证软件需求
从哪些方面验证软件需求的正确性 ：
一致性 完整性 现实性 有效性