• 面向对象的分析方法 (OOA)
–识别问题域内对象，及其之间的联系，并建立 模型
(3) 编制需求分析阶段的文档
软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施
计划
(4) 需求分析评审
系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否
–将系统看作若干功能模块的集合，进行子功 能分解，最终形成系统雏形。
• 结构化分析法
–面向数据流的结构化分析方法 (SA) –面向数据结构的Jackson方法 (JSD) –面向数据结构的结构化数据系统开发方法
(DSSD)
常用的分析方法
• 信息建模法
–借助各种有序模型（功能、信息、数据、控制、 决策等），来分析系统。常用工具：E－R图
起始
• 通常是在确定了商业要求或者发现新市场、 新服务时，项目才开始，
• 相关人员会进行粗略的可行性分析、并确 定项目范围后开始。
导出需求
• 看似简单：
– 询问客户，系统或者产品的主要目标是什么？ – 想要实现什么？ – 产品如何满足业务要求，如何用于日常工作？
• 实则困难
为何导出需求十分困难？
– 例如，数据流“乘客名单”，由姓名、身份证、 座位等级组成
乘客名单＝{姓名＋身份证＋座位等级}
（2）数据项 • 数据项也称数据元素，它“不可再分”，是数
据的最小单位。 • 主要给出每个数据单项的值类型、允许值，包
括：
1. 名称和编号。 2. 别名－数据项另外的名称。 3. 取值的范围和含义。 4. 长度－数据项包含的字符或数字的位数。
需求分析
福州大学 软件学院 张舒
本章主要内容
• 软件需求分析的任务和过程 • 结构化分析方法 • 原型化方法 • 动态分析方法 • 数据及数据库需求
需求（Requirements)
• 定义:需求是关于系统将要完成什么工作 (what)的一段描述语句,是指用户或者客户 对要开发的软件系统的要求。
–它们必须经过所有相关人员的认可,其目的是 彻底解决客户的问题。
逻辑视图给出的是系统要达到的功能 和要处理的信息间的关系，而不是实 现细节。
物理视图给出的是系统处理功能和数 据结构的实际表示形式，这通常由设 备本身所决定。
小结：需求分析方法
• 实践中，可以采取三阶段分析法： 1. 第一阶段：“访谈式”（Visitation）
– 这一阶段是和具体用户方的领导层、业务层 人员的访谈式沟通，
齐全; 文档中的所有描述是否完整、清晰、准
确反映用户要求; 与所有其它系统成分的重要接口是否都
已经描述;
被开发项目的数据流与数据结构是否足 够确定;
所有图表是否清楚，在不补充说明时能 否理解;
主要功能是否已包括在规定的软件范围 之内，是否都已充分说明;
设计的约束条件或限制条件是否符合实 际;
–数据流就是数据经过系统时的变化形式， 输入数据先转换成中间数据，再由中间 数据转换成输出结果数据。
–数据内容就是数据项。 –数据结构就是各数据项的逻辑组织。
• 把问题以自顶向下、逐层分解的方式分解 为几个较易理解的部分，并确定各部分之 间的接口，从而实现软件的整体功能。
– 在需求分析阶段，软件的功能域和信息域都可 以做进一步的分解。
• 初画时可以忽略琐碎的细节，以集中 精力于主要数据流
如何分解加工？
• 一个加工每次分解最多不要超过7个 • 分解要自然，概念上要合理、清晰 • 在不影响数据流图易理解性情况下，可以
适当多分几个部分 • 上层可以分解得快些，中、下层要分解得
慢些
数据流图的优点
• 自顶向下描述系统中信息的流动，结构清 晰，概念性强，有利于系统分析员理顺系 统脉络、澄清含混的概念和逻辑。
分析建模的方法
• 20世纪70年代，人们从早期的、非结构化 的方法入手，首次尝试使用标准化的方法， 开发并相继推出了各种“结构化分析”方 法，还相继衍生出若干派生方法。
• 20世纪90年代初，面向对象分析方法才悄 然成形，并且同样随之出现了一批大同小 异的派生方法。
ቤተ መጻሕፍቲ ባይዱ 结构化分析
基本思想：
用抽象模型的概念，按照软件内部数 据传递、变换的关系，自顶向下逐层 分解，直到找到满足功能要求的所有 可实现的软件为止。
结构化分析方法是一种依赖数据流图 的自顶向下的建模方法，
它的核心是数据流图，所以又说它是一 种面向数据流的分析方法。
结构化分析方法适合于数据处理类型 软件的需求分析。
• 结构化分析方法使用工具：
– 数据流图 – 数据词典 – 结构化英语 – 判定表与判定树
数据流图
• 数据流图中的主要图形元素
• 数据流图的表达方式是结构化的，易于与 常用的计算机处理相对应，容易转换为低 级别的设计
数据流图的缺点
• 可能变得非常复杂，不易理解。 • 不能处理出错和意外情况。 • 不能描述过程的控制结构（没有条件分支、
循环、选择）。
数据词典
• 数据字典是为了描述在结构化分析过程中 定义的对象的内容，而使用的一种半形式 化的工具。
商店业务处理系统
数据流图绘制步骤
1. 首先确定系统的输入和输出 2. 根据商店业务，画出顶层数据流图，
以反映最主要业务处理流程
这个数据流图只是一个高层的系统逻辑模 型，它反映了目标系统要实现的功能
3. 分析系统的主要功能：
商店业务处理的主要功能应当有销 售、采购、会计三大项。
主要数据流输入的源点和输出终点 是顾客和供应商。
(2) 分析与综合
基本思想：
从信息流和信息结构出发，逐步细化所有的 软件功能，
找出系统各元素之间的联系、接口特性和设 计上的约束，分析它们是否满足功能要求， 是否合理。
剔除其不合理的部分，增加其需要部分，最 终综合成系统的解决方案，给出目标系统的 详细逻辑模型。
常用的分析方法
• 功能分析法
– 确定系统功能、性能、运行等 方面要求
– 对将来可能提出的要求做准备
• 分析系统的数据要求
– 考虑数据、数据处理
• 导出系统逻辑模型
– 通常用数据流图表示
• 修正系统开发计划
– 对系统成本、进度有更精确的估算
• 总之，需求分析的任务就是借助于当 前系统的逻辑模型导出目标系统的逻 辑模型，解决目标系统的 “做什么” 的问题。
• 数据字典是描述数据信息的集合，它对数 据流图中的各个元素进行完整的定义与说 明，是数据流图的补充工具。
数据字典的内容
（1） 数据流 在数据流图中，数据以数据流为单位进行传输。 主要描述该数据流的各组成部分，包括：
1. 名字及称号。 2. 可能的来源和去处：外部实体，处理逻辑，数据存
储。 3. 组成：一个数据流可能包含若干个数据结构。
4. 然后从输入端开始，根据商店业 务工作流程，画出数据流流经的 各加工框，逐步画到输出端，得 到第一层数据流图
第一层数据流图
加细每一个加工框 销售细化
采购细化
绘制数据流图的原则
• 数据流图上所有图形符号只限于前 述四种基本图形元素
• 数据流图的主图必须包括前述四种 基本元素，缺一不可
• 数据流图的主图上的数据流必须封 闭在外部实体之间
需求分析的重要性
“构建一个软件系统最困难的部分是确 定构建什么。其他部分工作不会像这部分 工作一样，在出错之后会如此严重的影响 随后实现的系统，并且在以后修补竟会如 此的困难。”
－－Fred Brooks
• 问题：
对于任何项目是否一定要严格执行全面的 需求分析呢？
需求分析的过程
(1) 问题识别
数据加工 (数据变换) 数据源点或终点 (外部实体) 数据流 数据存储文件
描述银行取款过程的数据流图
数据流与数据加工之间的关系
数据流图的层次结构
• 为了表达数据处理过程的数据加工 情况，需要采用层次结构的数据流 图。
• 按照系统的层次结构进行逐步分解， 并以分层的数据流图反映这种结构 关系，能清楚地表达和容易理解整 个系统
• 确认
– 检查规格说明，排除不一致性、疏漏和错误
• 管理
– 帮助项目组在进展中标识、控制和跟踪需求及 其变更
软件需求分析的原则
1. 需要能够表达和理解问题的信 息域和功能域
2. 要能以层次化的方式对问题进 行分解和不断细化
3. 要给出系统的逻辑视图和物理 视图
信息域包括数据流、数据内容和数据结 构。
–需求的内容在“问题定义”中描述（可能是招 标文件）。
需求分析
• 指开发人员为了准确地理解和表达用 户要求，进行细致的调查分析，将用 户非形式的需求陈述转化为完整的需 求定义，再由需求定义转换到相应的 形式功能规约（需求规格说明）的过 程。
• 准确地回答“系统必须做什么？”
软件需求分析的目标
• 确定系统的综合要求
– 用户可以操作简单演示的DEMO，来感受一 下整个业务流程的设计合理性、准确性等等 问题，及时地提出改进意见和方法。
3. 第三阶段：“确认式”（Afirm）
– 这一阶段是在上述两个阶段成果的基础上， 进行具体的流程细化、数据项的确认阶段，
– 这个阶段承建方必须提供原型系统和明确的 业务流程报告、数据项表，并能清晰地向用 户描述系统的业务流设计目标。
• 范围问题
– 系统边界不清楚，客户或者用户的说明带有多 余的技术细节，可能混淆系统整体目标
• 理解问题
– 用户不能完全确定需要什么，在与工程师沟通 过程中有问题。需求之间还可能存在冲突。
• 易变问题
– 需求随时间变化
可采取的解决办法
• 发掘需求
– 克服企业背景对需求工程的影响 – 克服方法不当对需求工程的影响。 – 克服受访谈者对需求工程的影响。 – 克服就项目论项目对需求工程的影响。