定义项目
- 开发任何应用程序的第一步是通过分析定义用途、范围及目标
- 定义项目是项目经理、商业逻辑分析员及最终用户的工作，技术架构师并不直接参与
- 架构师的责任是确保项目的定义中有足够的连贯性，实际设计及实现时有足够的细节
- 架构师必须要有分析技能，否则不能识别项目定义中的弱点及缺口
- 在分析过程中，用例是一项重要的工具
- 用户界面原型可帮助精化用例
识别项目范围
- 在用例分析前对项目作出一个高层次的项目定义及对范围有初步的构想是需要的， 配合使用原型会更有效
- 高层次定义无需过于详细，它的用途只为确定用例分析的范围
例子：建立一个协助项目经理计划任务，跟踪所有组成员活动及评估完成日期的系统。这个程序可以允许用户完成以下的工作：
- 定义项目及它的任务
- 记录被分配入项目的人的任务及估计完成每项任务所需的时间
- 记录任务被完成的次序
- 记录项目进展及标记已完成任务
- 自动安排项目进度表
- 建立项目进展报告
识别参与者
- 用例分析的第一步是识别参与者
- 参与者可以是用户或外部服务系统，或受影响的用例
- 一个使用者可能同代表数个参与者
- 考虑在大型应用程序中加入应用程序管理员作为参与者
- 确保所有参与者都是直接使用系统的
- 由一个小组识开始别参与者会更便利
编写用例
- 一个用例是对参与者使用系统的描述
- 应以商业述语编写用例，应做到任何一个商业方人员无传释或技术术语表而可明白其中内容。否则，这表明在编写用例时已对所开发的程序有了技术上的假设
- 用例可充当为商业及开发方之间的非正式的合约，表明将会交付一套怎样的系统
- 用例应以“本系统（或本应用程序）将会”开始。如果发现不能以这种语句开始的话，很可能这只是另一个用例的其中一部份
- 用例通常牵涉多个参与者，应在用列中列出所有受影响的参与者
- 并无规则规定一个用例有多长，越详细越好。有不超过两句作为概要更佳
- 避免使用用例图，只会浪费时间
- 编写用例时需要商业方的深入参与
- 以一个小组展开用例分析
- 可考虑将用例加入数据库中管理
- 在用例讨论时， 征召某人作为记录员
- 当有更多资料时，修改现时用例
- 当组成员感觉已有足够资料可以评估每个用例实施所需时间，用例分析可以结束
- 确保包括有安全、可扩展性及可用性方面的需求
- 当有需求有涵接问题时不要慢下来，作假设然后继续。对方有责任告诉你是什么地方错了及应如何更正。（对此点有保留，如果只是一个独立的问题可以这样处理，但很可能其它的用例会依赖于这个用例，最好还是先搞清楚需求再作分析）
例子：一个报表系统的用例
- 本系统将提供一个界面以接受由现存MVS/CICS应用程序生成报表模板定义
- 本系统将允许应用程序管理员控制受信任的客户机构成员使用报表模板
- 本系统将在运行报表时至少达到原系统的平均速度
- 本系统将会限制所有受信任的客户用户只可接收到该受信任用户所属机构的数据
- 本系统将会允许银行支持客户使用来自任何受信任客户机构的数据执行所有报表模板
常见错误
- 强加技术设计的假设作为需求
- 包含实际设计在用例中
- 分析会议效率不能保持，如无人主导、过于细节的讨论、资料不足等
- 用例没有文档化
- 在每个用例都重复定义术语