软件工程导论第3章需求分析报告.docx
《软件工程导论第3章需求分析报告.docx》由会员分享，可在线阅读，更多相关《软件工程导论第3章需求分析报告.docx（10页珍藏版）》请在冰豆网上搜索。
软件工程导论第3章需求分析报告
第三章软件需求分析
虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一些可行的方案，但是可行性研究的基本目的是用较小的成本在较短的时间确定是否存在可行的解法。
因此许多细节被忽略了。
然而在员终的系统中却不能遗漏任何一个微小的细节，所以可行性研究并不能代替需求分析，它实际上并没有准确地回答“系统必须做什么？
”这个问题。
需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
软件需求分析是一个不断进行揭示和判断的过程。
3.1需求分析的任务
3.1.1确定系统的综合要求
1功能需要
划分出系统必须完成的所有功能
2性能需要
系统必须满足的定时约束或容量约束
速度（系统的响应时间）
信息速率
主存容量
磁盘容量
安全性
3.1.2分析系统的数据要求
任何一个软件系统其本质上都是一个信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的概貌，同时也对软件设计有着深远的影响。
分析系统的数据要求，这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法
系统的数据来源和去处一般含如下几个方面:
（1）从系统以外来，再到系统以外去；
（2）从系统以外来，再到系统部去；
（3）从系统部来，再到系统部去；
（4）从系统部来，再到系统外部去。
3.1.3导出系统的逻辑模型
用数据流图、实体--关系图、状态转换图、数据字典、主要的处理算法描述逻辑模型。
3.1.4修正系统开发计划
准确地估计系统的成本及进度，修正以前我们所制定的开发计划。
3.2与用户沟通获取需求的方法
3.2.1访谈
情景分析技术就是分析对用户将来使用目标解决问题的方法某个具体问题的方法和结果进行分析。
3.22面向数据流自顶向下求精
3.23简易的应用规格说明技术
3.24快速建立软件原型
3.3分析建模与规格说明
3.3.1分析建模
1建模：
是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。
模型由一组图形符号和组织这些符号的规则组成
2模型与工具
数据模型—实体-关系图
功能模型—数据流图
行为模型—状态转换图
3.3.2软件需求规格说明
用自然语言完整、准确、具体描述系统的数据需求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求、将来可能提出来的需求
3.4实体-关系图
3.4.1数据对象
数据对象：
是对软件必须理解的复合信息的抽象。
复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象。
数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构
数据对象彼此间是有关联的，它只封装了数据，没有对数据的操作
3.4.2属性
定义了数据对象的性质，属性用标识符表示
3.4.3联系
数据对象彼此之间相互连接的方式称为联系，
也称为关系。
联系分为3种类型。
（1）一对一联系（1:
1）
例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
（2）一对多联系（1:
N）
例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。
（3）多对多联系（M:
N）
例如，表示学生与课程间的联系（“学”）是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
3.4.4实体-关系图的符号
实体-关系图简称ER图
3.5数据规化
为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规化。
通常用“式”定义消除数据冗余的程度。
第一式数据冗余程度最大，第五式数据冗余程度最小。
但是，式的级别越高，存储同样数据就需要分解成更多表，因此，‘存储自身’的过程也就越复杂。
第二，随着式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。
第三，式级别提高则需要访问的表增多，因此性能（速度）将下降。
从实用角度看来，在大多数场合选用第三式都比较恰当。
下面给出第一、第二和第三式的定义：
（1）第一式:
每个属性值都必须是原子值，即仅仅是一个简单值而不含部结构。
（2）第二式:
满足第一式条件，而且每个非关键宇屑性都由整个关键字决定（而不是由关键字的一部分来决定）。
（3）第三式：
符合第二式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字局性的进一步描述（即一个非关镑字属性值不依赖于另一个非关键字属性值）。
3.6状态转换图
状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
此外，状态图还指明了作为特定事件的结果将做哪些动作。
因此，状态图满足了行为建模的机制。
3.1状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
状态规定了系统对事件的响应方式。
系统对事件的响应，既可以做一个（或一系列）动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态有改变动作。
状态图既可以表示系统循环运行过程，也可以表示单程生命期。
3.6.2事件
事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换的另一个状态的外界事件的抽象。
事件就是引起系统做动作或转换状态的控制信息。
3.6.3符号
3.6.4例子
3.7其他图形工具
3.7.1层次方框图
层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构的顶层是一个单独的矩形框，它代表完整的数据结构。
下面各层的矩形框代表这个数据的子集，最低层的各个框代表组成这个数据的实际数据元素（不可再分割）。
描绘一家计算机公司全部产品的数据结构图如下。
3.7.2Warnier图
Warnier图是由法国计算机科学家J.D.Warnier提出的表示信息层次结构的另外一种图形工具。
在Warnier图中花括号用来区分数据结构的层次，在一个花括号的所有名字都属于同一类信息；符号表示在其上、下方的名字中的一个名字；名字右边圆括号中的符号表示这个名字在信息类中重复出现的次数。
3.7.3IPO图
IPO图是输入/处理/输出图的简称，它是由美国IBM公司发展完善起来的一种图形工具，可以方便地表示输入数据、数据处理和输出数据三者之间的关系。
3.8验证软件需求
3.8.1验证软件需求的途径与方法
一致性：
在所有需求中，任何一条需求不能和其他需求互相矛盾。
形式化描述
完整性：
软件规格说明书必须包括用户需求的每一个功能或性能。
原型
现实性：
指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
仿真和模拟
有效性：
软件需求确实能解决用户所面对的问题。
原型
3.8.3用于需求分析的软件工具
PSL／PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理等八个方面描述信息系统。
一旦用PSL对系统做了完整描述，就可以调用PSA产生一组分析报告，其中包括所有修改规格说明数据库的记录，用各种形式描述数据库信息的参照报告（包括图形形式的描述），关于项目管理信息的总结报告，以及评价数据库持性的分析报告。
借助PSL／PSA系统可以边对目标系统进行自顶向下的逐层分解，边将需求分析过程中遇到的数据流、文件、处理等对象用PSL描述出来并输入到PSL／PSA系统中。
PSL将对输入信息作一致性和完整性检查，并且保存这些描述信息。
PsL／P5A系统的主要优点是它改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以减少管理和维护的费用。
分析追踪
数据流图
用户复查
无补充修正
细化数
据流图
不需分解
有补充修正
需要分解
图3.1面向数据流自顶向下求精过程
职称
职务
姓名
教工号
性别
教师
教
1
成绩
学号
姓名
性别
系
年级
学生
学
N
课程
NM
课名
学时
学分
课程号
图3.2某校教学管理ER图
初始事件
状态1
状态变量1
活动表1
事件表达式
状态2
状态变量2
活动表2
结束事件
图3.3状态图中使用的主要符号
挂断电话
闲置
拿起听筒
拨号音
timer=0
do/想拨号音且增加timer
超时
超时
do/响蜂鸣音
存储的信息
do/播放信息
无效号码
拨号
数字
接通中
do/试接通
有效号码
已接通
振铃
do/振铃
受话人回话
通话
断线
受话人挂断电话
信息播完
占线
忙音
do/响忙音
挂断电话
数字
图3.4电话系统的状态图
产品
软件
硬件
处理机
处理机
处理机
服务
软件服务
硬件维修
培训
系统软件
应用软件
操作系统
编译程序
软件工具
图3.5层次方框图的一个例子
软件产品
系统软件
应用软件
操作系统（P1）
编译程序（P2）
软件工具
编译程序（P3）
测试驱动程序（P4）
设计辅助工具（P5）
有效的
主纪录
有效的
事务纪录
更新后的
主文件
旧的主文件
事务文件
1．校验
主纪录
2．校验
事务纪录
3．更新
主纪录
输入
处理
输出
图3.7IPO图的一个例子
IPO表
系统：
作者：
模块：
日期：
编号：
注释：
被调用：
调用：
输入：
输出：
处理：
局部数据元素：
图3.8改进的IPO图的形式
升级会员 