需求工程第三讲-需求分析与建模资料
需求分析与建模PPT课件
.
4
5.2 结构化分析
结构化分析（SA）方法是一种面向过程的需求分析方法， 主要对数据 (流) 进行分析，基本思想是将系统抽取出“数 据”和“控制”两部分，再分别进行抽象和处理。
数据流图（DFD）、数据字典（DD）和流程图是结构化 分析最常用的工具。
数据流图用来描述数据流从输入到输出的变换流程。
.
9
5.3 面向对象的分析
------基本思想
面向对象的开发方法可描述为：
（1）客观事物都是由对象（object）组成的 （2对）象对是象在由客属观性事和物方基法础组上成抽象的结果，任何复杂
的事特(传(物34点))递都、对对消可属值象象息以性、之可（通（状间按m过a态的 其ett对s等联 属rsiab象。系 性gue的t通 进）方e）某过 行的法反种传 归方（映组递 类式m对合消e是t象h构息通o的成d来过）信。实消则息现息用特模来征式定。义如改： （c5la变）所s（的s对对类）谓。m象象（这封es属是种cs装ala性被g对（ses状封）象pena态装有或ctta的e的一类prsn各实定之u）l种a体的间和ti操，o结的方n作类构层）法方可，次，所式以结类即定。有构可指义子是以严的类靠有格操(继超的s作u承类模b过c关（块l程as系s化来su)p维。完er成 这系种的封。装的对象满足软件工程的要求，而且可以直接被 面向对象的程序设计语言所接受。
第5章 需求分析与建模
需求分析必要性 结构化分析 面向对象分析 需求用例分析
.
1
5.1 需求分析与软件分析
需求分析的必要性：
神父之牛的故事 有个神父在教堂为一个人忏悔。
那人说：“神父，我要。你应该把那头牛送还给失主才对。”
2．OO方法与结构化方法的比较 结构化方法：基于变换(输入→输出)，数据与指令分开 OO方法：基于分解，数据与指令放在一起
03需求分析PPT课件
2020年9月28日
15
(6) 文档需求
需哪些文档？ 文档针对哪些读者？
2020年9月28日
16
(7) 数据需求
输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？
2020年9月28日
19
(10) 软件成本消耗与开发进度需求
开发有规定的时间表吗？ 软硬件投资有无限制？
2020年9月28日
20
(11) 质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？ 规定系统平均出错时间？ 出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
统
描述现实系统是 如何在物理上实 现的。
目 描述新系统的主要 标 业务功能和用户新 系 的需求，无论系统 统 应如何实施。
2020年9月28日
描述新系统是如 何实施的（包括 技术）。
23
需求分析过程示意
(1) 通过对现实环境的调查，获取请
教务科
购 书 单
12
(3) 环境需求
硬件设备：机型、外设、接口、 地点、分布、温度、 湿度、磁场干扰等
软件： 操作系统 网络 数据库
2020年9月28日
13
(4) 界面需求
有来自其它系统的输入吗？ 到自其它系统的输出吗？ 对数据格式有规定吗？ 对数据存储介质有规定吗？
2020年9月28日
14
(5) 用户或人的因素
准确地定义未来系统的目标，确定为了 满足用户的需求“系统必须做什么”。用 《需求规格说明书》规范的形式准确地表 达用户的需求。
软件需求分析与建模.正式版PPT文档
Computer& Information
需求分析到底做什么之三：消除矛盾
在分析过程中，显然会发现有些需求是相 互矛盾、相互冲突的。由于你是在把收集 的信息放在一个预先定义的结构中发现这 些矛盾的，因此对矛盾的影响范围会有直 观的了解，也知道它影响到哪些层面。这 样，你就可以很快地找到相应的人员，通 过进一步的捕获来消除矛盾。
2．正确认识UML
UML是一种Language(语言) ！ UML是一种Modeling(建模)Language! UML是一种Unified(统一)Modeling Language！
如何选择UML图 ？
12
Computer& Information
第6章 需求分析与建模最佳实践
6.1 需求分析与建模的要点与误区分析 6.2 周期一:理清框架与脉络 You are here!
该工作的输入是需求定义阶段产生的业务 事件列表和报表列表，输出的是领域模型 和用例模型
在整个过程中是针对每个业务事件进行业 务流程分析、业务实体分析和用例分析； 针对每类报表业务实体分析和用例分析。
16
Computer& Information
业务流程分析是针对每个业务事件来进行的，业务事件是 业务流程的触发，沿着对业务事件的响应序列，找到所有
你在这儿！
6.3 周期二：确定需求细节 6.4 其他需求分析
13
Computer& Information
6.2 周期一:理清框架与脉络
14
Computer& Information
6.2 周期一:理清框架与脉络
15
Computer& Information
第三章：需求分析PPT课件
-
3.2 获取需求的方法
1、访谈
访谈有两种基本形式，分别是正式的和非正式的访谈。
当需要调查大量人员的意见时，向被调查人分发调查表 是一个十分有效的做法。
在访问用户的过程中使用情景分析技术往往非常有效。
情景分析技术的用处主要体现在下述两个方面：
(1) 它能在某种程度上演示目标系统的行为，从而便于用户 理解，而且还可能进一步揭示出一些分析员目前还不知道 的需求。
一般使用第三范式。
17
-
3.6 状态转换图
在需求分析过程中应该建立起软件系统的行为模型。状态转换图(简 称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统 的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例 如，处理数据)。
1、状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种 行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可 以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是 既改变状态又做动作。
7．其它需求
-
3.4概念模型
最常用的表示概念性数据模型的方法：实体—联 系方法(Entity-Relationship Approach)，简称ER模型。
E-R模型包含三个基本成分：“实体”、“联 系”、“属性”
(1)实体：是客观世界中存在的且可相互区分的事物。 它可以是人或物，也可以是具体事物或抽象事物。 – 例如：教师、学生、课程是实体。 实体用矩形框表示，如： 教师
在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态) 和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。
状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。
需求工程讲稿(第三讲)需求工程的方法
需求工程的方法过程、方法和技术描述的重要性建模的作用需求工程的维度♦表示维（代表需求的可维护、可验证的程度）⏹非形式的：自然语言⏹半形式的：图形语言（如：UML，DFD，等）⏹形式的：数学或逻辑语言（如：Z，等）♦内容维（代表需求工程的进行程度）⏹模糊的客观世界现象⏹明确的需求规格说明♦一致性维⏹代表某个投资者的观点得到全部投资者的认可需求工程的三维视图非形式非形式形式规格说明表示一致的程度模糊一般完全个人观点公共的观点表示维内容维接受度维再论描述的重要性♦软件开发：获取描述+逐步精化♦需求：是过程的起点需求代码设计系统需求问题描述什么、怎样、相互转化♦传统地，需求应该说明‘什么’而不说明‘怎样’⏹但是这不很容易区分：●一辆小汽车做什么？●一个WEB浏览器做什么？⏹在某个抽象层次上的‘怎样’形成下一个层次上的‘什么’♦Jackson&Zave的工作提供了一个区分：⏹‘什么’涉及系统的目的●对系统来说是外部的●是应用领域的特性⏹‘怎样’涉及系统的结构和行为●对系统是内部的●是机器领域的特性需求需求需求设计设计设计系统子系统单元什么什么什么怎样怎样怎样关注于问题♦问题先于解决方案⏹硬件和软件都能正常运行，但它起的作用却不是所想要的⏹对提早发现潜在的困难有帮助，困难越后发现越难解决♦计算机系统和现实世界的关系计算机系统计算机系统以外的世界解决方案在此问题在此世界和计算机之间的连接需求处于环境之中♦机器⏹我们称要被开发出来的软件系统为机器⏹硬件是为了运行软件而存在的，因此是机器的一部分♦应用领域⏹机器将与它所处的环境发生交互⏹建立机器为了实现现实世界中的某个目的⏹定义机器的环境，就是定义应用领域⏹应用领域常常是人类活动的系统♦实现的决策是出于那些在应用领域中没有基础的需求⏹例子：字典要存放在Hash表中；病人记录要存放在一个面向对象数据库中需求的环境零售企业系统客户银行帐户部门仓库供应商订购，付款帐单信用状态帐单，查询订购财务报告发货通知运送报告需求的环境借书还书续借需求就是描述♦指代：⏹环境中的实体：为它规定一个名字⏹观察到的现象：告诉你怎样识别它，并为它规定一个名字⏹指代通常是非形式的，但它将一个模糊的现象映射到一个形式的（或者说可表达的）语言上♦定义⏹为一个术语给出形式的定义，使这个术语能在其它描述中使用⏹定义或多或少是有用的，但它却是没有对错的需求就是描述♦可反驳的描述：领域的特性⏹陈述领域的某种特性，这种特性在原理上是可反驳的●可能实际上并不会去反驳它，但应该有这样的意识⏹可反驳性依赖于对我们正在描述的领域中的这个被指代的现象的一种询问♦一个粗略的框架⏹是要被开发出来系统描述的一个尝试性描述●允许包含未定义的术语例子♦指代：MOTHER(X,M)：表示M是X的母亲♦定义：CHILD(X,Y) ::= MOTHER(Y,X)∨FATHER(Y,X)♦可反驳的描述：对所有M和X有，MOTHER(X,M) →⌝MOTHER(M,X)♦粗略的框架：每个人实际上都只属于一个家庭描述的语气问题♦描述的不同语气⏹直述：给出一个事实⏹询问：问一个问题⏹命令：传递一个命令⏹假设：陈述一种可能⏹希求：表达一种愿望需求是希求式的♦需求一定包含“应该做什么”♦对需求工程来说，一般应该有的语气：⏹领域特性：直述式语气⏹需求：希求式语气♦语气随开发进程不断变化需求描述需求的表示维坐标语言语言的形式化程度需求的内容维：模型♦现实中的三类模型⏹图示模型：一个雕塑，可视化⏹类比模型：一架模型飞机，使能测试经验的决策⏹分析模型：表示社会经济的一组数学方程，使能分析所描述的系统的可能行为需求中的模型分析模型类比模型理解问题，为问题世界的相关部分建模映射为实现，比如：用数据库存放信息模型的抽象性♦模型不仅仅是描述⏹它具有自己的现象，和它自己的关于这些现象之间的关系●只有当模型的现象按一种系统的方法对应到要被建模的领域的现象时，这个模型才是有用的。
软件需求分析和建模
易变问题：分清需求稳定部分和易变部分
收集活动： 识别真正的客户/用户 正确理解客户的需求
耐心听取客户意见和思考
尽量使用符合客户语言习惯的表达
25/150
2.3 分析和精化
开发一个精确的技术模型，用以说明软件的功能、 特征和约束。
精化是一个分析建模动作，由一系列建模和求精 任务构成
2.1.2 扩展流程：......
31/150
系统需求
系统需求是比用户需求更详细的需求描述，是系 统实现的基本依据
系统需求描述可能包括许多不同的模型，如对象 模型和数据流模型
32/150
软件需求各组成部分之间的关系
33/150
软件需求规格说明的原则
从现实中分离功能，即描述要“做什么”而不是 “怎样实现”
用户交流不够 需求规约质量差 低效的需求分析
有拓展性的系统设计，才会给 系统更大的扩展空间，从而在 需求发生变化的时候可以更从 容的修改。
13/150需求分析的Fra bibliotek要性需求的重要性： 需求是产品的根源，需求工作的优劣对产品影响最大。 是系统开发的基础，质量和成败的关键 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一 直忙碌不停地开发。
软件工程方法与实践
软件需求分析与建模
..
1
主要问题
什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 什么是面向数据的建模？ 什么是面向数据流的建模？ 什么是非形式化建模、半形式化建模和形式化建模？ 什么是统一建模语言（UML）？ 什么是用例建模？ 什么是领域模型？
2/150
软件需求分析过程
软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“产品”， 它是客户、管理者、分析工程师、测试工程师、 维护工程师交流的标准和依据。
第3章 需求分析及功能建模方法
第3章需求分析及功能建模方法3.1 需求分析概述3.1.1 需求分析概念1、所谓需求分折：就是对待开发的系统要做什么，完成什么功能的全面描述。
2、需求分析的工作：通过对需求的调查、了解、观察和分析，通过对原始数据的收集、分类和抽象，并采用有效的技术、工具，对原始资料进行加工整理，描述开发目标、实现的功能及其相互关系等活动的集合;3、需求的定义：客户对一个待开发的系统在实现目标、完成功能、应达到的性能、安全性、可靠性等方面的期望和要求的集合;4、需求获取的困难：(1) 软件功能复杂;(2) 需求的可变性;5、需求分析阶段的主要任务：分析当前的业务流程，包括体系结构，各职能部门完成的主要任务、关系及其交流的信息。
6、需求分析的结果通常以模型等建模工具和方法描述系统的信息流、功能结构及完成各功能需要的数据。
7、功能模型和软件需求规格说明书是软件开发的依据，将指导后续的开发工作。
8、需求分析工作是系统分析员与用户不断交互的过程中完成的。
3.1.2 系统分析员的职能1、系统分析员的主要要任务：是确定应用信息系统及软件产品应该达到的各项功能性要求和非功能性要求，即用户要做什么。
2、系统分析员应该具备的素质：(1) 获取需求的能力;(2) 管理及沟通能力;(3) 技术素养;3.1.3 需求获取的方法常用的几种获取需求的方法：(1)面谈;(2)实地观察;(3)问卷调查;(4)查阅资源;3.1.4 需求分析过程1、标识问题：(1) 需求分析的第一步，通过对问题的识别和标识获得所求解问题及其运行环境的理解;(2) 标识问题从现行系统的业务流程做起，理解现行系统的业务流程;(3) 在标识理解需求的同时，还要注意确定系统的人机界面;2、建立需求模型：(1) 模型是对现实原形所作的一种抽象，其本质是只关心与研究内容有关的因素，而忽略无关的因素，其目的是把复杂的事物变得简单，便于认识和分析;(2) 目前常用的模型方法主要有DFD数据流图和IDEFO，都属于结构化分析方法，其特征是抽象和分解;(3) 首先对应用领域进行全面的分析，发现并找出同类事物的本质，用抽象方法把这类事物的非主要方面剔除，把握住事物的内部规律或本质，就可以找到解决办法;然后采用自上而下逐步求精的方法对复杂的问题进行分解;(4) 结构化分析及建模方法的主要优点：(A) 不过早陷入具体的细节;(B) 从整体或宏观入手分析问题;(C) 通过图形化的模型对象直观地表示系统要做什么，完成什么功能;(D) 图形化建模方法方便系统分析员理解和描述系统;(E) 模型对象不涉及太多的技术术语，便于用户理解;3、描述需求：(1) 需求描述的目标：对软件项目功能性和非功能性的需求全面描述;(2) 功能性需求：指需要计算机实际解决的问题或实现的具体功能，明确描述系统必须做什么，实现什么功能以及输入输出等;(3) 非功能性需求：软件项目对实际运行环境的要求;(4) 需求描述主要由需求模型和需求说明书组成，说明书侧重文字说明，内容如下：需求概述;功能需求;信息需求;性能需求;环境需求;其他需求;(5) 在对需求进行分析过程中，系统分析员要经常考虑的问题：(A) 描述的需求是完全的吗?(B) 需求描述是正确的和一致的吗?(C) 描述的这些需求是可行的、实际可操作的吗?(D) 描述中的每一条需求都是客户需要的吗?4、确认需求：1、评审委员会审核下列内容：功能需求;数据需求;性能;数据管理;其他需求。
数据需求分析与建模ppt课件
M
N
考试
课程
成绩
学生（学号，姓名，性别，年龄） 课程（课程号，课程名，授课老师）
考试（课程号，学号，成绩）
数据字典应用
数据元素说明 > 数据元素名或标识：即对用户而言有意义的名称； > 别名：可选择的名字 > 类型和长度：说明数据元素的组成部分，是数字、 字母还是其他；而长度则是指其最大的组成个数 > 默认值：即数据元素的一个初始值； > 可接受的值：即数据元素有效的合法取值范围 > 数据源：即对数据元素值的起源点的具体说明 > 安全：对于有权访问或更新每个数据元素的人或部 门的标识 > 有责任用户：负责输入/改变数据元素值的用户标识 > 描述和评论：加上一些更好的说明数据元素的注解
OLAP服务器
查询工具
报表工具
分析工具 ……
数据挖掘 工具
一对多关系 > 多端强制性 > 多端非强制性
多对多关系
确定实体间联系时的陷阱
学校
系
1
包含
N
系
1
拥有
N
教师
A)E-R模型
学校 教师
双扇
B)值图
1
N
1
N
学校
包含
系
拥有
教师
E-R图到关系模式的转换
实体模型：每个实体转成一个模式 客户（客户名，身份证号，地址，联系电话）
身份证号
地址
客户名
联系电话
客户
数据需求分析与建模
数据流通过程：数据流图（DFD） 数据存储方式：实体-关系图（ERD） 数据定义方式：数据字典（DD） 数据需求分析与设计要素
数据流图：基本元素
第3讲 需求分析阶段-过程建模
数据流图－外部实体
• 外部实体的图形表示：
– 在图形描述中，外部实体都需要一个名称来标识自己，它们通常会使用 能够代表其特征的名词为名称。
Lable Lable Lable Lable
DeMarco-Yourdon表示法
Gane-Sarson表示法
数据流图－外部实体
• 在实践中，常见的外部实体有：
DFD分层结构-N层图
• 0层图中的每个过程都可以进行分解，以展示更多的细节。被分解的 过程称为父过程，分解后产生的揭示更多细节的DFD图称为子图。对
– 对0层图的过程分解产生的子图称为1层图。 – 对子图中的过程还可以继续分解，即过程分解是可以持续进行的，直到 最终产生的子图都是基本DFD图。对N层图的过程分解后产生的子图称 为N+1层图（N>0）。 – 在低于0层图的子图上通常不显示外部实体。父过程的输入输出数据流称 为子图的接口流，在子图中从空白区域引出。如果父过程连接到某个数 据存储，则子图可以不包括该数据存储，也可以包括该数据存储。 – 子图中过程的编号需要以父过程的编号为前缀。
数据库系统设计
需求分析阶段－过程建模
概述
• 过程（处理）建模是结构化分析方法的典型技术。 • 过程建模将系统看做是过程的集合，其中一些由人来执行，另一些由 软件系统来执行。 • 过程的执行就是对数据的处理，它接收数据输入，进行数据转换，输 出数据结果。 • 过程执行时可能需要和软件系统外的实体尤其是人进行交互，会要求 外界提供数值输入或者将数据结果提供给外部实体。
• 其中
– 上下文图是DFD的一个特定层次，被用来说明系统的上下文环境，确定 系统的边界。 – DFD被用来建立过程的分解结构。
– 微规格说明被用来描述DFD过程分解结构中最底层过程的处理逻辑。
第三讲需求工程(requirementsengineering)资料
两种描述都叫做需求文档，分别对应于用户需求 和系统需求。
Page 10
2.2 需求的类型
用户需求
从客户的角度，采用自然语言配合以图表对目标系 统应提供的服务以及系统操作要受到的约束进行的 声明。
系统需求
系统需求是一种结构化文档，要运用一些专业的模 型详细的描述系统的功能及其约束。系统需求文档 有时也称为功能描述，应该是精确的，它可以成为 双方之间合同的重要内容，同时作为开发工作的依 据。
这种需求来自于系统的应用领域，反映领域特征。 可能是功能需求也可能是非功能需求。
Page 13
2.3.1 功能需求
功能需求描述系统所应提供的功能或服务。
取决于待开发软件的类型、未来的用户以及开 发的系统类型。
功能性的用户需求只需要对系统应提供的服务 进行高层一般描述，对于系统需求，则应该详 细的描述系统功能、输入输出及异常。
Sy stem req uirements elicitatio n
User req uirements elicitatio n
Feasibility stud y Prototyp in g
Requ iremen ts elicitatio n
Reviews
Requ iremen ts v alidatio n
你坐在办公室舒展着紧张了几个月的身躯，头脑中 盘算着如何让客户痛快的付清合同款。 这时，客户走进你的办公室，坐下，直视着你的眼 睛
说道：“我知道你认为你理解了我说的是什么，但
你恐怕不知道，我所说的其实不是我想要的。”
Page 4
需求工程过程
需求工程过程并不具有唯一的模型，按照不同的 应用领域、不同的客户与开发团队，需求工程的 过程有很大的差异。 然而，在所有的过程中都会涉及一些共同的活动， 它们是：
需求分析与建模PPT课件
需求分析必要性 结构化分析 面向对象分析 需求用例分析
.
1
5.1 需求分析与软件分析
需求分析的必要性：
神父之牛的故事 有个神父在教堂为一个人忏悔。
那人说：“神父，我偷了别人一头牛，我该怎么办？我把牛给你 好不好？”
神父回答：“我不要。你应该把那头牛送还给失主才对。”
如果你的分析习惯是在调研需求时最先弄清楚有多少部门 ，多少岗位，然后找到每一个岗位的业务代表，问他们类 似的问题：你平时都做什么？这件事是谁交办的？做完了 你需要通知或传达给谁吗？做这件事情你都需要填写些什 么表格吗？....那么恭喜你，你已经OO啦！
.
14
5.3 面向对象的分析------基本概念
1）类、属性、方法 类是具有相同属性和操作的对象集合的总称。它是面向
对象的一个基本概念，类封装了客观世界中对象实体的特征 与行为，即属性与方法。其表示法是一个矩形，由带有类名、 属性和方法（操作）的分格框组成。如下图所示。
.
16
5.3 面向对象的分析------基本概念
属性
属性是指类的特性，它 描述类所具有的一系列特性 值。一个类可以有多个属性， 也可以没有属性。在类图中 属性只要写上名字就可以了。 如右上图.
.
26
5.3 面向对象的分析------基本概念
7）依赖(dependency) 依赖是指一个类中的元素使用了另一个类。
依赖关系描述类之间的使用关系。
.
27
5.3 面向对象的分析------基本概念
8）关联 关联（Association）是指对象类之间具有的
语义联系。其基本表示如下。
应用于关联的4种修饰： •关联名 •角色名 •多重性 •限定符与约束符
4需求建模与分析
改进的目标G5：导航系统应允许驾驶员在不分散驾驶 员注意力的情况下输入所期望的目的地
20
3.1.2 目标描述的7个规则
• 规则6：为引入目标的原因提供简要而准确的描 述。了解引入目标的原理有助于对目标本身的 讨论，并支持对其他相关目标的识别
目标G6：系统应当提供直观的用户接口。 ？为什么要直观
改进的目标G6：因为80%的用户每月仅使用本系统12次，因此系统应当提供直观的用户接口。
目标G4：提高驾驶安全性。 ？可评测
改进的目标G4：通过AND分解 目标G4.1：在路面湿滑情况下降低20%的刹车距离 目标G4.2：在刹车过程中确保汽车的可操纵性
19
3.1.2 目标描述的7个规则
• 规则5：尽可能准确地描述目标为相关涉众创造 的价值或所期望创造的价值
目标G5：导航系统应当提供一种直观的输入旅行目的 地的方式。 ？什么是直观
2
3.1.1 目标建模基础
• 目标：是关于系统的目的、属性或者使用的 意图
̵ 可以在不同抽象层次上定义
• 高层目标：定义公司策略或产品策略相关的目标 • 具体目标：定义涉众关于系统使用和系统属性的期望 高层目标 精化 具体目标
3
3.1.1 目标建模基础
• 目标之间的关系
̵ 分解关系
• AND/OR分解关系
26
3.1.3 目标建模方法
定义：目标模型 目标模型是一种描述目标、目标向子目标的分解关系， 以及现有的目标依赖关系的概率模型
• 目标建模方法
̵ 目标建模语言
̵ 规则和指南：指导需求工程师有目的地使用目标建模语 言的建模元素来描述已知事实或建立有意义的目标模型
̵ 管理实践：为涉众规划、控制建模方法的使用
第3章需求工程与需求分析
许多的需求分析专家给出了不同形式的需求定义， 但从这些不同形式的定义不难发现：并没有一个清 晰、毫无二义性的“需求”术语存在，真正的“需 求”实际上在人们的脑海中。任何文档形式的需求 （例如：需求规格说明）仅是一个模型，一种叙述 （Lawrence 1998）。我们需要确保所有项目风险 承担者在描述需求的那些名词的理解上务必达成共 识。
解决问题的建议
1. 了解系统需求 2. 市场调查 3. 访问用户和用户领域专家 4. 考察现场
调查的方式
1. 调查提纲或调查表 2. 小型调查会议 3. 个别访问 4. 现场调查 5. 资料 6. 调查工具
调查中应注意的事项
1. 不要用计算机专业术语与用户或用户 领域专家交谈
2. 不要使用“你应该…”这样的字眼 3. 始终记住自己最近一段工作中要达到 的目标，引导用户说出你需要的信息
第3章需求工程与需求分 析
2021年8月5日星期四
3.1 基本的软件需求
基本的软件需求
软件项目中百分之四十至百分之六十 的问题都是在需求分析阶段埋下的 “祸根” 。可许多组织仍在那些基本 的项目功能上采用一些不合规范的方 法，这样导致的后果便是一条鸿沟 （期望差异）—开发者开发的与用户 所想得到的软件存在着巨大期望差异。
⑽ 从最近一次电源打开状态算起，如果B2被按下的次数比B3被按 下的次数多，L1亮，否则L2亮。 ⑾ 任何时候都不能有一个以上的灯泡亮；
软件系统运行时多所处的环境要求。 4．可靠性需求 各种软件在运行时，失败的影响各不相同，在需 求分析时，应对所开发的软件在投入运行后不发生 故障的概率，按实际的运行环境提出的要求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
❖ 系统模型的例子
▪ 数据处理模型 ▪ 组合模型 ▪ 分类模型 ▪ 刺激-响应模型 ▪ 过程模型
分析5:事件列表与功能列表
❖ 事件就是要求系统执行某项功能的请求 ❖ 业务事件与产品事件 ❖ 对复杂的业务任务采用任务说明、用例说
❖ 系统模型的界定 ❖ 需求规格说明中应该包含的高层次的模型
▪ 表示系统运行环境的模型 ▪ 说明系统如何分解为子系统的体系结构模型
❖ 系统建模需要注意的事项
需求分析前的工作
❖ 需求（系统）分析与建模
▪ 理解真实世界中的问题和用户的需要并提出 满足这些需要的解决方案的过程。
❖ 分析前的准备
▪ 确认系统的参与者 ▪ 确认系统的运行环境 ▪ 确认系统的约束
明或数据流图等方法进行解释。 ❖ 对复杂的功能采用数据流图、算法描述、
活动图、数学说明等进行解释
事件列表与功能列表(续)
❖ 事件及功能列表的优点
➢主要作为核对清单，以说明应开发什么。而 其中对这些功能的详细说明构成了功能需求 的主要部分
内容
❖ 需求分析概述 ❖ 结构化需求分析方法 ❖ 面向对象需求分析方法
需求分析与建模—结构化方法
❖ 结构化方法是一种系统分析和设计的方 法，包括定义、开发和确认系统模型过 程中用到的表示法、指南和规则。
❖ 功能需求分析与建模方法
▪ 功能需求说明数据的用途，以及如何记录、 计算、转换、修改及传输数据等。
❖ 效益
▪ 体系结构模型有助于划分系统需求 ▪ 体系结构模型说明了系统功能的概况 ▪ 体系结构模型有助于需求工程师找出那些涉及多个
子系统的需求
❖ 体系结构模型描述方式-方框图
系统体系结构“标准”模式
❖ 客户机-服务器
▪ 通用服务器提供共享的系统功能
❖ 分层系统
▪ 系统功能通过调用更低层次所提供的功能来实现
需求工程
第三讲 需求分析与建模
内容
❖ 需求分析概述 ❖ 结构化需求分析方法 ❖ 面向对象需求分析方法
需求分析的过程
分类筛选 合并 排序
需求分析成功的条件
甲方明确的 建设目标
乙方正确的 方法论
需求分析
分析什么？
业务流程优化 关键问题
怎么分析？
结构化分析法 面向对象分析法
系统建模
❖ 系统模型描述了系统的某个特殊方面，在需求文 档中对自然语言描述的系统需求加入补充信息。
需求分析的方法
❖ 绘制系统关联图 ❖ 创建用户接口原型 ❖ 分析需求可行性 ❖ 确定需求的优先级别 ❖ 为需求建立模型 （模型包括数据流图、实体关系
图、状态变换图、对话框图、对象类及交互作用图 ）
❖ 创建数据字典 ❖ 使用质量功能调配
需求分析方法（细节）
❖ 采用SRS模板 ❖ 指明需求的来源 ❖ 为每项需求注上标号 ❖ 记录业务规范 ❖ 创建需求跟踪能力矩阵 ❖ 审查需求文档 ❖ 以需求为依据编写测试用例 ❖ 编写用户手册 ❖ 确定合格的标准。
▪ 和正在说明的系统直接交互的其他系统 ▪ 其他有可能和本系统共存并发生交互的系统 ▪ 系统所在的业务过程（定义涉及的行为、它们的输入
和输出、负责这些过程的人以及支持这些过程的软件）
系统环境建模-上下文图
❖ 作用：
➢ 上下文图能很好地概括产品的必要接口，初步确新 产品包含了哪些内容，产品之外又包含哪些内容。 即说明产品及其环境的图示
SA法的基本思想
结构化分析方法的基本思想是“分解”和“抽象”。
分解：对于一个复杂的系统，为 了将复杂性降低到可以掌握的程度， 可以把大问题分解成若干小问题， 然后分别解决（如右图）。
x
1
3
2
1.1
1.2
1.3
2.1 2.3
2.2
1.1 1.3
抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略 去,以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的 属性表示一个系统的方法就是“抽象”。
输入数据
表 示 层
输出数据
请求按钮
业务处理请求和业 务处理所需的全部
输入数据
业务处理开始 数据存取请求
全部处理结束
业务处理结束
业务处理程序
SQL请求开始
数据登录/更新/读取
数
的请求
据
层
DBMS执行SQL
SQL请求结束
数据登录/更新/读取 的结果
业务处理开始 数据存取请求
业务处理结束
数据存取程序
分析4:开发互补的系统建模
分析1:定义系统的边界
❖ 评估原始需求，定义将要开发的计算机系 统的边界。
▪ 确定哪些是系统需求 ▪ 哪些是和系统相关的操作过程的需求 ▪ 哪些在系统范围之外的需求
❖ 原则
分析2:系统环境建模
❖ 环境模型是系统将要使用的语境模型，应该是最 先开发的系统模型之一。
❖ 效益：记录必须说明接口的外部系统 ❖ 模型包括：
❖ 数据需求分析与建模方法
▪ 数据需求指定系统的存储数据
结构化分析方法
结构化开发方法（Structured Developing Method） 是现有的软 件开发方法中最成熟、应用最广泛的方法，主要特点是快速、自然 和方便。结构化开发方法由结构化分析方法（SA法）、结构化设计 方法（SD法）及结构化程序设计方法（SP法）构成的。
结构化分析方法是面向数据流的需求分析方法，是20世纪70年 代末由Yourdon,Constaintine及DeMarco等人提出和发展，并得到广 泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理 系统。
SA法也是一种建模的活动，主要是根据软件内部的数据传递、 变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。
➢ 说明产品的范围
❖ 优点：
➢ 上下文图为开发人员概括了所有的接口，在开发中 或开发后，方便地验证是否已处理了所有接口
➢ 用户能不费力地理解上下文图，并发现遗漏的接口。
系统环境建模案例
❖ 邮件传阅系统环境建模
▪ 企业OA办公系统 ▪ 图书管理系统 ▪ 操作管理员 ▪ 一般工作人员
分析3:系统体系结构建模
❖ 基于库的系统
▪ 子系统通过一个共享库进行通信
❖ 管道系统
▪ 系统中的每个部件都进行一定的计算，并将结果传 给其他部件以进行进一步的操作
体系结构建模举例
浏览器
HTTP请求
HTTP应答
WEB服务器
应用服务器
数据库服务器
HTML、 ActiveX、 Script
用户界面层
ASP、XML
应用逻辑层 数据层