一.实际编写用例,每个开发组都应该形成并制定一套工作习惯,一种好的方式是由开发组和个人分工合作,因为组比个人有两个优点,一是便于集中讨论,二是便于对于问题达成共识,下面是整个工作过程.
第一阶段：制定 粗略的系统功能图
1、对系统的叙述达成共识（开发组）
2、对应用领域达成共识，集中讨论系统主执行者和系统目标（开发组）
3、编写系统描述（个人）
4、收集各种系统描述（开发组）
第一阶段工作完成，团队应向投资方发送以分系统叙述，显示新系统草图，应该包括以下各项：
-
系统的构想陈述
-
列出哪些在领域中，哪些不在领域中（包括设计和功能范围）
-
在执行环境中的草图
-
关键的主执行者列表
-
项目相关人员及其相关利益列表
-
最重要用户列表
-
系统的描述集（至少半页）
第二阶段：执行详细用例视图
1、集中研讨用例编写（开发组）
2、对用例编写格式达成共识（开发组）
3、编写用例（个人）
4、审核用例
二.从庞大,不同层次的团队收集用例(Andy Kraus)
-
不要忽略对会议场所的选择.
-
没有适合的人就找不到正确的用例.
-
与小团队相比,大团队更难一致.
-
每次与用户开会不要超过半个工作日.
-
与管理者同舟共济
-
在提取用例时负责系统结构的人应该在场.
-
如果让支持取代原系统的人参加会议就有一个达到目的的好机会
-
没有什么可以代替用例涉及的”真正用户”
-
使用抄写员(会议记录)
-
及时显示已建立用例来加速用例提取过程
-
一项工作的标题不是也给执行者
-
应用程序不关心你是谁,只关心你戴的帽子
-
在执行者初始编制过程,寻找遗漏的执行者.
-
“日常工作用例”促进了获取用例的讨论
-
不要急于求成
-
期望陷入困境;讨论的催化剂
-
用例提取是一项社会活动
-
标准的”描述符”有利于简化过程
-
构造,维护,显示前置条件列表
-
作最小主义者:尽可能使你的用例模板最小
原文地址：http://www.cnblogs.com/mach-arch/p/16922517.html
1. 本站所有资源来源于用户上传和网络，如有侵权请邮件联系站长！
2. 分享目的仅供大家学习和交流，请务用于商业用途!
3. 如果你也有好源码或者教程，可以到用户中心发布，分享有积分奖励和额外收入！
4. 本站提供的源码、模板、插件等等其他资源，都不包含技术服务请大家谅解！
5. 如有链接无法下载、失效或广告，请联系管理员处理！
6. 本站资源售价只是赞助，收取费用仅维持本站的日常运营所需！
7. 如遇到加密压缩包，默认解压密码为"gltf",如遇到无法解压的请联系管理员！
8. 因为资源和程序源码均为可复制品，所以不支持任何理由的退款兑现，请斟酌后支付下载
声明：如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性
