摘要：提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。
仅仅是确定系统必须完成哪些工作 产生初步的用户手册。
① 确定对系统的综合要求
功能需求性能需求可靠性和可用性需求出错处理需求接口需求约束逆向需求将来可能提出的需求② 分析系统的数据要求
通常采用建立数据模型的方法
Warnier图③ 导出系统的逻辑模型
数据流图实体-联系图状态转换图数据字典主要的处理算法描述④ 修正系统开发计划
① 访谈
（情景分析技术）
② 面向数据流自顶向下求精
结构化分析方法
把分析过程中得到的有关数据元素的信息记录在数据字典中把对算法的简明描述记录在IPO图中IPO图（输入、处理、输出图的简称；能够方便地描绘输入数据、对数据的处理和输出数据之间的关系）：
③ 简易的应用规格说明技术
（面向团队的需求收集法）
提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。
④ 快速建立软件原型
（特性：“快速”、“容易修改”）
旨在演示目标系统主要功能的可运行程序。
要点：实现用户看得见的功能，省略目标系统的“隐含”功能。
（1）数据模型
实体-联系图（ER图）（概念性的数据模型（也称为信息模型）；面向问题的数据模型）：
ER图的一个例子
ER图描绘数据对象及数据对象之间的关系。
包含：数据对象、数据对象的属性数据、对象彼此间相互连接的关系（联系）。
（联系也可能有属性）
（2）功能模型
数据流图（绘制方法：自顶向下，分层绘制、逐步求精）：
数据流图描绘当数据在软件系统中移动时被变换的逻辑模型。
（3）行为模型
状态转换图（状态图）：
状态转换图指明了作为外部事件结果的系统行为。
中间状态的格式
状态转换图既可以表示系统循环运行过程，也可以表示系统单程生命期。
软件需求规格说明书
（把形式化方法和欠形式化方法有机结合起来）
（1）非形式化
自然语言描述需求规格说明缺点：可能存在矛盾、二义性、含糊性、不完整性及抽象层次混乱等问题（2）半形式化
用数据流图或实体-联系图建立模型（3）形式化
（如果一种方法有坚实的数学基础，那么它就是形式化的）
是描述系统性质的基于数学的技术。
① 优点：
能够简洁准确地描述物理现象、对象或动作的结果（数学比自然语言更适于描述详细的需求）可以在不同的软件工程活动之间平滑地过渡提供了高层确认的手段消除了二义性
② 缺点：
大多数形式化的规格说明主要关注于系统的功能和数据，而问题的时序、控制和行为等方面的需求却更难于表示比欠形式化方法更难学习③ 应用准则
应该选用适当的表示方法应该形式化，但不要过分形式化应该估算成本应该有形式化方法顾问随时提供咨询不应该放弃传统的开发方法应该建立详尽的文档（建议用自然语言注释形式化的规格说明书）不应该放弃质量标准不应该盲目依赖形式化方法
（必须使用其他方法（例如评审、测试）来验证软件正确性）应该测试、测试再测试应该重用
（即使采用了形式化方法，软件重用仍然是降低软件成本和提高软件质量唯一合理的方法）
④ 有穷状态机
（表达规格说明的一种形式化方法）
优点：
这种形式的规格说明易于书写，易于验证，而且可以比较容易地把它转变成设计或程序代码比数据流图技术更精确，而且和它一样易于理解缺点：
在开发一个大系统时三元组（即状态、事件、谓词）的数量会迅速增长没有处理定时需求⑤ Petri网
（用于确定系统中隐含的定时问题的一种有效技术）
（当每个输入线上至少有一个权标，而禁止线上没有权标的时候，相应的转换才是允许的)
⑥ Z语言
组成：
给定的集合、数据类型及常数（给定的初始化集合称为Button，即所有按钮的集合 [Button]）状态定义初始状态操作
Z语言是应用得最广泛的形式化语言。
成功原因：
可以比较容易地发现用Z写的规格说明的错误用Z写规格说明时，要求作者十分精确地使用Z说明符Z是一种形式化语言，在需要时开发者可以严格地验证规格说明的正确性虽然完全学会Z语言相当困难，但经验表明，只学过中学数学的软件开发人员仍然可以只用比较短的时间就学会编写Z规格说明使用Z语言可以降低软件开发费用虽然用户无法理解用Z写的规格说明，但是，可以根据Z规格说明用自然语言重写规格说明数据规范化验证方面及方法
① 一致性
人工技术审查若软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具②完整性
使用原型系统③ 现实性
参照以往开发类似系统的经验仿真或性能模拟技术④ 有效性
使用原型系统用于需求分析的软件工具
【软件工程导论】需求分析
来源：司梵凰
