情况下的选课持续时间、是否按院系逐步开放选科、 选课人数的一般分布等—与性能设计密切相关 推荐关键管理人员使用USB Key设备，经济上是否可 以接受 ……
原型：如该企业有类似成熟系统可结合系 统演示进行需求调研
3.2.4 观察并记录商业过程(I)
观察 使用活动图来进行记录
学生购买教材的实际处理流程—当前系统物理模型 购 书 购 领 发 申 书 书 学 请 教务科 单 会计室 票 出纳员 单 教材科 书 学 108 107 206 206 生 生 赵 张 王 李 购 书 购 领 发 申 书 书 书 票 单 学 请 审查 单 学 开领 开发票 发书 生 有效性 书单 生
3.2.1 主要问题
主题 对用户来说的问题 商业过程和操作是什 你要干什么 么 商业过程应该怎样完 如何完成它？需要哪些步骤？ 成 需求什么样的信息 你要使用哪些信息？你要使 用什么样的表单或报告？
表 信息收集中的主要问题
3.2.2 复查报表、表格和过程描述
商业文档和过程描述是了解过程的一个好 方法。
第二阶段：制订访谈计划，深入讨论 相关需求
除了学生还有哪些相关用户?
选课规则(学分、课程人数限制等)、退课规则
了解客户对系统的期望：准确、访问速度快… ……
需求调研例—学生选课系统-2
第三阶段：基本了解需求后就一些关键细 节通过问卷进行明确
在已经了解总体选课人数之后，需要进一步了解通常
表格和报表可以为面谈提供可视化的帮助、 也可以提供工作文档。 复查现有过程文档将有助于识别面谈中不 会提及的商业规则。 有助于发现商业过程中的不一致和冗余。
3.2.3 面谈
面谈之前 确立面谈目的 确定要包括的相关用 户 确定参加会议的项目 小组成员 建立要讨论的问题和 要点列表 复查有关文档和资料 确立时间和地点 通知所有参加者有关 会议的目的、时间和地 点 进行面谈 衣着得体 准时到达 寻找异常和 错误情况 深入调查细 节 详细记录 找出和记录 未回答的条目 和未解决的问 题
数据模型中包含3种相互关联的信息：实体、 属性、联系
3.3.1 实体模型的概念(I)
• 实体：指客观世界存在的且可以相互区分的事务。 实体可以是人，也可以是物，还可以是抽象概念。 如职工、计算机、产品等都是实体。
• 属性：是指实体某一方面的特征。一个实体通常 由多个属性值组成，如学生实体具有学号、姓名、 专业、年级等属性。 • 联系：指实体之间的相互关系。 • 注意，联系也可以有属性。比如成绩既不是 学生的属性，也不是课程的属性，而是学生“学” 课程的属性，这个属性就是联系“学”的属性。
3.2.4 观察并记录商业过程(II)
3.2.5 建立原型
3.2.6 分发和收集调查表
举例：某出版社系统需求调查表
编号
1 2 3 4 5
提出问题 您在哪个部门工作？ 出版业务流程是什么？ 您每日都处理那些文件、数据、报表？ 工作中手工处理特别麻烦的事情是什么？ 工作中手工处理什么问题解决不了？影响效率的问题有哪 些？
闲置
摘机 拨号音 do：响拨号音 数字 数字 超时 超时 提示信息 do：播放信息 超时 do：响蜂鸣音
挂 机
挂 机
忙音 do：响忙音
无效号码 拨号 有效号码
占线
接通中 do：试接通
已接通 振铃 do：振铃 受话人摘机应答 通话 受话人挂机 断线
信 息 播 完
练习：办公室复印机的工作过程大致 如下：
3.1.2 逻辑模型
数据模型（ERD） 功能模型（DFD） 行为模型（状态转换图）
3.1.3 修正系统开发计划
根据在分析过程中获得的对系统的更深入 更具体的了解，可以比较准确地估计系统 的成本和进度，修正以前制定的开发计划。
3.2 信息收集技术
3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 主要问题 复查现有报表、表格和过程描述 访谈 观察并记录商业过程 建立原型 分发收集调查表 主持联合应用程序设计会议 面向数据流分析 简易规格说明书
项目名称 项目编号 开工日期 供应商编号
供应商名称 地址
工程项目 M 供应量 供应 N 零件 N
供应商 M 订购 订购量
零件编号
零件名称
3.4 功能模型(I)
基本加工逻辑说明 对数据流图的每一个基本加工，必须有 一个基本加工逻辑说明 基本加工逻辑说明必须描述基本加工如 何把输入数据流变换为输出数据流的加 工规则 加工逻辑说明必须描述实现加工的策略 而不是实现加工的细节 加工逻辑说明中包含的信息应是充足的， 完备的，有用的，无冗余的
通过描绘系统的状态及引起系统状态转换的事件来表示 系统的行为。
状态 do：动作
系统行为模式 do：在该状态下的动作 引起系统状态转换的控制信息
事件
STD中使用的主要符号
初始事件
状态1 do：行为1
事件1[条件1]
状态2 do：行为2
事件2[条件2]
结束事件
……
【例】电话系统的状态转换图
实发 工资
4.3.1.1 实体关系图
应发 工资 扣款 基本 工资 奖 金 水电 扣款 缺勤 扣款 个人 所得 税扣 款
3.3.1 实体模型的概念(II)
联系可分为以下3种类型：
(1) 一对一联系(1∶1)
(2) 一对多联系(1∶N) (3) 多对多联系(M∶N)
3.3.3 ERD实例(I)
3.3.3 ERD实例(II)
习题. 请为某仓库的管理设计一个ER模型。 该仓库主要管理零件的订购和供应等事项。 仓库向工程项目供应零件，并且根据需要 向供应商订购零件。
3.4 功能模型(II)
基本加工逻辑说明工具
结构化英语 判定表 判定树

3.5 状态转换图(I)
状态转换图(简称为状态图)通过描绘系统的 状态及引起系统状态转换的事件，来表示 系统的行为。 3.5.1 状态 3.5.2 事件 3.5.3 符号
（3）状态转换图（State Transition Diagram）
3.7 其他图形工具
3.7.1 层次方框图 3.7.2 Warnier图 3.7.3 IPO图
3.7.1 层次方框图(I)
层次方框图用树形结构的一系列多层次的 矩形框描绘数据的层次结构。
例如，描绘一家计算机公司全部产品的数 据结构可以用图3.5中的层次方框图表示。
3.7.1 层次方框图(II)
突出优点：开发者与用户不分彼此，齐心协力， 密切合作；即时讨论并求精；有能导出规格说明 的具体步骤。
分组讨论
为《社交故事管理系统》设计信息 收集方案 时间：20分钟
3.3 ERD(I)
分析建模方法：
数据模型：ERD(实体联系图) 功能模型：DFD(数据流图)
行为模型：STD(状态转换图)
3.1.1 需求内容 3.1.2 逻辑模型 3.1.3 修正系统开发计划
需求包括的内容
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) 功能 系统做什么？ 性能 软件开发的技术性指标 系统何时做什么？ 环境 硬件设备 存储容量限制 系统何时及如何修改或升级？ 接口 有来自其它系统的输入吗？ 机型、外设、接口、地点、分布、 执行速度、响应时间 用户或人的因素 用户类型？ 到自其它系统的输出吗？ 温度、湿度、磁场干扰等 吞吐量 文档 对数据格式有规定吗？ 各种用户熟练程度？ 软件 系统的可靠性要求？ 数据 需哪些文档？ 对数据存储介质有规定吗？ 需对访问系统或系统信息加以控 资源 需受何种训练？ 操作系统、网络、数据库 系统必须监测和隔离错误吗？ 文档针对哪些读者？ 输入、输出数据的格式？ 安全保密 制吗？ 用户理解、使用系统的难度？ 规定系统平均出错时间？ 软件运行时所需的数据、软件、 接收、发送数据的频率？ 软件成本消耗与开发进度 如何隔离用户之间的数据？ 用户错误操作系统的可能性？ 出错后，重启系统允许的时间？ 内存空间等资源 数据的准确性和精度？ 质量保证 系统变化如何反映到设计中？ 用户程序如何与其它程序和操作 开发有规定的时间表吗？ 软件开发、维护所需的人力、支 数据流量？ 开发进度 系统隔离？ 软硬件投资有无限制？ 维护是否包括对系统的改进？ 撑软件、开发设备等 数据需保持的时间？ 系统的可移植性？ 系统备份要求？
3.2.7 主持联合应用程序设计会议
JAD的目的是把所有这些活动压缩为用户 和项目小组成员一起参加得更短的JAD会 议。 参加人员：
JAD会议领导者 用户 技术人员 项目组成员
3.2.8 面向数据流自顶向下求精
数据流图是帮助复查的极好工具。
从输入端开始，分析员借助数据流图、数 据字典和IPO图向用户解释输入数据是怎 样一步一步地转变成输出数据的。 这些认识正确吗?有没有遗漏?用户应该注 意倾听分析员的报告，并及时纠正和补充 分析员的认识。复查过程验证了已知的元 素，补充了未知的元素，填补了文档中的 空白。
(1) 必须理解并描述问题的信息域，根据这条
准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要 求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为， 这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行 分解，用层次的方式展示细节。
3.1 需求分析的任务
面谈之后 复查笔记的准确性、 完整性和可理解性 把所收集的信息转 化为适当的模型和 文档 确定需要进一步澄 清的问题域 适当的时间向参加 会议的每一个人发 一封感谢信