2.1 用例描述事物本质，与界面无关
用例描述，关注参与者的目标，而不是实现界面这类细节
1）洞察“the goal of the goal ”
Example, “Log on”, 收银员在想着 GUI, dialog box, user ID, and password
但这是一种实现机制, 不是目标, 目标是验证收银员的身份
系统分析师得出 ”与实现机制无关”的目标
“能够标识我的身份，并得到授权”
或者更高的目标 “能够防止小偷非法进入…"
2）描述事物本质 essential style , 与用户界面无关
例如, 用例“Manage Users”
1、管理员标识自己的身份 Administrator identifies self
2、系统对此身份进行认证 System authenticates identity…
针对这种描述, 今后的设计可以非常灵活
生物信息读取GUI 、指纹识别等
3）比较另一种描述：具体化风格 Concrete Style
…
1、管理员在对话框中输入ID和密码（见图3)
2、系统对管理员进行认证
3、系统显示“编辑用户”窗口（见图4）
…
这种方式可以用, 但尽量不要在需求分析的早期! 为什么？
2.2 用例描写要简洁
有人喜欢阅读大量的需求吗？
例如，保险公司的合同文本
用例描述应该“用词简洁”
“系统认证…” 、“这个系统认证… ” 哪个简洁 ？
2.3 把用例视作“黑盒”
“黑盒”用例描述 Black-Box Use Cases
通过职责来描述用例，不描述系统内部是如何工作的、内部有哪些构件等
do not describe the internal workings of the system, its components, or design
即，描述系统应该完成那些功能，但不去描述系统是如何完成这些功能的
2.4 从参与者及其目标的角度进行描述
根据用例的定义
系统执行一系列动作，产生对参与者有价值的结果
关注系统的参与者来编写需求，询问他们的目标和典型场景
聚焦于如何理解参与者的“有价值的结果”，而不是开发人员认为的“价值”
小结 用例描述
用例描述很重要、也很难
“口袋技能”、“软技能”
文字表达能力
沟通交流能力
领域问题的理解能力 .
归纳、抽象能力
写作态度
错别字
句子
标点符号