用例技术（四）——用例编写工作过程和大型团队中用例收集的建议

  一.实际编写用例,每个开发组都应该形成并制定一套工作习惯,一种好的方式是由开发组和个人分工合作,因为组比个人有两个优点,一是便于集中讨论,二是便于对于问题达成共识,下面是整个工作过程.

    第一阶段：制定 粗略的系统功能图

        1、对系统的叙述达成共识（开发组）

        2、对应用领域达成共识，集中讨论系统主执行者和系统目标（开发组）

        3、编写系统描述（个人）

        4、收集各种系统描述（开发组）

        第一阶段工作完成，团队应向投资方发送以分系统叙述，显示新系统草图，应该包括以下各项：

• 系统的构想陈述
• 列出哪些在领域中，哪些不在领域中（包括设计和功能范围）
• 在执行环境中的草图
• 关键的主执行者列表
• 项目相关人员及其相关利益列表
• 最重要用户列表
• 系统的描述集（至少半页）

    第二阶段：执行详细用例视图

        1、集中研讨用例编写（开发组）

        2、对用例编写格式达成共识（开发组）

        3、编写用例（个人）

        4、审核用例

 

二.从庞大,不同层次的团队收集用例(Andy Kraus)

1. 不要忽略对会议场所的选择.
2. 没有适合的人就找不到正确的用例.
3. 与小团队相比,大团队更难一致.
4. 每次与用户开会不要超过半个工作日.
5. 与管理者同舟共济
6. 在提取用例时负责系统结构的人应该在场.
7. 如果让支持取代原系统的人参加会议就有一个达到目的的好机会
8. 没有什么可以代替用例涉及的"真正用户"
9. 使用抄写员(会议记录)
10. 及时显示已建立用例来加速用例提取过程
11. 一项工作的标题不是也给执行者
12. 应用程序不关心你是谁,只关心你戴的帽子
13. 在执行者初始编制过程,寻找遗漏的执行者.
14. "日常工作用例"促进了获取用例的讨论
15. 不要急于求成
16. 期望陷入困境;讨论的催化剂
17. 用例提取是一项社会活动
18. 标准的"描述符"有利于简化过程
19. 构造,维护,显示前置条件列表
20. 作最小主义者:尽可能使你的用例模板最小