HRMS用例图设计合理性咨询：需求覆盖及Inventory关联确认

一、蛛网式用例图的有效性判断 #

蛛网式用例图不一定直接失效，但要警惕职责过载问题：

• 如果是某个核心用例（比如「处理预订」）被大量其他用例直接关联，大概率是用例拆分太粗糙——把本该属于子流程的逻辑硬拆成独立用例，导致依赖关系混乱，这种情况需要重新梳理用例职责。
• 如果是单个参与者（比如「前台员工」）关联多个用例，只要每个用例的职责清晰、符合实际业务场景，就完全没问题——毕竟前台本来就要负责宾客登记、入住退房、报表生成这些工作。

二、需求覆盖情况验证 #

对照你列出的需求模块，逐一核对核心用例：

• ✅ 宾客信息登记模块：对应「登记宾客信息」用例
• ✅ 入住/退房模块：对应「办理入住」「办理退房」用例
• ✅ 客房管理模块：对应「维护客房信息」「更新客房状态」用例
• ✅ 与预订集成：对应「处理预订请求」「修改预订信息」用例
• ✅ 账单及库存报表模块：对应「生成账单」「生成库存报表」用例
• ✅ 用户管理：对应「管理系统用户」「分配用户权限」用例

如果你的用例图包含以上这些核心场景，需求覆盖就是充分的；如果有遗漏（比如没考虑「修改预订」场景），补充对应用例即可。

三、Inventory（库存）与预订用例的关联方式选择 #

核心看业务逻辑的强制性：

1. 包含关系（<>）：如果预订流程必须执行库存检查（比如预订客房前必须确认对应房型有空房），就用包含——这是预订的必要核心步骤，没有库存检查，整个预订流程无法完成。
2. 扩展关系（<>）：如果库存检查是可选分支（比如只有预订带额外物资的套餐时才需要校验库存，普通客房预订不需要），就用扩展——这是对主预订流程的补充，不影响主流程的基本执行。

举个实际场景例子：

• 常规客房预订：必须先查空房，此时「检查客房库存」是「处理预订」的包含用例。
• 预订带下午茶的客房：只有用户选择下午茶套餐时才需要检查食材库存，此时「检查餐饮库存」是「处理预订」的扩展用例。

内容的提问来源于stack exchange，提问作者Nathan Budhuu