简介：酒店管理系统概要设计说明.doc 是一份面向软件开发人员、项目评审员及测试人员的系统设计文档，完整阐述了系统总体架构与设计思路。资源围绕顾客就餐管理、住宿管理、用户权限管理及数据库信息管理四大核心模块展开，详细规划了处理流程、模块化结构、接口设计、运行环境、数据结构与出错处理，可作为课程设计、毕业设计或中小型管理信息系统开发的参考模板。包体为 1 个 doc 文档，大小 206KB，内容涵盖引言、总体设计、接口设计、运行设计、数据结构设计及系统出错处理等标准章节。目前已有 45 人学习浏览。文档从需求规定到物理结构层层递进，并配有系统模块运作流程，读者可据此快速理解酒店业务的信息化实现路径，也能够借鉴其格式规范完善自身项目设计资料。
1. 酒店管理系统概要设计：一份20年前的设计文档能教给现在的我们什么
拿一份《酒店管理系统概要设计说明.doc》当架构参考，第一反应通常是"这也太老了"——奔腾3处理器、128MB内存、Windows 98/XP，数据库还是SQL Server 2000。但把它逐节拆完会发现，这份文档把"顾客就餐管理、顾客住宿管理、用户信息管理、数据库信息管理"四大功能域的输入、处理、输出梳理得很清楚，权限模型已经有了RBAC的雏形，七层模块结构放到今天的Controller-Service-DAO分层里依然能对上号。对正在写课程设计的学生、要给MIS系统写概要设计的新手工程师，以及接手老酒店系统做二次开发的维护者来说，这份文档最大的价值不在技术栈，而在"怎么把业务拆成模块、再把模块落到数据表和接口"的完整方法论。
2. 需求规定与模块划分：四大功能域和七层模块结构怎么对应代码
文档2.1节的需求规定和2.4节的结构表要对照着读。概要设计最关键的产出，就是"功能→模块→程序"的映射。如果只记住四个功能域的名字，不往下拆到模块层，详细设计阶段仍然无从下手。
2.1 四个功能域的业务边界：从输入、处理到输出
文档对每项需求都按"输入→处理过程描述→输出"三段式写。这种写法看着笨，但排查需求歧义非常管用。我把四个域的关键流程整理成一张表：
| 功能域 | 核心输入 | 处理过程 | 输出 |
|---|---|---|---|
| 顾客就餐管理 | 顾客姓名、证件号 | 验证身份→提供菜单→点菜录入→换菜/退菜→结账 | 操作成功或失败的提示 |
| 顾客住宿管理 | 姓名、证件号、性别、年龄、籍贯、工作单位 | 验证身份→提供房间信息→选房录入→调房→结账 | 操作成功或失败的提示 |
| 用户信息管理 | 系统管理员用户名和密码 | 验证→增删用户、设定权限 | 操作成功或失败的提示 |
| 数据库信息管理 | 用户名和密码 | 验证→按权限查询、增删、修改 | 操作成功或失败的提示 |
注意就餐和住宿都提到了"先检查顾客的正确身份"，但检查方式文档没展开——是凭证件、会员卡还是人工核对？这就是概要设计的边界，它只告诉你要检查身份，不告诉你用什么算法。到详细设计阶段需要补一张"身份验证方式"的决策表。
从模块化角度看，两个前台业务域加两个后台管理域，恰好映射了现代架构里的"前台应用+管理后台"。如果做微服务拆分，这四个域天然就是四个服务，权限判断可以抽成独立的鉴权服务。概要设计阶段的域划分，决定了后面所有的表结构和接口边界，这一步定错了，后面全是返工。
2.2 权限模型：不是RBAC，但已经有了RBAC的骨架
文档2.3节把登录后的权限判断画成了活动图。拆开看其实是三个层次。
第一层是口令验证，用户名和密码匹配才能进系统，口令无效直接提示出错。第二层是角色判断，根据用户分类信息，把用户分到"就餐管理员、住宿管理员、数据库信息管理员、用户信息管理员"四个角色之一。第三层是细粒度权限，数据库信息管理员还能再细分到餐桌信息、菜肴信息、房间信息、顾客就餐记录信息、顾客住宿记录信息五个子权限。
把权限矩阵补全来看：
| 角色 | 可访问的功能模块 |
|---|---|
| 就餐管理员 | 顾客就餐管理（点菜、换菜、退菜、结账） |
| 住宿管理员 | 顾客住宿管理（选房、入住、调房、结账） |
| 数据库信息管理员 | 餐桌/菜肴/房间/就餐记录/住宿记录信息管理 |
| 用户信息管理员 | 用户增删、权限设定 |
| 系统管理员（拥有全部权限） | 以上所有 |
文档还特别说明：同一用户可以拥有一个或多个权限，拥有全部权限就是系统管理员。这个设计比单纯给每个用户打一个角色标签要好，因为它允许权限叠加。
用伪代码还原这段判断逻辑，便于后面写详细设计：
# 根据文档2.3节"基本设计概念和处理过程"转写的登录与权限判断逻辑 def login_and_auth(username, password): if not validate_user(username, password): return "口令无效" # 第一层：身份校验 role = get_user_role(username) # 第二层：取用户角色 menus = [] if "jiucan" in role: menus.append("顾客就餐管理") # 就餐管理员菜单 if "zhusu" in role: menus.append("顾客住宿管理") # 住宿管理员菜单 if "database" in role: menus.extend(["餐桌信息", "菜肴信息", "房间信息", "就餐记录", "住宿记录"]) # 数据库管理员子权限 if "admin" in role: menus.extend(["用户信息管理", "数据库信息管理"]) return render_main_interface(menus)这段逻辑说明两点：一是菜单生成完全由角色列表驱动，新增角色只需要扩展menus数组；二是文档把"用户信息管理"和"数据库信息管理"放在系统管理员一级，说明普通管理员默认没有管理其他用户的权限。数据库子权限不是角色级别的"全有或全无"，而是操作级别的"按需授予"，已经具备RBAC的核心骨架。
提示：概要设计里能写出这种权限矩阵，详细设计阶段就可以直接照着建角色表和用户-角色关联表。怕的是只写"用户有权限"五个字，后面全凭开发人员自由发挥。
2.3 七层21个模块：一个可落地的功能分解表
文档2.4节给了一张模块表，从第一层主模块Main到第七层正常显示/出错显示模块，一共21个模块。按层级重新整理一遍：
| 层数 | 模块 | 职责 |
|---|---|---|
| 第一层 | 主模块Main | 系统入口，组织整个结构 |
| 第二层 | 用户输入模块UserInput、输出模块Output | 接收用户名口令、输出显示 |
| 第三层 | 系统管理模块、输出处理模块Display、用户输入处理模块UserUse | 系统处理、显示正误信息、判断用户类型 |
| 第四层 | 就餐/住宿/数据库/用户信息管理员用户模块 | 四类角色入口 |
| 第五层 | 就餐管理、住宿管理、数据库信息管理、用户信息管理 | 四域业务管理 |
| 第六层 | 就餐记录、餐桌信息、菜肴信息、房间信息、住宿记录信息管理 | 细分数据管理 |
| 第七层 | 正常显示模块RightDisplay、出错显示模块ErrorDisplay | 结果反馈 |
这个结构的核心思想是"总控→分类→业务→数据"的四段式调用：第一到第三层是骨架，不碰任何业务；第四层做角色分流；第五、六层承载业务和数据操作；第七层统一处理显示。对应到现在的分层架构，第一到第三层就是控制器层加一个类型分发器，第五、六层是服务层加数据访问层，第七层是统一的响应封装。
拆这类文档时，把这张模块表抄进Excel里，每个模块列一行，然后再去代码里找对应目录。如果某个模块在代码里找不到对应包名，说明要么概要设计过度设计，要么详细设计漏了模块。这张表最有价值的地方在于，它把"显示正误信息"和"出错显示"单独提出来作为模块，而不是散落在每个业务方法里——在2000年代的系统里这是很超前的统一异常处理意识。
人肉核对这21个模块会发现一个小问题：文档5.1节列了"菜单信息表"作为数据表，但模块表第六层只有餐桌信息管理、菜肴信息管理，没有单独的"菜单信息管理"模块。这说明概要设计在功能和数据之间出现了断口——数据字典里出现了模块体系没覆盖的对象。这种断口就是后面避坑章要重点排查的典型问题。
3. 数据结构设计：五张核心表的数据字典与建表SQL落地
文档5.1节说"用表格的形式存储信息，包括旅客信息表、团体信息表、房间信息表、菜单信息表、餐桌信息表"，但5.3节实际给出完整字段的只有旅客、团体、房间三张表，菜单表和餐桌表只写了名字。这说明概要设计阶段的数据字典不必100%完整，但核心表必须定下来。这一章把三张有字段的表逐项拆开，再补上建表SQL，详细设计阶段可以少踩一半坑。
3.1 旅客信息表：14个字段里藏着一个主键设计问题
原始文档给出的旅客信息表字段如下：
| 字段名称 | 类型 | 大小 | 键 |
|---|---|---|---|
| 房间编号 | 字符串 | 16 | *（主键） |
| 姓名 | 字符串 | 16 | |
| 性别 | 字符串 | 4 | |
| 年龄 | 字符串 | 4 | |
| 文化程度 | 字符串 | 32 | |
| 职业 | 字符串 | 32 | |
| 从何处来 | 字符串 | 32 | |
| 到何处去 | 字符串 | 32 | |
| 住宿理由 | 字符串 | 32 | |
| 证件名称 | 字符串 | 32 | |
| 证件号 | 字符串 | 32 | |
| 工作单位 | 字符串 | 32 | |
| 离店日期 | 日期 | ||
| 备注 | 字符串 | 32 |
先说一个反直觉的设计：房间编号是主键。这意味着系统假设一个房间同时只有一个旅客登记。如果旅馆允许拼房、加床、团客两人住一间，这张表在插入第二条同一房间的记录时就会主键冲突。现在做酒店类系统，旅客表一律用自增主键，房间编号只做业务字段加索引，最多加一个唯一约束——同一房间同一时段只能有一条有效入住。
字段还有个年代烙印：年龄用字符串类型存放。二十年前很多MIS系统为了图省事，把所有短字段都统一成定长字符串，排序、统计的坑全留给后面的人。年龄用字符串，按年龄段分组时要么写一堆CASE WHEN，要么先CAST成整数再算，都会后悔当初为什么不用INT。
3.2 团体信息表和房间信息表：多一个"接待对象"维度
团体信息表字段更多，关键项如下：
| 字段名称 | 类型 | 大小 | 键 |
|---|---|---|---|
| 房间编号 | 字符串 | 16 | * |
| 接待对象 | 字符串 | 32 | |
| 联系时间 | 日期 | ||
| 联系单位 | 字符串 | 32 | |
| 联系人 | 字符串 | 32 | |
| 人数 | 整型 | * | |
| 住宿起时 | 日期 | ||
| 住宿终时 | 日期 | ||
| 住宿标准 | 字符串 | 8 | |
| 结账单位 | 字符串 | 32 | |
| 备注 | 字符串 | 32 |
注意"人数"也标了*键——在原始文档里这是第二个候选主键字段。但"人数"作为键本身是奇怪的，因为你不可能用"人数"去唯一标识一条团体记录。这里更可能的解读是文档起草人想表达"人数是团体登记的必填校验字段"，但错用了键标记。读到这类细节要多留个心眼，不能照抄，要结合业务语义判断。
团体信息表比旅客表多出来的字段集中在"接待对象、联系单位、联系人、结账单位"——这是为商务团、旅行团设计的，一个单位订一批房间，最后统一结账。这个场景在单体酒店里很常见，现在做管理系统，团体表一般会拆成"团队主表+团队成员明细表"两张，但概要设计这张单表已经能把业务表达清楚。
房间信息表相对简单：
| 字段名称 | 类型 | 大小 | 键 |
|---|---|---|---|
| 房间编号 | 字符串 | 16 | * |
| 房间等级 | 字符串 | 8 | |
| 房价 | 浮点 | ||
| 房价折扣 | 整型 | ||
| 住房人数 | 整型 | ||
| 登记时间 | 日期 |
房价折扣用整型，设计意图大概是"9折存9、8折存8"，但这样算价时要除以10，而且遇到85折就只能存85。这个字段应该直接存浮点折扣率，后面算价才不容易出错。概要设计文档只给类型不给业务规则，这就是一个典型的需要在详细设计阶段补充的决策点。
三张表之间的关系是：旅客信息表.房间编号→房间信息表.房间编号，团体信息表.房间编号→房间信息表.房间编号，菜单信息表和餐桌信息表从文档信息看是就餐子系统独立维护，与房间体系没有强关联。也就是说，就餐和住宿在数据层是两棵并行的树，共用一套用户权限，但业务数据不交叉。这个结构对单体小系统没问题，如果要做数据统计分析，比如住客在酒店餐厅的消费连带率，就得额外建关联表。
3.3 从数据字典到建表SQL：按文档字段补全的落地示例
数据字典定了，建表就顺理成章。下面是按文档字段补全的SQL，补全逻辑是：文档标*的字段设为主键，没有标但业务上不能空的设NOT NULL，外键关系在详细设计阶段再明确加约束。
-- 基于文档5.3节数据字典补全，供详细设计阶段落地参考 CREATE TABLE room_info ( room_no VARCHAR(16) PRIMARY KEY, -- 房间编号，文档标注主键 room_level VARCHAR(8), -- 房间等级，如：标准间/套间 room_price FLOAT, -- 房价，浮点类型按文档原样保留 room_discount INT, -- 房价折扣，文档用整型，建议改FLOAT occupant_cnt INT, -- 住房人数 checkin_time DATE -- 登记时间 ); CREATE TABLE guest_info ( room_no VARCHAR(16) NOT NULL, -- 房间编号，外键关联room_info guest_name VARCHAR(16) NOT NULL, -- 顾客姓名 gender VARCHAR(4), -- 性别，文档为字符串 age VARCHAR(4), -- 年龄，文档为字符串，建议改INT education VARCHAR(32), -- 文化程度 occupation VARCHAR(32), -- 职业 origin VARCHAR(32), -- 从何处来 destination VARCHAR(32), -- 到何处去 stay_reason VARCHAR(32), -- 住宿理由 id_type VARCHAR(32), -- 证件名称 id_no VARCHAR(32), -- 证件号 work_unit VARCHAR(32), -- 工作单位 leave_date DATE, -- 离店日期 remarks VARCHAR(32), -- 备注 guest_id INT IDENTITY(1,1) PRIMARY KEY -- 新增自增主键，规避一房一客问题 );两点说明：guest_info表在文档字段基础上增加了一个自增的guest_id作为真正主键，把room_no降级为普通外键字段，原因是3.1节里分析的"一房一客"假设在团客场景下会直接产生主键冲突，这个改动属于详细设计阶段的合理修正。
饭店相关的菜单信息表和餐桌信息表因为文档没给字段，这里没有硬造，等详细设计阶段访谈业务人员后补。概要设计文档没列出的表，不代表不用建，而是这个阶段没有数据来源。把它记进"待确认问题清单"，比强行编两张表要负责任得多。
另外，文档2.7节题为"尚未问决的问题"，但正文是空的。这是概要设计文档的高频状态——写文档的人知道有问题，但还没从需求方拿到答案。我的做法是单独维护一份问题清单，把"菜单信息表字段待定""身份验证方式待定"这类事项记下来，评审时逐条确认。空着不写，后面就一定会变成开发的自由发挥。
4. 接口设计与运行设计：三重接口、DBMS选型和0.5秒响应约束
接口设计在概要设计里常常被一句话带过，但文档这部分给的信息量其实不少：用户接口定义了账户初始值和密码规则，外部接口锁定了数据库和操作系统，内部接口明确了子系统划分。运行设计又补了模块组合和响应时间指标。这四小节合起来，基本就是一份可以交给开发团队开工的约束清单。
4.1 用户接口的三条硬约束：初始账号、密码长度和三次锁定
文档3.1节给了几条明确的参数：
| 约束项 | 参数值 |
|---|---|
| 系统管理员初始账号 | Admin |
| 系统管理员初始密码 | 000000 |
| 账号类型 | 字符型，长度20字节 |
| 密码类型 | 字符型，长度6~20字节 |
| 密码错误处理 | 连续三次错误，系统直接关闭 |
| 输入方式 | 鼠标、键盘，可视化界面 |
"Admin/000000"这个组合放到今天看就是安全灾难，但在单机版管理软件普及的年代，几乎每个MIS系统出厂都带一套默认超级账户。文档里写了"系统管理员第一次使用后进行密码修改"，说明设计者已经意识到默认密码的风险，只靠一条流程约定来兜底。真要在现代环境复用这套设计，至少要加上"首次登录强制改密+密码复杂度校验+账号锁定策略"，光靠文档里这一句话是挡不住暴力破解的。
三次错误关闭系统的策略，出发点显然是防暴力试密码，但"关闭"这个处置在多人共用收银机的场景里很尴尬——普通收银员手误连按三次，整台POS机就要重新启动。合理的做法是"连续失败锁定账户N分钟"或者"锁定当次终端"，并保留Admin手工解锁的旁路。概要设计阶段的策略定下来，后面做登录模块就不用反复改需求。
4.2 外部接口：SQL Server 2000与Windows 98时代的选型逻辑
文档2.2节和3.2节写得很清楚：系统需要Microsoft SQL Server 2000或更高版本DBMS支持，操作系统支持Windows 9x/2k/me/xp，硬件要求是奔腾3以上、内存128MB、硬盘20G。这套配置放到现在的开发机上是古董级，但概要设计把一个运行环境钉得这么死，在当时是有道理的。
第一，酒店的前台电脑通常不配置高性能硬件，奔3+128MB是2000年代初期的标准商用机配置，定了低配基线，开发团队就不会在界面动画、大数据量加载上过度设计。第二，SQL Server 2000在那个时候是Windows平台最成熟的小型数据库，和Windows操作系统打包部署的兼容性问题最少。
现在的运行环境肯定要变。常见做法是：数据库改用SQL Server Express或MySQL 8，应用层用Python/Java重写，前端换成Web页面，操作系统直接上Windows Server或Linux。文档写的是"SQL Server 2000或更高版本"，既然原文给了兼容性空间，迁移到高版本SQL Server并不违背原始设计约束。放到互联网环境里跑，原先的单机版设计还要补网络并发、多门店数据同步、安全传输三块内容，这份概要设计里的运行环境章节就只能作为历史参考，不能作为架构决策依据。
提示：老文档里的运行环境章节不要照抄。它的作用是告诉你"当初为什么这么选"，而不是"现在必须这么配"。硬件指标过时了，但"先定环境再开发"的思路不过时。
4.3 内部接口与运行设计：模块怎么组合、控制在多少时间内
文档3.3节说系统内部划分为顾客就餐管理和顾客住宿管理两个主要子系统，加上用户信息管理系统和数据库信息管理系统。内部接口说的就是这四个子系统之间的调用关系。按2.4节的模块表，主模块Main是唯一入口，根据用户权限分发到对应子模块，子模块之间没有横向调用，全部经由主模块中转。
这个"星型调用"结构在这个量级的项目里是合理的：它保证了权限判断只发生在主模块一张入口上，不需要每个子模块自己再判断一次权限，也就不会出现一个普通就餐管理员绕过入口直接调用住宿接口的越权路径。
运行设计部分给了两个约束：一是运行模块组合，即按用户类型加载对应菜单；二是运行时间，文档明确"模块所占用时间不多，应控制在0.5s以内"。这句话不能只当成性能指标来读——在128MB内存、机械硬盘的年代，0.5秒意味着所有业务模块都必须在内存里完成操作，任何过度依赖磁盘I/O的环节都要优化。放在现在的Web系统里，这个指标依然适用，前端交互超过0.5秒用户就会觉得卡。
文档2.6节"人工处理过程"还提到"对用户类型的分类，即用户的分配需要人工处理为系统用户增加用户名与权限"。这说明角色分配不是自助申请的，而是管理员离线决定好之后手动录入。这个约束对接口设计的影响是：不需要做自助注册页面，只需要一个管理员维护用户的界面。概要设计文档里任何一句"人工处理"，都意味着对应模块要预留一个人工操作入口，写代码时最容易漏的就是这种环节。
文档最后一章出错误处理设计分了出错信息、补救措施、系统维护设计三小节。别小看这三项，它对应的是代码里的异常提示统一、备份恢复流程和系统升级策略。概要设计文档能把这三项写进目录，已经算完整了，很多同类文档直接略过。
5. 避坑指南：从这份概要设计到详细设计的五个高频问题
概要设计文档不是写完就完了，后面每一阶段都可能回来找它的麻烦。以下五条是拆这类老式设计文档时真实踩过的坑，每条按现象、原因、解决三个层次记录。
5.1 年龄字段用字符串，统计报表全乱
现象：按文档把年龄建成VARCHAR(4)，数据写入正常，一到做统计就翻车。按年龄排序，"100"排在"20"前面，按年龄段分组要么写一长串CASE WHEN，要么得先把字符串转整数。
原因：文档5.3节原样标着"年龄 字符串类型 4"。那个年代很多MIS设计者习惯用定长字符串统吃短字段，觉得这样长度可控、界面显示对齐。但数据库的排序、比较、聚合函数对字符串和数字的处理逻辑完全不同。
解决：详细设计阶段把年龄改成INT，离店日期保持DATE不改。有历史数据的话先做一次范围校验（比如0~120）再迁移，避免"abc"混进数字列导致转换报错。
5.2 旅客信息表用房间编号做主键，团客一入住就爆主键冲突
现象：两个客人同住一间房，第二条记录死活插不进去，报主键重复。更隐蔽的是，同一个客人离店后再入住，也会产生两条room_no相同的记录。
原因：文档把房间编号标为主键，隐含了"房间当前只属于一个旅客"的假设，没有考虑拼房、加床、二次入住。
解决：新建guest_id自增主键，room_no改为普通字段并加索引，约束改成"同一房间同一入住时间段不可重复"。这个改动虽然在概要设计之后才能发现，但影响范围只限于旅客表本身，房间表不用动。发现得越早，改动成本越低。
5.3 密码三次错误就关闭系统，收银台直接被锁死
现象：收银员手误连输三次错密码，系统直接黑屏关闭，重开系统还要等管理员过来解锁。在多人共用一台POS机的场景下，这比密码被破解更容易造成业务中断。
原因：文档3.1节写了"连续三次输入错误，系统则关闭"。这个设计的初衷是防暴力破解，但"关闭"这个动作没有区分"锁定账户"和"锁定终端"，也没有考虑多用户共用设备的问题。
解决：把"关闭"改成"账户锁定N分钟"或"当日锁定"，锁定期间其他合法用户不受影响；保留Admin的后门解锁通道，防止管理员自己把账户锁死。
5.4 文档里满屏"XX"占位符，数据字典要猜
现象：原文档里到处是"存储顾客的XX""XX信息管理""满足XX性"，关键字段名全都变成了XX，直接照着建库根本没法写。
原因：这份文档是脱敏或OCR处理过的版本，原始的"姓名、用户、安全"等词被统一替换成XX，不是设计者真的写了占位符。
解决：处理方法是根据上下文逐处还原——"顾客的XX,证件类型"这里的位置对应的是姓名；"XX信息管理"从活动图里的功能看是用户信息管理；"满足XX性"结合前后文是安全性。还原之后要全局搜一遍遗留的XX，防止同一个词在不同章节被替换成不同含义。遇到此类脱敏文档，先用半小时建一个"XX对照表"再往下读，不然会反复卡壳。
5.5 把酒店管理系统做成客户关系管理系统，边界没划清
现象：设计数据库信息管理模块时，觉得顾客信息表应该加会员等级、积分、消费偏好、定向营销这些字段，结果越加越多，最后发现住宿和就餐两个核心流程反而被复杂字段拖累。
原因：酒店管理系统和客户关系管理系统（CRM）的边界被混淆了。这份概要设计里的"顾客信息"服务于入店到离店的业务闭环，核心是房间、账单、在住状态；CRM的核心是客户画像、会员运营、营销触达。两者对象都叫"顾客"，但数据模型差异很大。
解决：在概要设计开头用一段话明确系统边界——本系统只负责酒店运营流程，客户生命周期管理不在范围内。如果业务上确实需要CRM，单独建一张客户主数据表，和酒店管理系统的顾客表通过customer_id关联，不要在一个表里既塞运营数据又塞营销数据。
6. 用双向核对表验证概要设计完整性：一个10分钟出结果的笨办法
这里不聊新概念，聊一个每次评审概要设计都会做的验证动作——把模块表和数据字典放在同一张表里做双向核对。这个方法简单到不需要工具，一张白纸加一支笔就够，但能打捞出概要设计里绝大多数断口。
做法分三步。第一步，把文档里的数据表列成行：旅客信息表、团体信息表、房间信息表、菜单信息表、餐桌信息表。第二步，把功能模块列成列：就餐管理、住宿管理、数据库信息管理、用户信息管理。第三步，在交叉格里填W（写）或R（读），比如就餐管理要写菜单表、读餐桌表，就在对应格子填。
填完会出现三种情况。一种是某张表没有任何模块读或写，说明这个数据对象是多余的，或者对应的功能模块丢了——这个系统里"菜单信息表"就接近这种状态，模块表里找不到明确的菜单管理模块。第二种是某个模块对应不到任何表，说明它的数据存储没定义，比如"用户信息管理"如果找不到用户表，那用户名、密码、权限数据存哪就是一块空白。第三种是同一张表被多个模块同时写，要考虑并发和事务，比如房间信息表同时被住宿管理和数据库信息管理写，就需要在详细设计里约定更新顺序和锁的粒度。
按这个方法给这份文档做个简化示意：
| 数据表 \ 功能模块 | 就餐管理 | 住宿管理 | 数据库信息管理 | 用户信息管理 |
|---|---|---|---|---|
| 旅客信息表 | W / R | R | ||
| 团体信息表 | W / R | R | ||
| 房间信息表 | W / R | W / R | ||
| 菜单信息表 | W / R | R | ||
| 餐桌信息表 | W / R | R |
这张表一旦填出来，问题就暴露了：用户信息管理整列是空的，说明文档在整个数据结构设计里漏掉了用户表和权限表；数据库信息管理只读不写，那"增删餐桌、增删菜肴"的功能往哪张表上落？这两个断口在前面避坑部分已经讨论过，但在双向核对表面前是直接逼出来的，不需要翻文档猜。
从那以后，每次评审概要设计文档，都强制自己先做这张双向核对表。它能让我在10分钟内判断一份文档能不能进入详细设计，而不是等代码写完了才发现缺表缺模块。文档里的表格和字段再多，也经不起这张表一照。希望帮到你。
本文还有配套的精品资源，点击获取
