软件工程 咸阳师范学院 信息工程学院.

Slides:



Advertisements
Similar presentations
主要内容 IPO 审核规则体系介绍 审核中关注的重点问题 2007 年以来被否决企业的原因分析. 第一部分 IPO 发行审核的规则体系 ● 法律:证券法 ● 行政规章:首次公开发行股票并上市 管理办法 ● 规范性文件:招股说明书准则、备忘录、 证券期货法律适用意见.
Advertisements

“ 软件工程 ” 考试安排 考试方式 每人从给出的题目中选择一题,独立撰写论文一篇。 论文要求 1. 论文既要结合软件工程的理论知识,又要结合自身 的实践体会,特别要联系课设自己的实际工作(请 说明自己在课程设计中所承担的主要工作及自己的 认识、体会、总结)。论文应具有自己的分析、观 点,并有实例分析。
實踐國中綜合活動. 我們的團隊 輔導 — 邱敏芳主任、洪穎馨組長、朱孝安組 長、徐維莉師、蔡嘉容師、蔡燕娟師 童軍 --- 蘇月琴團長、蔡盟玉師 家政 --- 阮雅倩師、李怡慧師、蔡佩瑩師.
<<會計資訊系統課程講義>> 統一塑模語言(UML)語法精要 -- 物件導向概念、需求分析及系統分析
第6章 企业集团的资金运筹 课 程:高级财务管理 主讲教师:龙文滨.
♥走馬瀨露營心得分享 二年七班 19號 鄭宜欣.
客家围龙屋 想知道梅州有哪些好吃好玩的吗?那接下来就让我带你去看吧!!GO。。。 梅州游乐篇.
An Introduction to Database System
第六章 数据库设计.
软件工程 第四章 结构化分析与设计 制作者 程丽.
MMS2实训 数据库设计.
第3章 需求分析(续) 学习目标 人事工资管理系统 考务管理系统 家庭保安系统 图书管理系统.
新竹二日遊 準備出發囉!!GO.
第3章 需求分析(续) 学习目标 什么是需求建模? 需求分析建模方法 掌握实体—关系图(E—R图); 掌握状态转换图;
中国证监会投资者保护局、上海证监局提醒您:
第二章 可行性研究.
第八章 信息系统开发概述.
---中国第一支产权市场交易基金 ---为国内产权交易提供专业融资服务
12年國教 中正高中課程發展分享 簡菲莉
2016中重卡网络规划 中重卡营销部 2016年6月.
D、結構化技術 主要的結構化技術 結構化程式設計 (Structured Programming)
小儿营养不良 第四篇第二章第二节小儿营养不良.
任务一:利用结构化方法分析、设计项目 (续).
第六章 数据库设计.
第一章 体育统计的基本知识 主讲教师:王丽艳 徐栋.
歡迎一年五班家長蒞臨參加 本年度下學期 學校日活動.
2016年莱芜市乡村医生在岗培训 启动会.
单元 SD 5 菜鸟学飞 附件二 想学飞的职场菜鸟.
我的社區_觀塘 第三課.
飛天小女警遊縣警局.
图解监管转型简政放权 上市公司篇.
主題樂園的開發評估與規劃.
復興國中95學年度生涯檔案製作簡介.
软件工程 主讲:饶国政 天 津 大 学.
Chapter 5 Verilog硬體描述語言
資料表正規化.
C 程式設計— 控制敘述 台大資訊工程學系 資訊系統訓練班.
第5章 結構化分析與設計-流程塑模.
MIS原理与应用 第七讲 系统需求分析之 逻辑模型
第六章 : 資料模型之繪製 1. 前言 資料流程圖 ( DFD ) 及 處理邏輯工具
Database Systems Design Part III : Normalization
第五章 详细设计.
第6章 管理信息系统的系统设计 系统分析阶段,主要解决的是新系统“做什么”的问题。而在系统设计阶段,需要回答的中心问题是“怎么做”,即通过给出新系统物理模型的方式,描述如何实现在系统分析中规定的系统功能。
A、資訊系統開發概論與課程簡介 何謂資訊系統? 為何需要系統分析師? 需要瞭解哪些知識? 領域知識? 資訊科技? 開發方法與技術? 課程簡介.
複詞三胞胎(偏義複詞、同義複詞、反義複詞)
证书发放工作要点及流程 学院办公室.
软件工程 第四章 软件设计 软件过程设计技术与工具.
中華生活商圈 商家管理系統 指導老師:王素華老師 學 生: 陳逸文 張治仁.
ER Model.
梁文新 办公室:综合楼108 电 话: 软件工程导论 梁文新 办公室:综合楼108 电 话:
软件设计任务 从工程管理的角度来看,软件设计分两步完成。 概要设计,将软件需求转化为数据结构和软件的系统结构。
圖畫成語 Go !Go ! Go ! 遊戲說明.
信息系统开发 信息系统开发的组织工作 第一阶段 系统规划 第二阶段 系统分析.
第15章 系統分析與設計.
信息系统开发 信息系统开发的组织工作 第一阶段 系统规划 第二阶段 系统分析 第三阶段 系统设计 第四阶段 系统实施.
第5章 软件详细设计 本章内容结构 本章引言 学习目标 教学内容 本章小结 思考和练习 课堂讨论 2019年4月26日.
系统设计系统总体结构设计 代码设计 数据结构与数据库设计 输入输出设计 模块功能与处理过程 系统设计报告
Create and Use the Authorization Objects in ABAP
业务流程重组 1.概念 业务流程重组(BPR ,Business Process Reengineering)强调以业务流程为改造对象和中心、以关心客户的需求和满意度为目标、对现有的业务流程进行根本的再思考和彻底的再设计,利用先进的制造技术、信息技术以及现代化的管理手段、最大限度地实现技术上的功能集成和管理上的职能集成,以打破传统的职能型组织结构(Function-Organization),建立全新的过程型组织结构(Process-Oriented.
B、資訊系統開發方法論 系統開發生命週期法 雛型開發法 合作需求規劃與合作應用設計 使用者自建系統 資訊系統的委外與租用 套裝軟體的引進
響應立法院親民黨團擴大舉辦向全民徵文 《若我有8800億,要怎麼改造台灣!?》
學生端 操作說明.
第四节 数据库设计 数据库设计是指根据用户需求分析、在现有的数据库管理系统的基础上建立数据库结构的过程。具体讲,是指对于给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之有效地存储数据,满足用户信息要求和处理要求。 数据库设计的依据DFD、DD、DBMS 。 数据库的设计过程是通过E-R图(依据“实体-联系”法实现,Entity.
§4 连续型随机变量.
天澤堂兒童三色GO 高小級主日學 導師:李志誠 黃少華 2011年10月8日
OOA/OOD UML RUP Architecture Pattern MDA
Visual FoxPro 应用基础与面向对象 程序设计教程
6.1.1 平方根.
作文教學--遊記篇 適用年級:五年級 教學者:鄭文娟老師.
Presentation transcript:

软件工程 咸阳师范学院 信息工程学院

第二章 需求分析

主要内容 1 需求分析的基本概念 2 结构化分析方法 3 数据流图 4 数据词典 5 实体关系图和状态迁移图 6 原型法化方法 7 需求规格说明与评审

软件需求分析的基本概念 1.什么是软件需求工程? 2.软件需求分析的目标和任务 3.需求工程过程 4.软件需求分析方法

问题定义 编 码 需求分析 设 计 可行性研究 运行与维护 测 试 瀑布模型 (维护报告) 问题定义 编 码 需求分析 设 计 可行性研究 运行与维护 测 试 开发 时期 运行 计划时期 (目标与范围说明书) (可行性论证论告) (测试报告) (程序) (设计文档) (需求说明书) 软件需求分析是软件生命期中重要的一步,也是决定性的一步。

可行性研究的目的是用较小的沉浮股本在最短的时间内确定是否存在可行的解法。 需求分析的任务是准确回答“系统必须做什么”的问题。 在需求分析的过程中,分析员和用户起着关键的作用。

软件需求分析的准则 必须理解并描述问题的信息域,根据这条准则建立数据模型。 必须定义软件应完成的功能,这条准则建立功能模型。 必须描述作为外部事件结果的软件行为,这条准则建立行为模型。 必须对描述信息、功能和行为的模型进行分解,用层次的方式展开细节。

需求分析阶段的目标:深入描述软件的功能和性能,确定软件设计的约束,软件同其他系统元素的接口细节,定义软件的其他有效性需求 对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程——需求工程 需求分析阶段的目标:深入描述软件的功能和性能,确定软件设计的约束,软件同其他系统元素的接口细节,定义软件的其他有效性需求

软 件需 求 用 户需 求 系 统需 求 功能需求 非功能需求 领域需求

在可行性分析的基础上,进一步了解确定用户需求。准确地回答 “系统必须做什么?” 的问题。获得需求规格说明书。   需求分析阶段的任务:   在可行性分析的基础上,进一步了解确定用户需求。准确地回答 “系统必须做什么?” 的问题。获得需求规格说明书。  Boehm对软件需求的定义:   研究一种无二义性的表达工具,它能为用户和软件人员双方都接受并能够把“需求”严格地、形式地表达出来。   由于需求分析方法不同,描述形式不同。其实现步骤如下图所示: 理解需求 表达需求 做什么 模型化 抽象化 导出 当前系统 物理模型 逻辑模型 具体化 实例化 目标系统 物理模型 逻辑模型

软件需求分析的任务 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划

分析模型 数 据 对 象 描 述 加 工 规 格 说 明 实 体 关 系 图 数 据 流 图 数据词典 状态转换图 控 制 规 格 说 明 数据流图(DFD) 功能模型 实体关系图(ERD) 数据模型 状态转换图(STD) 行为模型 实 体 关 系 图 数 据 流 图 数据词典 状态转换图 控 制 规 格 说 明

需求工程过程 问题识别 分析与综合 编写文档 分析评审 需求导出 可行性研究 和分析 需求描述 可行性报告 需求有效性 系统模型 验证 用户需求和 系统需求 需求文挡 分析与综合 编写文档 分析评审

需求规格说明与评审 需求规格说明书的格式 需求规格说明评审 优秀的需求规格说明正确性 不和格的需求规格说明 完备性 可行性 一致性 必要性 可验证性 可理解性 可修改性 可追踪性 不和格的需求规格说明 无足够用户参与 用户需求不断增加 模棱两可的需求70%-80% 不必要的特性 过于精减的规格说明 忽略了用户分类

需求分析方法 功能分析方法 结构化分析方法 信息建模法 面向对象的分析方法 不同的开发方法,需求分析的方法也有所不同,常见的分析方法有: 将系统看作若干功能模块的集合,每个功能又可以分解为若干子功能,子功能还可继续分解,分解的结果已经是系统的雏形。 结构化分析方法 是一种以数据、数据的封闭性为基础,从问题空间到某种表示的映射方法,由数据流图(DFD图)表示。 信息建模法 是从数据的角度对现实世界建立模型的,基本工具是ER图。 面向对象的分析方法 面向对象的分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型。

结构化开发方法(Structured Developing Method) 是现有的软件开发方法中最成熟,应用最广泛的方法,主要特点是快速,自然和方便。 结构化方法总的指导思想自顶向下、逐步求精。它的基本原则是功能的分解与抽象。 结构化开发方法的组成 70年代初 结构化程序设计方法 SP法(Structured Program) 70年代中 结构化设计方法 SD法(Structured Design) 70年代末 结构化分析方法 SA法(Structured Analysis)  SA,SD,SP 法相互衔接,形成了一整套开发方法。若将SA,SD 法结合起来,又称为结构化分析与设计技术(SADT 技术)。

2.2.1 SA法概述 一、SA法的基本思想 结构化分析方法的基本思想是“分解”和“抽象”。 1.1 1.2 1.3 x 2 1 3 2.1 2.2 2.3 分解:对于一个复杂的系统,为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决(如右图)。 抽象:分解可以分层进行,即先考虑问题最本质的属性,暂把细节略去,以后再逐层添加细节,直至涉及到最详细的内容,这种用最本质的属性表示一个系统的方法就是“抽象”。

二、SA法的步骤 1、建立当前系统的“具体模型”。 2、抽象出当前系统的逻辑模型。 3、建立目标系统的逻辑模型。 4、为了对目标系统做完整的描述,还需要考虑人机界面和其他一些问题。 三、SA法的描述方法 1、分层的数据流图 2、数据词典 3、描述加工逻辑的结构化语言、判定表及判定树

出版社 顾客 文件名 文件名 DFD图的例子 验证 订单 汇总 图书目录文件 顾客档案 待处理订单文件 正确 一批 出版社档案文件 订货存根文件 加工名 编号 加工名 编号 文件名 文件名

出版社 顾客 画图步骤 : 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 例1:图书预定系统(顶层DFD图) 图书目录文件 出版社档案文件 出版社 订单 出版社 订单 顾客 验证 订单 正确 订单 一批 订单 汇总 订单 待处理订单文件 顾客档案 订货存根文件 画图步骤 : 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来,形成数据封闭。 注意:标注各加工框及数据流名称。 P26 图2.7

2.2.2 数据流图 数据流图(Data Flow Diagram,DFD)是描述系统中数据流程的图形工具,它标识了一个系统的逻辑输入和逻辑输出,以及把逻辑输入转换为逻辑输出所需的加工处理。 一、数据流图的图符 四种基本图形符号: 还有一些辅助的图例: 数据存储 数据源点 或终点 加 工 加工名 数据流 数据流名 文件名 实体名 箭 头 圆或椭圆 单或双杠 矩形框 T A B * C + * 与 + 或 互斥 +

“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤: 2。逐层分解顶层DFD图,获得若干中间层DFD图。 3。画出底层的DFD图。 顶层图说明了系统的边界,即系统的输入和输出数据流,顶层图只有一张。底层图由一些不能再分解的加工组成,这些加工都已足够简单,称为基本加工。在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解,而它的组成部分又要进一步分解。 画各层DFD图时,“由外向内”。

先全局后局部,先整体后细节,先抽象后具体. X 顶层 分层DFD 图 0图 1 3 2 中 间 层 1.1 1.2 1.4 1.3 2.1 2.2 2图 1图 1.1.1 1.1.2 2.1.3 2.1.2 2.1.1 2.2.2 2.2.3 2.2.1 底 层 2.2图 2.1图 1.1图

1、监视病员的病症(血压、体温、脉搏等)。 2、定时更新病历。 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 2.2.4 实例:医院病房监护系统 2.2.4 实例:医院病房监护系统 监视病情 产生 病情报告 经过初步的需求分析,得到系统功能要求: 1、监视病员的病症(血压、体温、脉搏等)。 2、定时更新病历。 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 更新病历

系统功能要求: 1、监视病员的病症(血压、体温、脉搏等) 2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 例2 医院病房监护系统 系统功能要求: 1、监视病员的病症(血压、体温、脉搏等) 2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 顶层: 病员 护士 病员监 护系统 病员日志 病症信号 要求报告 病症报告 报警

第一层: 医院病房监护系统顶层DFD图 1 局部监视 病员极限 病症信号 病员 生理信号 极限值 病员数据 3 报警 中央监视 格式化 护士 病员日志 病症信号 要求报告 病症报告 报警 局部监视 生成报告 病员极限 更新日志 病员数据 格式化 生理信号 极限值 1 3 2 4 日志数据

第二层:加工“中央监视”分解 病员极限 计算超过 极限值否 格式化 时钟 医院病房监护系统二层DFD图 3.1 开解信号 3.2 产生 病员数据 超过极限值 报警 开解信号 产生 报警信息 病员极限 格式化 体温 血压、体温脉搏 生理信号 极限值 时间 脉搏 血压 日期 时钟 3.1 3.2 3.3 3.4

医院病房监护系统分层DFD图 第一层 第二层:加工“中央监视”分解 图 2..15 图 2..16 格式化 病员数据 生理信号 极限值 病员 护士 中央监视 病员日志 病症信号 要求报告 病症报告 报警 局部监视 生成报告 病员极限 更新日志 1 3 2 4 日志数据 计算超过 极限值否 病员数据 超过极限值 报警 开解信号 产生 报警信息 病员极限 格式化 体温 血压、体温、 脉搏 生理信号 极限值 时间 血压 日期 时钟 3.1 3.2 3.3 3.4 第二层:加工“中央监视”分解 图 2..15 图 2..16

所谓数据守恒是指加工的输入输出数据流是否匹配,即每一个加工既有输入数据流又有输出数据流。或者说一个加工至少有一个输入数据流,一个输出数据流。 2.2.5 画分层DFD图的基本原则 数据守恒与数据封闭原则   所谓数据守恒是指加工的输入输出数据流是否匹配,即每一个加工既有输入数据流又有输出数据流。或者说一个加工至少有一个输入数据流,一个输出数据流。 数据封闭是对整个系统而言。 加工分解的原则  自然性:概念上合理、清晰; 均匀性:理想的分解是将一个问题分解成大小均匀的几个部分;  分解度:一般每一个加工每次分解最多不要超过7个子加工,分解应分解到基本加工为止。

2.2.5 画分层DFD图的基本原则 子图与父图的“平衡”   父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同(相对应),分层数据流图的这种特点称为子图与父图“平衡”。 合理使用文件   当文件作为某些加工之间的交界面时,文件必须画出来,一旦文件作为数据流图中的一个独立成份画出来了,那么他同其他成份之间的联系也应同时表达出来。 注意 DFD图不是流程图,不表示软件的控制流程。

分层DFD图的改进 DFD图必须经过反复修改,才能获得最终的目标系统的逻辑模型(目标系统的DFD图)。可从以下方面考虑DFD图的改进: 1、检查数据流的正确性 ① 数据守恒 ② 子图、父图的平衡 ③ 文件使用是否合理。特别注意输入/出文件的数据流。 2、改进DFD图的易理解性 ① 简化加工之间的联系(加工间的数据流越少,独立性越强,易理解性越好)。 ② 改进分解的均匀性。 ③ 适当命名(各成分名称无二义性,准确、具体)。

考务处理系统有如下功能: 对考生送来的报名表进行检查。 对合格的报名表编号准考证号码后将准考证送给考生,将汇总后的考生名单送给阅卷站。 对阅卷站送来的成绩进行检查,并根据考试中心指定的合格标准审定合格者。 填写考生通知单(包括考试成绩和合格/不合格标志),送给考生。 5 进行成绩的统计和试题难度分析,产生统计分析表。

报名表 考务处理 系统 统计分析表 不合格报名表 考生 考试中心 准考证 报名表 合格标准 考生名单 错误成绩表 成绩表 阅卷站

成绩表 报名表 考生通知单 登 记 报 名 表 统 计 成 绩 不合格报名表 统计分析表 准考证 错误成绩表 考生名单 合格标准 考生名册

词条描述:在数据词典中的每个词条都 应包含以下信息: 数据词典(DD) 作用: 为表示每个数据对象和控制项的特性,建立了数据词典。数据词典精确、严格的定义了每个与系统有关的数据元素,并以字典方式将它们组织起来,使得用户和分析员对所有的输入、输出、存储成分都有共同的理解。 词条描述:在数据词典中的每个词条都 应包含以下信息: 名称; 别号或编号; 分类; 描述; 何处使用

内容描述: 符号 含义 举例 = 被定义为 + 与 x=a + b [……,……] 或 x=[a ,b] […|…] 或 x=[a|b] 内容描述:  在数据词典的编制中,分析员最经常用的描述内容或数据结构的符号如图: 符号 含义 举例 = 被定义为 + 与 x=a + b [……,……] 或 x=[a ,b] […|…] 或 x=[a|b] {…} 重复 x={a} m{…}n 重复 x=3{a}10 (…) 可选 x=(a) “…” 基本元素 x=“a” … 连接符 x=1..9

数据词典的实现: 随着系统规模扩大,数据词典的规模和复杂性将迅速扩大 实现方式: 1 全人工过程 2 全自动过程 3 混和过程 数据词典的特点: 1 通过名字能方便的查阅数据定义 2 没有冗余 3 容易修改和更新 4 能单独处理描述每个数据元素的信息 5 定义的书写方式简便而严格

实体关系图(ERD) 数据模型 为了把用户的数据要求清除、准确的描述出来,系统 分析员建立数据模型。从用户角度看到的数据。 数据模型包含3种相互关联的信息: 数据对象——软件必须理解的复合信息 的抽象。 属性——定义了数据对象的性质。 联系——数据对象彼此之间的相互连接 方式。 一对一 一对多 多对多

数据规范化 为减少数据冗余,避免出现插入异常或删除异常,简化数据的修改过程,需要数据规范化。通常用“范式”定义消除数据冗余的程度。 1NF, 2NF, 3nf, BCNF, 4NF, 5NF (1)范式级别越高,存储过程越复杂。 (2)随着范式级别的提高,需求变化时数据 的稳定性较差。 (3)范式级别提高,性能下降。 因此,大多采用第三范式。

行为建模 s1 s2 STD图 利用来描述系统或对象的状态,以及导致系统或对象的状态改变的 事件,从而描述系统的行为。 表示可得到的系统状态 状态的迁移 在箭头上要挟导致状态迁移的 信号或事件的名称 表示可得到的系统状态 s1 t1 t4 t3 s2 s3 t2

状态迁移表 状态 S1 S2 S3 事件 t1 t2 t3 t4 S3 S2 S3 S1 2 Petri网 用于描述并发执行的处理系统

状态图 状态图(state diagram)展示对象所具有的状态,以及哪些事件影响着这些状态。 一张状态图可以有一个起始状态和若干个(可以为0)结束状态,状态之间用标以事件的箭头相连,表示当箭头上所标的事件发生时,执行从一个状态到另一个状态的迁移(transition) 。 状态名 状态变量 活动 状态 迁移 起始状态 结束状态 状态图的基本符号

电梯升降的状态图 Moving up do/moving to floor Moving down Idle timer=0 do/increase timer arrived go down (floor) Moving to First floor go up(floor) [timer=time-out] On first floor

inc/minutes := minutes + 1 事件 事件是指已发生并可能引发某种活动的一件事 数字手表类及其状态图 Digital_Watch mode_button() inc() do/display minutes Set minutes do/display hours Set hours current time Display mode_button inc/hours := hours + 1 inc/minutes := minutes + 1 类 状态图

[timer=time-out] ^self.go down(first floor) 电梯升降的状态图 Moving up do/moving to floor Moving down Idle timer=0 do/increase timer arrived go down (floor) go up(floor) On first floor

加工规格说明 对数据流图中每一个不能再分解的基本加工都必须有一个小说明给出这个加工的精确描述。小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。加工逻辑是其中最基本的部分,是指用户对这个加工的逻辑要求。 对基本加工说明有三种描述方式: 结构化语言 判定表 判定树

一、 结构化英语 结构化英语是介于自然语言和形式语言之间的一种半形式语言,它是自然语言的一个受限制的子集。一般分为两层结构:外层语法较具体,为控制结构(顺序、选择、循环),内层较灵活,表达“做什么”。 例如:外层可为以下结构: 1、顺序结构 2、选择结构 IF–THEN-ELSE; CASE-OF-ENDCASE; 3、循环结构 WHILE-DO; REPEAT-UNTIL

IF the Current–Capital–Value is less then $1000 Then 结构化英语举例 IF the Current–Capital–Value is less then $1000 Then Set Depreciated–Amount to Current–Capital–Value. Set Current–Capital–Value to zero. Otherwise Set Depreciated–Amount to 10% of Current–Capital–Value. Reduce Current –Capital-Value by 10%. 结构化英语特点: 简单,易学,少二义性。不好处理组合条件。

例:一图书销售系统,其中一加工为“优惠处理”,条件是:顾客的营业额大于1000元,同时必须信誉好,或者虽然信誉不好,但是20年以上的老主顾。 应用举例 例:一图书销售系统,其中一加工为“优惠处理”,条件是:顾客的营业额大于1000元,同时必须信誉好,或者虽然信誉不好,但是20年以上的老主顾。 用结构化语言来描述: 如果 营业额大于1000元 同时 如果信誉好 则 优惠处理。 否则 正常处理。 否则 信誉不好 但是20年以上的老主顾,则优惠处理。 否则 营业额小于、等于1000元 则 正常处理。 显然,用结构化英语来描述组合条件不清晰。

判定表是一种二维的表格,常用于较复杂的组合条件(与结构化语言比较)。 二、 判定表 判定表是一种二维的表格,常用于较复杂的组合条件(与结构化语言比较)。 通常由四部分组成。 条件框 — 条件定义。 操作框 — 操作的定义。 条件条目 — 各条件的取值及组合。 操作条目 — 在各条件取值组合下所执行的操作。 条件框 条件条目 操作框 操作条目 例如: 对商店每天的营业额所收税率 营业额X (¥) 1000≤X<5000 5000 ≤X<10000 X≥10000 税 率 5% 8% 10% 特点:可处理较复杂的组合条件,但不易理解.不易输入计算机。

例:一图书销售系统,其中一加工为“优惠处理”,条件是:顾客的营业额大于1000元,同时必须信誉好,或者虽然信誉不好,但是20年以上的老主顾。 判定表应用举例 例:一图书销售系统,其中一加工为“优惠处理”,条件是:顾客的营业额大于1000元,同时必须信誉好,或者虽然信誉不好,但是20年以上的老主顾。 1 2 3 4 >1000元 Y Y Y N 信誉好 Y N N - >20 年 - Y N - 优 惠 X X 正 常 X X 化简后 1 2 3 4 5 6 7 8 >1000元 Y Y Y Y N N N N 信誉好 Y Y N N Y Y N N >20 年 Y N Y N Y N Y N 优 惠 X X X 正 常 X X X X X Y-满足条件 N-不满足条件 X-选中判定的结论

用判定表表达复杂的条件组合的逻辑关系 举例 帽子颜色问题 地点: 某旅游公司的宣传点 人物: 三位同学,小李、小王、小张 旅游公司的主持人 举例 帽子颜色问题 地点: 某旅游公司的宣传点 人物: 三位同学,小李、小王、小张 旅游公司的主持人 故事: 3顶白色 2顶红色 蒙上同学的眼睛,每人 带1顶依次 摘掉蒙 布,猜自己的帽子颜色,可以猜也可以不猜。有一人答对, 三人一起免费旅游。 有一人答错,三人都不能去。 结局:小李先没猜,小王没猜,小张没摘蒙布就猜出来,六人免费 旅游。

帽子颜色问题的判定表 条 件 x 规则1 规则2 规则3 规则4 规则5 规则6 规则7 规则8 红色 白色 小李帽子的颜色 小王帽子的颜色 条 件 规则1 规则2 规则3 规则4 规则5 规则6 规则7 规则8 小李帽子的颜色 红色 白色 小王帽子的颜色 小张帽子的颜色 行 动 不可能,只有2红 x 小李应该猜出 小王应该猜出 排除,因小李、 小王没猜 小张知到自己 带白色帽子

特点:描述一般组合条件较清晰,易理解。不易输入计算机。 三、 判定树 营业额 > 1000元 ≤ 1000元 正常处理 好的支付信誉 优惠处理 坏的支付信誉 > 20年 优惠处理 < 20年 正常处理 如上例 特点:描述一般组合条件较清晰,易理解。不易输入计算机。

教育基金会的捐助资金管理系统 由教育单位提出用款申请,在进行相应的合法性校验和核对相应的捐助储备后做出支出。 1 由捐助者向基金会提出捐助请求,经身份确认后被接受,对捐助人进行登记并授予捐助证书,捐款存入银行。 由教育单位提出用款申请,在进行相应的合法性校验和核对相应的捐助储备后做出支出。 每月给基金会的理事会一份财政状况报表,列出本月的支出和收入情况和资金余额 。

其他图形工具 层次方框图 Warnier图 IPO图

验证软件需求 一致性 人工技术审查 现实性 参照以往经验 ;仿真、模拟技术 有效性 用户参与 完整性 原型法

什么是原型化方法(Prototyping Method) ? 2.3 原型化方 原型化方法   按照传统的瀑布模型进行软件开发,由于将软件开发这样一个充满回朔的过程硬性地割裂开,虽然强调各个阶段的复审,而用户所提出的需求往往是模糊的,因此很难得到一个完整精确的规格说明,直接影响到后期的开发,针对其主要缺点推出了原型化方法。 什么是原型化方法(Prototyping Method) ?   原型是软件开发过程中,软件的一个早期可运行的版本,它反映了最终系统的部分重要特性。   原型化方法的基本思想是花费少量代价建立一个可运行的系统,使用户及早获得学习的机会,原型化方法又称速成原型法(Rapid Prototyping),强调的是软件开发人员与用户的不断交互,通过原型的演进不断适应用户任务改变的需求。将维护和修改阶段的工作尽早进行,使用户验收提前,从而使软件产品更加适用。

由于软件项目的特点和运行原型的目的不同,分为两种类型: 软件原型的分类  由于软件项目的特点和运行原型的目的不同,分为两种类型:  1、废弃(throw away)型  也称为快速建立需求规格原型RSP法(Rapid Specific Prototyping),先构造一个功能简单而且质量要求不高的模型系统,针对这个模型系统反复进行分析修改,让用户学习。待需求说明书一旦确定,原型将被废弃,后阶段的工作仍按照瀑布模型开发。 2、追加(add on)型  也称快速建立渐进原型RCP法(Rapid Cyclic Prototyping)法采用循环渐进的开发方式,对系统模型作连续精化,即先构造一个功能简单而且质量要求不高的模型系统,将系统需要具备的性质逐步添加上去,通过不断地扩充修改,逐步追加新的要求,直至所有性质全部满足,此时的原型模型也就是最终的产品。

快速原型开发模型 构造 快速原型法的工作模型如图所示,按以下步骤循环执行。 快速分析   快速确定软件系统的基本要求,确定原型所要体现的特性(总体结构,功能,性能、界面等)。 2.构造原型  根据基本规格说明,忽略细节,只考虑主要特性,快速构造一个可运行的系统。有三类原型:用户界面原型,功能原型,性能原型。 3.运行和评价原型   用户试用原型并与开发者之间频繁交流,发现问题,目的是验证原型的正确性。 4.修正与改进   对原型进行修改,增删。 快速 分析或修改 运 行 评价 构造 原型化模型

快速建立系统原型进行系统的分析和构造有如下优点: 1、增进软件开发人员和用户对系统需求的理解。便于将用户模糊的功能需求明确化。 细化的原型化模型 构造原型 运行/评价原型 原型完成否 要细部说明否 严格说明细部 效果满意否 整理原型提供文档 修 正 改 进 原 型 Y N 快速分析,确定初步规格说明 快速原型化开发过程 快速建立系统原型进行系统的分析和构造有如下优点: 1、增进软件开发人员和用户对系统需求的理解。便于将用户模糊的功能需求明确化。 2、为用户提供了一种强有力的学习手段。 3、易于确定系统的性能,是理解和确认软件需求规格说明的工具。 4、按照RCP 法建立的原型即为最终的产品。

需求工程小结 最初,需求工程仅仅是软件工程的一个组成部分,是软件生命周期的第一个阶段。 最初,需求工程仅仅是软件工程的一个组成部分,是软件生命周期的第一个阶段。   在传统软件工程生命周期中,涉及需求的阶段称作需求分析。一般来说,需求分析的作用是: ● 系统工程师说明软件的功能和性能,指明软件和其他系统成分的接口,并定义软件必须满足的约束; ● 软件工程师求精软件的配置,建立数据模型、功能模型和行为模型; ● 为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型; ● 提供开发人员和客户需求规格说明,用于作为评估软件质量的依据。

需求工程小结(续) 软件需求分析的工作,是软件开发人员与用户密切配合,充分交换意见,达到对需求分析一致的意见。在开发人员一方,进行需求分析工作的主要是系统分析员和系统工程师等,他们处于用户和高级程序员之间,负责沟通用户和开发人员的认识和见解,起着桥梁作用,是需求分析的主要角色。 需求分析阶段的最终任务是要完成目标系统的需求规格说明,确定系统的功能和性能,为后阶段的开发打下基础。 需求分析的方法和技术因具体的系统而定,常用的有SA法,原型法,OOA法等。

需求工程小结 需求工程是系统工程和软件工程的一个交叉分支,涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。   需求工程的基本活动包括:   ● 抽取需求;    ● 模拟和分析需求;    ● 传递需求;    ● 认可需求;    ● 进化需求。

需求工程小结 一、需求抽取 ——非常困难,主要原因有: 一、需求抽取 ——非常困难,主要原因有: ● 缺乏领域知识,应用领域的问题常常是模糊的、不精确的; ● 存在默认的知识,即难以描述的日常知识(常识问题); ● 存在多个知识源,而且多知识源之间可能有冲突; ● 面对的客户可能有偏见,如不能提供你需要了解什么或不想告知你需要了解的事情。   需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等,还有知识工程方法,如:场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。

需求工程小结 二、模拟和分析需求 ● 指导抽取; ● 帮助需求工程师了解进展; ● 帮助发现问题; ● 帮助检查对问题的理解。   ● 帮助需求工程师了解进展;   ● 帮助发现问题;   ● 帮助检查对问题的理解。 需求分析和模拟又包含三个层次的工作。 1、需求建模 2、需求模拟(分为企业模拟、功能需求模拟和非功能需求模拟等) 3、需求规格说明