2012-5-10 14
下列系统规范说明一致吗
“当且仅当系统正常操作时（p），系统处 于多用户状态(q)。如果系统正常操作，则 它的核心程序正在运行(r)。核心程序不能 正常运行，或者系统处于中断模式(s)。如 果系统不处于多用户状态，它就处于中断 模式。系统不处在中断模式。”
2012-5-10
15
2012-5-10
11
情景分析技术的用处主要体现在下述两个方面： 情景分析技术的用处主要体现在下述两个方面：
(1) 它能在某种程度上演示目标系统的行为，从而便于用户 理解，而且还可能进一步揭示出一些分析员目前还不知道 的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术能保证 用户在需求分析过程中始终扮演一个积极主动的角色。需 求分析的目标是获知用户的真实需求，而这一信息的惟一 来源是用户，因此，让用户起积极主动的作用对需求分析 工作获得成功是至关重要的。
2012-5-10 前一页
21
细化数据流图
面向数据流自顶向下求精过程
分 析 过 程
分析员向 用户解释
需要 分解
2012-5-10 前一页
22
修正开发计划 分 析 过 程
经过需求分析阶段的工 作，在对目标系统有了更深 入的认识之后，可以对原来 的开发计划作进一步的修正。
2012-5-10 前一页
23
2012-5-10
17
分析过程
主 要 内 容 沿数据流图回溯 用户复查 细化数据流图 修正开发计划 书写文档
2012-5-10
前一页
18
沿数据流图回溯 分 析 过 程
步骤： 从输出端沿着数据流图向输入端回 溯，由此确定出每个数据的来源 把分析过程得到的有关数据元素的 信息记录在数据字典中，把算法记 录在IPO图中
为了快速地构建和修改原型，通常使用下述3种方 法和工具：
(1) 第四代Βιβλιοθήκη 术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他 非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可 执行的代码，它们是较理想的快速原型工具。
(2) 可重用的软件构件
另外一种快速构建原型的方法，是使用一组已有的软件构件(也称为 组件)来装配(而不是从头构造)原型。 软件构件：数据结构(或数据库)，或软件体系结构构件(即程序)，或 过程构件(即模块)。
2012-5-10
12
合理使用逻辑表达式可以避免二义
用p=“扫描消息中的病毒”；q=“消息来自一个未 知的系统”以及逻辑词来表示下面的系统规范说 明。 1.每当消息来自一个未知的系统时，就扫描消息中 的病毒。 2.“消息来自一个未知的系统，但不扫描消息中的病 毒。” 3.“每当消息来自一个未知的系统时，就有必要扫描 消息中的病毒。” 4.“当消息不是来自一个未知的系统时，就不扫描消 息中的病毒。”
前一页
26
简易的应用规格说明技术
步骤： 步骤： 初步访谈，确定问题的范围和解决方案 由开发者和用户分别写出“产品需求”，并在由双方 代表组成的会议上讨论 会议上确定与会人员意见一致的问题和列表 将与会者分成小组，每个小组就列表中的问题展开讨 论，然后形成小型规格说明 小组讨论结束后，每组向全体人员展示小型规格说明 每个与会者都制定出产品的一整套确认标准 专门人员根据会议成果起草完整的软件需求文档
2012-5-10 8
分析系统的数据要求
分析系统的数据要求，这是软件需求分析的一个重要任务。 分析系统的数据要求通常采用建立数据模型的方法(见3.4 节)。 数据字典的缺点是不够形象直观。为了提高可理解性，常 常利用图形工具辅助描绘数据结构。常用的图形工具有层 次方框图和Warnier图，在本章第3.7节中将简要地介绍这两 种图形工具。 软件系统经常使用各种长期保存的信息，这些信息通常以 一定方式组织并存储在数据库或文件中，为减少数据冗余， 避免出现插入异常或删除异常，简化修改数据的过程，通 常需要把数据结构规范化(见3.5节)。
2012-5-10
前一页
7
3.1需求分析的任务 3.1需求分析的任务
需求分析是软件定义的最后一个阶段， 需求分析是软件定义的最后一个阶段，它的基本任务是准确地回答 系统必须做什么？ 这个问题。对目标系统提出完整、准确、清晰、 “系统必须做什么？”这个问题。对目标系统提出完整、准确、清晰、 具体的要求。 具体的要求。
确定对系统的综合要求
系统功能要求 ——指定系统必须提供的服务 系统性能要求（系统必须满足的定时约束或容量约束—响应时间， 所需存储容量及后援存储，安全性和简便性）。 可靠性和可用性需求 出错处理需求——说明系统对环境错误应该怎样响应 接口需求——描述应用系统与他的环境通信的格式（用户接口需求， 硬件接口需求，软件接口需求，通信接口需求） 约束——设计约束或实现约束描述在设计或实现应用系统时应遵守 的限制条件 逆向需求——说明软件系统不应该做什么 将来可能提出的要求
10
3.2 与用户沟通获取需求的方法
3.2.1 访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为 止仍然广泛使用的需求分析技术。 访谈有两种基本形式：正式的和非正式的。 当需要调查大量人员的意见时，向被调查人分发调查表是 一个十分有效的做法。 在访问用户的过程中使用情景分析技术往往非常有效。所 谓情景分析就是对用户将来使用目标系统解决某个具体问 题的方法和结果进行分析。
2012-5-10 27
简易的应用规格说明技术
面向团队的需求收集法优点： 强调了用户的参与，开发者和用户密切合 作 讨论即时并求精 有能导出规格说明的具体步骤
2012-5-10
28
3.2.4 快速建立软件原型
快速建立软件原型是最准确、最有效、最强大的需求分析 技术。 快速原型就是快速建立起来的旨在演示目标系统主要功能 的可运行的程序。 构建原型的要点是，它应该实现用户看得见的功能(例如， 屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如， 修改文件)。
2012-5-10 13
例2
使用命题p“用户输入有效的口令”；q“访 问被授权”；r ”用户已经付费”以及逻辑 词表达下列系统规范说明。 1.“用户已经付费，但没有输入有效的口令。” 2.“每当用户已经付费并输入有效的口令，访 问被授权。” 3.“如果用户没有付费，访问被拒绝。” 4.“如果用户没有输入有效的口令但已经付费， 访问被授权。”
例3 下列系统规范说明一致吗
“路由器能向系统发送分组仅当它支持新的 地址空间时。要让路由器支持新的地址空间， 就必须安装最新的软件发布。如果最新的软 件发布被安装了，路由器就能向系统发送分 组。路由器不支持新的地址空间。”
2012-5-10
16
3.2.2 面向数据流自顶向下求精
任何信息处理系统的基本功能都是把输入数据转变成需要 的输出信息。数据决定了需要的处理和算法，看来数据显 然是需求分析的出发点。 结构化分析方法就是面向数据流自顶向下逐步求精进行需 求分析的方法。 可行性研究已经得出了目标系统的高层数据流图， 需求分析的目标之一就是把数据流和数据存储定义到元 素级。 为了达到这个目标，通常从数据流图的输出端着手分析。
快速原型应该具备的第一个特性是“快速” 快速原型应该具备的第一个特性是“快速”。 快速原型应该具备的第二个特性是“容易修改” 快速原型应该具备的第二个特性是“容易修改”。原型的 “修改—试用—反馈”过程可能重复多遍，如果修改耗时 修改—试用—反馈” 过多，势必延误软件开发时间
2012-5-10 29
需求分析
需求分析的任务就是借助于当前系统的逻辑模型导 出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
怎么做
模型化 当前系统 物理模型 抽象化 逻辑模型
做什么
理 导解 需 出求 表 达 需 求
6
具体化 目标系统
2012-5-10
实例化 物理模型 逻辑模型
需求分析的任务
主 要 内 容
确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划 开发原型系统
书写文档
1)系统规格说明：主要描述目标系统的概 1)系统规格说明
分 析 过 程
貌、功能要求、性能要求、运行要求和 将来可能提出的要求。用数据流图、IPO 等描述的算法也是其中主要的组成部分。 此外，还应包括用户需求与系统功能之 间的参照关系，设计约束等 。
2)数据要求：主要包括数据字典、层次方框 2)数据要求
2012-5-10 前一页 20
细化数据流图
为了追踪更详细的数据流图，分析员 应该把数据流图扩展到更低的层次。
分 析 过 程
通过对功能的分解 来完成对数据流图 的细化。在数据流图中选取功能比较复杂 的处理，将其功能分解为若干子功能，使 其成为数据流图新的处理。 对数据流图细化之后，数据元素之间 的关系更加清楚，处理加工算法更加具体。 分析员将越来越深入具体地定义目标系统 。
软件工程
（Software Engineering）
第三章 需求分析
2012-5-10
1
第三章需求分析
学习要求： 1、了解需求分析的任务； 2、掌握并熟练使用与用户沟通获取需求的方法； 3、会分析建模和编写需求规格说明书； 4、会使用E-R图、状态转换图、IPO/HIPO图做分析， 、会使用E 图、状态转换图、IPO/HIPO图做分析， 会对数据库信息进行规范化； 5、了解软件需求验证的内容；
2012-5-10
19
用户复查 分 析 过 程
对于数据字典、数据流图、IPO图 中的有关内容是否完整正确地描述了 目标系统，只有用户是最清楚的。与 用户共同对描述的目标系统进行复查 是极为重要的一个环节。 “复查、补充、修改、再复查…”， 是一个不断循环的过程，系统在这个 过程中不断完善，分析员的认识在这 个过程中不断加深。
(3) 形式化规格说明和原型环境