3.1 信息系统的设计
知识点
1.本单元要学什么
单元主题：信息系统的设计与开发——从一个想法，到一套真正能用的系统。
| 小节 | 核心问题 |
|---|---|
| 3.1 信息系统的设计 | 系统怎么"想清楚"？需求怎么变成方案？ |
| 3.2 数据库的构建 | 数据怎么存？表怎么建？SQL 怎么写？ |
| 3.3 信息系统的数据输入 | 数据怎么"进得来、进得对"？ |
| 3.4 信息系统的数据处理 | 数据怎么清洗、统计、加工？ |
| 3.5 信息系统的数据呈现 | 结果怎么"看得懂、用得上"？ |
单元主线：设计 → 建库 → 输入 → 处理 → 呈现。这五步正好对应数据的"一生"：从纸面方案到落地系统，从原始数据到可视化结论。
一句话记住本单元的地位：第2单元是"把设备连起来"，第3单元是"把系统造出来"。
2.设计阶段到底在做什么
设计的本质：把"用户想要的"翻译成"开发者能做的"。
| 阶段 | 输入 | 输出 | 谁主导 |
|---|---|---|---|
| 需求分析 | 用户的想法与抱怨 | 需求清单 | 用户＋分析员 |
| 系统分析 | 需求清单 | 数据流图、E-R 图 | 系统分析员 |
| 概要设计 | 分析结果 | 架构、模块划分、数据库设计 | 系统设计师 |
| 详细设计 | 概要设计 | 流程图、界面原型、接口定义 | 设计师＋程序员 |
核心风险：需求错，全盘错。设计阶段改一行，开发阶段省十天；上线后才发现需求错，可能要重做。
3.需求分析：把"想要的"说清楚
（1）需求的三个层次
| 层次 | 内容 | 举例（宿舍报修系统） |
|---|---|---|
| 功能需求 | 系统必须做什么 | 学生提交报修单、维修工接单、管理员统计 |
| 非功能需求 | 做得多好 | 页面 2 秒内打开、支持 300 人、数据不丢 |
| 约束条件 | 受什么限制 | 预算 500 元、两周完成、只能用学校服务器 |
学生最容易漏的是"非功能需求"——而它往往决定系统好不好用。
（2）需求的来源
| 来源 | 方法 | 优点 | 缺点 |
|---|---|---|---|
| 访谈 | 与用户面对面聊 | 深入、能挖出真实痛点 | 耗时，样本小 |
| 问卷 | 大范围收集 | 覆盖面广、易量化 | 问题设计不好就白做 |
| 观察 | 到现场看用户怎么干活 | 能发现"说的"和"做的"不一致 | 耗时间 |
| 文档分析 | 看现有表格、单据、报表 | 快速了解业务 | 文档可能过时 |
| 原型试用 | 先做个样子给用户试 | 反馈最真实 | 需要先投入一点开发 |
最有效的一条经验：看用户现在用的那张纸。很多业务规则就写在纸质单据的栏目和流程里——那是真实需求的"化石"。
（3）用户故事：把需求写成一句话
句式：作为（角色），我希望（功能），以便（价值）。
| 角色 | 用户故事 |
|---|---|
| 学生 | 作为学生，我希望扫码提交报修并上传照片，以便说清楚故障情况 |
| 维修工 | 作为维修工，我希望按楼栋查看待办工单，以便少跑冤枉路 |
| 管理员 | 作为管理员，我希望看到各楼栋平均维修时长，以便评价维修效率 |
好处：一句话里同时包含了角色、功能、价值，天然可验收，也方便排优先级。
（4）需求优先级：MoSCoW 法
| 级别 | 含义 | 处理 |
|---|---|---|
Must | 必须有，没有系统就没意义 | 第一版必做 |
Should | 应该有，很重要但可暂缓 | 第二版做 |
Could | 可以有，锦上添花 | 有余力再做 |
Won't | 这次不做 | 明确写出来，避免扯皮 |
写清"不做什么"和写清"做什么"一样重要——这是控制项目范围的关键。
4.可行性分析：先判断"该不该做"
| 维度 | 要回答的问题 | 判断依据 |
|---|---|---|
| 技术可行性 | 现有技术与人能力能否实现 | 有无成熟方案、团队会不会 |
| 经济可行性 | 投入产出是否划算 | 设备／软件／人力成本 vs 节省的时间与人力 |
| 操作可行性 | 用户愿不愿用、会不会用 | 操作是否比原来更简单 |
| 时间可行性 | 能否按期交付 | 工作量与人力匹配度 |
| 法律与伦理可行性 | 是否合规 | 个人信息采集是否必要、有无授权 |
常见误判：只算"技术能不能做"，不算"人愿不愿用"。很多系统失败不是技术不行，是没人用。
结论可以是三种：立项开发、缩小范围开发、不开发（改用现成产品）。
5.系统分析：用图把业务画清楚
（1）数据流图（DFD）——画"数据怎么流动"
四种基本符号（必背）：
| 符号 | 名称 | 含义 | 举例 |
|---|---|---|---|
| 矩形 | 外部实体 | 系统之外的人或组织 | 学生、维修工、教务处 |
| 圆形（或圆角矩形） | 加工 | 对数据做的处理 | 审核报修单、计算工时 |
| 两条平行线（或开口矩形） | 数据存储 | 数据存放的地方 | 报修单表、学生名册 |
| 箭头 | 数据流 | 数据流动方向与内容 | 报修单、审核结果 |
画法要点（答题规范）：
- 自顶向下、逐层分解——先画顶层图（系统与外部实体的关系），再画 0 层图细化内部加工；
- 每个加工都要有输入和输出——只有输入没有输出，说明这一步没意义；
- 数据流必须命名（写清"什么数据"），不能只画箭头不写字；
- 外部实体在系统之外，不能画到系统内部。
顶层图示例（宿舍报修系统）：
学生 →（报修单）→ 报修系统 →（派工单）→ 维修工 维修工 →（完工记录）→ 报修系统 →（统计报表）→ 管理员
（2）E-R 图——画"数据之间什么关系"
| 元素 | 图形 | 含义 | 举例 |
|---|---|---|---|
| 实体 | 矩形 | 一类对象 | 学生、图书、报修单 |
| 属性 | 椭圆 | 实体的特征 | 学号、姓名、书名 |
| 联系 | 菱形 | 实体之间的关系 | 借阅、提交、属于 |
三种联系类型：
| 类型 | 含义 | 举例 |
|---|---|---|
| 一对一（1:1） | 一个对一个 | 班级 ↔ 班长 |
| 一对多（1:n） | 一个对多个 | 班级 → 学生 |
| 多对多（m:n） | 多个对多个 | 学生 ↔ 课程（一个学生选多门课，一门课有多个学生） |
E-R 图的作用：它是从"业务"到"数据库表"的桥梁——实体变表、属性变字段、联系按类型处理（多对多必须拆成中间表）。3.2 会展开这一步。
6.概要设计：定架构、分模块
（1）选系统架构
| 架构 | 特点 | 适用 |
|---|---|---|
| 单机版 | 数据在本机，不联网 | 个人工具 |
C/S | 客户端＋服务器，性能好 | 需硬件交互、专业软件 |
B/S | 浏览器＋服务器，免安装 | 绝大多数管理系统 |
移动端 APP／小程序 | 手机原生体验 | 面向公众、需定位推送 |
（2）模块划分
把系统按功能切成若干相对独立、职责单一的模块。
| 原则 | 含义 | 反例 |
|---|---|---|
| 高内聚 | 一个模块内部的功能紧密相关 | "工具模块"里既算工资又发邮件 |
| 低耦合 | 模块之间依赖尽量少 | 改一个页面要连带改五个模块 |
| 单一职责 | 一个模块只做一件事 | 一个函数既校验又存库又发通知 |
为什么重要：模块化让系统"可改、可测、可复用"。小型系统也一样——把"登录校验"写成独立函数，将来换认证方式只改一处。
（3）分层思想（了解）
表示层（界面）→ 业务逻辑层（规则）→ 数据访问层（读写数据库）
分层的好处：界面改了不影响业务，数据库换了不影响界面。这是现代系统设计的基本共识。
7.详细设计：把每个模块说透
详细设计要产出四样东西：
| 产出 | 内容 | 举例 |
|---|---|---|
| 处理流程 | 用流程图描述每个功能的步骤 | 借书：扫码 → 查库存 → 判额度 → 写记录 → 减库存 |
| 界面原型 | 每个页面的布局与元素 | 图书列表页（搜索框、表格、分页） |
| 数据设计 | 表结构、字段类型、约束 | borrow 表（借出日期、应还日期） |
| 接口定义 | 前后端怎么传数据 | GET /api/books?kw=python 返回 JSON |
判定"详细设计是否够细"的标准：换一个程序员来看，能照着写出来。写不出来，说明还不够细。
8.界面设计：好用比好看更重要
七条可用性原则：
| 原则 | 含义 | 反例 |
|---|---|---|
| 一致性 | 同类操作在同一位置、同一叫法 | 一处叫"提交"，一处叫"确定" |
| 可见性 | 重要状态一眼可见 | 不知道当前登录的是谁 |
| 及时反馈 | 操作后有明确响应 | 点了"保存"没任何提示，用户反复点 |
| 防错优于纠错 | 从设计上避免出错 | 日期让用户手输而不是选日历 |
| 减少记忆负担 | 选项可见，不用背 | 让用户记住上一步的编号 |
| 容错与可撤销 | 误操作能恢复 | 删除没有二次确认，删了找不回 |
| 简洁 | 一屏解决主要任务 | 首页堆二十个按钮 |
移动端额外考虑：触控目标足够大、单手可操作、少输入多选择。
原型的两级：
- 低保真原型——纸笔草图或线框图，快、便宜，用来确认"结构对不对"；
- 高保真原型——接近真实视觉与交互，用来确认"体验好不好"。
建议：先用低保真把流程走通，再做视觉。学生常犯的错是一上来就挑颜色，结果结构返工。
9.设计文档：让方案可交接
| 文档 | 内容 | 谁看 |
|---|---|---|
| 需求规格说明书 | 功能清单、非功能要求、约束、验收标准 | 用户与开发者共同确认 |
| 系统设计说明书 | 架构图、模块划分、E-R 图、表结构、接口 | 开发者 |
| 界面原型说明 | 页面清单、跳转关系、交互规则 | 设计与前端 |
| 测试计划 | 测试范围、用例、通过标准 | 测试与验收 |
文档不是形式主义——它的作用是**"把共识写下来"**。项目做到一半人员变动，靠的就是文档。
小型项目的务实写法：一页需求清单＋一张架构图＋一张 E-R 图＋一份表结构说明，四样齐了就能开工。
10.好设计的六条标准
| 标准 | 含义 |
|---|---|
| 正确性 | 满足需求，业务规则算得对 |
| 可靠性 | 长时间稳定运行，异常能恢复 |
| 易用性 | 用户不用培训就能上手 |
| 可维护性 | 能改、能查错、能扩展 |
| 安全性 | 权限清晰、数据受保护 |
| 经济性 | 成本与收益匹配，不盲目堆技术 |
评价顺序：正确 → 可靠 → 易用 → 可维护 → 安全 → 经济。前一条不满足，后一条没有意义。
11.速查表
| 序号 | 考点 | 结论 |
|---|---|---|
| 1 | 设计的本质 | 把"用户想要的"翻译成"开发者能做的" |
| 2 | 需求三层次 | 功能需求、非功能需求、约束条件 |
| 3 | 最易漏的需求 | 非功能需求 |
| 4 | 需求来源五法 | 访谈、问卷、观察、文档分析、原型试用 |
| 5 | 用户故事句式 | 作为…我希望…以便… |
| 6 | MoSCoW | Must／Should／Could／Won't |
| 7 | 可行性五维 | 技术、经济、操作、时间、法律伦理 |
| 8 | DFD 四符号 | 外部实体、加工、数据存储、数据流 |
| 9 | DFD 绘制原则 | 自顶向下逐层分解，加工必有输入输出 |
| 10 | E-R 三元素 | 实体（矩形）、属性（椭圆）、联系（菱形） |
| 11 | 三种联系 | 1:1、1:n、m:n |
| 12 | E-R 的作用 | 业务到数据库表的桥梁 |
| 13 | 多对多联系处理 | 必须拆成中间表 |
| 14 | 模块化原则 | 高内聚、低耦合、单一职责 |
| 15 | 三层架构 | 表示层、业务逻辑层、数据访问层 |
| 16 | 详细设计四产出 | 流程、界面、数据、接口 |
| 17 | 详细设计合格标准 | 换个程序员能照着写出来 |
| 18 | 界面设计核心 | 防错优于纠错、及时反馈、一致性 |
| 19 | 原型两级 | 低保真（结构）、高保真（体验） |
| 20 | 设计评价顺序 | 正确 → 可靠 → 易用 → 可维护 → 安全 → 经济 |
12.课堂提示（讲课参考）
- 用"点外卖"讲需求三层次：功能需求是"能下单、能付款、能看配送进度"；非功能需求是"3 秒内打开、不重复扣款"；约束是"只能用手机号注册"。学生天天用，理解零成本。
DFD是本节最大难点，务必"从一张纸开始"：先让学生画出"现在没有系统时，报修这件事怎么走"（口头说、纸条传、电话催），再把这些动作换成四种符号。先有业务，再有图，不要一上来讲符号。E-R图用"学生—课程—成绩"讲透多对多：问"成绩该记在学生上还是课程上"，学生答不出，正好引出"多对多必须建中间表"。这个问题想通了，3.2 的建表就顺了。- "防错优于纠错"用真实反例：找一个要手动输入身份证号、日期靠手打的旧系统截图，让学生说说"如果让你改，改哪里"。比讲七条原则更有效。
- 作业建议：让每组选一个身边场景，交一页需求清单＋一张顶层
DFD＋一张E-R图。下节课互评时只问一句"换个程序员能照着做出来吗"——用这一条标准检验详细设计的质量。