职业技能：用例（Use Case）撰写 第一步：理解“用例”的基本概念与核心价值 用例是一种用于描述系统（可以是软件系统、业务流程或服务）如何与外部参与者（用户或其他系统）交互，以实现特定目标的结构化方法。它聚焦于“用户做什么”和“系统如何响应”，而非技术实现细节。其核心价值在于： 用户视角 ：确保设计始终围绕用户目标和需求，促进用户中心设计。 沟通桥梁 ：作为业务分析师、用户、开发人员和测试人员之间的通用语言，减少歧义。 需求基础 ：明确功能范围，是编写功能需求、测试案例和用户手册的重要输入。 第二步：掌握用例的核心构成要素 一个规范的用例包含几个关键部分，共同构成一个完整的叙事： 参与者 ：与系统交互以达成目标的实体，可以是人（如“顾客”、“管理员”）或其他外部系统。 用例名称 ：以“动词+宾语”形式清晰概括目标，如“订购图书”、“重置密码”。 前置条件 ：用例开始前系统必须满足的状态，如“用户已登录”。 基本事件流（主成功场景） ：描述参与者与系统交互以实现目标最直接、无错误的理想步骤序列。这是用例的核心。 扩展事件流（替代流） ：描述在主流程中出现异常、错误或分支选择时的处理路径，如“库存不足”、“输入信息无效”。 后置条件 ：用例成功完成后系统所处的状态，如“订单已生成并待支付”。 第三步：学习编写一个标准用例的详细过程 以“在线购物-提交订单”为例，实践编写： 识别参与者 ：主要参与者为“注册顾客”。次要参与者可能包括“支付网关系统”。 确定用例名称 ：“提交订单”。 设定前置条件 ：顾客已登录，购物车中至少有一件商品。 撰写基本事件流 ： 参与者动作：顾客进入购物车页面，点击“去结算”。 系统响应：系统显示订单确认页面，包含商品清单、总价、配送地址栏和支付方式选项。 参与者动作：顾客确认信息无误，选择支付方式，点击“提交订单”。 系统响应：系统生成唯一订单号，锁定库存，将订单状态置为“待支付”，并引导顾客至支付页面。 规划扩展事件流 ： 扩展点：在订单确认页面修改配送地址 。 顾客点击“修改地址”。 系统弹出地址管理界面。 顾客选择或新增地址后保存。 流程回到基本流中系统显示更新后的订单确认页面。 扩展点：提交时库存不足 。 系统检测到某商品库存不足，提示“商品[ XXX ]库存仅剩Y件，请调整数量”。 用例结束（订单未创建）。 明确后置条件 ：订单已创建，状态为“待支付”；相关商品库存已被锁定。 第四步：进阶应用与最佳实践 掌握基础后，需了解如何有效运用和提升用例质量： 用例的层次与粒度 ： 用户目标级 ：描述参与者完成一个完整有价值目标的过程（如“提交订单”），是最常用的层级。 子功能级 ：作为用户目标的一部分，如“修改配送地址”。应避免过度分解为原子操作。 用例图 ：使用UML用例图可视化展示系统边界、所有参与者、用例及其关系（包含、扩展、泛化），提供系统功能的顶层视图。 撰写原则 ： 使用主动语态和简单句 ，如“系统验证密码”而非“密码应被系统验证”。 描述“做什么”，而非“怎么做” ，避免涉及界面控件（如“点击XX按钮”）或内部技术逻辑。 保持目标导向 ，确保每个用例都对应一个明确的参与者目标。 与用户故事的区别 ：用户故事（作为X，我想Y，以便Z）是需求的轻量级占位符，强调对话；用例是更详细、结构化的需求规约，强调契约。两者可互补，用户故事可在细化时扩展为用例。 第五步：实际工作流中的整合应用 用例不是孤立文档，需融入完整的产品开发流程： 需求获取与分析阶段 ：通过访谈和研讨识别主要参与者和他们的目标，列出用例清单。 需求规格阶段 ：为关键和高风险用例撰写详细描述，与干系人评审确认。 设计与开发阶段 ：开发人员依据用例理解功能行为；测试人员依据基本流和扩展流设计测试用例。 持续管理 ：将用例作为活文档，随需求变更而更新，维护其与代码、测试的一致性。 通过以上步骤，你可以系统性地掌握用例撰写这一核心技能，将其转化为清晰定义需求、协调团队、交付符合预期产品的有效工具。