用例规约的写作要点与常见误区

[[用例技术族四种技术的用途定位]]中的用例规约写作有几条容易被忽视的要点。第一，用例规约对系统行为的描述以用户为中心展开，便于和用户交流，同时既要关注主事件流描述的成功场景，也要关注备选事件流描述的异常场景——这种”两面都要看”的写法本身就在促进系统化思维，帮助设计者主动发现异常场景、完善系统功能、提高易用性。第二，用例规约的格式并非一成不变，可以按实际需要剪裁或扩充：比如增加”使用频率”字段供界面设计和性能设计参考，增加”需求背景及可能的变化”字段供架构师设计可扩展架构时参考——用例规约本质上是一种思维工具，格式服务于目的，不是死板的模板。第三个也是最容易被误用的一点：用例规约中不应该包含用户界面原型。界面如何规划本质上属于设计工作，如果把这部分设计混入需求文档、提前”确定”下来，会造成后续设计工作的被动（相当于需求阶段就替设计做了决定，压缩了设计空间）——但这不意味着完全排斥界面设计参与需求阶段，实践中推荐在需求分析时就同步开始界面设计（配合开发水平抛弃原型），用来辅助需求交流，只是这部分成果不应正式写入用例规约或需求文档本身。第四，后置条件应该覆盖所有可能的用例结束状态，不能只写用例成功结束后的状态，还必须包含用例因发生错误而结束后的状态——比如储蓄系统”销户”用例中”证件不符而退出”“密码不符而退出”都属于因错误结束的情况，遗漏这些异常结束状态会让用例规约看起来完整、实际上留下了设计和测试的盲区。