一.实际编写用例,每个开发组都应该形成并制定一套工作习惯,一种好的方式是由开发组和个人分工合作,因为组比个人有两个优点,一是便于集中讨论,二是便于对于问题达成共识,下面是整个工作过程.
第一阶段:制定 粗略的系统功能图
1、对系统的叙述达成共识(开发组) 2、对应用领域达成共识,集中讨论系统主执行者和系统目标(开发组) 3、编写系统描述(个人) 4、收集各种系统描述(开发组) 第一阶段工作完成,团队应向投资方发送以分系统叙述,显示新系统草图,应该包括以下各项:- 系统的构想陈述
- 列出哪些在领域中,哪些不在领域中(包括设计和功能范围)
- 在执行环境中的草图
- 关键的主执行者列表
- 项目相关人员及其相关利益列表
- 最重要用户列表
- 系统的描述集(至少半页)
第二阶段:执行详细用例视图
1、集中研讨用例编写(开发组) 2、对用例编写格式达成共识(开发组) 3、编写用例(个人) 4、审核用例二.从庞大,不同层次的团队收集用例(Andy Kraus)
- 不要忽略对会议场所的选择.
- 没有适合的人就找不到正确的用例.
- 与小团队相比,大团队更难一致.
- 每次与用户开会不要超过半个工作日.
- 与管理者同舟共济
- 在提取用例时负责系统结构的人应该在场.
- 如果让支持取代原系统的人参加会议就有一个达到目的的好机会
- 没有什么可以代替用例涉及的"真正用户"
- 使用抄写员(会议记录)
- 及时显示已建立用例来加速用例提取过程
- 一项工作的标题不是也给执行者
- 应用程序不关心你是谁,只关心你戴的帽子
- 在执行者初始编制过程,寻找遗漏的执行者.
- "日常工作用例"促进了获取用例的讨论
- 不要急于求成
- 期望陷入困境;讨论的催化剂
- 用例提取是一项社会活动
- 标准的"描述符"有利于简化过程
- 构造,维护,显示前置条件列表
- 作最小主义者:尽可能使你的用例模板最小