本讲的主要内容
? 软件需求分析的意义
? 需求分析的步骤
? 需求规格说明书 SRS
? 需求分析方法学
? 结构化分析方法
需求（ Requirements)
? 定义,需求是关于系统将要完成什么工作
(what)的一段描述语句,它们必须经过所
有相关人员的认可,其目的是彻底解决客
户的问题。
? 需求是指用户或者客户对要开发的软件
系统的要求。需求的内容在, 问题定义,
中描述（可能是招标文件）。
软件需求的类型
? 功能需求
– 系统可以完成的所有事情
– 涉及与本系统有接口的其他系统的所有事情
? 非功能需求
– 是软件开发过程中必须遵守的约束（ Constraint)。
是对可以使用的资源和软件质量的各个方面的限
制，往往会影响软件工程师做决策的自由度。
– 非功能需求应是可验证的（ Verifiable)。
非功能需求
目
标
系
统
的
限
制
性能 实时性、精确度、资源利用率等
可靠性 有效性、完整性
安全 /保密性 安全性、保密性
运行限制 使用频度、运行期限、控制方式、操作要求
物理限制 系统规模等限制
开
发
和
维
护
的
限
制
开发类型 实用性开发、试验性开发
开发工作量的估计
开发方法 质量控制标准、里程碑和评审、验收标准
优先性和可修改性
可维护性
需求分析 (Requirements Analysis)
? 指开发人员为了准确地理解和表达用户要求，进
行细致的调查分析，将用户非形式的需求陈述转
化为完整的需求定义，再由需求定义转换到相应
的形式功能规约（需求规格说明）的过程。
? 准确地回答, 系统必须做什么？,
? Requirements analysis results in the specification of
software’s operational characteristics； indicates
software’s interface with other system elements; and
establishes constraints that software must meet,
需求分析的意义
? 有关软件错误和需求分析的一组事实
– 在软件生命周期中，一个错误发现得越晚，修复
的费用也越高。
– 许多错误是潜伏的，并且在错误产生后很长一段
时间才被检查出来。
– 在需求过程中会产生很多错误和误解，人与人之
间的“通信”障碍无法避免。
– 需求阶段代表性的错误：疏忽、不一致、二义性。
– 需求错误是可以被检查和审查出来的。
需求的相关概念
? 问题域与解空间
– 现实世界中系统处理的业务范围。
– 问题空间，它是人们利用认识现实世界和描述现实
问题的方法所描述的。它与“解空间”的概念相对
应，软件工程应该是问题空间和解空间一致
? 系统责任
– 所开发的系统应该具备的职能。
? 系统边界
– 开发出的系统和与该系统打交道的人或物之间的明
确边界。
领域分析（ Domain Analysis)
Domain
Analysis
Sources of
Domain
Knowledge
Domain
Analysis
Model
Technical literature
Existing applications
Customer surveys
Expert advice
Current/future requirements
Class taxonomies
Reuse standards
Functional models
Domain languages
需求过程中可能的参与者
? 合同监督人员, 提出里程碑 （ Milestones） 和约
束系统开发进度的计划
? 需求者, 客户 (Customer)和使用者 (User)。
? 开发者
– 项目管理者, 必须理解建立和使用目标系统所可
能产生的后果 。
– 系统分析员 ——分析阶段活动的主体 。
– 设计员 ——依据需求提出可接受的解决方案 。
– 测试员 ——确保软件系统满足每一需求 。
系统分析员应具有的素质
? 综合能力
– 总体规划，抽象和分解，本质确认的能力
? 过程
– 保证整个过程的善始善终的能力
? 交流
– 理解和表达能力
? 技术
– 了解问题域和描述解空间的能力
资金
需求
合同义务
软件系统
需求
客户
发起系统开发
用户
使用系统
开发者
建立系统
软件开发的参与者
参考当前系统建立目标系统模型
当前系统
目标系统
物理模型
物理模型
逻辑模型
逻辑模型
模型化
怎么做
具体化 实例化
抽象化
做什么 理解
需求
表达
需求
导
出
需求获取和分析的步骤
? 通过对现实环境的研究，获得系统具体模型。
? 去掉具体模型的非本质因素，抽取出当前系
统的逻辑模型
? 分析当前系统和目标系统的差别，建立目标
系统的逻辑模型。
? 对目标系统进行完善和补充，写出完整的需
求分析。
学生在学校教材科购买教材的系统的例子
一、通过对现实环境的研究，获得系统具体模型。
购书
发票 购书单 书
购书
证明赵秘
书
购书
申请 钱会
计
孙出
纳 李保管
学
生
学
生
学生在学校教材科购买教材的系统的例子
二、去掉具体模型的非本质因素，抽取出当前系统的逻辑模型
发票 领书 单 书有效 单有效
性
购书
单 开票 开领
书单
发书学
生
学
生
学生在学校教材科购买教材的系统的例子
三,分析当前系统和目标系统的差别，建立目标系统的逻辑模型。
发票
领书
单 书审查并开发票
购书
单 开领书单 发书学
生
学
生
学生在学校教材科购买教材的系统的例子
四,对目标系统进行完善和补充，写出完整的需求说明。
五、对需求说明进行复审，直到确认文档齐全并符合用户
的全部需求为止。
发票 领书单审查并
开发票
购书单 开领书单
无效书单
学
生
学
生
需求规格说明书 SRS
需求分析结果 ?SRS，它一般包括：
? 引言：问题定义所确定的目标和范围
? 数据描述：数据流图，数据字典等等
? 功能描述：功能要求文档（可形式化描述）
? 性能描述：性能要求文档
? 质量保证：描述交付前需要进行的各种测
试和验收标准
? 其他：运行要求、将来可能的要求
第四讲
软件需求获取与描述
一、需求分析越来越难
1,问题域的复杂性越来越高 。
2,交流障碍 。 需求分析过程所涉及人员具备
的背景知识不同, 考虑问题的角度不同,
扮演的角色不同, 相互之间的交流存在一
定的困难 。 认识可能混淆, 产生误解 （ 自
然语言的多义性, 一语双关 ） 。
3,完整性问题 。 用户对问题的陈述往往是不
完备的, 需求之间可能存在着矛盾 。 用户
意见不统一 。 涉及许多细节 。
4,需求易变性 。 需求永远不会稳定, 往往存
在错误的需求
二、需求收集与分析技术
? 观察（ Observation)
? 面谈 (Interviewing)
? 头脑风暴 (Brainstorming)
? 原型化 (Paper prototype or Rapid prototype)
? 非正式用例分析 (Informal use case analysis)
三、需求阶段所要获取的主要内容
? 物理环境 (Physical Environment)
? 接口 ( Interfaces)
? 用户或人的因素 (Factors)
? 功能 (Functionality)
? 文档 (Documentation)
? 数据 (Data)
? 资源 (Resources)
? 安全性 (Security)
? 质量保证 (Quality Assurance)
? 设备的主要用途, 在哪里发挥什么作用？
? 所须设置的设备的多少？
? 环境限制等, 如温度, 湿度或磁声干扰？
1,物理环境描述 (Physical Environment)
? 来自一个或多个其他系统的输入？
? 对一个或多个其它系统的输出？
? 数据是否必须预先进行规定的格式化处理？
? 数据是否需要预先存放的介质？
2,接口描述（ Interface Description）
? 谁使用系统？
? 有几种类型的用户？
? 每种类型用户的技术水平怎样？
? 对每型用户需要什么样的培训？
? 用户理解, 使用系统的难易度怎样？
? 用户误用系统的困难程度怎样？
3,用户和人为因素
? 系统将做什么？
? 系统将在何时做？
? 有几种操作方式？
? 系统能在何时、怎样被改变或增强？
? 对执行速度，响应时间或数据流量有何限
制和约束？
4.功能描述 （ Function Description）
5,文档 （ Documents）
? 需要多少文档？
? 是联机文档还是静态文档或者二者皆可？
? 文档所面向的对象 （ 读者 ）？
6,数据 （ Data）
? I/O数据格式应该是什么样的？
? 数据收或发的频度？
? 数据的精确度
? 系统流经的数据流量？
? 数据必须在何时予以保存, 保存多久？
7,资源描述（ Resource Description）
? 建立和维护系统都要什么材料, 人员或其
他资源？
? 开发者必须具有哪些技术？
? 系统占用多少物理空间？
? 对开发规定了时间表了？
? 对用于开发或软硬件上的资金有限制？
? 对系统或信息的存取必须在我们的控制之
下？
? 不同用户的数据之间将如何实现隔离？
? 不同用户程序之间，以及和操作系统间怎
样隔离？
? 系统如何备份？
? 备份副本必须被存于一个不同的位置？
? 应采取措施防火，防水防盗等安全措施？
8,安全描述 (Security)
? 质量属性：可靠性, 有效性, 可维护性等要求？
? 如何向别人示范系统的特征？
? 系统必须有效检测并隔离故障？
? 平均无故障时间规定为多少？
? 对一次失败后重启系统有一个最大时间？
? 系统如何将变化合并到设计？
? 维护将仅仅是纠正错误, 还是包括改进系统？
? 对资源和响应时间使用什么样的有效度量？
? 系统移植性 （ 如不同的硬件环境和操作系统环境
等 )容易程度如何？
9,质量保证 (Quality Assurance)
? 结构化分析方法
? Z 语言,RSL,RSML等（形式化的需求
描述语言）
? 原型需求分析方法
? 面向对象方法（能够更好地消除“语义断
层”）
? UML(Unified Modeling Language)
四、软件需求分析方法学
五,How to Express Requirements
1,Static descriptions
2,Dynamic descriptions
3,Object-oriented specification
4,Formal Methods
1,Static Descriptions
? 数据流图、数据字典、加工说明等
? 判定表（ Decision Tables ），判定树
? E-R模型（ p52)
? 层次方框图,Warnier图,IPO图（ p58)
Warnier Diagrams
Software
products
System
Application
OS(n1)
Compiler(n2)
Software Tool
Editor(n3)
Test driver(n4)
CAD tool(n5)
IPO Diagrams
Oldmaster
files
Otherfiles
Input Process Output
VertifyPrimary
Record
VertifyOrther
Record
Updaterecord
ValidPrimary
Record
ValidOrther
Record
Updatedfiles
A New Form of IPO
IPO
System,Modules,
Date,NO,
Call,Be Called,
Input,Output,
Process,
Local data,Annotation,
Decision Tables
Rule
1
Rule
2
Rule
3
Rule
4
Rule
5
High standardized exam scores T F F F F
High grades — T F F F
Outside activities — — T F F
Good recommendations — — — T F
Send rejection letter X X X
Send admission forms X X
2,Dynamic Descriptions
? Functional Descriptions and Transition
Diagrams
? Event Tables
? Petri Nets （ p72)
Functional Descriptions
? ? kji SCSf ?,
State i State kCondition j
Transition Diagrams
S i S k
Event or Condition X
Transition Diagrams→ Transition Table
S1 S2
S3
0
1
1
1
0
0
Current state Input Next State
S1 0 S2
S1 1 S1
S2 0 S2
S2 1 S1
S3 0 S1
S3 1 S3
Fence Diagram showing State Transitions
(Null)
Requested
On waiting list
Confirmed
Used
Canceled
Archive
(Hotel reservations)
UML notation for state transition
S1 S2
condition
actions
Event Tables
Mode Event1 Event2 Event3 Event4
Graphics Action1 Action8 0 X
Architecture X
Action2
followed by
Action3
Action5,6
in parallel 0
Native 0 Action4 Action1,2,3 Action7
Petri Nets
C,A,Petri (1962,German),
To represent a complexity system in graphical
mode and describe synchronization an parallel
processing
f (State A,Event)→ State S
f (State A,Event 1,Event 2,…,Event N)→ State S
f (State A,Event 1,Event 2,…,Event N)→ State1,
State2,…,State M
Petri Nets(2)
? Tokens（标记、令牌）
? 四种表示符号 —位置、转移、前提、结果（ p66)
? 以下四种 Firing rules
No firing
? Object
? Class
? Method or Operation
? Encapsulation
? Inheritance hierarchy
? Multiple Inheritance
? Polymorphism
3,Object-oriented specification
4,Formal Methods
The Encyclopedia of Software Engineering
defines formal methods in the following manner:
A method is formal if it has a sound mathematical
basis,typically given by a formal specification
language,This basis provides a means of precisely
defining notions like consistency and
completeness,and more relevantly,specification,
implementation and correctness.
六、对需求说明书的要求
? 正确性
? 无二义性（需求确实是用户所需吗？）
? 完整性（完备性，包括用户需要的每一功能或性能）
? 一致性（需求之间不能互相矛盾）
? 可检验性（非计算机人员可以理解）
? 可实现性（有效性，需求是能够现实的吗？硬件系
统的支持力度怎样？）
? 可修改性
? 可跟踪性
? 注释
七、对需求规约的验证
验证的方法
? 复审和进一步需求分析
? 实现原型系统
? 支持需求分析工具
验证的主要内容
? 一致性验证
? 现实性验证（需求是现实的吗？）
? 完整性（完备性）和有效性验证
? 必须有形式化的语法，便于计算机的自动
解释和实现。
? 得益于这些工具的支持，自动导出文档。
? 提供分析 SRS不一致性和冗余性的手段，
给出 SRS完整性分析报告。
? 能够改进用户、开发人员、客户之间，以
及可阶段之间的通信状况。
八、需求分析工具的基本要求
九、需求分析工具实例一 PSL/PSA
（ Problem Statement Language/Analysis ）
1977年由美国密执安大学开发。
PSL是用来描述系统的形式语言，其描述结果由
PSA进行分析和处理以产生各种报告。
PSL/PSA的主要功能：
? 描述任何应用领域的信息系统
? 创建一个数据库保存对信息系统的描述符；
? 对描述符数据库进行管理
? 生成格式化的需求文档和关于 SRS的各种分析报告
十、需求分析工具实例二 RSML
（ Requirement Specification Modeling language）
? 1996年由加利福利亚大学开发的一种对层次性的基于
状态的需求进行完整性和一致性检查的方法 。
? RSML将目标系统看成是一台有限状态机, 对事件的
状态, 转换以及事件序列进行建模 。
? RSML可以图形化地定义一个叫做, next-state”的数学
函数, 以定义所有可能的系统状态 (d-completeness特性 ）,
也能说明系统是一致性 。
? RSML被用于分析美国空间冲突规避系统 （ TCASⅡ ）,
揭示了一个意外的含有严重的安全隐患的不确定性问题,
而这在原需求规格中是不明显的 。
第五讲
结构化需求分析方法与形
式化说明技术
面向数据流的分析方法
? 提出,Yourdon E.和 Constantine L.等人
? 类型,结构化分析 （ Structured Analysis） 方法。
? 数据流图（ Data flow Diagram）
– 数据流（ p30）
– 源
– 潭
– 加工
– 存储
? 数据字典 (Data Dictionary,or Data about Data)
? 加工小说明
机票预定系统顶层图
旅行社 机票预定系统 旅客
取票单
订
票
单
取票单
机票
机票预定系统 0层图
旅行社 预定机票 1 顾客取票 2
旅客
取票通知单
机票文件
订
票
单
机票
取票单
一个数据流图的例子
帐单
有效订票单
分类并检索 订票
记账
航班目录
记账文件
订
票
单
旅客
旅行社
旅行社
准备机票 取票单
航班
机票文件
有
效
取
票
单
取
票
单
机票
画数据流图的步骤
? 先画系统的输入输出，即先画顶层数据流图 。
? 从 0层开始采用自顶向下，由外向内逐层画数据
流图 。
– 画 0层数据流图时，一般根据当前系统工作分组情况，并
按新系统应有的外部功能，分解顶层数据流图系统为若
干子系统，决定每个子系统间的数据接口和活动关系。
– 画更下层数据流图时，则分解上层图中的加工，一般沿
着输入流的方向，凡数据流的组成或值发生变化的地方
则设置一个加工，一直到输出数据流（反之亦可）。
? 如果加工的内部还有数据流，则继续分解，直到
每个加工足够简单为止（基本加工）。
建立数据流图应该注意的事项
? 数据流、数据存储、加工的命名要含义明确 。
?,画数据流而不是控制流。
? 一般不画物质流。
? 一个加工至少有一个输入数据流和一个输出数据
流，反映出此加工数据的来源与加工的结果。
? 编号。
? 父图与子图的平衡。
? 局部数据存储。
? 提高数据流图的易理解性。一张图中所包含的数
据处理不应多于 7个。
数据流图实例 ——采购管理系统
? P 32
数据字典（ DD——Data about Data
or Data Dictionary）
? 目的：定义数据流和数据字典
? 包括
– 数据流条目：名称，描述，频率和数据量
– 数据存储条目：名称，描述，存储方式，安全
性要求等等
– 数据项条目：名称，描述，数据类型，取值范
围以及缺省数值，精度，计量单位
加工小说明
? 目的
– 描述数据的加工
? 手段
– 结构化自然语言
– 判定表
– 判定树
进行结构化分析的步骤
? 确定系统边界，画出系统环境图
? 自顶向下，画出各层数据流
– 对加工进行分解
? 定义数据字典
? 定义小说明
? 汇总结果
IDEF方法
?IDEF 方法是 1981 年美国空军用于 ICAM 项目
（ Integrated Computer Aided Manufacturing）
中进行复杂系统分析和设计的方法, 是在结构化分
析与设计技术的基础上提出来的 。
?IDEF——Icam DEFinition
?IDEF方法分为三部分：
– IDEF0：用来描述系统的功能活动极其联系, 建立系统的
功能模型 。
– IDEF1：用来描述系统的信息及其联系, 建立系统的信息
模型 。 美国空军项目组对 IDEF1进行了扩充与完善, 于
1985年正式推出了 IDEF1x。
– IDEF2：用来进行系统模拟, 建立系统的动态模型 。
IDEF0方法的图形表示
?活动：用带编号的方框表示系统功能 。
?系统的各种活动的相互关系：用箭头表示 。
?四种箭头类型：输入, 输出, 控制和机制 。
调整工资 3输入 输出
原工资 新工资
调整
政策
控制
机制
人事
部门
IDEF0方法的特点
? 图形符号简单, 能够描述系统的活动, 数据流, 活动
所受到的约束条件及实现机制 。 通过各个侧面清楚地
反映了系统的功能 。 IDEF0图宜作为正式文档 。
? 采用自顶向下, 逐层分解的方式建立系统功能模型 。
? 符合 SA方法的分析策略 。 顶层确定系统范围, 采用抽
象原则, 然后有控制地逐步展开有关活动的细节 。
? IDEF0规定每张图至少有３个, 最多有６个方框, 上
届６保证采用层次性描述复杂问题的可理解性, 下界
３保证分解有意义 。
结构化分析方法小结
? 传统的 SA方法主要 是基于功能分解, 仅是一个静态模
型, 没有反映处理的顺序, 即控制流程 。 因此, 不适
合描述实时控制系统 。
? SA方法使用 DFD在分析与描述, 数据要求, 方面是有
局限的, DFD应与数据库技术中的 ER图结合起来 。
? DFD不适合人机界面系统的需求 。
? 为更精确的描述软件需求, 提高软件系统的可靠性,
安全性, 需用更形式化的描述方法 。
? 借助于需求分析工具, 提高需求分析的质量及效率 。
形式化分析技术
? 非形式化与形式化方法的比较（ p65）
? 应用形式化方法的准则
? 有穷状态机
? Petri 网
? Z语言
? 软件需求分析的意义
? 需求分析的步骤
? 需求规格说明书 SRS
? 需求分析方法学
? 结构化分析方法
需求（ Requirements)
? 定义,需求是关于系统将要完成什么工作
(what)的一段描述语句,它们必须经过所
有相关人员的认可,其目的是彻底解决客
户的问题。
? 需求是指用户或者客户对要开发的软件
系统的要求。需求的内容在, 问题定义,
中描述（可能是招标文件）。
软件需求的类型
? 功能需求
– 系统可以完成的所有事情
– 涉及与本系统有接口的其他系统的所有事情
? 非功能需求
– 是软件开发过程中必须遵守的约束（ Constraint)。
是对可以使用的资源和软件质量的各个方面的限
制，往往会影响软件工程师做决策的自由度。
– 非功能需求应是可验证的（ Verifiable)。
非功能需求
目
标
系
统
的
限
制
性能 实时性、精确度、资源利用率等
可靠性 有效性、完整性
安全 /保密性 安全性、保密性
运行限制 使用频度、运行期限、控制方式、操作要求
物理限制 系统规模等限制
开
发
和
维
护
的
限
制
开发类型 实用性开发、试验性开发
开发工作量的估计
开发方法 质量控制标准、里程碑和评审、验收标准
优先性和可修改性
可维护性
需求分析 (Requirements Analysis)
? 指开发人员为了准确地理解和表达用户要求，进
行细致的调查分析，将用户非形式的需求陈述转
化为完整的需求定义，再由需求定义转换到相应
的形式功能规约（需求规格说明）的过程。
? 准确地回答, 系统必须做什么？,
? Requirements analysis results in the specification of
software’s operational characteristics； indicates
software’s interface with other system elements; and
establishes constraints that software must meet,
需求分析的意义
? 有关软件错误和需求分析的一组事实
– 在软件生命周期中，一个错误发现得越晚，修复
的费用也越高。
– 许多错误是潜伏的，并且在错误产生后很长一段
时间才被检查出来。
– 在需求过程中会产生很多错误和误解，人与人之
间的“通信”障碍无法避免。
– 需求阶段代表性的错误：疏忽、不一致、二义性。
– 需求错误是可以被检查和审查出来的。
需求的相关概念
? 问题域与解空间
– 现实世界中系统处理的业务范围。
– 问题空间，它是人们利用认识现实世界和描述现实
问题的方法所描述的。它与“解空间”的概念相对
应，软件工程应该是问题空间和解空间一致
? 系统责任
– 所开发的系统应该具备的职能。
? 系统边界
– 开发出的系统和与该系统打交道的人或物之间的明
确边界。
领域分析（ Domain Analysis)
Domain
Analysis
Sources of
Domain
Knowledge
Domain
Analysis
Model
Technical literature
Existing applications
Customer surveys
Expert advice
Current/future requirements
Class taxonomies
Reuse standards
Functional models
Domain languages
需求过程中可能的参与者
? 合同监督人员, 提出里程碑 （ Milestones） 和约
束系统开发进度的计划
? 需求者, 客户 (Customer)和使用者 (User)。
? 开发者
– 项目管理者, 必须理解建立和使用目标系统所可
能产生的后果 。
– 系统分析员 ——分析阶段活动的主体 。
– 设计员 ——依据需求提出可接受的解决方案 。
– 测试员 ——确保软件系统满足每一需求 。
系统分析员应具有的素质
? 综合能力
– 总体规划，抽象和分解，本质确认的能力
? 过程
– 保证整个过程的善始善终的能力
? 交流
– 理解和表达能力
? 技术
– 了解问题域和描述解空间的能力
资金
需求
合同义务
软件系统
需求
客户
发起系统开发
用户
使用系统
开发者
建立系统
软件开发的参与者
参考当前系统建立目标系统模型
当前系统
目标系统
物理模型
物理模型
逻辑模型
逻辑模型
模型化
怎么做
具体化 实例化
抽象化
做什么 理解
需求
表达
需求
导
出
需求获取和分析的步骤
? 通过对现实环境的研究，获得系统具体模型。
? 去掉具体模型的非本质因素，抽取出当前系
统的逻辑模型
? 分析当前系统和目标系统的差别，建立目标
系统的逻辑模型。
? 对目标系统进行完善和补充，写出完整的需
求分析。
学生在学校教材科购买教材的系统的例子
一、通过对现实环境的研究，获得系统具体模型。
购书
发票 购书单 书
购书
证明赵秘
书
购书
申请 钱会
计
孙出
纳 李保管
学
生
学
生
学生在学校教材科购买教材的系统的例子
二、去掉具体模型的非本质因素，抽取出当前系统的逻辑模型
发票 领书 单 书有效 单有效
性
购书
单 开票 开领
书单
发书学
生
学
生
学生在学校教材科购买教材的系统的例子
三,分析当前系统和目标系统的差别，建立目标系统的逻辑模型。
发票
领书
单 书审查并开发票
购书
单 开领书单 发书学
生
学
生
学生在学校教材科购买教材的系统的例子
四,对目标系统进行完善和补充，写出完整的需求说明。
五、对需求说明进行复审，直到确认文档齐全并符合用户
的全部需求为止。
发票 领书单审查并
开发票
购书单 开领书单
无效书单
学
生
学
生
需求规格说明书 SRS
需求分析结果 ?SRS，它一般包括：
? 引言：问题定义所确定的目标和范围
? 数据描述：数据流图，数据字典等等
? 功能描述：功能要求文档（可形式化描述）
? 性能描述：性能要求文档
? 质量保证：描述交付前需要进行的各种测
试和验收标准
? 其他：运行要求、将来可能的要求
第四讲
软件需求获取与描述
一、需求分析越来越难
1,问题域的复杂性越来越高 。
2,交流障碍 。 需求分析过程所涉及人员具备
的背景知识不同, 考虑问题的角度不同,
扮演的角色不同, 相互之间的交流存在一
定的困难 。 认识可能混淆, 产生误解 （ 自
然语言的多义性, 一语双关 ） 。
3,完整性问题 。 用户对问题的陈述往往是不
完备的, 需求之间可能存在着矛盾 。 用户
意见不统一 。 涉及许多细节 。
4,需求易变性 。 需求永远不会稳定, 往往存
在错误的需求
二、需求收集与分析技术
? 观察（ Observation)
? 面谈 (Interviewing)
? 头脑风暴 (Brainstorming)
? 原型化 (Paper prototype or Rapid prototype)
? 非正式用例分析 (Informal use case analysis)
三、需求阶段所要获取的主要内容
? 物理环境 (Physical Environment)
? 接口 ( Interfaces)
? 用户或人的因素 (Factors)
? 功能 (Functionality)
? 文档 (Documentation)
? 数据 (Data)
? 资源 (Resources)
? 安全性 (Security)
? 质量保证 (Quality Assurance)
? 设备的主要用途, 在哪里发挥什么作用？
? 所须设置的设备的多少？
? 环境限制等, 如温度, 湿度或磁声干扰？
1,物理环境描述 (Physical Environment)
? 来自一个或多个其他系统的输入？
? 对一个或多个其它系统的输出？
? 数据是否必须预先进行规定的格式化处理？
? 数据是否需要预先存放的介质？
2,接口描述（ Interface Description）
? 谁使用系统？
? 有几种类型的用户？
? 每种类型用户的技术水平怎样？
? 对每型用户需要什么样的培训？
? 用户理解, 使用系统的难易度怎样？
? 用户误用系统的困难程度怎样？
3,用户和人为因素
? 系统将做什么？
? 系统将在何时做？
? 有几种操作方式？
? 系统能在何时、怎样被改变或增强？
? 对执行速度，响应时间或数据流量有何限
制和约束？
4.功能描述 （ Function Description）
5,文档 （ Documents）
? 需要多少文档？
? 是联机文档还是静态文档或者二者皆可？
? 文档所面向的对象 （ 读者 ）？
6,数据 （ Data）
? I/O数据格式应该是什么样的？
? 数据收或发的频度？
? 数据的精确度
? 系统流经的数据流量？
? 数据必须在何时予以保存, 保存多久？
7,资源描述（ Resource Description）
? 建立和维护系统都要什么材料, 人员或其
他资源？
? 开发者必须具有哪些技术？
? 系统占用多少物理空间？
? 对开发规定了时间表了？
? 对用于开发或软硬件上的资金有限制？
? 对系统或信息的存取必须在我们的控制之
下？
? 不同用户的数据之间将如何实现隔离？
? 不同用户程序之间，以及和操作系统间怎
样隔离？
? 系统如何备份？
? 备份副本必须被存于一个不同的位置？
? 应采取措施防火，防水防盗等安全措施？
8,安全描述 (Security)
? 质量属性：可靠性, 有效性, 可维护性等要求？
? 如何向别人示范系统的特征？
? 系统必须有效检测并隔离故障？
? 平均无故障时间规定为多少？
? 对一次失败后重启系统有一个最大时间？
? 系统如何将变化合并到设计？
? 维护将仅仅是纠正错误, 还是包括改进系统？
? 对资源和响应时间使用什么样的有效度量？
? 系统移植性 （ 如不同的硬件环境和操作系统环境
等 )容易程度如何？
9,质量保证 (Quality Assurance)
? 结构化分析方法
? Z 语言,RSL,RSML等（形式化的需求
描述语言）
? 原型需求分析方法
? 面向对象方法（能够更好地消除“语义断
层”）
? UML(Unified Modeling Language)
四、软件需求分析方法学
五,How to Express Requirements
1,Static descriptions
2,Dynamic descriptions
3,Object-oriented specification
4,Formal Methods
1,Static Descriptions
? 数据流图、数据字典、加工说明等
? 判定表（ Decision Tables ），判定树
? E-R模型（ p52)
? 层次方框图,Warnier图,IPO图（ p58)
Warnier Diagrams
Software
products
System
Application
OS(n1)
Compiler(n2)
Software Tool
Editor(n3)
Test driver(n4)
CAD tool(n5)
IPO Diagrams
Oldmaster
files
Otherfiles
Input Process Output
VertifyPrimary
Record
VertifyOrther
Record
Updaterecord
ValidPrimary
Record
ValidOrther
Record
Updatedfiles
A New Form of IPO
IPO
System,Modules,
Date,NO,
Call,Be Called,
Input,Output,
Process,
Local data,Annotation,
Decision Tables
Rule
1
Rule
2
Rule
3
Rule
4
Rule
5
High standardized exam scores T F F F F
High grades — T F F F
Outside activities — — T F F
Good recommendations — — — T F
Send rejection letter X X X
Send admission forms X X
2,Dynamic Descriptions
? Functional Descriptions and Transition
Diagrams
? Event Tables
? Petri Nets （ p72)
Functional Descriptions
? ? kji SCSf ?,
State i State kCondition j
Transition Diagrams
S i S k
Event or Condition X
Transition Diagrams→ Transition Table
S1 S2
S3
0
1
1
1
0
0
Current state Input Next State
S1 0 S2
S1 1 S1
S2 0 S2
S2 1 S1
S3 0 S1
S3 1 S3
Fence Diagram showing State Transitions
(Null)
Requested
On waiting list
Confirmed
Used
Canceled
Archive
(Hotel reservations)
UML notation for state transition
S1 S2
condition
actions
Event Tables
Mode Event1 Event2 Event3 Event4
Graphics Action1 Action8 0 X
Architecture X
Action2
followed by
Action3
Action5,6
in parallel 0
Native 0 Action4 Action1,2,3 Action7
Petri Nets
C,A,Petri (1962,German),
To represent a complexity system in graphical
mode and describe synchronization an parallel
processing
f (State A,Event)→ State S
f (State A,Event 1,Event 2,…,Event N)→ State S
f (State A,Event 1,Event 2,…,Event N)→ State1,
State2,…,State M
Petri Nets(2)
? Tokens（标记、令牌）
? 四种表示符号 —位置、转移、前提、结果（ p66)
? 以下四种 Firing rules
No firing
? Object
? Class
? Method or Operation
? Encapsulation
? Inheritance hierarchy
? Multiple Inheritance
? Polymorphism
3,Object-oriented specification
4,Formal Methods
The Encyclopedia of Software Engineering
defines formal methods in the following manner:
A method is formal if it has a sound mathematical
basis,typically given by a formal specification
language,This basis provides a means of precisely
defining notions like consistency and
completeness,and more relevantly,specification,
implementation and correctness.
六、对需求说明书的要求
? 正确性
? 无二义性（需求确实是用户所需吗？）
? 完整性（完备性，包括用户需要的每一功能或性能）
? 一致性（需求之间不能互相矛盾）
? 可检验性（非计算机人员可以理解）
? 可实现性（有效性，需求是能够现实的吗？硬件系
统的支持力度怎样？）
? 可修改性
? 可跟踪性
? 注释
七、对需求规约的验证
验证的方法
? 复审和进一步需求分析
? 实现原型系统
? 支持需求分析工具
验证的主要内容
? 一致性验证
? 现实性验证（需求是现实的吗？）
? 完整性（完备性）和有效性验证
? 必须有形式化的语法，便于计算机的自动
解释和实现。
? 得益于这些工具的支持，自动导出文档。
? 提供分析 SRS不一致性和冗余性的手段，
给出 SRS完整性分析报告。
? 能够改进用户、开发人员、客户之间，以
及可阶段之间的通信状况。
八、需求分析工具的基本要求
九、需求分析工具实例一 PSL/PSA
（ Problem Statement Language/Analysis ）
1977年由美国密执安大学开发。
PSL是用来描述系统的形式语言，其描述结果由
PSA进行分析和处理以产生各种报告。
PSL/PSA的主要功能：
? 描述任何应用领域的信息系统
? 创建一个数据库保存对信息系统的描述符；
? 对描述符数据库进行管理
? 生成格式化的需求文档和关于 SRS的各种分析报告
十、需求分析工具实例二 RSML
（ Requirement Specification Modeling language）
? 1996年由加利福利亚大学开发的一种对层次性的基于
状态的需求进行完整性和一致性检查的方法 。
? RSML将目标系统看成是一台有限状态机, 对事件的
状态, 转换以及事件序列进行建模 。
? RSML可以图形化地定义一个叫做, next-state”的数学
函数, 以定义所有可能的系统状态 (d-completeness特性 ）,
也能说明系统是一致性 。
? RSML被用于分析美国空间冲突规避系统 （ TCASⅡ ）,
揭示了一个意外的含有严重的安全隐患的不确定性问题,
而这在原需求规格中是不明显的 。
第五讲
结构化需求分析方法与形
式化说明技术
面向数据流的分析方法
? 提出,Yourdon E.和 Constantine L.等人
? 类型,结构化分析 （ Structured Analysis） 方法。
? 数据流图（ Data flow Diagram）
– 数据流（ p30）
– 源
– 潭
– 加工
– 存储
? 数据字典 (Data Dictionary,or Data about Data)
? 加工小说明
机票预定系统顶层图
旅行社 机票预定系统 旅客
取票单
订
票
单
取票单
机票
机票预定系统 0层图
旅行社 预定机票 1 顾客取票 2
旅客
取票通知单
机票文件
订
票
单
机票
取票单
一个数据流图的例子
帐单
有效订票单
分类并检索 订票
记账
航班目录
记账文件
订
票
单
旅客
旅行社
旅行社
准备机票 取票单
航班
机票文件
有
效
取
票
单
取
票
单
机票
画数据流图的步骤
? 先画系统的输入输出，即先画顶层数据流图 。
? 从 0层开始采用自顶向下，由外向内逐层画数据
流图 。
– 画 0层数据流图时，一般根据当前系统工作分组情况，并
按新系统应有的外部功能，分解顶层数据流图系统为若
干子系统，决定每个子系统间的数据接口和活动关系。
– 画更下层数据流图时，则分解上层图中的加工，一般沿
着输入流的方向，凡数据流的组成或值发生变化的地方
则设置一个加工，一直到输出数据流（反之亦可）。
? 如果加工的内部还有数据流，则继续分解，直到
每个加工足够简单为止（基本加工）。
建立数据流图应该注意的事项
? 数据流、数据存储、加工的命名要含义明确 。
?,画数据流而不是控制流。
? 一般不画物质流。
? 一个加工至少有一个输入数据流和一个输出数据
流，反映出此加工数据的来源与加工的结果。
? 编号。
? 父图与子图的平衡。
? 局部数据存储。
? 提高数据流图的易理解性。一张图中所包含的数
据处理不应多于 7个。
数据流图实例 ——采购管理系统
? P 32
数据字典（ DD——Data about Data
or Data Dictionary）
? 目的：定义数据流和数据字典
? 包括
– 数据流条目：名称，描述，频率和数据量
– 数据存储条目：名称，描述，存储方式，安全
性要求等等
– 数据项条目：名称，描述，数据类型，取值范
围以及缺省数值，精度，计量单位
加工小说明
? 目的
– 描述数据的加工
? 手段
– 结构化自然语言
– 判定表
– 判定树
进行结构化分析的步骤
? 确定系统边界，画出系统环境图
? 自顶向下，画出各层数据流
– 对加工进行分解
? 定义数据字典
? 定义小说明
? 汇总结果
IDEF方法
?IDEF 方法是 1981 年美国空军用于 ICAM 项目
（ Integrated Computer Aided Manufacturing）
中进行复杂系统分析和设计的方法, 是在结构化分
析与设计技术的基础上提出来的 。
?IDEF——Icam DEFinition
?IDEF方法分为三部分：
– IDEF0：用来描述系统的功能活动极其联系, 建立系统的
功能模型 。
– IDEF1：用来描述系统的信息及其联系, 建立系统的信息
模型 。 美国空军项目组对 IDEF1进行了扩充与完善, 于
1985年正式推出了 IDEF1x。
– IDEF2：用来进行系统模拟, 建立系统的动态模型 。
IDEF0方法的图形表示
?活动：用带编号的方框表示系统功能 。
?系统的各种活动的相互关系：用箭头表示 。
?四种箭头类型：输入, 输出, 控制和机制 。
调整工资 3输入 输出
原工资 新工资
调整
政策
控制
机制
人事
部门
IDEF0方法的特点
? 图形符号简单, 能够描述系统的活动, 数据流, 活动
所受到的约束条件及实现机制 。 通过各个侧面清楚地
反映了系统的功能 。 IDEF0图宜作为正式文档 。
? 采用自顶向下, 逐层分解的方式建立系统功能模型 。
? 符合 SA方法的分析策略 。 顶层确定系统范围, 采用抽
象原则, 然后有控制地逐步展开有关活动的细节 。
? IDEF0规定每张图至少有３个, 最多有６个方框, 上
届６保证采用层次性描述复杂问题的可理解性, 下界
３保证分解有意义 。
结构化分析方法小结
? 传统的 SA方法主要 是基于功能分解, 仅是一个静态模
型, 没有反映处理的顺序, 即控制流程 。 因此, 不适
合描述实时控制系统 。
? SA方法使用 DFD在分析与描述, 数据要求, 方面是有
局限的, DFD应与数据库技术中的 ER图结合起来 。
? DFD不适合人机界面系统的需求 。
? 为更精确的描述软件需求, 提高软件系统的可靠性,
安全性, 需用更形式化的描述方法 。
? 借助于需求分析工具, 提高需求分析的质量及效率 。
形式化分析技术
? 非形式化与形式化方法的比较（ p65）
? 应用形式化方法的准则
? 有穷状态机
? Petri 网
? Z语言
