软件需求分析和建模

16/150
功能需求
软件系统的功能需求描述可以有许多方式： 文字描述 图表表示
功能需求可以以不同的详细程度反复编写和细化 功能需求描述应该完整而且一致和准确
完整性意味着用户所需的所有的服务应该全部给 出描述
一致性意味着需求描述不能前后矛盾 准确性是指需求不能出现模糊和二义性的地方
17/150
功能需求描述：出卷系统
经过需求处理后，达到需求规范要求 分析的方法是一套“建模”技术
15/150
软件需求的分类
功能需求：描述系统预期提供的功能或服务 对系统应提供的服务 如何对输入做出反应 系统在特定条件下的行为
非功能需求：指那些不直接与系统具体功能相关 的一类需求 产品需求 机构需求 外部需求
领域需求：源于系统的应用领域需求
1、软件需求可定义为： 用户需解决某一问题或达 到某一目标所需的软件功能。
2、系统或系统构件为了满足合同、规约、标准或其 他正式实行的文档而必须满足或具备的软件功能。
5/150
需求工程基本任务
需求工程
需求开发
需求管理
需求获取
需求分析
需求验证
需求规格说明
变更管理
6/150
需求分析的基本任务
需求分析的基本任务不是确定系统怎样完成它的工 作，而是确定系统必须完成哪些工作，也就是对目 标系统提出完整、准确、清晰、具体的要求。并在 在需求分析阶段结束之前，由系统分析员写出软件 需求规格说明书，以书面形式准确地描述软件需求。
非功能需求关心的是系统整体特征而不是个别的系统 的特征，比功能需求对系统更关键。
达 需
DFD图、STD图、
求 E-R图、用例
图、
类图、顺序图
等
8/150
需求分析模型
逻辑模型
物理模型
(本质模型、概念模型) (实施模型、技术模型)
现 行 描述重要的业务功能 系 ，无论系统是如何实 统 施的。
描述现实系统是如何 在物理上实现的。
目 描述新系统的主要业 描述新系统是如何实 标 务功能和用户新的需 施的（包括技术）。 系 求，无论系统应如何 统 实施。
需求分析的任务就是借助于当前系统的逻辑模型导 出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
7/150
当前系统 模型化
怎 物理模型 么 做 物理模型 具体化
目标系统
需求分析模型
系统实现模型
需求分析的 主要工作
做什么
理
抽象化 逻辑模型
解 需
系统流程图
求 或高层DFD图
导
实例化 逻辑模型
出表
需求分析是通过问题识别、分析与综合、制订规格说明和评 审等阶段，达到为系统设计提供依据的目标。因此，需求分 析过程包括： 确定对系统的综合要求 分析系统的数据要求 抽象出并确立目标系统的逻辑模型 编写需求规格说明书
14/150
需求分析的成果
需求分析就是为了实现系统需求，并使最后交付成果与需求 所要求的目标不产生：含糊性、不完整性、不可检验性、不 一致性、不可追踪性和不可用性。
软件工程方法与实践
软件需求分析与建模
..
1
主要问题
什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 什么是面向数据的建模？ 什么是面向数据流的建模？ 什么是非形式化建模、半形式化建模和形式化建模？ 什么是统一建模语言（UML）？ 什么是用例建模？ 什么是领域模型？
2/150
软件需求分析过程
3/150
软件需求分析过程
什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 需求规格文档有哪些内容？ 需求分析有哪些技术？
4/150
1 什么是软件需求
一般把需求定义为“（正在构建的）系统必须符 合的条件或具备的功能或能力”。电气和电子工程师 学会使用的定义与此类似。
著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定 义，它特指软件方面 - 但不仅仅限于软件：
用户交流不够 需求规约质量差 低效的需求分析
有拓展性的系统设计，才会给 系统更大的扩展空间，从而在 需求发生变化的时候可以更从 容的修改。
13/150
需求分析的重要性
需求的重要性： 需求是产品的根源，需求工作的优劣对产品影响最大。 是系统开发的基础，质量和成败的关键 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一 直忙碌不停地开发。
题是： 1、需求规格说明 2、管理客户需求 相对而言，编码不 是问题
1、需求规格说明 4、软件和测试
2、管理客户需求 5、项目管理
3、建档
6、编码
问题的重要性依次降低
11/150
需求错误的代价
0.1-0.2
需求阶段
0.5
设计
1
编码
2
单元测试
5
验收测试
20
维护
源自文库
修复的相对成本
“ 需求开发可能是软件开发中最困难、最关键、最易
教师能够根据自己的要求手动或自动出一份试卷； 教师可以修改试卷中不合适的题目，并能自动生
成各种样式的试卷； 教师可以对试题中的题目进行更新。
18/150
非功能需求
非功能需求主要与系统的总体特征相关，是一些限制 性要求，是对实际使用环境所做的要求 性能要求 可靠性要求 安全性要求 可用性要求 移植性要求
需求分析面向下阶段——系统概要设计 需求分析采用自己的特定方法，达到相应的阶段要求
采用的方法是尽量地让用户和开发团队都能理解并认同 系统目标和范围界定的方法——业务/系统模型、用例和 USE CASE图
需求分析阶段的目标是用计算机的（而不再是用户）眼 光和语言，分解需求、定义需求。但是，这个眼光不是 程序设计员的眼光，是系统分析师的眼光
9/150
软件需求曾经让我们如此狼狈
10/150
软件开发的问题分类
ESPITI(欧洲软件
过程改进培训倡议）
所作的一个调查， 3800个被调查者认
60 50 40
为，软件开发的主 30
要问题、次要问题 20
和不是问题的问题 10
如图。
0
一半以上的人认为，
123456
主要问题 次要问题 不是问题
软件的二个最大问
出错以及最需要沟通的方面 ”
12/150
需求变化
合理范围内的变化：
用户不了解自己的需求
需求本身易变，市场、技术、竞争因素
不合理的变化：
需求文档质量不高
需求分析技能、技术和管理上的缺陷
需求变化的原因： 未受控制的需求变更 遗漏需求
谨记一点，需求是经常变动的， 只有先做好需求的分析，了解 业务以后的发展趋势，做好具